[dcc2] required tokens / options

[Dan Smith]

>
>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.


I have been thinking over the extensibility aspect of this token system 
that you raised, and I think your right again Szymon! There are four 
different types of tokens if we look at it this way:

1. A required choice.  The receiving client must choose one option from an 
enumeration.  The security layer or transport are examples of this: 
NONE,SSL3,TLS1 and IPv4,IPv6

2. An optional choice.  The receiving client chooses one option, but is not 
required.  We haven't defined any of these yet.

3. A required boolean.  The receiving client must support this token, NAT 
is an example.

4. An optional boolean.  The receiving client can choose to support this 
option.


Your idea for the Option= and Required= are good, and we can bring this 
down to the token level.  For example, instead of having several tokens for 
the security layer, we can have SECURITY=NONE,SSL3,TLS1 or 
TRANSPORT=IPV4,IPV6.  This would mark SECURITY as a choice between several 
options.  However, we still must mark it as required or optional.

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*

Do these four scenarios cover everything?  What are your thoughts?

Cheers!
Dan



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