jiebi/TextFlow huggingface dataset:
Original text:
QUIC version 1, that connection closure MUST use a transport error of type TRANSPORT_PARAMETER_ERROR.  If the Version Information was missing, the endpoints MAY complete the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the <del> client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR. </del>  If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other if it received a Version Negotiation packet that listed the versions in the server's Other Versions field, plus the negotiated version. If the client would have selected a different version, the client <del> MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR.  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </del>  This validation of Other Versions is not sufficient to prevent downgrade.  Downgrade prevention also depends on the client ignoring

Reviewer comments:
Defining an error code for QUICv1 is good, but I think that you need to frame this differently. It probably needs to be framed in terms of a requirement on all QUIC versions. So rather than: You might say something like:
I like this. Can you make it a PR?

Revised text:
QUIC version 1, that connection closure MUST use a transport error of type TRANSPORT_PARAMETER_ERROR. <ins> Every QUIC version that supports version negotiation MUST define a method for closing the connection with a version negotiation error. For QUIC version 1, version negotiation errors are signaled using a transport error of type VERSION_NEGOTIATION_ERROR; see iana-error. </ins> If the Version Information was missing, the endpoints MAY complete the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the  <ins> client MUST close the connection with a version negotiation error. </ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other if it received a Version Negotiation packet that listed the versions in the server's Other Versions field, plus the negotiated version. If the client would have selected a different version, the client  <ins> MUST close the connection with a version negotiation error.  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </ins> This validation of Other Versions is not sufficient to prevent downgrade.  Downgrade prevention also depends on the client ignoring
Original text:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not.  4. This document specifies two means of performing version negotiation:

