Draft: draft-ietf-quic-qpack

Commentary: There are a few manual tweaks here , but the first commit is strictly automated . 
 More of the same ; see . 
 This might even touch -transport as it turns out that  did n't catch 'em all . 
 I did a search through with a focus on , but intentionally kept some of the other formulations mid - sentence , etc . Also certainly may have missed a bunch !  is lacking some emojis I need here ... 
 Largely goodness ; a few quibbles .
Paragraph (version A):
If the dynamic table does not contain enough room for a new entry
without evicting other entries, and the entries which would be
evicted are not evictable, the encoder MUST NOT insert that entry
into the dynamic table (including duplicates of existing entries).
In order to avoid this, an encoder that uses the dynamic table has to
keep track of each dynamic table entry referenced by each header
block until that header block is acknowledged by the decoder (see
header-acknowledgement).
Paragraph (version B):
If the dynamic table does not contain enough room for a new entry
without evicting other entries, and the entries which would be
evicted are not evictable, the encoder MUST NOT insert that entry
into the dynamic table (including duplicates of existing entries).
In order to avoid this, an encoder that uses the dynamic table has to
keep track of each dynamic table entry referenced by each header
block until that header block is acknowledged by the decoder; see
header-acknowledgement.
Paragraph (version A):
While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, HTTP/3-specific settings are
conveyed in the SETTINGS frame.  After the QUIC connection is
established, a SETTINGS frame (frame-settings) MUST be sent by each
endpoint as the initial frame of their respective HTTP control stream
(see control-streams).
Paragraph (version B):
While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, HTTP/3-specific settings are
conveyed in the SETTINGS frame.  After the QUIC connection is
established, a SETTINGS frame (frame-settings) MUST be sent by each
endpoint as the initial frame of their respective HTTP control
stream; see control-streams.
Paragraph (version A):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
In general, a server is considered authoritative for all URIs with
the "https" scheme for which the hostname in the URI is present in
the authenticated certificate provided by the server, either as the
CN field of the certificate subject or as a dNSName in the
subjectAltName field of the certificate (see RFC6125).  For a host
that is an IP address, the client MUST verify that the address
appears as an iPAddress in the subjectAltName field of the
certificate.  If the hostname or address is not present in the
certificate, the client MUST NOT consider the server authoritative
for origins containing that hostname or address.  See Section 5.4 of
SEMANTICS for more detail on authoritative access.
Paragraph (version B):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
In general, a server is considered authoritative for all URIs with
the "https" scheme for which the hostname in the URI is present in
the authenticated certificate provided by the server, either as the
CN field of the certificate subject or as a dNSName in the
subjectAltName field of the certificate; see RFC6125.  For a host
that is an IP address, the client MUST verify that the address
appears as an iPAddress in the subjectAltName field of the
certificate.  If the hostname or address is not present in the
certificate, the client MUST NOT consider the server authoritative
for origins containing that hostname or address.  See Section 5.4 of
SEMANTICS for more detail on authoritative access.
Paragraph (version A):
A server that does not wish clients to reuse connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request (see Section 9.1.2 of HTTP2).
Paragraph (version B):
A server that does not wish clients to reuse connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 9.1.2 of HTTP2.
Paragraph (version A):
Pushed responses are sent on a server-initiated unidirectional QUIC
stream (see push-streams).  A server sends zero or more interim HTTP
responses, followed by a single final HTTP response, in the same
manner as a standard response.  Push is described in more detail in
server-push.
Paragraph (version B):
Pushed responses are sent on a server-initiated unidirectional QUIC
stream; see push-streams.  A server sends zero or more interim HTTP
responses, followed by a single final HTTP response, in the same
manner as a standard response.  Push is described in more detail in
server-push.
Paragraph (version A):
To ensure that the HTTP/1.1 request line can be reproduced
accurately, this pseudo-header field MUST be omitted when
translating from an HTTP/1.1 request that has a request target in
origin or asterisk form (see Section 3.2 of HTTP11).  Clients that
generate HTTP/3 requests directly SHOULD use the ":authority"
pseudo-header field instead of the Host field.  An intermediary
that converts an HTTP/3 request to HTTP/1.1 MUST create a Host
field if one is not present in a request by copying the value of
the ":authority" pseudo-header field.
Paragraph (version B):
To ensure that the HTTP/1.1 request line can be reproduced
accurately, this pseudo-header field MUST be omitted when
translating from an HTTP/1.1 request that has a request target in
origin or asterisk form; see Section 3.2 of HTTP11.  Clients that
generate HTTP/3 requests directly SHOULD use the ":authority"
pseudo-header field instead of the Host field.  An intermediary
that converts an HTTP/3 request to HTTP/1.1 MUST create a Host
field if one is not present in a request by copying the value of
the ":authority" pseudo-header field.
Paragraph (version A):
Contains the path and query parts of the target URI (the "path-
absolute" production and optionally a '?' character followed by
the "query" production (see Sections 3.3 and 3.4 of RFC3986).  A
request in asterisk form includes the value '*' for the ":path"
pseudo-header field.
Paragraph (version B):
Contains the path and query parts of the target URI (the "path-
absolute" production and optionally a '?' character followed by
the "query" production; see Sections 3.3 and 3.4 of URI.  A
request in asterisk form includes the value '*' for the ":path"
pseudo-header field.
Paragraph (version A):
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'.  The exception to this rule is an
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field
with a value of '*' (see Section 3.2.4 of HTTP11).
Paragraph (version A):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request (connect).
Paragraph (version B):
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'.  The exception to this rule is an
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field
with a value of '*'; see Section 3.2.4 of HTTP11.
Paragraph (version B):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request; see connect.
Paragraph (version A):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code (see Section 9 of SEMANTICS).  This
pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (malformed).
Paragraph (version B):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 9 of SEMANTICS.  This
pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (malformed).
Paragraph (version A):
The request stream remains open at the end of the request to carry
the data to be transferred.  A CONNECT request that does not conform
to these restrictions is malformed (see malformed).
Paragraph (version B):
The request stream remains open at the end of the request to carry
the data to be transferred.  A CONNECT request that does not conform
to these restrictions is malformed; see malformed.
Paragraph (version A):
Server push is only enabled on a connection when a client sends a
MAX_PUSH_ID frame (see frame-max-push-id).  A server cannot use
server push until it receives a MAX_PUSH_ID frame.  A client sends
additional MAX_PUSH_ID frames to control the number of pushes that a
server can promise.  A server SHOULD use Push IDs sequentially,
starting at 0.  A client MUST treat receipt of a push stream with a
Push ID that is greater than the maximum Push ID as a connection
error of type H3_ID_ERROR.
Paragraph (version B):
Server push is only enabled on a connection when a client sends a
MAX_PUSH_ID frame; see frame-max-push-id.  A server cannot use server
push until it receives a MAX_PUSH_ID frame.  A client sends
additional MAX_PUSH_ID frames to control the number of pushes that a
server can promise.  A server SHOULD use Push IDs sequentially,
starting at 0.  A client MUST treat receipt of a push stream with a
Push ID that is greater than the maximum Push ID as a connection
error of type H3_ID_ERROR.
Paragraph (version A):
The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative (see connection-reuse).
A client SHOULD send a CANCEL_PUSH frame upon receipt of a
PUSH_PROMISE frame carrying a request for which it does not consider
the server authoritative.  If the pushed response arrives on a push
stream, this MAY be treated as a stream error of type
H3_STREAM_CREATION_ERROR.
Paragraph (version B):
The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative; see connection-reuse.  A
client SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE
frame carrying a request for which it does not consider the server
authoritative.  If the pushed response arrives on a push stream, this
MAY be treated as a stream error of type H3_STREAM_CREATION_ERROR.
Paragraph (version A):
When a server later fulfills a promise, the server push response is
conveyed on a push stream (see push-streams).  The push stream
identifies the Push ID of the promise that it fulfills, then contains
a response to the promised request using the same format described
for responses in request-response.
Paragraph (version B):
When a server later fulfills a promise, the server push response is
conveyed on a push stream; see push-streams.  The push stream
identifies the Push ID of the promise that it fulfills, then contains
a response to the promised request using the same format described
for responses in request-response.
Paragraph (version A):
A client has more flexibility in the value it chooses for the Push ID
in a GOAWAY that it sends.  A value of 2^62 - 1 indicates that the
server can continue fulfilling pushes which have already been
promised, and the client can continue granting push credit as needed
(see frame-max-push-id).  A smaller value indicates the client will
reject pushes with Push IDs greater than or equal to this value.
Like the server, the client MAY send subsequent GOAWAY frames so long
as the specified Push ID is strictly smaller than all previously sent
values.
Paragraph (version B):
A client has more flexibility in the value it chooses for the Push ID
in a GOAWAY that it sends.  A value of 2^62 - 1 indicates that the
server can continue fulfilling pushes which have already been
promised, and the client can continue granting push credit as needed;
see frame-max-push-id.  A smaller value indicates the client will
reject pushes with Push IDs greater than or equal to this value.
Like the server, the client MAY send subsequent GOAWAY frames so long
as the specified Push ID is strictly smaller than all previously sent
values.
Paragraph (version A):
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
integer.  The Push ID identifies the server push that is being
cancelled (see frame-push-promise).  If a CANCEL_PUSH frame is
received which references a Push ID greater than currently allowed on
the connection, this MUST be treated as a connection error of type
H3_ID_ERROR.
Paragraph (version B):
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
integer.  The Push ID identifies the server push that is being
cancelled; see frame-push-promise.  If a CANCEL_PUSH frame is
received which references a Push ID greater than currently allowed on
the connection, this MUST be treated as a connection error of type
H3_ID_ERROR.
Paragraph (version A):
The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a Push ID that the server can use
(see frame-push-promise).  A MAX_PUSH_ID frame cannot reduce the
maximum Push ID; receipt of a MAX_PUSH_ID that contains a smaller
value than previously received MUST be treated as a connection error
of type H3_ID_ERROR.
Paragraph (version B):
The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a Push ID that the server can use;
see frame-push-promise.  A MAX_PUSH_ID frame cannot reduce the
maximum Push ID; receipt of a MAX_PUSH_ID that contains a smaller
value than previously received MUST be treated as a connection error
of type H3_ID_ERROR.
Paragraph (version A):
Because new error codes can be defined without negotiation (see
extensions), use of an error code in an unexpected context or receipt
of an unknown error code MUST be treated as equivalent to
H3_NO_ERROR.  However, closing a stream can have other effects
regardless of the error code (see request-response).
Paragraph (version B):
Because new error codes can be defined without negotiation (see
extensions), use of an error code in an unexpected context or receipt
of an unknown error code MUST be treated as equivalent to
H3_NO_ERROR.  However, closing a stream can have other effects
regardless of the error code; see request-response.
Paragraph (version A):
QUIC endpoints measure the delay incurred between when a packet is
received and when the corresponding acknowledgment is sent, allowing
a peer to maintain a more accurate round-trip time estimate (see
Section 13.2 of QUIC-TRANSPORT).
Paragraph (version B):
QUIC endpoints measure the delay incurred between when a packet is
received and when the corresponding acknowledgment is sent, allowing
a peer to maintain a more accurate round-trip time estimate; see
Section 13.2 of QUIC-TRANSPORT.
Paragraph (version A):
Endpoints stop sending and receiving Initial packets once they start
exchanging Handshake packets (see Section 17.2.2.1 of QUIC-
TRANSPORT).  At this point, recovery state for all in-flight Initial
packets is discarded.
Paragraph (version B):
Endpoints stop sending and receiving Initial packets once they start
exchanging Handshake packets; see Section 17.2.2.1 of QUIC-TRANSPORT.
At this point, recovery state for all in-flight Initial packets is
discarded.
Paragraph (version A):
It is expected that keys are discarded after packets encrypted with
them would be acknowledged or declared lost.  Initial secrets however
might be destroyed sooner, as soon as handshake keys are available
(see Section 4.10.1 of QUIC-TLS).
Paragraph (version B):
It is expected that keys are discarded after packets encrypted with
them would be acknowledged or declared lost.  Initial secrets however
might be destroyed sooner, as soon as handshake keys are available;
see Section 4.10.1 of QUIC-TLS.
Paragraph (version A):
An endpoint MUST NOT send a packet if it would cause bytes_in_flight
(see vars-of-interest) to be larger than the congestion window,
unless the packet is sent on a PTO timer expiration (see pto).
Paragraph (version B):
An endpoint MUST NOT send a packet if it would cause bytes_in_flight
(see vars-of-interest) to be larger than the congestion window,
unless the packet is sent on a PTO timer expiration; see pto.
Paragraph (version A):
A QUIC packet that contains frames other than ACK, PADDING, and
CONNECTION_CLOSE.  These cause a recipient to send an
acknowledgment (see sending-acknowledgements).
Paragraph (version B):
A QUIC packet that contains frames other than ACK, PADDING, and
CONNECTION_CLOSE.  These cause a recipient to send an
acknowledgment; see sending-acknowledgements.
Paragraph (version A):
QUIC allows for an arbitrary number of streams to operate
concurrently and for an arbitrary amount of data to be sent on any
stream, subject to flow control constraints (see flow-control) and
stream limits.
Paragraph (version B):
QUIC allows for an arbitrary number of streams to operate
concurrently and for an arbitrary amount of data to be sent on any
stream, subject to flow control constraints and stream limits; see
flow-control.
Paragraph (version A):
Once a final size for a stream is known, it cannot change.  If a
RESET_STREAM or STREAM frame is received indicating a change in the
final size for the stream, an endpoint SHOULD respond with a
FINAL_SIZE_ERROR error (see error-handling).  A receiver SHOULD treat
receipt of data at or beyond the final size as a FINAL_SIZE_ERROR
error, even after a stream is closed.  Generating these errors is not
mandatory, but only because requiring that an endpoint generate these
errors also means that the endpoint needs to maintain the final size
state for closed streams, which could mean a significant state
commitment.
Paragraph (version B):
Once a final size for a stream is known, it cannot change.  If a
RESET_STREAM or STREAM frame is received indicating a change in the
final size for the stream, an endpoint SHOULD respond with a
FINAL_SIZE_ERROR error; see error-handling.  A receiver SHOULD treat
receipt of data at or beyond the final size as a FINAL_SIZE_ERROR
error, even after a stream is closed.  Generating these errors is not
mandatory, but only because requiring that an endpoint generate these
errors also means that the endpoint needs to maintain the final size
state for closed streams, which could mean a significant state
commitment.
Paragraph (version A):
Note that multiple QUIC packets - even of different packet types -
can be coalesced into a single UDP datagram (see packet-coalesce),
and so this handshake may consist of as few as 4 UDP datagrams, or
any number more.  For instance, the server's first flight contains
Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT
packets with a short header.
Paragraph (version B):
Note that multiple QUIC packets - even of different packet types -
can be coalesced into a single UDP datagram; see packet-coalesce).
As a result, this handshake may consist of as few as 4 UDP datagrams,
or any number more.  For instance, the server's first flight contains
Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT
packets with a short header.
Paragraph (version A):
Attackers could replay tokens to use servers as amplifiers in DDoS
attacks.  To protect against such attacks, servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time.
Tokens that are provided in NEW_TOKEN frames (see frame-new-token)
need to be valid for longer, but SHOULD NOT be accepted multiple
times in a short period.  Servers are encouraged to allow tokens to
be used only once, if possible.
Paragraph (version B):
Attackers could replay tokens to use servers as amplifiers in DDoS
attacks.  To protect against such attacks, servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time.
Tokens that are provided in NEW_TOKEN frames (frame-new-token) need
to be valid for longer, but SHOULD NOT be accepted multiple times in
a short period.  Servers are encouraged to allow tokens to be used
only once, if possible.
Paragraph (version A):
initial value (see QUIC-RECOVERY).
Paragraph (version B):
initial value; see QUIC-RECOVERY.
Paragraph (version A):
An endpoint that detects an error SHOULD signal the existence of that
error to its peer.  Both transport-level and application-level errors
can affect an entire connection (see connection-errors), while only
application-level errors can be isolated to a single stream; see
stream-errors.
Paragraph (version B):
An endpoint that detects an error SHOULD signal the existence of that
error to its peer.  Both transport-level and application-level errors
can affect an entire connection; see connection-errors.  Only
application-level errors can be isolated to a single stream; see
stream-errors.
Paragraph (version A):
QUIC endpoints communicate by exchanging packets.  Packets have
confidentiality and integrity protection (see packet-protected) and
are carried in UDP datagrams (see packet-coalesce).
Paragraph (version A):
This version of QUIC uses the long packet header (see long-header)
during connection establishment.  Packets with the long header are
Initial (packet-initial), 0-RTT (packet-0rtt), Handshake (packet-
handshake), and Retry (packet-retry).  Version negotiation uses a
version-independent packet with a long header (see packet-version).
Paragraph (version A):
Packets with the short header (short-header) are designed for minimal
overhead and are used after a connection is established and 1-RTT
keys are available.
Paragraph (version B):
QUIC endpoints communicate by exchanging packets.  Packets have
confidentiality and integrity protection; see packet-protected.
Packets are carried in UDP datagrams; see packet-coalesce.
Paragraph (version B):
This version of QUIC uses the long packet header during connection
establishment; see long-header.  Packets with the long header are
Initial (packet-initial), 0-RTT (packet-0rtt), Handshake (packet-
handshake), and Retry (packet-retry).  Version negotiation uses a
version-independent packet with a long header; see packet-version.
Paragraph (version B):
Packets with the short header are designed for minimal overhead and
are used after a connection is established and 1-RTT keys are
available; see short-header.
Paragraph (version A):
Endpoints SHOULD prioritize retransmission of data over sending new
data, unless priorities specified by the application indicate
otherwise (see stream-prioritization).
Paragraph (version B):
Endpoints SHOULD prioritize retransmission of data over sending new
data, unless priorities specified by the application indicate
otherwise; see stream-prioritization.
Paragraph (version A):
Two bits (those with a mask of 0x0c) of byte 0 are reserved across
multiple packet types.  These bits are protected using header
protection (see Section 5.4 of QUIC-TLS).  The value included
prior to protection MUST be set to 0.  An endpoint MUST treat
receipt of a packet that has a non-zero value for these bits,
after removing both packet and header protection, as a connection
error of type PROTOCOL_VIOLATION.  Discarding such a packet after
only removing header protection can expose the endpoint to attacks
(see Section 9.3 of QUIC-TLS).
Paragraph (version B):
Two bits (those with a mask of 0x0c) of byte 0 are reserved across
multiple packet types.  These bits are protected using header
protection; see Section 5.4 of QUIC-TLS.  The value included prior
to protection MUST be set to 0.  An endpoint MUST treat receipt of
a packet that has a non-zero value for these bits, after removing
both packet and header protection, as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.3 of QUIC-TLS.
Paragraph (version A):
In packet types which contain a Packet Number field, the least
significant two bits (those with a mask of 0x03) of byte 0 contain
the length of the packet number, encoded as an unsigned, two-bit
integer that is one less than the length of the packet number
field in bytes.  That is, the length of the packet number field is
the value of this field, plus one.  These bits are protected using
header protection (see Section 5.4 of QUIC-TLS).
Paragraph (version B):
In packet types which contain a Packet Number field, the least
significant two bits (those with a mask of 0x03) of byte 0 contain
the length of the packet number, encoded as an unsigned, two-bit
integer that is one less than the length of the packet number
field in bytes.  That is, the length of the packet number field is
the value of this field, plus one.  These bits are protected using
header protection; see Section 5.4 of QUIC-TLS.
Paragraph (version A):
The packet number field is 1 to 4 bytes long.  The packet number
has confidentiality protection separate from packet protection, as
described in Section 5.4 of QUIC-TLS.  The length of the packet
number field is encoded in the Packet Number Length bits of byte 0
(see above).
Paragraph (version B):
The packet number field is 1 to 4 bytes long.  The packet number
has confidentiality protection separate from packet protection, as
described in Section 5.4 of QUIC-TLS.  The length of the packet
number field is encoded in the Packet Number Length bits of byte
0; see above.
Paragraph (version A):
A client stops both sending and processing Initial packets when it
sends its first Handshake packet.  A server stops sending and
processing Initial packets when it receives its first Handshake
packet.  Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged
beyond this point.  Initial packet protection keys are discarded (see
Section 4.10.1 of QUIC-TLS) along with any loss recovery and
congestion control state (see Section 6.5 of QUIC-RECOVERY).
Paragraph (version B):
A client stops both sending and processing Initial packets when it
sends its first Handshake packet.  A server stops sending and
processing Initial packets when it receives its first Handshake
packet.  Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged
beyond this point.  Initial packet protection keys are discarded (see
Section 4.10.1 of QUIC-TLS) along with any loss recovery and
congestion control state; see Section 6.5 of QUIC-RECOVERY.
Paragraph (version A):
The Destination Connection ID field in a Handshake packet contains a
connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of
the packet wishes to use (see negotiating-connection-ids).
Paragraph (version B):
The Destination Connection ID field in a Handshake packet contains a
connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of
the packet wishes to use; see negotiating-connection-ids.
Paragraph (version A):
A client sets the Destination Connection ID field of this Initial
packet to the value from the Source Connection ID in the Retry
packet.  Changing Destination Connection ID also results in a change
to the keys used to protect the Initial packet.  It also sets the
Token field to the token provided in the Retry.  The client MUST NOT
change the Source Connection ID because the server could include the
connection ID as part of its token validation logic (see token-
integrity).
Paragraph (version B):
A client sets the Destination Connection ID field of this Initial
packet to the value from the Source Connection ID in the Retry
packet.  Changing Destination Connection ID also results in a change
to the keys used to protect the Initial packet.  It also sets the
Token field to the token provided in the Retry.  The client MUST NOT
change the Source Connection ID because the server could include the
connection ID as part of its token validation logic; see token-
integrity.
Paragraph (version A):
A server acknowledges the use of a Retry packet for a connection
using the original_connection_id transport parameter (see transport-
parameter-definitions).  If the server sends a Retry packet, it MUST
include the Destination Connection ID field from the client's first
Initial packet in the transport parameter.
Paragraph (version B):
A server acknowledges the use of a Retry packet for a connection
using the original_connection_id transport parameter; see transport-
parameter-definitions.  If the server sends a Retry packet, it MUST
include the Destination Connection ID field from the client's first
Initial packet in the transport parameter.
Paragraph (version A):
The next two bits (those with a mask of 0x18) of byte 0 are
reserved.  These bits are protected using header protection (see
Section 5.4 of QUIC-TLS).  The value included prior to protection
MUST be set to 0.  An endpoint MUST treat receipt of a packet that
has a non-zero value for these bits, after removing both packet
and header protection, as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks (see
Section 9.3 of QUIC-TLS).
Paragraph (version B):
The next two bits (those with a mask of 0x18) of byte 0 are
reserved.  These bits are protected using header protection; see
Section 5.4 of QUIC-TLS.  The value included prior to protection
MUST be set to 0.  An endpoint MUST treat receipt of a packet that
has a non-zero value for these bits, after removing both packet
and header protection, as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.3 of QUIC-TLS.
Paragraph (version A):
The least significant two bits (those with a mask of 0x03) of byte
0 contain the length of the packet number, encoded as an unsigned,
two-bit integer that is one less than the length of the packet
number field in bytes.  That is, the length of the packet number
field is the value of this field, plus one.  These bits are
protected using header protection (see Section 5.4 of QUIC-TLS).
Paragraph (version B):
The least significant two bits (those with a mask of 0x03) of byte
0 contain the length of the packet number, encoded as an unsigned,
two-bit integer that is one less than the length of the packet
number field in bytes.  That is, the length of the packet number
field is the value of this field, plus one.  These bits are
protected using header protection; see Section 5.4 of QUIC-TLS.
Paragraph (version A):
Many transport parameters listed here have integer values.  Those
transport parameters that are identified as integers use a variable-
length integer encoding (see integer-encoding) and have a default
value of 0 if the transport parameter is absent, unless otherwise
stated.
Paragraph (version B):
Many transport parameters listed here have integer values.  Those
transport parameters that are identified as integers use a variable-
length integer encoding; see integer-encoding.  Transport parameters
have a default value of 0 if the transport parameter is absent unless
otherwise stated.
Paragraph (version A):
A variable-length integer indicating the stream ID of the stream
(see stream-id).
Paragraph (version B):
A variable-length integer indicating the stream ID of the stream;
see stream-id.
Paragraph (version A):
A MAX_STREAM_DATA frame can be sent for streams in the Recv state
(see stream-send-states).  Receiving a MAX_STREAM_DATA frame for a
locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version B):
A MAX_STREAM_DATA frame can be sent for streams in the Recv state;
see stream-send-states.  Receiving a MAX_STREAM_DATA frame for a
locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR.  An
endpoint that receives a MAX_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
to send data, but is unable to due to connection-level flow control
(see flow-control).  DATA_BLOCKED frames can be used as input to
tuning of flow control algorithms; see fc-credit.
Paragraph (version B):
A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
to send data, but is unable to due to connection-level flow control;
see flow-control.  DATA_BLOCKED frames can be used as input to tuning
of flow control algorithms; see fc-credit.
Paragraph (version A):
In addition to the advice in iana-policy, specifications for new
permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of
frame.  An accompanying transport parameter registration (see iana-
transport-parameters) is expected for most registrations.
Specifications for permanent registrations also needs to describe the
format and assigned semantics of any fields in the frame.
Paragraph (version B):
In addition to the advice in iana-policy, specifications for new
permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of
frame.  An accompanying transport parameter registration is expected
for most registrations; see iana-transport-parameters.
Specifications for permanent registrations also needs to describe the
format and assigned semantics of any fields in the frame.