[dcc2] required tokens / options

[Theo Julienne]

Dan Smith wrote:

> What happens if the user could have accepted and choose not to?  could 
> the user give a reason in the reject errormessage for the rejection?  
> Would errortokens= exist in this case?

That would be very useful to stop the classic "Why is your client 
rejecting the file?" problem. At least any client using DCC2 would be 
able to auto-reject files with a reason, rather than just saying "No".

ErrorToken could be set so something like "UserDefined", specifying that 
it was not the tokens that caused the problem, but rather the user/client.

Possibly, there could be the option of customised error messages, or 
default ones. Say the error "None of the security protocols are 
supported" could be sent as CANTSECURE - then the client can write it's 
own text ( in the native language ). If the ErrorMessage contains 
quotes, it could then display that ( assuming it was a user/autoreject 
message ).

So something like:

 > DCC REJECT ErrorMessage="None of the security protocols is supported" 
ErrorToken=Security

Would instead be

 > DCC REJECT ErrorMessage=CANTSECURE ErrorToken=Security

If the client autorejects ans wants the remote user to see a standard 
message:

 > DCC REJECT ErrorMessage=BADFILENAME ErrorToken=File

Or, if the user wrote a customised message:

 > DCC REJECT ErrorMessage="Sorry, I don't trust you :-)" 
ErrorToken=UserDefined

An ErrorToken of UserDefined could mean that the user rejected it.

Some possible standard reasons could be:

CANTSECURE = "The remote client could not accept any of the security 
protocols offered"
BADFILENAME = "The remote client rejected the send based on the filename"
BLACKLIST = "The remote user rejected the send because you are on 
his/her dcc blacklist"
TURNOFF = "The remote user has chosen not to accept any DCC sends"

---
Kind Regards,

Theo Julienne
http://www.bersirc.com/