Original text:
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 <del> 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: In most cases, this field will be equal to the value of the Version field in the long header that carries this data. <del> The contents of the "Other Versions" field depends on whether it is </del>  sent by the client or by the server. <del> When sent by a client, the "Other Versions" field lists all the </del>  versions that this first flight is compatible with, ordered by <del> 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 </del>  preference is only advisory, servers MAY choose to use their own preference instead. <del> When sent by a server, the "Other Versions" field lists all the </del>  Fully-Deployed Versions of this server deployment, see server- <del> fleet.  Note that the version in the "Chosen Version" field is not </del>  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. Clients and servers MAY both include versions following the pattern <del> "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. </del>  6. 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>  If the Version Information was missing, the endpoints MAY complete the handshake if they have reason to believe the peer might not Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of <del> type "VERSION_NEGOTIATION_ERROR". </del>  If the client received and acted on a Version Negotiation packet, the <del> client MUST validate the server's "Other Versions" field.  The "Other Versions" field is validated by confirming that the client would have </del>  attempted the same version with knowledge of the versions the server supports.  That is, the client would have selected the same version if it received a Version Negotiation packet that listed the versions <del> in the server's "Other Versions" field, plus the negotiated version. </del>  If the client would have selected a different version, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type <del> "VERSION_NEGOTIATION_ERROR".  This connection closure prevents an </del>  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 </del>  downgrade.  Downgrade prevention also depends on the client ignoring Version Negotiation packets that contain the original version; see incompat-vn. After the process of version negotiation in this document completes, the version in use for the connection is the version that the server <del> sent in the "Chosen Version" field of its Version Information.  That </del>  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

Reviewer comments:
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them

Revised text:
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  <ins> 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: In most cases, this field will be equal to the value of the Version field in the long header that carries this data.  <ins> The contents of the Other Versions field depends on whether it is </ins> sent by the client or by the server.  <ins> When sent by a client, the Other Versions field lists all the </ins> versions that this first flight is compatible with, ordered by  <ins> 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 </ins> preference is only advisory, servers MAY choose to use their own preference instead.  <ins> When sent by a server, the Other Versions field lists all the </ins> Fully-Deployed Versions of this server deployment, see server-  <ins> fleet.  Note that the version in the Chosen Version field is not </ins> 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. Clients and servers MAY both include versions following the pattern  <ins> 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. </ins> 6. 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. </ins> If the Version Information was missing, the endpoints MAY complete the handshake if they have reason to believe the peer might not Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of  <ins> type VERSION_NEGOTIATION_ERROR. </ins> If the client received and acted on a Version Negotiation packet, the  <ins> client MUST validate the server's Other Versions field.  The Other Versions field is validated by confirming that the client would have </ins> attempted the same version with knowledge of the versions the server supports.  That is, the client would have selected the same version if it received a Version Negotiation packet that listed the versions  <ins> in the server's Other Versions field, plus the negotiated version. </ins> If the client would have selected a different version, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type  <ins> VERSION_NEGOTIATION_ERROR.  This connection closure prevents an </ins> 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 </ins> downgrade.  Downgrade prevention also depends on the client ignoring Version Negotiation packets that contain the original version; see incompat-vn. After the process of version negotiation in this document completes, the version in use for the connection is the version that the server  <ins> sent in the Chosen Version field of its Version Information.  That </ins> 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