Draft: draft-ietf-quic-version-negotiation

Commentary: This draft talks about clients and servers " thinking " and " believing " things . Those verbs do n't necessarily apply to protocol implementations , no matter what new frontiers we 're exploring in the machine learning space . Might be worth a pass to rephrase these in terms of client or server capabilities and information . " Know " is a little fuzzier , since an endpoint does in fact possess information at certain points in the process . 
 So ... when my computer says " thinking ... " , are you saying it 's lying to me ?
When the server can parse the client's first flight using the
original version, it can extract the client's Version Information
structure (see vers-info).  This contains the list of versions that
the client thinks its first flight is compatible with.
If the server supports one of the client's compatible versions, and
the server also believes that the original version is compatible with
this version, then the server converts the client's first flight to
that version and replies to the client as if it had received the
converted first flight.  The version used by the server in its reply
is refered to as the "negotiated version".  The server MUST NOT reply
with a version that is not present in the client's compatible
versions, unless it is the original version.
When the server can parse the client's first flight using the
original version, it can extract the client's Version Information
structure (see vers-info).  This contains the list of versions that
the client knows its first flight is compatible with.
If the server supports one of the client's compatible versions, and
the server also knows that the original version is compatible with
this version, then the server converts the client's first flight to
that version and replies to the client as if it had received the
converted first flight.  The version used by the server in its reply
is refered to as the "negotiated version".  The server MUST NOT reply
with a version that is not present in the client's compatible
versions, unless it is the original version.
If the Version Information was missing, the endpoints MAY complete
the handshake if they have reason to believe the peer might not
support this extension.  However, if a client has reacted to a
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
type VERSION_NEGOTIATION_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
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.
The client's first connection attempt SHOULD be made using the
version that the server is most likely to support.  The client
selects the version it believes to be best supported from the
versions that are compatible with the client's most preferred
version.  Without additional information this could mean selecting
the oldest version that the client supports.
The client's first connection attempt SHOULD be made using the
version that the server is most likely to support.  The client
selects the version most likely to be supported from the versions
that are compatible with the client's most preferred version.
Without additional information this could mean selecting the oldest
version that the client supports.