Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nits: spellcheck #113

Merged
merged 2 commits into from
Jul 11, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 6 additions & 6 deletions draft-ietf-quic-version-negotiation.md
Original file line number Diff line number Diff line change
Expand Up @@ -118,7 +118,7 @@ versions are compatible.
The client initiates a QUIC connection by choosing an initial version and
sending a first flight of QUIC packets with a long header to the server {{INV}}.
The client's first flight includes Version Information (see {{vers-info}}) which
will be used to optionally enable compatible version negotation (see
will be used to optionally enable compatible version negotiation (see
{{compat-vn}}), and to prevent version downgrade attacks (see {{downgrade}}).

Upon receiving this first flight, the server verifies whether it knows how to
Expand Down Expand Up @@ -254,7 +254,7 @@ If the server does not find a compatible version (including the client's chosen
version), it will perform incompatible version negotiation instead, see
{{incompat-vn}}.

Note that it is possible to have incompatible version negotation followed by
Note that it is possible to have incompatible version negotiation followed by
compatible version negotiation. For instance, if version A is compatible with B
and C is compatible with D, the following scenario could occur:

Expand Down Expand Up @@ -429,7 +429,7 @@ client sends a first flight using them.
Offered Versions:
: This is the set of versions that a given server instance will send in a
Version Negotiation packet if it receives a first flight from an unknown
version. This set will most often be equal to the Acceptaple Versions set,
version. This set will most often be equal to the Acceptable Versions set,
except during short transitions while versions are added or removed (see below).

Fully-Deployed Versions:
Expand Down Expand Up @@ -545,9 +545,9 @@ compatible and incompatible) interacts with retry during a handshake that
requires both. For example, that could be accomplished by having the server send
a Retry packet in the original version first thereby validating the client's IP
address before attempting compatible version negotiation. If both versions
support authenticating Retry packets, the compatibility defition needs to define
how to authenticate the Retry in the negotiated version handshake even though
the Retry itself was sent using the client's chosen version.
support authenticating Retry packets, the compatibility definition needs to
define how to authenticate the Retry in the negotiated version handshake even
though the Retry itself was sent using the client's chosen version.


## Interaction with TLS resumption
Expand Down