Reviewer comments:
Two versions might be compatible in the sense that one can convert the Initial Packet from one into the other. But one version might not have the features necessary for an application. There are two ways to mediate this that I can see: 1) The client excludes compatible versions that are inadequate for the app from its TP. This means the QUIC API will need a way for applications to control the advertised versions. 2) Servers understand what capabilities are needed and will not select an advertised compatible version that does not support them. For incompatible VN, if the server can identify the application based on IP and port, it might scrub irrelevant versions from its VN packet, though I don't know if that's a good idea or not.
When MsQuic implemented this extension, we exposed a configuration option to the app for it to specify its "desired version list". My expectation is that a client would include all acceptable QUIC versions here, and then adapt (if necessary) their protocol layer accordingly. Though, this might get harry, for instance, if they need to then choose a different ALPN based on the negotiated QUIC version (we don't currently support that).
NAME you're describing an implicit assumption of the draft: the list of supported versions are specific to an application, not just to an implementation. Perhaps we can add a sentence to make that more obvious, such as Servers don't need to do anything here, it's the client's responsibility to know what it wants to do with a given connection, not the server's.
Yes NAME that works for me. The real issue is that this not totally internal to the QUIC implementation and there needs to be an API for the application to manage this.
I agree that such an API is reasonable (Google QUICHE provides one for example) but I think that's out of scope for this document though.
I agree you shouldn't define the API, but it would be good to say, "hey, dummy, don't just advertise every compatible version the QUIC implementation supports"
Note that the relationship between version selection and ALPN is similar to the aftereffects of HTTP/2, which made the cipher selection and ALPN selection within TLS interdependent. That was a pain. It doesn't affect this draft per se, but I do hope we don't paint ourselves into that particular corner again.

Revised text:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support the intended application layer protocol. </ins> 4. This document specifies two means of performing version negotiation:
Original text:
version such that commonly deployed versions are compatible with it. For example, a successor to QUIC version 1 may wish to design its transport parameters in a way that does not preclude compatibility. <del> Additionally, frames in QUIC version 1 do not use a self-describing encoding, so unrecognized frame types cannot be parsed or ignored (see the Extension Frames section of QUIC); this means that new versions that wish to be very similar to QUIC version 1 and compatible with it should avoid introducing new frames in initial packets. </del> 11.

Reviewer comments:
In : This is not an issue. If v2 defines a new frame type that can appear in Initial-equivalent packets, then to be compatible with v1 (in both directions) that frame type could simply be optional in v2. The lack of a self-describing encoding is not an issue as the parsing of the v2 packet is done with knowledge of all the core frame types in v2. Sure, you can't introduce an extension frame here, but that's true of v1 on its own. The only way in which a version might become incompatible is if it includes new information that can't be inferred from the other version or doesn't have a valid default. I think that the intent of this was to say that if there is any need for the Initial flight to carry new information that is only consumed by a compatible version, then there is no way for QUIC version 1 to carry that new information by using new frames. Instead, it has to use a field in v1 that would be ignored by a v1 endpoint. As v1 defines no real extension points of this sort, the options in this case are limited. I think that this text can be removed. Maybe you could talk about the problem of carrying version-specific information in other versions.
This makes sense. This text was somewhat vestigial from earlier designs of this mechanism.

Revised text:
version such that commonly deployed versions are compatible with it. For example, a successor to QUIC version 1 may wish to design its transport parameters in a way that does not preclude compatibility.  11.
Original text:
5. During the handshake, endpoints will exchange Version Information, <del> which is a blob of data that is defined below.  In QUIC version 1, the Version Information is transmitted using a new transport parameter, version_information.  The contents of Version Information are shown below (using the notation from the "Notational Conventions" section of QUIC): </del>  The content of each field is described below:

Reviewer comments:
I think that the answer is "no" (see also Betteridge's Law) in that the format is version-specific, but is pretty obtuse about this: The first sentence reads as an absolute; the second is clearly narrowly scoped. But then nothing is said about other versions. As I mentioned with error codes in , I think that the way this needs to be phrased is as a requirement on QUIC versions that support version negotiation. The requirement is that those protocols need to define a way to carry certain information. You can then define that information in the abstract when articulating that requirement; again see . The concrete form you choose for v1 then only needs to apply to v1.
The intention was for the handshake version information to be invariant, and for how it is conveyed to be version-specific. But I agree that we should state that versions need an authenticated way to exchange handshake version information.
It needs to go further than that. I think that you need to list, concretely, what information is being authenticated. And you need to explain the consequences, namely: And then in Section 4, say precisely what information needs to be authenticated in order to achieve this goal, with a concrete definition for how the information is carried in QUIC version 1 transport parameters.
That works for me.

Revised text:
5. During the handshake, endpoints will exchange Version Information,  <ins> which consists of a chosen version and a list of other versions.  Any version of QUIC that supports this mechanism MUST provide a mechanism to exchange Version Information in both directions during the handshake, such that this data is authenticated. In QUIC version 1, the Version Information is transmitted using a new transport parameter, version_information.  The contents of Version Information are shown below (using the notation from the "Notational Conventions" section of QUIC): </ins> The content of each field is described below:
Original text:
will perform incompatible version negotiation instead, see incompat- vn. <del> For the duration of the compatible version negotiation process, clients MUST use the same 5-tuple (source and destination IP addresses and UDP port numbers).  During that time, clients MUST also use the same Destination Connection ID, except if the server explicitly instructs the client to use a different Destination Connection ID (for example, a QUIC version 1 server can accomplish this by sending an INITIAL packet with a Source Connection ID that differed from the client's Destination Connection ID).  This allows load balancers to ensure that packets for a given connection are routed to the same server. </del>  5.

Reviewer comments:
indicates that the address tuple used for the first flight remain stable. This is probably OK, but I think that this is unnecessary. What seems particularly risky here is anticipating the rules about connection IDs that might apply to both versions: My preference here is to drop this text entirely and leave it to the negotiated version to specify these rules. Once you have performed whatever mapping/transformation that is defined, then the first flight complies with the requirements of the negotiated version and you are subject to the rules of that version. Trying to manage the intersection of both sets of rules is complicated. Better not to chase down that rabbit hole (I've been there). FWIW, I fully expect v2 to also specify address tuple stability during the handshake. However, if it does not and a client can send a v2 first flight on multiple tuples (leaving aside the implausibility of expecting those datagrams to arrive at the same place), then that won't be naturally compatible with v1 and you won't be able to start with v2 in that way and expect to be able to negotiate v1 out of that. This is no different than your new, optional frame example.
I think we need to state something about 5-tuple stability here, because if version A requires 5-tuple stability and version B requires 5-tuple stability, neither of those documents specifies that the two halves of the handshake (the first half using A, and the second half using B) need 5-tuple stability between them.
I don't think that you need to say anything about that specifically. You might use it as an example in a sentence like:
Fair enough, that works for me.

Revised text:
will perform incompatible version negotiation instead, see incompat- vn.  <ins> Note that, after the first flight is converted to the negotiated version, the handshake completes in the negotiated version.  The entire handshake (including the converted first flight) needs to conform to the rules of the negotiated version.  For instance, if the negotiated version requires that the 5-tuple remain stable for the entire handshake (as QUIC version 1 does), then this applies to the entire handshake, including the first flight. </ins> 5.
Original text:
fleet.  Note that the version in the Chosen Version field is not necessarily included in this list, because the server operator could be in the process of removing support for this version.  For <del> the same reason, this field MAY be empty. </del>  Clients and servers MAY both include versions following the pattern 0x?a?a?a?a in their Other Versions list.  Those versions are reserved

Reviewer comments:
The draft says: Server-Sent Other Versions: When sent by a server, the Other Versions field lists all the Fully-Deployed Versions of this server deployment, see Section 2. Note that the version in the Chosen Version field is not necessarily included in this list, because the server operator could be in the process of removing support for this version. For the same reason, this field MAY be empty. But the syntax is: What does the draft exactly mean by "this field MAY be empty"?
The "Other Versions" field contains a list of versions, whose length can be zero. That text exists to remind people that the list of Fully-Deployed Versions can be empty, and that shouldn't cause handshake failures.
The text is far from clear, because the sentence mixes references to "Other Versions" and "Chosen version". Stating "For the same reason, the Other Versions field MAY be empty" would remove the ambiguity.
Thanks for clarifying, I've written that up as .

Revised text:
fleet.  Note that the version in the Chosen Version field is not necessarily included in this list, because the server operator could be in the process of removing support for this version.  For  <ins> the same reason, the Other Versions field MAY be empty. </ins> Clients and servers MAY both include versions following the pattern 0x?a?a?a?a in their Other Versions list.  Those versions are reserved
Original text:
entire handshake (as QUIC version 1 does), then this applies to the entire handshake, including the first flight.  5. During the handshake, endpoints will exchange Version Information,

Reviewer comments:
After pushback from NAME I think this covers the main point with a whole lot less text.
As discussed in URL, there are various levels of partial support for this standard, different for client and server, and there ought to be normative language around these capabilities. There are certain modes that MUST be supported along with multiple versions, and others that are just performance improvements. AFAICT, for any server that supports >1 versions, there are two possible levels of support: Send the TP and support incompatible negotiation Support compatible negotiation For a client, it's more complicated: NAME proposes: No support: do not the send nor parse the TP. If you get a VN packet, fail the QUIC connection Downgrade prevention only: send the TP with only one other version, also parse and validate the TP. If you get a VN packet, fail the QUIC connection. This protects against intermediaries that are rewriting the version field on Initial packets. In v1/v2, these attacks will be detected by the authenticated version field in subsequent handshake packets, but that is not generalizable to all versions of QUIC. Compatible only: downgrade prevention and be prepared to accept an upgrade Incompatible only: advertise only one version, so there's downgrade prevention when trying again with new version after a VN packet. Full: downgrade prevention, compatible VN and incompatible VN
LGTM

Revised text:
entire handshake (as QUIC version 1 does), then this applies to the entire handshake, including the first flight. <ins> Note also that the client can disable compatible version negotiation by only including the Chosen Version in the Other Versions field of the Version Information Transport Parameter. </ins> 5. During the handshake, endpoints will exchange Version Information,
Original text:
from version B.  As an example, if versions A and B are absolutely equal in their wire image and behavior during the handshake but differ after the handshake, then A is compatible with B and B is <del> compatible with A. </del>  Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with

Reviewer comments:
This is NAME 's proposed text to fix this issue.
LGTM. I am going to merge this on the basis of it being David's text and my approval.
LGTM
Section 9 is pretty clear that 'compatible versions' might not have commonly usable 0-RTT packets. But Section 3 defines 'compatible' as a translatable first flight. 0-RTT is part of the first flight, so one of these definitions has to change.
That doesn't necessarily follow. You can translate a first flight in a way that 0-RTT is rejected and the 0-RTT packets are just dropped and the handshake will still succeed. I'm not sure I see an inconsistency here.
Having read sec 3 a few times now, I see the subtlety in your point. 0-RTT could fall under the third paragraph as something that can't be included to be compatible. I still don't really like the definition. I'll think on it some more, but I'd prefer something like "A is said to be 'compatible' with B if the first flight of A contains all the information minimally necessary to complete a first flight of B." So to be compatible with v1 , vx needs to contain a TLS 1.3 client hello including TPs for version negotiation and all the other required v1 TPs. For v1 to be compatible with vx, v_x must not have any additional information to complete its first fligth besides the client hello at the v1 TPs. Whether or not there's 0-RTT in the flight doesn't matter. We are drifting into the editorial, but if you like that definition I'm happy to write a PR.
I'm not sure "minimally necessary" is well-defined. How about something like:

Revised text:
from version B.  As an example, if versions A and B are absolutely equal in their wire image and behavior during the handshake but differ after the handshake, then A is compatible with B and B is  <ins> compatible with A.  Note that the conversion of the first flight can be lossy: some data such as QUICv1 0-RTT packets could be ignored during conversion and retransmitted later. </ins> Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with
Original text:
When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that <del> support the intended application layer protocol. </del>  4.

Reviewer comments:
Mix recommendations of NAME and NAME
LGTM
The document currently says: However, as we see with HTTP over TCP, clients routinely offer "h2", "http/1.1" and are content with either selection. Particularly if ALPN tokens map 1:1 to QUIC versions as specified in H3, the client's goal might be to use any of a collection of application-layer protocols. Perhaps tweak this to "...support one of the intended application layer protocols."? The first statement might or might not need to be expanded as well.
Perhaps we add a sentence after the ones you quoted along the lines of "For example, if the client's first flight advertises multiple ALPN tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects."

Revised text:
When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that  <ins> support one of the intended application layer protocols.  For example, if the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) RFC7301 tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects. </ins> 4.
Original text:
if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of <del> type TRANSPORT_PARAMETER_ERROR. </del>  Every QUIC version that supports version negotiation MUST define a method for closing the connection with a version negotiation error.

Reviewer comments:
Should an endpoint be required to reject a transport parameter that contains 0?
Sure.
CC with ?
That's what I currently have in my implementation :)
Off topic but what if version 0 is included in Supported Version of a VN packet?
That would make the VN packet malformed. I'd suggest either dropping such packets or ignoring the zero.
OK. I modified my client to drop such packets as same as the case of the original version included.
I considered treating it as an error, but as it is an unauthenticated packet, it's better to drop it. I've done the same for ours.

Revised text:
if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of  <ins> type TRANSPORT_PARAMETER_ERROR.  If an endpoint receives a Chosen Version equal to zero, or any Other Version equal to zero, it MUST treat it as a parsing failure. </ins> Every QUIC version that supports version negotiation MUST define a method for closing the connection with a version negotiation error.