Draft: draft-ietf-quic-qpack

Commentary: They would need to let me add several zeroes to Heather 's salary ... 
  will include this PR as part of his job application for the RPC . This PR can be his entire application . 
 QPACK changes look ok , with a minor commentThanks ,
Paragraph (version A):
An instruction which represents a field line, possibly by
reference to the dynamic and static tables.
Paragraph (version A):
An implementation which encodes field sections.
Paragraph (version A):
An implementation which decodes encoded field sections.
Paragraph (version A):
A reference point for relative and post-base indices.
Representations which reference dynamic table entries are relative
to a Base.
Paragraph (version B):
An instruction that represents a field line, possibly by reference
to the dynamic and static tables.
Paragraph (version B):
An implementation that encodes field sections.
Paragraph (version B):
An implementation that decodes encoded field sections.
Paragraph (version B):
A reference point for relative and post-base indices.
Representations that reference dynamic table entries are relative
to a Base.
Paragraph (version A):
Inserting entries into the dynamic table might not be possible if the
table contains entries which cannot be evicted.
Paragraph (version B):
Inserting entries into the dynamic table might not be possible if the
table contains entries that cannot be evicted.
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 field
section until those representations are 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 that 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 field section
until those representations are acknowledged by the decoder; see
header-acknowledgement.
Paragraph (version A):
The decoder specifies an upper bound on the number of streams which
can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; see
configuration.  An encoder MUST limit the number of streams which
could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS
at all times.  If a decoder encounters more blocked streams than it
promised to support, it MUST treat this as a connection error of type
QPACK_DECOMPRESSION_FAILED.
Paragraph (version A):
Note that the decoder might not become blocked on every stream which
risks becoming blocked.
Paragraph (version B):
The decoder specifies an upper bound on the number of streams that
can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; see
configuration.  An encoder MUST limit the number of streams that
could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS
at all times.  If a decoder encounters more blocked streams than it
promised to support, it MUST treat this as a connection error of type
QPACK_DECOMPRESSION_FAILED.
Paragraph (version B):
Note that the decoder might not become blocked on every stream that
risks becoming blocked.
Paragraph (version A):
An encoder can decide whether to risk having a stream become blocked.
If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,
compression efficiency can often be improved by referencing dynamic
table entries that are still in transit, but if there is loss or
reordering the stream can become blocked at the decoder.  An encoder
can avoid the risk of blocking by only referencing dynamic table
entries which have been acknowledged, but this could mean using
literals.  Since literals make the encoded field section larger, this
can result in the encoder becoming blocked on congestion or flow
control limits.
Paragraph (version B):
An encoder can decide whether to risk having a stream become blocked.
If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,
compression efficiency can often be improved by referencing dynamic
table entries that are still in transit, but if there is loss or
reordering the stream can become blocked at the decoder.  An encoder
can avoid the risk of blocking by only referencing dynamic table
entries that have been acknowledged, but this could mean using
literals.  Since literals make the encoded field section larger, this
can result in the encoder becoming blocked on congestion or flow
control limits.
Paragraph (version A):
If the decoder encounters a reference in a field line representation
to a dynamic table entry which has already been evicted or which has
an absolute index greater than or equal to the declared Required
Insert Count (header-prefix), it MUST treat this as a connection
error of type QPACK_DECOMPRESSION_FAILED.
Paragraph (version A):
If the decoder encounters a reference in an encoder instruction to a
dynamic table entry which has already been evicted, it MUST treat
this as a connection error of type QPACK_ENCODER_STREAM_ERROR.
Paragraph (version B):
If the decoder encounters a reference in a field line representation
to a dynamic table entry that has already been evicted or that has an
absolute index greater than or equal to the declared Required Insert
Count (header-prefix), it MUST treat this as a connection error of
type QPACK_DECOMPRESSION_FAILED.
Paragraph (version B):
If the decoder encounters a reference in an encoder instruction to a
dynamic table entry that has already been evicted, it MUST treat this
as a connection error of type QPACK_ENCODER_STREAM_ERROR.
Paragraph (version A):
Each entry possesses an absolute index which is fixed for the
lifetime of that entry.  The first entry inserted has an absolute
index of "0"; indices increase by one with each insertion.
Paragraph (version B):
Each entry possesses an absolute index that is fixed for the lifetime
of that entry.  The first entry inserted has an absolute index of
"0"; indices increase by one with each insertion.
Paragraph (version A):
An encoder sends encoder instructions on the encoder stream to set
the capacity of the dynamic table and add dynamic table entries.
Instructions adding table entries can use existing entries to avoid
transmitting redundant information.  The name can be transmitted as a
reference to an existing entry in the static or the dynamic table or
as a string literal.  For entries which already exist in the dynamic
table, the full entry can also be used by reference, creating a
duplicate entry.
Paragraph (version B):
An encoder sends encoder instructions on the encoder stream to set
the capacity of the dynamic table and add dynamic table entries.
Instructions adding table entries can use existing entries to avoid
transmitting redundant information.  The name can be transmitted as a
reference to an existing entry in the static or the dynamic table or
as a string literal.  For entries that already exist in the dynamic
table, the full entry can also be used by reference, creating a
duplicate entry.
Paragraph (version A):
An encoder informs the decoder of a change to the dynamic table
capacity using an instruction which begins with the '001' three-bit
pattern.  This is followed by the new dynamic table capacity
represented as an integer with a 5-bit prefix; see prefixed-integers.
Paragraph (version B):
An encoder informs the decoder of a change to the dynamic table
capacity using an instruction that begins with the '001' three-bit
pattern.  This is followed by the new dynamic table capacity
represented as an integer with a 5-bit prefix; see prefixed-integers.
Paragraph (version A):
Reducing the dynamic table capacity can cause entries to be evicted;
see eviction.  This MUST NOT cause the eviction of entries which are
not evictable; see blocked-insertion.  Changing the capacity of the
dynamic table is not acknowledged as this instruction does not insert
an entry.
Paragraph (version B):
Reducing the dynamic table capacity can cause entries to be evicted;
see eviction.  This MUST NOT cause the eviction of entries that are
not evictable; see blocked-insertion.  Changing the capacity of the
dynamic table is not acknowledged as this instruction does not insert
an entry.
Paragraph (version A):
After processing an encoded field section whose declared Required
Insert Count is not zero, the decoder emits a Section Acknowledgement
instruction.  The instruction begins with the '1' one-bit pattern
which is followed by the field section's associated stream ID encoded
as a 7-bit prefix integer; see prefixed-integers.
Paragraph (version B):
After processing an encoded field section whose declared Required
Insert Count is not zero, the decoder emits a Section Acknowledgement
instruction.  The instruction begins with the '1' one-bit pattern,
followed by the field section's associated stream ID encoded as a
7-bit prefix integer; see prefixed-integers.
Paragraph (version A):
When a stream is reset or reading is abandoned, the decoder emits a
Stream Cancellation instruction.  The instruction begins with the
'01' two-bit pattern, which is followed by the stream ID of the
affected stream encoded as a 6-bit prefix integer.
Paragraph (version B):
When a stream is reset or reading is abandoned, the decoder emits a
Stream Cancellation instruction.  The instruction begins with the
'01' two-bit pattern, followed by the stream ID of the affected
stream encoded as a 6-bit prefix integer.
Paragraph (version A):
A single-pass encoder determines the Base before encoding a field
section.  If the encoder inserted entries in the dynamic table while
encoding the field section, Required Insert Count will be greater
than the Base, so the encoded difference is negative and the sign bit
is set to 1.  If the field section was not encoded using
representations which reference the most recent entry in the table
and did not insert any new entries, the Base will be greater than the
Required Insert Count, so the delta will be positive and the sign bit
is set to 0.
Paragraph (version B):
A single-pass encoder determines the Base before encoding a field
section.  If the encoder inserted entries in the dynamic table while
encoding the field section, Required Insert Count will be greater
than the Base, so the encoded difference is negative and the sign bit
is set to 1.  If the field section was not encoded using
representations that reference the most recent entry in the table and
did not insert any new entries, the Base will be greater than the
Required Insert Count, so the delta will be positive and the sign bit
is set to 0.
Paragraph (version A):
QPACK defines two settings which are included in the HTTP/3 SETTINGS
frame.
Paragraph (version A):
While the negotiated limit on the dynamic table size accounts for
much of the memory that can be consumed by a QPACK implementation,
data which cannot be immediately sent due to flow control is not
affected by this limit.  Implementations should limit the size of
unsent data, especially on the decoder stream where flexibility to
choose what to send is limited.  Possible responses to an excess of
unsent data might include limiting the ability of the peer to open
new streams, reading only from the encoder stream, or closing the
connection.
Paragraph (version B):
While the negotiated limit on the dynamic table size accounts for
much of the memory that can be consumed by a QPACK implementation,
data that cannot be immediately sent due to flow control is not
affected by this limit.  Implementations should limit the size of
unsent data, especially on the decoder stream where flexibility to
choose what to send is limited.  Possible responses to an excess of
unsent data might include limiting the ability of the peer to open
new streams, reading only from the encoder stream, or closing the
connection.
Paragraph (version A):
Server push is an interaction mode introduced in HTTP/2 HTTP2 which
permits a server to push a request-response exchange to a client in
anticipation of the client making the indicated request.  This trades
off network usage against a potential latency gain.  Several HTTP/3
frames are used to manage server push, such as PUSH_PROMISE,
MAX_PUSH_ID, and CANCEL_PUSH.
Paragraph (version B):
Server push is an interaction mode introduced in HTTP/2 HTTP2 that
permits a server to push a request-response exchange to a client in
anticipation of the client making the indicated request.  This trades
off network usage against a potential latency gain.  Several HTTP/3
frames are used to manage server push, such as PUSH_PROMISE,
MAX_PUSH_ID, and CANCEL_PUSH.
Paragraph (version A):
Non-compatible experiments that are based on these draft versions
MUST append the string "-" and an experiment name to the identifier.
For example, an experimental implementation based on draft-ietf-quic-
http-09 which reserves an extra stream for unsolicited transmission
of 1980s pop music might identify itself as "h3-09-rickroll".  Note
that any label MUST conform to the "token" syntax defined in
Section 5.4.1.1 of SEMANTICS.  Experimenters are encouraged to
coordinate their experiments on the quic@ietf.org [2] mailing list.
Paragraph (version B):
Non-compatible experiments that are based on these draft versions
MUST append the string "-" and an experiment name to the identifier.
For example, an experimental implementation based on draft-ietf-quic-
http-09 that reserves an extra stream for unsolicited transmission of
1980s pop music might identify itself as "h3-09-rickroll".  Note that
any label MUST conform to the "token" syntax defined in
Section 5.4.1.1 of SEMANTICS.  Experimenters are encouraged to
coordinate their experiments on the quic@ietf.org [2] mailing list.
Paragraph (version A):
Although HTTP is independent of the transport protocol, the "http"
scheme associates authority with the ability to receive TCP
connections on the indicated port of whatever host is identified
within the authority component.  Because HTTP/3 does not use TCP,
HTTP/3 cannot be used for direct access to the authoritative server
for a resource identified by an "http" URI.  However, protocol
extensions such as ALTSVC permit the authoritative server to identify
other services which are also authoritative and which might be
reachable over HTTP/3.
Paragraph (version B):
Although HTTP is independent of the transport protocol, the "http"
scheme associates authority with the ability to receive TCP
connections on the indicated port of whatever host is identified
within the authority component.  Because HTTP/3 does not use TCP,
HTTP/3 cannot be used for direct access to the authoritative server
for a resource identified by an "http" URI.  However, protocol
extensions such as ALTSVC permit the authoritative server to identify
other services that are also authoritative and that might be
reachable over HTTP/3.
Paragraph (version A):
A server MAY send one or more PUSH_PROMISE frames (see frame-push-
promise) before, after, or interleaved with the frames of a response
message.  These PUSH_PROMISE frames are not part of the response; see
server-push for more details.  These frames are not permitted in
pushed responses; a pushed response which includes PUSH_PROMISE
frames MUST be treated as a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version B):
A server MAY send one or more PUSH_PROMISE frames (see frame-push-
promise) before, after, or interleaved with the frames of a response
message.  These PUSH_PROMISE frames are not part of the response; see
server-push for more details.  These frames are not permitted in
pushed responses; a pushed response that includes PUSH_PROMISE frames
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
If the ":scheme" pseudo-header field identifies a scheme which has a
mandatory authority component (including "http" and "https"), the
request MUST contain either an ":authority" pseudo-header field or a
"Host" header field.  If these fields are present, they MUST NOT be
empty.  If both fields are present, they MUST contain the same value.
If the scheme does not have a mandatory authority component and none
is provided in the request target, the request MUST NOT contain the
":authority" pseudo-header and "Host" header fields.
Paragraph (version B):
If the ":scheme" pseudo-header field identifies a scheme that has a
mandatory authority component (including "http" and "https"), the
request MUST contain either an ":authority" pseudo-header field or a
"Host" header field.  If these fields are present, they MUST NOT be
empty.  If both fields are present, they MUST contain the same value.
If the scheme does not have a mandatory authority component and none
is provided in the request target, the request MUST NOT contain the
":authority" pseudo-header and "Host" header fields.
Paragraph (version A):
HTTP/3 uses QPACK field compression as described in QPACK, a
variation of HPACK which allows the flexibility to avoid compression-
induced head-of-line blocking.  See that document for additional
details.
Paragraph (version B):
HTTP/3 uses QPACK field compression as described in QPACK, a
variation of HPACK that allows the flexibility to avoid compression-
induced head-of-line blocking.  See that document for additional
details.
Paragraph (version A):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
SETTINGS_MAX_FIELD_SECTION_SIZE parameter.  An implementation which
has received this parameter SHOULD NOT send an HTTP message header
which exceeds the indicated size, as the peer will likely refuse to
process it.  However, because this limit is applied at each hop,
messages below this limit are not guaranteed to be accepted.
Paragraph (version B):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
SETTINGS_MAX_FIELD_SECTION_SIZE parameter.  An implementation that
has received this parameter SHOULD NOT send an HTTP message header
that exceeds the indicated size, as the peer will likely refuse to
process it.  However, because this limit is applied at each hop,
messages below this limit are not guaranteed to be accepted.
Paragraph (version A):
When the server rejects a request without performing any application
processing, it SHOULD abort its response stream with the error code
H3_REQUEST_REJECTED.  In this context, "processed" means that some
data from the stream was passed to some higher layer of software that
might have taken some action as a result.  The client can treat
requests rejected by the server as though they had never been sent at
all, thereby allowing them to be retried later on a new connection.
Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests
which were partially or fully processed.  When a server abandons a
response after partial processing, it SHOULD abort its response
stream with the error code H3_REQUEST_CANCELLED.
Paragraph (version B):
When the server rejects a request without performing any application
processing, it SHOULD abort its response stream with the error code
H3_REQUEST_REJECTED.  In this context, "processed" means that some
data from the stream was passed to some higher layer of software that
might have taken some action as a result.  The client can treat
requests rejected by the server as though they had never been sent at
all, thereby allowing them to be retried later on a new connection.
Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests
that were partially or fully processed.  When a server abandons a
response after partial processing, it SHOULD abort its response
stream with the error code H3_REQUEST_CANCELLED.
Paragraph (version A):
The TCP connection can be closed by either peer.  When the client
ends the request stream (that is, the receive stream at the proxy
enters the "Data Recvd" state), the proxy will set the FIN bit on its
connection to the TCP server.  When the proxy receives a packet with
the FIN bit set, it will terminate the send stream that it sends to
the client.  TCP connections which remain half-closed in a single
direction are not invalid, but are often handled poorly by servers,
so clients SHOULD NOT close a stream for sending while they still
expect to receive data from the target of the CONNECT.
Paragraph (version B):
The TCP connection can be closed by either peer.  When the client
ends the request stream (that is, the receive stream at the proxy
enters the "Data Recvd" state), the proxy will set the FIN bit on its
connection to the TCP server.  When the proxy receives a packet with
the FIN bit set, it will terminate the send stream that it sends to
the client.  TCP connections that remain half-closed in a single
direction are not invalid, but are often handled poorly by servers,
so clients SHOULD NOT close a stream for sending while they still
expect to receive data from the target of the CONNECT.
Paragraph (version A):
Server push is an interaction mode which permits a server to push a
request-response exchange to a client in anticipation of the client
making the indicated request.  This trades off network usage against
a potential latency gain.  HTTP/3 server push is similar to what is
described in HTTP/2 HTTP2, but uses different mechanisms.
Paragraph (version B):
Server push is an interaction mode that permits a server to push a
request-response exchange to a client in anticipation of the client
making the indicated request.  This trades off network usage against
a potential latency gain.  HTTP/3 server push is similar to what is
described in HTTP/2 HTTP2, but uses different mechanisms.
Paragraph (version A):
Each server push is identified by a unique Push ID.  This Push ID is
used in one or more PUSH_PROMISE frames (see frame-push-promise) that
carry the request fields, then included with the push stream which
ultimately fulfills those promises.  When the same Push ID is
promised on multiple request streams, the decompressed request field
sections MUST contain the same fields in the same order, and both the
name and the value in each field MUST be exact matches.
Paragraph (version B):
Each server push is identified by a unique Push ID.  This Push ID is
used in one or more PUSH_PROMISE frames (see frame-push-promise) that
carry the request fields, then included with the push stream, which
ultimately fulfills those promises.  When the same Push ID is
promised on multiple request streams, the decompressed request field
sections MUST contain the same fields in the same order, and both the
name and the value in each field MUST be exact matches.
Paragraph (version A):
The header section of the request message is carried by a
PUSH_PROMISE frame (see frame-push-promise) on the request stream
which generated the push.  This allows the server push to be
associated with a client request.
Paragraph (version B):
The header section of the request message is carried by a
PUSH_PROMISE frame (see frame-push-promise) on the request stream
that generated the push.  This allows the server push to be
associated with a client request.
Paragraph (version A):
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
PUSH_PROMISE frame carrying a request which is not cacheable, is not
known to be safe, that indicates the presence of a request body, or
for which it does not consider the server authoritative.
Paragraph (version B):
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
PUSH_PROMISE frame carrying a request that is not cacheable, is not
known to be safe, that indicates the presence of a request body, or
for which it does not consider the server authoritative.
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 no greater than any previously sent
value.
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 that 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 no greater than any previously sent
value.
Paragraph (version A):
An HTTP/3 implementation can immediately close the QUIC connection at
any time.  This results in sending a QUIC CONNECTION_CLOSE frame to
the peer indicating that the application layer has terminated the
connection.  The application error code in this frame indicates to
the peer why the connection is being closed.  See errors for error
codes which can be used when closing a connection in HTTP/3.
Paragraph (version B):
An HTTP/3 implementation can immediately close the QUIC connection at
any time.  This results in sending a QUIC CONNECTION_CLOSE frame to
the peer indicating that the application layer has terminated the
connection.  The application error code in this frame indicates to
the peer why the connection is being closed.  See errors for error
codes that can be used when closing a connection in HTTP/3.
Paragraph (version A):
For various reasons, the QUIC transport could indicate to the
application layer that the connection has terminated.  This might be
due to an explicit closure by the peer, a transport-level error, or a
change in network topology which interrupts connectivity.
Paragraph (version A):
If a connection terminates without a GOAWAY frame, clients MUST
assume that any request which was sent, whether in whole or in part,
might have been processed.
Paragraph (version B):
For various reasons, the QUIC transport could indicate to the
application layer that the connection has terminated.  This might be
due to an explicit closure by the peer, a transport-level error, or a
change in network topology that interrupts connectivity.
Paragraph (version B):
If a connection terminates without a GOAWAY frame, clients MUST
assume that any request that was sent, whether in whole or in part,
might have been processed.
Paragraph (version A):
If the stream header indicates a stream type which is not supported
by the recipient, the remainder of the stream cannot be consumed as
the semantics are unknown.  Recipients of unknown stream types MAY
abort reading of the stream with an error code of
H3_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be a
connection error of any kind.
Paragraph (version A):
Implementations MAY send stream types before knowing whether the peer
supports them.  However, stream types which could modify the state or
semantics of existing protocol components, including QPACK or other
extensions, MUST NOT be sent until the peer is known to support them.
Paragraph (version B):
If the stream header indicates a stream type that is not supported by
the recipient, the remainder of the stream cannot be consumed as the
semantics are unknown.  Recipients of unknown stream types MAY abort
reading of the stream with an error code of H3_STREAM_CREATION_ERROR,
but MUST NOT consider such streams to be a connection error of any
kind.
Paragraph (version B):
Implementations MAY send stream types before knowing whether the peer
supports them.  However, stream types that could modify the state or
semantics of existing protocol components, including QPACK or other
extensions, MUST NOT be sent until the peer is known to support them.
Paragraph (version A):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
H3_MISSING_SETTINGS.  Only one control stream per peer is permitted;
receipt of a second stream which claims to be a control stream MUST
be treated as a connection error of type H3_STREAM_CREATION_ERROR.
The sender MUST NOT close the control stream, and the receiver MUST
NOT request that the sender close the control stream.  If either
control stream is closed at any point, this MUST be treated as a
connection error of type H3_CLOSED_CRITICAL_STREAM.
Paragraph (version B):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
H3_MISSING_SETTINGS.  Only one control stream per peer is permitted;
receipt of a second stream claiming to be a control stream MUST be
treated as a connection error of type H3_STREAM_CREATION_ERROR.  The
sender MUST NOT close the control stream, and the receiver MUST NOT
request that the sender close the control stream.  If either control
stream is closed at any point, this MUST be treated as a connection
error of type H3_CLOSED_CRITICAL_STREAM.
Paragraph (version A):
HTTP frames are carried on QUIC streams, as described in stream-
mapping.  HTTP/3 defines three stream types: control stream, request
stream, and push stream.  This section describes HTTP/3 frame formats
and the streams types on which they are permitted; see stream-frame-
mapping for an overview.  A comparison between HTTP/2 and HTTP/3
frames is provided in h2-frames.
Paragraph (version B):
HTTP frames are carried on QUIC streams, as described in stream-
mapping.  HTTP/3 defines three stream types: control stream, request
stream, and push stream.  This section describes HTTP/3 frame formats
and their permitted stream types; see stream-frame-mapping for an
overview.  A comparison between HTTP/2 and HTTP/3 frames is provided
in h2-frames.
Paragraph (version A):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error (errors) of
type H3_FRAME_ERROR.  Streams which terminate abruptly may be reset
at any point in a frame.
Paragraph (version B):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error (errors) of
type H3_FRAME_ERROR.  Streams that terminate abruptly may be reset at
any point in a frame.
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 that 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):
SETTINGS parameters are not negotiated; they describe characteristics
of the sending peer, which can be used by the receiving peer.
However, a negotiation can be implied by the use of SETTINGS - each
peer uses SETTINGS to advertise a set of supported values.  The
definition of the setting would describe how each peer combines the
two sets to conclude which choice will be used.  SETTINGS does not
provide a mechanism to identify when the choice takes effect.
Paragraph (version B):
SETTINGS parameters are not negotiated; they describe characteristics
of the sending peer that can be used by the receiving peer.  However,
a negotiation can be implied by the use of SETTINGS - each peer uses
SETTINGS to advertise a set of supported values.  The definition of
the setting would describe how each peer combines the two sets to
conclude which choice will be used.  SETTINGS does not provide a
mechanism to identify when the choice takes effect.
Paragraph (version A):
An HTTP implementation MUST NOT send frames or requests which would
be invalid based on its current understanding of the peer's settings.
Paragraph (version B):
An HTTP implementation MUST NOT send frames or requests that would be
invalid based on its current understanding of the peer's settings.
Paragraph (version A):
A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data.  The server MUST
include all settings which differ from their default values.  If a
server accepts 0-RTT but then sends settings that are not compatible
with the previously specified settings, this MUST be treated as a
connection error of type H3_SETTINGS_ERROR.  If a server accepts
0-RTT but then sends a SETTINGS frame that omits a setting value that
the client understands (apart from reserved setting identifiers) that
was previously specified to have a non-default value, this MUST be
treated as a connection error of type H3_SETTINGS_ERROR.
Paragraph (version B):
A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data.  The server MUST
include all settings that differ from their default values.  If a
server accepts 0-RTT but then sends settings that are not compatible
with the previously specified settings, this MUST be treated as a
connection error of type H3_SETTINGS_ERROR.  If a server accepts
0-RTT but then sends a SETTINGS frame that omits a setting value that
the client understands (apart from reserved setting identifiers) that
was previously specified to have a non-default value, this MUST be
treated as a connection error of type H3_SETTINGS_ERROR.
Paragraph (version A):
Frame types which were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and receipt MAY be treated as an error of
type H3_FRAME_UNEXPECTED.
Paragraph (version B):
Frame types that were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and receipt MAY be treated as an error of
type H3_FRAME_UNEXPECTED.
Paragraph (version A):
This section describes HTTP/3-specific error codes which can be used
to express the cause of a connection or stream error.
Paragraph (version B):
This section describes HTTP/3-specific error codes that can be used
to express the cause of a connection or stream error.
Paragraph (version A):
Peer violated protocol requirements in a way which doesn't match a
more specific error code, or endpoint declines to use the more
specific error code.
Paragraph (version B):
Peer violated protocol requirements in a way that doesn't match a
more specific error code, or endpoint declines to use the more
specific error code.
Paragraph (version A):
A frame was received which was not permitted in the current state
or on the current stream.
Paragraph (version B):
A frame was received that was not permitted in the current state
or on the current stream.
Paragraph (version A):
The use of ALPN in the TLS and QUIC handshakes establishes the target
application protocol before application-layer bytes are processed.
Because all QUIC packets are encrypted, it is difficult for an
attacker to control the plaintext bytes of an HTTP/3 connection which
could be used in a cross-protocol attack on a plaintext protocol.
Paragraph (version B):
The use of ALPN in the TLS and QUIC handshakes establishes the target
application protocol before application-layer bytes are processed.
Because all QUIC packets are encrypted, it is difficult for an
attacker to control the plaintext bytes of an HTTP/3 connection,
which could be used in a cross-protocol attack on a plaintext
protocol.
Paragraph (version A):
The ability to send undefined protocol elements which the peer is
required to ignore can be abused to cause a peer to expend additional
processing time.  This might be done by setting multiple undefined
SETTINGS parameters, unknown frame types, or unknown stream types.
Note, however, that some uses are entirely legitimate, such as
optional-to-understand extensions and padding to increase resistance
to traffic analysis.
Paragraph (version B):
The ability to send undefined protocol elements that the peer is
required to ignore can be abused to cause a peer to expend additional
processing time.  This might be done by setting multiple undefined
SETTINGS parameters, unknown frame types, or unknown stream types.
Note, however, that some uses are entirely legitimate, such as
optional-to-understand extensions and padding to increase resistance
to traffic analysis.
Paragraph (version A):
The properties described in this document apply to all versions of
QUIC.  A protocol that does not conform to the properties described
in this document is not QUIC.  Future documents might describe
additional properties which apply to a specific QUIC version, or to a
range of QUIC versions.
Paragraph (version B):
The properties described in this document apply to all versions of
QUIC.  A protocol that does not conform to the properties described
in this document is not QUIC.  Future documents might describe
additional properties that apply to a specific QUIC version, or to a
range of QUIC versions.
Paragraph (version A):
Each Handshake layer message (e.g., Handshake, Alerts, and
Application Data) is carried as a series of typed TLS records by the
Record layer.  Records are individually cryptographically protected
and then transmitted over a reliable transport (typically TCP) which
provides sequencing and guaranteed delivery.
Paragraph (version B):
Each Handshake layer message (e.g., Handshake, Alerts, and
Application Data) is carried as a series of typed TLS records by the
Record layer.  Records are individually cryptographically protected
and then transmitted over a reliable transport (typically TCP), which
provides sequencing and guaranteed delivery.
Paragraph (version A):
A full 1-RTT handshake in which the client is able to send
Application Data after one round trip and the server immediately
responds after receiving the first handshake message from the
client.
Paragraph (version A):
A 0-RTT handshake in which the client uses information it has
previously learned about the server to send Application Data
immediately.  This Application Data can be replayed by an attacker
so it MUST NOT carry a self-contained trigger for any non-
idempotent action.
Paragraph (version B):
A full 1-RTT handshake, in which the client is able to send
Application Data after one round trip and the server immediately
responds after receiving the first handshake message from the
client.
Paragraph (version B):
A 0-RTT handshake, in which the client uses information it has
previously learned about the server to send Application Data
immediately.  This Application Data can be replayed by an attacker
so it MUST NOT carry a self-contained trigger for any non-
idempotent action.
Paragraph (version A):
Unlike TLS over TCP, QUIC applications which want to send data do not
send it through TLS "application_data" records.  Rather, they send it
as QUIC STREAM frames or other frame types which are then carried in
QUIC packets.
Paragraph (version B):
Unlike TLS over TCP, QUIC applications that want to send data do not
send it through TLS "application_data" records.  Rather, they send it
as QUIC STREAM frames or other frame types, which are then carried in
QUIC packets.
Paragraph (version A):
ACK frames MAY appear in any packet number space, but can only
acknowledge packets which appeared in that packet number space.
However, as noted below, 0-RTT packets cannot contain ACK frames.
Paragraph (version B):
ACK frames MAY appear in any packet number space, but can only
acknowledge packets that appeared in that packet number space.
However, as noted below, 0-RTT packets cannot contain ACK frames.
Paragraph (version A):
If the packet is from a previously installed encryption level, it
MUST NOT contain data which extends past the end of previously
received data in that flow.  Implementations MUST treat any
violations of this requirement as a connection error of type
PROTOCOL_VIOLATION.
Paragraph (version B):
If the packet is from a previously installed encryption level, it
MUST NOT contain data that extends past the end of previously
received data in that flow.  Implementations MUST treat any
violations of this requirement as a connection error of type
PROTOCOL_VIOLATION.
Paragraph (version A):
The output of this algorithm is a 5-byte mask which is applied to the
protected header fields using exclusive OR.  The least significant
bits of the first byte of the packet are masked by the least
significant bits of the first mask byte, and the packet number is
masked with the remaining bytes.  Any unused bytes of mask that might
result from a shorter packet number encoding are unused.
Paragraph (version B):
The output of this algorithm is a 5-byte mask that is applied to the
protected header fields using exclusive OR.  The least significant
bits of the first byte of the packet are masked by the least
significant bits of the first mask byte, and the packet number is
masked with the remaining bytes.  Any unused bytes of mask that might
result from a shorter packet number encoding are unused.
Paragraph (version A):
For example, an attacker could inject a packet containing an ACK
frame that makes it appear that a packet had not been received or to
create a false impression of the state of the connection (e.g., by
modifying the ACK Delay).  Note that such a packet could cause a
legitimate packet to be dropped as a duplicate.  Implementations
SHOULD use caution in relying on any data which is contained in
Initial packets that is not otherwise authenticated.
Paragraph (version B):
For example, an attacker could inject a packet containing an ACK
frame that makes it appear that a packet had not been received or to
create a false impression of the state of the connection (e.g., by
modifying the ACK Delay).  Note that such a packet could cause a
legitimate packet to be dropped as a duplicate.  Implementations
SHOULD use caution in relying on any data that is contained in
Initial packets that is not otherwise authenticated.
Paragraph (version A):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for
a QUIC connection to be delivered to the wrong endpoint.  Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with
that connection ID to be routed back to the endpoint and to be
identified by the endpoint upon receipt.
Paragraph (version B):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for
a QUIC connection to be delivered to the wrong endpoint.  Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method that will allow packets with that
connection ID to be routed back to the endpoint and to be identified
by the endpoint upon receipt.
Paragraph (version A):
An endpoint MUST ensure that every Stateless Reset that it sends is
smaller than the packet which triggered it, unless it maintains state
sufficient to prevent looping.  In the event of a loop, this results
in packets eventually being too small to trigger a response.
Paragraph (version B):
An endpoint MUST ensure that every Stateless Reset that it sends is
smaller than the packet that triggered it, unless it maintains state
sufficient to prevent looping.  In the event of a loop, this results
in packets eventually being too small to trigger a response.
Paragraph (version A):
Disposing of connection state prior to the end of the closing or
draining period could cause delayed or reordered packets to generate
an unnecessary stateless reset.  Endpoints that have some alternative
means to ensure that late-arriving packets on the connection do not
induce a response, such as those that are able to close the UDP
socket, MAY use an abbreviated draining period which can allow for
faster resource recovery.  Servers that retain an open socket for
accepting new connections SHOULD NOT exit the closing or draining
period early.
Paragraph (version B):
Disposing of connection state prior to the end of the closing or
draining period could cause delayed or reordered packets to generate
an unnecessary stateless reset.  Endpoints that have some alternative
means to ensure that late-arriving packets on the connection do not
induce a response, such as those that are able to close the UDP
socket, MAY use an abbreviated draining period to allow for faster
resource recovery.  Servers that retain an open socket for accepting
new connections SHOULD NOT exit the closing or draining period early.
Paragraph (version A):
Initial (packet-initial), 0-RTT (packet-0rtt), and Handshake (packet-
handshake) packets contain a Length field, which determines the end
of the packet.  The length includes both the Packet Number and
Payload fields, both of which are confidentiality protected and
initially of unknown length.  The length of the Payload field is
learned once header protection is removed.
Paragraph (version B):
Initial (packet-initial), 0-RTT (packet-0rtt), and Handshake (packet-
handshake) packets contain a Length field that determines the end of
the packet.  The length includes both the Packet Number and Payload
fields, both of which are confidentiality protected and initially of
unknown length.  The length of the Payload field is learned once
header protection is removed.
Paragraph (version A):
Conceptually, a packet number space is the context in which a packet
can be processed and acknowledged.  Initial packets can only be sent
with Initial packet protection keys and acknowledged in packets which
are also Initial packets.  Similarly, Handshake packets are sent at
the Handshake encryption level and can only be acknowledged in
Handshake packets.
Paragraph (version B):
Conceptually, a packet number space is the context in which a packet
can be processed and acknowledged.  Initial packets can only be sent
with Initial packet protection keys and acknowledged in packets that
are also Initial packets.  Similarly, Handshake packets are sent at
the Handshake encryption level and can only be acknowledged in
Handshake packets.
Paragraph (version A):
An endpoint MUST NOT send a non-ack-eliciting packet in response to a
non-ack-eliciting packet, even if there are packet gaps which precede
the received packet.  This avoids an infinite feedback loop of
acknowledgements, which could prevent the connection from ever
becoming idle.  Non-ack-eliciting packets are eventually acknowledged
when the endpoint sends an ACK frame in response to other events.
Paragraph (version B):
An endpoint MUST NOT send a non-ack-eliciting packet in response to a
non-ack-eliciting packet, even if there are packet gaps that precede
the received packet.  This avoids an infinite feedback loop of
acknowledgements, which could prevent the connection from ever
becoming idle.  Non-ack-eliciting packets are eventually acknowledged
when the endpoint sends an ACK frame in response to other events.
Paragraph (version A):
The QUIC Version is a 32-bit field that follows the first byte.
This field indicates which version of QUIC is in use and
determines how the rest of the protocol fields are interpreted.
Paragraph (version B):
The QUIC Version is a 32-bit field that follows the first byte.
This field indicates the version of QUIC that is in use and
determines how the rest of the protocol fields are interpreted.
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 that 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 remainder of the Version Negotiation packet is a list of 32-bit
versions which the server supports.
Paragraph (version B):
The remainder of the Version Negotiation packet is a list of 32-bit
versions that the server supports.
Paragraph (version A):
This version of QUIC defines a single packet type which uses the
short packet header.
Paragraph (version B):
This version of QUIC defines a single packet type that uses the short
packet header.
Paragraph (version A):
QUIC encodes transport parameters into a sequence of bytes, which are
then included in the cryptographic handshake.
Paragraph (version B):
QUIC encodes transport parameters into a sequence of bytes, which is
then included in the cryptographic handshake.
Paragraph (version A):
Contains additional ranges of packets which are alternately not
acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges.
Paragraph (version B):
Contains additional ranges of packets that are alternately not
acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges.
Paragraph (version A):
A variable-length integer containing the application protocol
error code (see app-error-codes) which indicates why the stream is
being closed.
Paragraph (version B):
A variable-length integer containing the application protocol
error code (see app-error-codes) that indicates why the stream is
being closed.
Paragraph (version A):
Loss or reordering can cause a MAX_STREAMS frame to be received which
states a lower stream limit than an endpoint has previously received.
MAX_STREAMS frames which do not increase the stream limit MUST be
ignored.
Paragraph (version B):
Loss or reordering can cause a MAX_STREAMS frame to be received that
state a lower stream limit than an endpoint has previously received.
MAX_STREAMS frames that do not increase the stream limit MUST be
ignored.
Paragraph (version A):
A variable-length integer indicating the stream which is blocked
due to flow control.
Paragraph (version B):
A variable-length integer indicating the stream that is blocked
due to flow control.
Paragraph (version A):
A variable-length integer error code which indicates the reason
for closing this connection.  A CONNECTION_CLOSE frame of type
0x1c uses codes from the space defined in transport-error-codes.
A CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see app-error-codes.
Paragraph (version B):
A variable-length integer error code that indicates the reason for
closing this connection.  A CONNECTION_CLOSE frame of type 0x1c
uses codes from the space defined in transport-error-codes.  A
CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see app-error-codes.
Paragraph (version A):
Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see pmtud), but the use of these
packets is extremely limited.  The only other type of packet that an
endpoint might accept is a stateless reset (stateless-reset) which
relies on the token being kept secret until it is used.
Paragraph (version B):
Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see pmtud), but the use of these
packets is extremely limited.  The only other type of packet that an
endpoint might accept is a stateless reset (stateless-reset), which
relies on the token being kept secret until it is used.
Paragraph (version A):
This document defines QUIC Version Negotiation packets in version-
negotiation, which can be used to negotiate the QUIC version used
between two endpoints.  However, this document does not specify how
this negotiation will be performed between this version and
subsequent future versions.  In particular, Version Negotiation
packets do not contain any mechanism to prevent version downgrade
attacks.  Future versions of QUIC that use Version Negotiation
packets MUST define a mechanism that is robust against version
downgrade attacks.
Paragraph (version B):
This document defines QUIC Version Negotiation packets in version-
negotiation that can be used to negotiate the QUIC version used
between two endpoints.  However, this document does not specify how
this negotiation will be performed between this version and
subsequent future versions.  In particular, Version Negotiation
packets do not contain any mechanism to prevent version downgrade
attacks.  Future versions of QUIC that use Version Negotiation
packets MUST define a mechanism that is robust against version
downgrade attacks.
Paragraph (version A):
Computing the server's first flight for a full handshake is
potentially expensive, requiring both a signature and a key exchange
computation.  In order to prevent computational DoS attacks, the
Retry packet provides a cheap token exchange mechanism which allows
servers to validate a client's IP address prior to doing any
expensive computations at the cost of a single round trip.  After a
successful handshake, servers can issue new tokens to a client which
will allow new connection establishment without incurring this cost.
Paragraph (version B):
Computing the server's first flight for a full handshake is
potentially expensive, requiring both a signature and a key exchange
computation.  In order to prevent computational DoS attacks, the
Retry packet provides a cheap token exchange mechanism that allows
servers to validate a client's IP address prior to doing any
expensive computations at the cost of a single round trip.  After a
successful handshake, servers can issue new tokens to a client, which
will allow new connection establishment without incurring this cost.
Paragraph (version A):
A blind attacker, one who injects packets without being able to
observe valid packets for a connection, is unlikely to be successful,
since packet protection ensures that valid packets are only generated
by endpoints which possess the key material established during the
handshake; see handshake and handshake-properties.  Similarly, any
active attacker that observes packets and attempts to insert new data
or modify existing data in those packets should not be able to
generate packets deemed valid by the receiving endpoint.
Paragraph (version B):
A blind attacker, one who injects packets without being able to
observe valid packets for a connection, is unlikely to be successful,
since packet protection ensures that valid packets are only generated
by endpoints that possess the key material established during the
handshake; see handshake and handshake-properties.  Similarly, any
active attacker that observes packets and attempts to insert new data
or modify existing data in those packets should not be able to
generate packets deemed valid by the receiving endpoint.