[dcc2] required tokens / options

[Dan Smith]

>Immediately a couple of considerations:
>
>One usually *requires* the connection to be encrypted. In fact, this is 
>probably the most common case.
>There should be a way to specify mandatory and non mandatory options. A 
>first solution might be:
>
>         DCC2 Cmd=SEND Sid=1234 File=filehandle Size=1234 
> Options=IPv4,IPv6 Require=SSLv2,NAT
>         "The sender requires the connection to be encrypted with SSLv2 
> and asserts that it is unable to listen"

That is a good point about required options, and it currently isn't 
addressed for encryption! The current draft only stats SSL3 and TLS1 are 
valid types of connections (which is a glaring omission, sorry!).  This 
could be solved by defining the connection more precisely.  We could define 
a token for a non encrypted connection, NOCRYPT for example.

Then when a user initiates a DCC2 negotiation, they can mix and match which 
types they will accept.  To make encryption mandatory, they could include 
their supported encryption protocols and no NOCRYPT token.

Example with mandatory encryption:
DCC2 connection type=ircchat ipv4 ipv6 ssl2 tls1

Example with optional encryption:
DCC2 connection type=ircchat ipv4 ipv6 nocrypt ssl2 tls1

If the receiving client is unable to support the required encryption, it 
could then send back a CANNOTACCEPT message (or silently ignore).  I think 
this fits in more closely with the publish-negotiate paradigm.  Boolean 
tokens such as NAT are self described as a "required" token for connection, 
and tokens in a options group can become required by not publishing the 
other options.  Can anyone think of any cases that would require explicit 
"required" tokens?  If so, then we should look into a nomenclature for 
marking a token as required.

Cheers!
Dan

---------------------------
Dan Smith (dan at algenta.com)
+1 608-213-2867
Algenta Technologies, LLC