Draft: draft-ietf-quic-transport

Commentary: This is beyond editorial , so skipping an issue for this , but since it came up in . Bikeshed time ! Let 's pick between semicolons and parenthesis . This PR unifies the " see Section X.Y.Z " at the ends of sentences into the form instead of However , this does n't touch the middle of sentences : Suggestions welcome for the semicolon form of that . There are other cases that do n't quite seem to fit with semicolons , as well : and this seems like it would n't want to split between two different styles : One last example for this one : And , finally , direct references without " see " too : vs. So , for now , I 've changed all of the " see Section X.Y.Z " form to use semicolons , as they were pretty split between the two already . Either way we choose , happy to switch this up to match ( it 's not consistent either way , so no matter what a change is necessary ) , so this PR can be used to go in either direction . 
 If we 're going in this direction , we should update the other drafts as well(in subsequent PRs ) . I 'm a fan of parens myself , but it 's a bikeshed and I do n't care that much . 
 I 'm fine with leaving the parens mid - sentence . To me , the distinction is whether they 're providing extra information about the entire sentence , or about a specific term in the sentence . If it 's about a specific term , use parens immediately after the term ; if it 's about the sentence in general , use a semicolon after the sentence . 
 Personally , I did n’t mind the parenthesis , but thanks for putting some rationale together for mid vs. end of sentence refs like this — that sounds like a strategy I can live with . 
  's rationale is excellent . Though I would add that the good practice of one concept per sentence leads to using a semicolon more often than not . 
 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 ... 
 We 've been working toward this piecemeal . This helps a lot .
