However, it was noted that nothing is specified what happens if the server party (in C-C) would send a token. Sending token in the INF regardless of client or server party means that the implementation can probably be simplified and needn't care about whether it's client or server.
That leaves the spec, which does not specify what should happen or if this should indeed be valid. I don't see any problems associated with allowing the server party to send the token, as well as I see no benefit (beyond allowing simplier implementations).
I would therefore propose that the server party may send a token, but that they "should not" (basically a discouragement). There are a few things that the receiving end can do (or what we can mandate);
* That it is unspeciifed what shall happen (leave things up to implementations; some may disconnect, some may do nothing, etc)
* Ignore the token (and its value).
* Make sure that the token is the same and valid, which is basically what the server party should do when it receives the INF
I generally prefer the second or third option, as the first gives too much leeway. The following is the third option and should be what the server party is required to do anyway.
Therefore, I propose the following would be added to the state management or CTM;
Also change the CTM text;The server party may, but should not, provide the token in its INF.
(Note that these changes would be included in a "ADC 1.0.3".)Implementations should not accept incoming connections with a token that was not sent earlier.