[dcc2] required tokens / options

[Dan Smith]

Hi Szymon :)

At 02:04 PM 2/24/2004 +0100, you wrote:

>At this point I'd drop the "NONE" security option from the above examples 
>since
>         Security=NONE,A is equivalent to Security*=A

Good idea


>A thought about the "*" character:

Yeah, we should pick a character that doesn't have to be escaped, or 
escaped in regex expressions.  Doesn't really matter which character, as 
long as it isn't used in the token name [A-Z0-9].


>Another thought about the "CANNOTACCEPT" message.
>I suggest changing the message name in "REJECT" since it better describes 
>all the possible conditions.
>A nice idea could be to define an ErrorMessage=<description> token to 
>provide the users with some feedback
>about why the negotiation failed.
>
>More speculations:
>I can also think of some sort of automated recovery of failed transactions.
>The rejecting client could optionally add an ErrorToken=<token> specifying 
>the token that has causes
>the request to be rejected. This could allow the offering client to take 
>actions in order to restart the
>negotiation after adjusting the parameters and maybe informing the user.
>For example:
>A--->B: DCC SEND File=<filehandle> Security=SSLv2 ....
>B--->A: DCC REJECT ErrorMessage="None of the security protocols is 
>supported" ErrorToken=Security
>Client A asks the user: "The remote client didn't support the requested 
>encryption protocol, do you want the file to
>be transmitted without encryption ?"
>If the user accepts a non-secure transmission then the negotiation 
>restarts without the mandatory Security token.


That is a good point!  we really don't address anything about failure 
yet.  Here are some questions.

Multiple Failures:

What happens if more than one required token fails?  Perhaps a comma 
delimited list of errortoken='s, or just the tokens themselves as REJECT 
tokens?

Error Message:

I think that the errormessage= should be thought about more.  What about 
internationalization?  I suppose the clients could just infer an error 
message based on the errortoken(s) that were sent back and ignore the 
errormessage= ?


User Rejection:

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?


>Yet more thoughts:
>It is really common for IRC clients to ignore the rejected DCC/CTCP request.
>The draft should explicitly encourage the clients to reply with the REJECT 
>message unless they are really flooded with
>the requests (in fact the clients should have a message queuing algorithm 
>that would forbib


Yeah, that would be nice, but not all clients implement rate limiting.  We 
should not force an automated response to a message the client receives due 
to the nature of irc and "flooding".  I think the strongest wording we 
could have is: "should" send the response and "may" be silently ignored.

All this means is that a client can not rely on receiving a reject message.



Cheers!
Dan



Dan Smith
+1 608-213-2867
Algenta Technologies, LLC