LGTM. David On Wed, Mar 1, 2023 at 9:46 AM Martin Duke <[email protected]> wrote:
> Hello all, > > I'm going through the final step for publishing RFC9369 (QUICv2) [ > https://www.rfc-editor.org/authors/rfc9369.html] and my reading of it > finds something that is just the tiniest bit ambiguous. > > In Section 5: > Clients MUST NOT use a session ticket or token from a QUIC version 1 > connection to initiate a QUIC version 2 connection, and vice versa. > > My intent was that in the following sequence: > > - Client sends initial with v1; > - Server replies with v2 (compatible VN) > - Server sends resumption and NEW_TOKEN tokens > > that those tokens are considered to be v2 tokens, so they can only be used > if the subsequent connection with the client has a v2 Initial. > > Does anyone disagree with that interpretation? I'd like to change the > first paragraph of Section 5 as follows: > > OLD: > TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version > of the connection that provided them. Clients MUST NOT use a session ticket > or token from a QUIC version 1 connection to initiate a QUIC version 2 > connection, and vice versa. > > NEW: > TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version > of the connection that provided them. Clients MUST NOT use a session ticket > or token from a QUIC version 1 connection to initiate a QUIC version 2 > connection, and vice versa. When a connection includes compatible version > negotiation, any server tokens are considered to originate from the > negotiated version, not the original one. > > Martin > > > >