Paragraph (version A):
Streams are identified within a connection by a numeric value,
referred to as the stream ID.  A stream ID is a 62-bit integer (0 to
2^62-1) that is unique for all streams on a connection.  Stream IDs
are encoded as variable-length integers (see integer-encoding).  A
QUIC endpoint MUST NOT reuse a stream ID within a connection.
Paragraph (version B):
Streams are identified within a connection by a numeric value,
referred to as the stream ID.  A stream ID is a 62-bit integer (0 to
2^62-1) that is unique for all streams on a connection.  Stream IDs
are encoded as variable-length integers; see integer-encoding.  A
QUIC endpoint MUST NOT reuse a stream ID within a connection.
Paragraph (version A):
When a STREAM frame with a FIN bit is received, the final size of the
stream is known (see final-size).  The receiving part of the stream
then enters the "Size Known" state.  In this state, the endpoint no
longer needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data.
Paragraph (version B):
When a STREAM frame with a FIN bit is received, the final size of the
stream is known; see final-size.  The receiving part of the stream
then enters the "Size Known" state.  In this state, the endpoint no
longer needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data.
Paragraph (version A):
An endpoint limits the cumulative number of incoming streams a peer
can open.  Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened (see long-packet-types).
Initial limits are set in the transport parameters (see transport-
parameter-definitions) and subsequently limits are advertised using
MAX_STREAMS frames (frame-max-streams).  Separate limits apply to
unidirectional and bidirectional streams.
Paragraph (version B):
An endpoint limits the cumulative number of incoming streams a peer
can open.  Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened; see long-packet-types.
Initial limits are set in the transport parameters (see transport-
parameter-definitions) and subsequently limits are advertised using
MAX_STREAMS frames (frame-max-streams).  Separate limits apply to
unidirectional and bidirectional streams.
Paragraph (version A):
If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer (see integer-
encoding).  If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR (see
immediate-close).
Paragraph (version B):
If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer; see integer-
encoding.  If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR; see
immediate-close.
Paragraph (version A):
If the version selected by the client is not acceptable to the
server, the server responds with a Version Negotiation packet (see
packet-version).  This includes a list of versions that the server
will accept.  An endpoint MUST NOT send a Version Negotiation packet
in response to receiving a Version Negotiation packet.
Paragraph (version B):
If the version selected by the client is not acceptable to the
server, the server responds with a Version Negotiation packet; see
packet-version.  This includes a list of versions that the server
will accept.  An endpoint MUST NOT send a Version Negotiation packet
in response to receiving a Version Negotiation packet.
Paragraph (version A):
An endpoint MUST NOT send more than one PATH_RESPONSE frame in
response to one PATH_CHALLENGE frame (see retransmission-of-
information).  The peer is expected to send more PATH_CHALLENGE
frames as necessary to evoke additional PATH_RESPONSE frames.
Paragraph (version B):
An endpoint MUST NOT send more than one PATH_RESPONSE frame in
response to one PATH_CHALLENGE frame; see retransmission-of-
information.  The peer is expected to send more PATH_CHALLENGE frames
as necessary to evoke additional PATH_RESPONSE frames.
Paragraph (version A):
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
destination CID.  The flow label generation MUST be designed to
minimize the chances of linkability with a previously used flow
label, as this would enable correlating activity on multiple paths
(see migration-linkability).
Paragraph (version B):
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
destination CID.  The flow label generation MUST be designed to
minimize the chances of linkability with a previously used flow
label, as this would enable correlating activity on multiple paths;
see migration-linkability.
Paragraph (version A):
An endpoint MAY discard connection state if it does not have a
validated path on which it can send packets (see migrate-validate).
Paragraph (version B):
An endpoint MAY discard connection state if it does not have a
validated path on which it can send packets; see migrate-validate.
Paragraph (version A):
An endpoint enters a closing period after initiating an immediate
close (immediate-close).  While closing, an endpoint MUST NOT send
packets unless they contain a CONNECTION_CLOSE frame (see immediate-
close for details).  An endpoint retains only enough information to
generate a packet containing a CONNECTION_CLOSE frame and to identify
packets as belonging to the connection.  The endpoint's selected
connection ID and the QUIC version are sufficient information to
identify packets for a closing connection; an endpoint can discard
all other connection state.  An endpoint MAY retain packet protection
keys for incoming packets to allow it to read and process a
CONNECTION_CLOSE frame.
Paragraph (version B):
An endpoint enters a closing period after initiating an immediate
close; immediate-close.  While closing, an endpoint MUST NOT send
packets unless they contain a CONNECTION_CLOSE frame; see immediate-
close for details.  An endpoint retains only enough information to
generate a packet containing a CONNECTION_CLOSE frame and to identify
packets as belonging to the connection.  The endpoint's selected
connection ID and the QUIC version are sufficient information to
identify packets for a closing connection; an endpoint can discard
all other connection state.  An endpoint MAY retain packet protection
keys for incoming packets to allow it to read and process a
CONNECTION_CLOSE frame.
Paragraph (version A):
While in the closing period, an endpoint could receive packets from a
new source address, indicating a connection migration (migration).
An endpoint in the closing state MUST strictly limit the number of
packets it sends to this new address until the address is validated
(see migrate-validate).  A server in the closing state MAY instead
choose to discard packets received from a new source address.
Paragraph (version B):
While in the closing period, an endpoint could receive packets from a
new source address, indicating a connection migration; migration.  An
endpoint in the closing state MUST strictly limit the number of
packets it sends to this new address until the address is validated;
see migrate-validate.  A server in the closing state MAY instead
choose to discard packets received from a new source address.
Paragraph (version A):
New packets from unverified addresses could be used to create an
amplification attack (see address-validation).  To avoid this,
endpoints MUST either limit transmission of CONNECTION_CLOSE frames
to validated addresses or drop packets without response if the
response would be more than three times larger than the received
packet.
Paragraph (version B):
New packets from unverified addresses could be used to create an
amplification attack; see address-validation.  To avoid this,
endpoints MUST either limit transmission of CONNECTION_CLOSE frames
to validated addresses or drop packets without response if the
response would be more than three times larger than the received
packet.
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), while only
application-level errors can be isolated to a single stream; see
stream-errors.
Paragraph (version A):
The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet
protection is applied (see QUIC-TLS for details).  The underlying
packet number increases with each packet sent in a given packet
number space; see packet-numbers for details.
Paragraph (version B):
The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet
protection is applied; see QUIC-TLS for details.  The underlying
packet number increases with each packet sent in a given packet
number space; see packet-numbers for details.
Paragraph (version A):
Using the Length field, a sender can coalesce multiple QUIC packets
into one UDP datagram.  This can reduce the number of UDP datagrams
needed to complete the cryptographic handshake and start sending
data.  This can also be used to construct PMTU probes (see pmtu-
probes-src-cid).  Receivers MUST be able to process coalesced
packets.
Paragraph (version B):
Using the Length field, a sender can coalesce multiple QUIC packets
into one UDP datagram.  This can reduce the number of UDP datagrams
needed to complete the cryptographic handshake and start sending
data.  This can also be used to construct PMTU probes; see pmtu-
probes-src-cid.  Receivers MUST be able to process coalesced packets.
Paragraph (version A):
Packet numbers are limited to this range because they need to be
representable in whole in the Largest Acknowledged field of an ACK
frame (frame-ack).  When present in a long or short header however,
packet numbers are reduced and encoded in 1 to 4 bytes (see packet-
encoding).
Paragraph (version B):
Packet numbers are limited to this range because they need to be
representable in whole in the Largest Acknowledged field of an ACK
frame (frame-ack).  When present in a long or short header however,
packet numbers are reduced and encoded in 1 to 4 bytes; see packet-
encoding.
Paragraph (version A):
A sender bundles one or more frames in a QUIC packet (see frames).
Paragraph (version B):
A sender bundles one or more frames in a QUIC packet; see frames.
Paragraph (version A):
An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the
time an acknowledgment is sent.  The endpoint encodes this delay in
the Ack Delay field of an ACK frame (see frame-ack).  This allows the
receiver of the ACK to adjust for any intentional delays, which is
important for getting a better estimate of the path RTT when
acknowledgments are delayed.  A packet might be held in the OS kernel
or elsewhere on the host before being processed.  An endpoint MUST
NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame.
Paragraph (version B):
An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the
time an acknowledgment is sent.  The endpoint encodes this delay in
the Ack Delay field of an ACK frame; see frame-ack.  This allows the
receiver of the ACK to adjust for any intentional delays, which is
important for getting a better estimate of the path RTT when
acknowledgments are delayed.  A packet might be held in the OS kernel
or elsewhere on the host before being processed.  An endpoint MUST
NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame.
Paragraph (version A):
ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see packet-protected).  For
instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys.
Paragraph (version B):
ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed; see packet-protected.  For
instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys.
Paragraph (version A):
On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames (see
generating-acks and frame-ack).  Note that this requires being able
to read the ECN codepoints from the enclosing IP packet, which is not
possible on all platforms.
Paragraph (version B):
On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames; see
generating-acks and frame-ack.  Note that this requires being able to
read the ECN codepoints from the enclosing IP packet, which is not
possible on all platforms.
Paragraph (version A):
A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least 1200 bytes, by adding PADDING frames to
the Initial packet or by coalescing the Initial packet (see packet-
coalesce).  Sending a UDP datagram of this size ensures that the
network path from the client to the server supports a reasonable
Maximum Transmission Unit (MTU).  Padding datagrams also helps reduce
the amplitude of amplification attacks caused by server responses
toward an unverified client address; see address-validation.
Paragraph (version B):
A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least 1200 bytes, by adding PADDING frames to
the Initial packet or by coalescing the Initial packet; see packet-
coalesce.  Sending a UDP datagram of this size ensures that the
network path from the client to the server supports a reasonable
Maximum Transmission Unit (MTU).  Padding datagrams also helps reduce
the amplitude of amplification attacks caused by server responses
toward an unverified client address; see address-validation.
Paragraph (version A):
The first packet sent by a client always includes a CRYPTO frame that
contains the start or all of the first cryptographic handshake
message.  The first CRYPTO frame sent always begins at an offset of 0
(see handshake).
Paragraph (version B):
The first packet sent by a client always includes a CRYPTO frame that
contains the start or all of the first cryptographic handshake
message.  The first CRYPTO frame sent always begins at an offset of
0; see handshake.
Paragraph (version A):
A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server.  It is
used by a server that wishes to perform a retry (see validate-
handshake).
Paragraph (version B):
A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server.  It is
used by a server that wishes to perform a retry; see validate-
handshake.
Paragraph (version A):
The next Initial packet from the client uses the connection ID and
token values from the Retry packet (see negotiating-connection-ids).
Aside from this, the Initial packet sent by the client is subject to
the same restrictions as the first Initial packet.  A client MUST use
the same cryptographic handshake message it includes in this packet.
A server MAY treat a packet that contains a different cryptographic
handshake message as a connection error or discard it.
Paragraph (version B):
The next Initial packet from the client uses the connection ID and
token values from the Retry packet; see negotiating-connection-ids.
Aside from this, the Initial packet sent by the client is subject to
the same restrictions as the first Initial packet.  A client MUST use
the same cryptographic handshake message it includes in this packet.
A server MAY treat a packet that contains a different cryptographic
handshake message as a connection error or discard it.
Paragraph (version A):
The next bit (0x04) of byte 0 indicates the key phase, which
allows a recipient of a packet to identify the packet protection
keys that are used to protect the packet.  See QUIC-TLS for
details.  This bit is protected using header protection (see
Section 5.4 of QUIC-TLS).
Paragraph (version B):
The next bit (0x04) of byte 0 indicates the key phase, which
allows a recipient of a packet to identify the packet protection
keys that are used to protect the packet.  See QUIC-TLS for
details.  This bit is protected using header protection; see
Section 5.4 of QUIC-TLS.
Paragraph (version A):
The value of the Destination Connection ID field from the first
Initial packet sent by the client.  This transport parameter is
only sent by a server.  This is the same value sent in the
"Original Destination Connection ID" field of a Retry packet (see
packet-retry).  A server MUST include the original_connection_id
transport parameter if it sent a Retry packet.
Paragraph (version B):
The value of the Destination Connection ID field from the first
Initial packet sent by the client.  This transport parameter is
only sent by a server.  This is the same value sent in the
"Original Destination Connection ID" field of a Retry packet; see
packet-retry.  A server MUST include the original_connection_id
transport parameter if it sent a Retry packet.
Paragraph (version A):
A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout
transport parameter (see termination).  However, state in middleboxes
might time out earlier than that.  Though REQ-5 in RFC4787 recommends
a 2 minute timeout interval, experience shows that sending packets
every 15 to 30 seconds is necessary to prevent the majority of
middleboxes from losing state for UDP flows.
Paragraph (version B):
A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout
transport parameter; see termination.  However, state in middleboxes
might time out earlier than that.  Though REQ-5 in RFC4787 recommends
a 2 minute timeout interval, experience shows that sending packets
every 15 to 30 seconds is necessary to prevent the majority of
middleboxes from losing state for UDP flows.
Paragraph (version A):
A variable-length integer representing the time delta in
microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer.  The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame (see transport-parameter-
definitions).  Scaling in this fashion allows for a larger range
of values with a shorter encoding at the cost of lower resolution.
Because the receiver doesn't use the ACK Delay for Initial and
Handshake packets, a sender SHOULD send a value of 0.
Paragraph (version B):
A variable-length integer representing the time delta in
microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer.  The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame; see transport-parameter-
definitions.  Scaling in this fashion allows for a larger range of
values with a shorter encoding at the cost of lower resolution.
Because the receiver doesn't use the ACK Delay for Initial and
Handshake packets, a sender SHOULD send a value of 0.
Paragraph (version A):
A variable-length integer indicating the number of contiguous
packets preceding the Largest Acknowledged that are being
acknowledged.  The First ACK Range is encoded as an ACK Range (see
ack-ranges) starting from the Largest Acknowledged.  That is, the
smallest packet acknowledged in the range is determined by
subtracting the First ACK Range value from the Largest
Acknowledged.
Paragraph (version B):
A variable-length integer indicating the number of contiguous
packets preceding the Largest Acknowledged that are being
acknowledged.  The First ACK Range is encoded as an ACK Range; see
ack-ranges starting from the Largest Acknowledged.  That is, the
smallest packet acknowledged in the range is determined by
subtracting the First ACK Range value from the Largest
Acknowledged.
Paragraph (version A):
A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states (see stream-send-states).  Receiving a STOP_SENDING
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 STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version B):
A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states; see stream-send-states.  Receiving a STOP_SENDING 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 STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR.
Paragraph (version A):
A variable-length integer containing the application-specified
reason the sender is ignoring the stream (see app-error-codes).
Paragraph (version B):
A variable-length integer containing the application-specified
reason the sender is ignoring the stream; see app-error-codes.
Paragraph (version A):
All data sent in STREAM frames counts toward this limit.  The sum of
the largest received offsets on all streams - including streams in
terminal states - MUST NOT exceed the value advertised by a receiver.
An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR
error if it receives more data than the maximum data value that it
has sent, unless this is a result of a change in the initial limits
(see zerortt-parameters).
Paragraph (version B):
All data sent in STREAM frames counts toward this limit.  The sum of
the largest received offsets on all streams - including streams in
terminal states - MUST NOT exceed the value advertised by a receiver.
An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR
error if it receives more data than the maximum data value that it
has sent, unless this is a result of a change in the initial limits;
see zerortt-parameters.
Paragraph (version A):
The data sent on a stream MUST NOT exceed the largest maximum stream
data value advertised by the receiver.  An endpoint MUST terminate a
connection with a FLOW_CONTROL_ERROR error if it receives more data
than the largest maximum stream data that it has sent for the
affected stream, unless this is a result of a change in the initial
limits (see zerortt-parameters).
Paragraph (version B):
The data sent on a stream MUST NOT exceed the largest maximum stream
data value advertised by the receiver.  An endpoint MUST terminate a
connection with a FLOW_CONTROL_ERROR error if it receives more data
than the largest maximum stream data that it has sent for the
affected stream, unless this is a result of a change in the initial
limits; see zerortt-parameters.
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):
A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
it wishes to open a stream, but is unable to due to the maximum
stream limit set by its peer (see frame-max-streams).  A
STREAMS_BLOCKED frame of type 0x16 is used to indicate reaching the
bidirectional stream limit, and a STREAMS_BLOCKED frame of type 0x17
indicates reaching the unidirectional stream limit.
Paragraph (version B):
A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
it wishes to open a stream, but is unable to due to the maximum
stream limit set by its peer; see frame-max-streams.  A
STREAMS_BLOCKED frame of type 0x16 is used to indicate reaching the
bidirectional stream limit, and a STREAMS_BLOCKED frame of type 0x17
indicates reaching the unidirectional stream limit.
Paragraph (version A):
An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide
its peer with alternative connection IDs that can be used to break
linkability when migrating connections (see migration-linkability).
Paragraph (version B):
An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide
its peer with alternative connection IDs that can be used to break
linkability when migrating connections; see migration-linkability.
Paragraph (version A):
A 128-bit value that will be used for a stateless reset when the
associated connection ID is used (see stateless-reset).
Paragraph (version B):
A 128-bit value that will be used for a stateless reset when the
associated connection ID is used; see stateless-reset.
Paragraph (version A):
The Retire Prior To field counts connection IDs established during
connection setup and the preferred_address transport parameter (see
retiring-cids).  The Retire Prior To field MUST be less than or equal
to the Sequence Number field.  Receiving a value greater than the
Sequence Number MUST be treated as a connection error of type
FRAME_ENCODING_ERROR.
Paragraph (version B):
The Retire Prior To field counts connection IDs established during
connection setup and the preferred_address transport parameter; see
retiring-cids.  The Retire Prior To field MUST be less than or equal
to the Sequence Number field.  Receiving a value greater than the
Sequence Number MUST be treated as a connection error of type
FRAME_ENCODING_ERROR.
Paragraph (version A):
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
indicate that it will no longer use a connection ID that was issued
by its peer.  This may include the connection ID provided during the
handshake.  Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use
(see connection-id).  New connection IDs can be delivered to a peer
using the NEW_CONNECTION_ID frame (frame-new-connection-id).
Paragraph (version B):
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
indicate that it will no longer use a connection ID that was issued
by its peer.  This may include the connection ID provided during the
handshake.  Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use;
see connection-id.  New connection IDs can be delivered to a peer
using the NEW_CONNECTION_ID frame (frame-new-connection-id).
Paragraph (version A):
An endpoint received more data than it permitted in its advertised
data limits (see flow-control).
Paragraph (version A):
An endpoint received a frame for a stream that was not in a state
that permitted that frame (see stream-states).
Paragraph (version B):
An endpoint received more data than it permitted in its advertised
data limits; see flow-control.
Paragraph (version B):
An endpoint received a frame for a stream that was not in a state
that permitted that frame; see stream-states.
Paragraph (version A):
Servers SHOULD provide mitigations for this attack by limiting the
usage and lifetime of address validation tokens (see validate-
future).
Paragraph (version B):
Servers SHOULD provide mitigations for this attack by limiting the
usage and lifetime of address validation tokens; see validate-future.
Paragraph (version A):
An endpoint that acknowledges packets it has not received might cause
a congestion controller to permit sending at rates beyond what the
network supports.  An endpoint MAY skip packet numbers when sending
packets to detect this behavior.  An endpoint can then immediately
close the connection with a connection error of type
PROTOCOL_VIOLATION (see immediate-close).
Paragraph (version B):
An endpoint that acknowledges packets it has not received might cause
a congestion controller to permit sending at rates beyond what the
network supports.  An endpoint MAY skip packet numbers when sending
packets to detect this behavior.  An endpoint can then immediately
close the connection with a connection error of type
PROTOCOL_VIOLATION; see immediate-close.
Paragraph (version A):
Normally, clients will open streams sequentially, as explained in
stream-id.  However, when several streams are initiated at short
intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence.  On receiving a higher-
numbered stream ID, a receiver is required to open all intervening
streams of the same type (see stream-recv-states).  Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams.
Paragraph (version B):
Normally, clients will open streams sequentially, as explained in
stream-id.  However, when several streams are initiated at short
intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence.  On receiving a higher-
numbered stream ID, a receiver is required to open all intervening
streams of the same type; see stream-recv-states.  Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams.