[dcc2] required tokens / options

[Szymon Stefanek]

Sorry for the late reply, I've been just a bit too busy to think it out enough.

> Marking a token as optional could be as simple as appending a character,
> such as *, to the end of the token.  So for some examples of DCC2
> publication for 1-4 with the enumerations and optional markings:
>
> 1. SECURITY=NONE,SSL3,SSL2,TLS1
> 2. NEWTOKEN*=ONE,TWO,THREE
> 3. NAT
> 4. NEWTOKEN2*

Hm, so Security=A,B,C would mean: mandatory usage of security with one of the available protocols.
and Security=A,B,C would be just a listing of supported options. That sounds good :)

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

So finally the protocol should state explicitly that any token with the special character appended is optional
and clients *should* ignore it if it is not recognized.


A thought about the "*" character: maybe we should avoid *,?,^ and $ characters in the protocol specification
since they are commonly used for wildcard/pattern matching. The same applies to ",% and \ which are used
for string escaping/encoding. Maybe something like (Security)=A,B or Security+=A,B ?
I don't exactly know which character to suggest in place of "*", maybe we should conduct a survey ?
On the other hand, Security?=A,B would be really nice to seel.
Dunno, I've just thrown the ball :)

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.

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 forbid


-- 

Szymon Stefanek

------------------------------------------------------------------------------
-
- Energy of the gods, adrenaline surge
- Won't stop til I hit the ground, I'm on my way for sure
- Up here in the air, this will never hurt
- I'm on my way to impact, taste the high speed dirt
-
------------------------------------------------------------------------------