Strengthen 2119 language around tokens. #2124
Conversation
Rationale: 1. We should recommend that people use tokens. 2. Saying "SHOULD" attempt to validate seems weak. Why isn't this a MUST? This is the weakest of these changes, I think.
| @@ -1627,7 +1627,7 @@ interface. A client needs to start the connection process over if it migrates | |||
| prior to completing the handshake. | |||
|
|
|||
| When a server receives an Initial packet with an address validation token, it | |||
| SHOULD attempt to validate it, unless it has already completed address | |||
| MUST attempt to validate it, unless it has already completed address | |||
There was a problem hiding this comment.
MUST implies that it must fail if it cannot validate. During server cluster upgrades that might not be feasible. It could lead to consistent connection failures as long at the client has a token to try. It is in the servers interest to generally attempt validation so SHOULD seems reasonable to me.
There was a problem hiding this comment.
No that's not correct. The next sentence describes how to handle failures.
There was a problem hiding this comment.
Let's go back to 2119 definitions: Are there situations in which a server might choose not to validate? Will a failure to validate cause an interoperability problem?
There was a problem hiding this comment.
We also use MUST for security problems.
There was a problem hiding this comment.
There's an "unless" clause that captures the cases where a server won't validate, AFAICT. I'm ok with MUST here.
Also, the "it" is ambiguous. I would change the sentence to ".... MUST attempt to validate the token"
| @@ -1627,7 +1627,7 @@ interface. A client needs to start the connection process over if it migrates | |||
| prior to completing the handshake. | |||
|
|
|||
| When a server receives an Initial packet with an address validation token, it | |||
| SHOULD attempt to validate it, unless it has already completed address | |||
| MUST attempt to validate it, unless it has already completed address | |||
There was a problem hiding this comment.
We also use MUST for security problems.
| @@ -1610,7 +1610,7 @@ A resumption token SHOULD be constructed to be easily distinguishable from | |||
| tokens that are sent in Retry packets as they are carried in the same field. | |||
|
|
|||
| If the client has a token received in a NEW_TOKEN frame on a previous connection | |||
| to what it believes to be the same server, it can include that value in the | |||
| to what it believes to be the same server, it SHOULD include that value in the | |||
There was a problem hiding this comment.
I think that we need text on why it might not. I suspect that this is a MUST unless (sending from a new address) OR (you don't feel like it).
I think that the "can" is fine here.
There was a problem hiding this comment.
... or it dropped its store of tokens. SHOULD is useful in encouraging clients to do the performant thing -- use tokens unless they really can't.
There was a problem hiding this comment.
If we go with SHOULD, then we need to address the reasons that an endpoint might diverge from that. I realize that it's a cop-out, but "can" is so much easier.
martinthomson
added
editorial
|
Rebased and merged manually. |
Rationale:
MUST? This is the weakest of these changes, I think.