Change:
load balancers to ensure that packets for a given connection are routed to the same server. <del> 4. </del> <ins> 5. </ins> <del> During the handshake, endpoints will exchange handshake version information, which is a blob of data that is defined below.  In QUIC version 1, the handshake version information is transmitted using a new transport parameter, "version_negotiation".  The contents of handshake version information depend on whether the client or server is sending it, and are shown below (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> During the handshake, endpoints will exchange Version Information, 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): </ins> The content of each field is described below: <del> The version that the client is attempting to use.  This field MUST be equal to the value of the Version field in the long header that carries this data. If the client is sending this first flight in response to a Version Negotiation packet, this field contains the version that the client used in the previous first flight that triggered the version negotiation packet.  If the client did not receive a Version Negotiation packet, this field SHALL be all-zeroes. A variable-length integer specifying the number of Received Negotiation Version fields following it.  If the client is sending this first flight in response to a Version Negotiation packet, the subsequent versions SHALL include all the versions from that Version Negotiation packet in order, even if they are not supported by the client (even if the versions are reserved).  If the client has not received a Version Negotiation packet on this connection, this field SHALL be 0. A variable-length integer specifying the number of Compatible Version fields following it.  The client lists all versions that this first flight is compatible with in the subsequent Compatible Version fields, ordered by descending preference.  Note that the version in the Currently Attempted Version field MUST be included in the Compatible Version list to allow the client to communicate the currently attempted version's preference.  Note that this preference is only advisory, servers MAY choose to use their own preference instead. </del> <ins> The version that the sender has chosen to use for this connection. In most cases, this field will be equal to the value of the Version field in the long header that carries this data. </ins> <del> The content of each field is described below: </del> <ins> The contents of the "Other Versions" field depends on whether it is sent by the client or by the server. </ins> <del> The version that the server chose to use for the connection.  This field MUST be equal to the value of the Version field in the long header that carries this data. A variable-length integer specifying the number of Supported Version fields following it.  The server encodes all versions it supports in the subsequent list, ordered by descending preference. Note that the version in the Negotiated Version field MUST be included in the Supported Version list to allow the server to communicate the negotiated version's preference.  Note that this preference is only advisory, clients MAY choose to use their own </del> <ins> When sent by a client, the "Other Versions" field lists all the versions that this first flight is compatible with, ordered by descending preference.  Note that the version in the "Chosen Version" field MUST be included in this list to allow the client to communicate the chosen version's preference.  Note that this preference is only advisory, servers MAY choose to use their own </ins> preference instead. <del> Clients MAY include versions following the pattern "0x?a?a?a?a" in their "Compatible Version" list, and the server in their "Supported Version" list.  Those versions are reserved to exercise version negotiation (see the Versions section of QUIC), and will be ignored when parsing these fields.  On the other hand, the "Received Negotiation Version" list MUST be identical to the received Version Negotiation packet, so clients MUST NOT add or remove reserved version from that list. </del> <ins> When sent by a server, the "Other Versions" field lists all the Fully-Deployed Versions of this server deployment, see server- fleet. </ins> <del> 5. </del> <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 to exercise version negotiation (see the Versions section of QUIC), and will never be selected when choosing a version to use. 6. </ins> Clients MUST ignore any received Version Negotiation packets that contain the version that they initially attempted.  Once a client has reacted to a Version Negotiation packet, it MUST drop all subsequent Version Negotiation packets on that connection. <del> Servers MUST validate that the client's "Currently Attempted Version" matches the version in the long header that carried the handshake version information.  Similarly, clients MUST validate that the server's "Negotiated Version" matches the long header version.  If an endpoint's validation fails, it MUST close the connection.  If the connection was using QUIC version 1, it MUST be closed with a transport error of type "VERSION_NEGOTIATION_ERROR". When a server parses the client's handshake version information, if the "Received Negotiation Version Count" is not zero, the server MUST validate that it could have sent the Version Negotation packet described by the client in response to a first flight of version "Previously Attempted Version".  In particular, the server MUST ensure that there are no versions that it supports that are absent from the Received Negotiation Versions, and that the ordering matches the server's preference.  If this validation fails, the server MUST close the connection.  If the connection was using QUIC version 1, it MUST be closed with a transport error of type "VERSION_NEGOTIATION_ERROR".  This mitigates an attacker's ability to forge Version Negotiation packets to force a version downgrade. If a server operator is progressively deploying a new QUIC version throughout its fleet, it MAY perform a two-step process where it first progressively adds support for the new version, but without enforcing its presence in "Received Negotiation Versions".  Once all servers have been upgraded, the second step is to start enforcing that the new version is present in "Received Negotiation Versions". This opens connections to version downgrades during the upgrade window, since those could be due to clients communicating with both upgraded and non-upgraded servers. If an endpoint receives its peer's Handshake Version Information and fails to parse it (for example, if it is too short), then the endpoint MUST close the connection.  If the connection was using QUIC version 1, it MUST be closed with a transport error of type "TRANSPORT_PARAMETER_ERROR". 6. The server's "Supported Version" list allows it to communicate the full list of versions it supports to the client.  In the case where clients initially attempt connections with the oldest version they support, this allows them to be notified of more recent versions the server supports.  If the client notices that the server supports a version that is more preferable that the one initially attempted by default, the client SHOULD cache that information and attempt the preferred version in subsequent connections. </del> <ins> Both endpoints MUST parse their peer's Version Information during the handshake.  If the Version Information was missing or if parsing it failed (for example, 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 type "TRANSPORT_PARAMETER_ERROR". If a client has reacted to a Version Negotiation packet, it MUST validate that the server's "Other Versions" field does not contain the client's original version, and that the client would have selected the same negotiated version if it had received a Version Negotiation packet whose Supported Versions field had the same contents as the server's "Other Versions" field.  If any of these checks fail, the 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".  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. After the process of version negotiation in this document completes, the version in use for the connection is the version that the server sent in the "Chosen Version" field of its Version Information.  That remains true even if other versions were used in the Version field of long headers at any point in the lifetime of the connection; endpoints MUST NOT change the version that they consider to be in use based on the Version field of long headers as that field could be forged by attackers. </ins> 7.

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.