[dcc2] required tokens / options
Szymon Stefanek
pragma at kvirc.net
Thu Feb 12 19:12:19 EST 2004
On Thursday 12 February 2004 16:53, Dan Smith wrote:
> 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.
Marking tokens as required makes the protocol extensible.
Otherwise we will never be able to add tokens without breaking clients compatibility.
A short example will make the things clear.
- We release the 1.0 draft specifying tokens SSLv2 and SSLv3 as encryption methods.
- Client A and client B implement the protocol specification
- We release the 2.0 draft adding SSLv4 as encryption method.
- Client A implements the 2.0 protocol, client B doesn't (or an user has just an old version).
- Client A sends a request to client B specifying SSLv4 as encryption method.
- Client B is forced to refuse the message since it doesn't know the SSLv4 token at all
and thus it can't determine if the token means something "required" or not.
With something similar to the Option=A,B,C and Required=E,F all the tokens
appearing in the Option= part are optional: the receiver can even ignore their meaning.
This means that not only we can add new optional tokens in the standard, the clients
can add them "silently" too.
Adding non-standard tokens should be obviously discouraged but could also be a method
for the developers of pointing out the protocol omissions.
--
Szymon Stefanek
------------------------------------------------------------------------------
-
- Tried anarchy, once. Found it had too many constraints.
-
------------------------------------------------------------------------------
More information about the dcc2
mailing list