Draft: draft-ietf-quic-http

Commentary: Those that did n't seem to warrant separate issues , anyway . 
 We explicitly discuss what the behavior should be for H2 frame types that do n't have corresponding H3 frames . The same sort of reservation with IANA is done with settings , but is n't explicitly stated in the definition of SETTINGS . 
 Arguably editorial , since the text in the  clearly implies this was already intended to be the case , but fixing entails new  and MAY statements . 
 Lets run this as design for visibility .
Paragraph (version A):
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org [1]), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Paragraph (version B):
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Paragraph (version A):
HTTP semantics SEMANTICS are used for a broad range of services on
the Internet.  These semantics have most commonly been used with
HTTP/1.1, over a variety of transport and session layers, and with
HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new
transport protocol, QUIC.
Paragraph (version B):
HTTP semantics (SEMANTICS) are used for a broad range of services on
the Internet.  These semantics have most commonly been used with
HTTP/1.1, over a variety of transport and session layers, and with
HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new
transport protocol, QUIC.
Paragraph (version A):
HTTP/1.1 HTTP11 uses whitespace-delimited text fields to convey HTTP
messages.  While these exchanges are human-readable, using whitespace
for message formatting leads to parsing complexity and excessive
tolerance of variant behavior.  Because HTTP/1.x does not include a
multiplexing layer, multiple TCP connections are often used to
service requests in parallel.  However, that has a negative impact on
congestion control and network efficiency, since TCP does not share
congestion control across multiple connections.
Paragraph (version A):
HTTP/2 HTTP2 introduced a binary framing and multiplexing layer to
improve latency without modifying the transport layer.  However,
because the parallel nature of HTTP/2's multiplexing is not visible
to TCP's loss recovery mechanisms, a lost or reordered packet causes
all active transactions to experience a stall regardless of whether
that transaction was directly impacted by the lost packet.
Paragraph (version B):
HTTP/1.1 (HTTP11) uses whitespace-delimited text fields to convey
HTTP messages.  While these exchanges are human-readable, using
whitespace for message formatting leads to parsing complexity and
excessive tolerance of variant behavior.  Because HTTP/1.x does not
include a multiplexing layer, multiple TCP connections are often used
to service requests in parallel.  However, that has a negative impact
on congestion control and network efficiency, since TCP does not
share congestion control across multiple connections.
Paragraph (version B):
HTTP/2 (HTTP2) introduced a binary framing and multiplexing layer to
improve latency without modifying the transport layer.  However,
because the parallel nature of HTTP/2's multiplexing is not visible
to TCP's loss recovery mechanisms, a lost or reordered packet causes
all active transactions to experience a stall regardless of whether
that transaction was directly impacted by the lost packet.
Paragraph (version A):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 TLS13 at the transport layer, offering
comparable security to running TLS over TCP, with the improved
connection setup latency of TCP Fast Open TFO.
Paragraph (version B):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 (TLS13) at the transport layer, offering
comparable security to running TLS over TCP, with the improved
connection setup latency of TCP Fast Open (TFO).
Paragraph (version A):
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 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):
As in HTTP/2, request and response fields are compressed for
transmission.  Because HPACK HPACK relies on in-order transmission of
compressed field sections (a guarantee not provided by QUIC), HTTP/3
replaces HPACK with QPACK QPACK.  QPACK uses separate unidirectional
streams to modify and track field table state, while encoded field
sections refer to the state of the table without modifying it.
Paragraph (version B):
As in HTTP/2, request and response fields are compressed for
transmission.  Because HPACK (HPACK) relies on in-order transmission
of compressed field sections (a guarantee not provided by QUIC),
HTTP/3 replaces HPACK with QPACK (QPACK).  QPACK uses separate
unidirectional streams to modify and track field table state, while
encoded field sections refer to the state of the table without
modifying it.
Paragraph (version B):
Packet diagrams in this document use the format defined in
Section 1.3 of QUIC-TRANSPORT to illustrate the order and size of
fields.
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 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 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 mailing list.
Paragraph (version A):
An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the Application Layer Protocol
Negotiation (ALPN) RFC7301 token defined in connection-establishment.
Paragraph (version B):
An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the Application Layer Protocol
Negotiation (ALPN; see RFC7301) token defined in connection-
establishment.
Paragraph (version A):
On receipt of an Alt-Svc record indicating HTTP/3 support, a client
MAY attempt to establish a QUIC connection to the indicated host and
port and, if successful, send HTTP requests using the mapping
described in this document.
Paragraph (version B):
On receipt of an Alt-Svc record indicating HTTP/3 support, a client
MAY attempt to establish a QUIC connection to the indicated host and
port; if this connection is successful, the client can send HTTP
requests using the mapping described in this document.
Paragraph (version A):
QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST support a mechanism to indicate the
target host to the server during the TLS handshake.  If the server is
identified by a DNS name, clients MUST send the Server Name
Indication (SNI) RFC6066 TLS extension unless an alternative
mechanism to indicate the target host is used.
Paragraph (version B):
QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST support a mechanism to indicate the
target host to the server during the TLS handshake.  If the server is
identified by a DNS name, clients MUST send the Server Name
Indication (SNI; RFC6066) TLS extension unless an alternative
mechanism to indicate the target host is used.
Paragraph (version A):
Clients SHOULD NOT open more than one HTTP/3 connection to a given
host and port pair, where the host is derived from a URI, a selected
alternative service ALTSVC, or a configured proxy.  A client MAY open
multiple connections to the same IP address and UDP port using
different transport or TLS configurations but SHOULD avoid creating
multiple connections with the same configuration.
Paragraph (version B):
Clients SHOULD NOT open more than one HTTP/3 connection to a given
host and port pair, where the host is derived from a URI, a selected
alternative service (ALTSVC), or a configured proxy.  A client MAY
open multiple connections to the same IP address and UDP port using
different transport or TLS configurations but SHOULD avoid creating
multiple connections with the same configuration.
Paragraph (version A):
A client sends an HTTP request on a client-initiated bidirectional
QUIC stream.  A client MUST send only a single request on a given
stream.  A server sends zero or more interim HTTP responses on the
same stream as the request, followed by a single final HTTP response,
as detailed below.
Paragraph (version B):
A client sends an HTTP request on a client-initiated bidirectional
QUIC stream.  A client MUST send only a single request on a given
stream.  A server sends zero or more interim HTTP responses on the
same stream as the request, followed by a single final HTTP response,
as detailed below.  See Section 10 of SEMANTICS for a description of
interim and final HTTP responses.
Paragraph (version A):
the header field section (see Section 5 of SEMANTICS), sent as a
single HEADERS frame (see frame-headers),
Paragraph (version A):
optionally, the payload body, if present (see Section 7.3.3 of
SEMANTICS), sent as a series of DATA frames (see frame-data),
Paragraph (version A):
optionally, the trailer field section, if present (see Section 5.6
of SEMANTICS), sent as a single HEADERS frame.
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 that includes PUSH_PROMISE frames
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
the header field section, sent as a single HEADERS frame (see
frame-headers),
Paragraph (version B):
optionally, the trailer field section, if present, sent as a
single HEADERS frame.
Paragraph (version B):
Header and trailer field sections are described in Section 5 of
SEMANTICS; the payload body is described in Section 7.3.3 of
SEMANTICS.
Paragraph (version B):
A server MAY send one or more PUSH_PROMISE frames (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):
A response MAY consist of multiple messages when and only when one or
more informational responses (1xx; see Section 10.2 of SEMANTICS)
precede a final response to the same request.  Interim responses do
not contain a payload body or trailers.
Paragraph (version B):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see Section 10.2 of SEMANTICS) precede a
final response to the same request.  Interim responses do not contain
a payload body or trailers.
Paragraph (version A):
When a stream is closed, this indicates the end of an HTTP message.
Because some messages are large or unbounded, endpoints SHOULD begin
processing partial HTTP messages once enough of the message has been
received to make progress.  If a client-initiated stream terminates
without enough of the HTTP message to provide a complete response,
the server SHOULD abort its response with the error code
H3_REQUEST_INCOMPLETE.
Paragraph (version B):
When a stream is closed, this indicates the end of the final HTTP
message.  Because some messages are large or unbounded, endpoints
SHOULD begin processing partial HTTP messages once enough of the
message has been received to make progress.  If a client-initiated
stream terminates without enough of the HTTP message to provide a
complete response, the server SHOULD abort its response with the
error code H3_REQUEST_INCOMPLETE.
Paragraph (version A):
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 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 or "Host" header fields.
Paragraph (version A):
To allow for better compression efficiency, the "Cookie" field
RFC6265 MAY be split into separate field lines, each with one or more
cookie-pairs, before compression.  If a decompressed field section
contains multiple cookie field lines, these MUST be concatenated into
a single octet string using the two-octet delimiter of 0x3B, 0x20
(the ASCII string "; ") before being passed into a context other than
HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP
server application.
Paragraph (version B):
To allow for better compression efficiency, the "Cookie" field
(RFC6265) MAY be split into separate field lines, each with one or
more cookie-pairs, before compression.  If a decompressed field
section contains multiple cookie field lines, these MUST be
concatenated into a single octet string using the two-octet delimiter
of 0x3B, 0x20 (the ASCII string "; ") before being passed into a
context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection,
or a generic HTTP server application.
Paragraph (version A):
For malformed requests, a server MAY send an HTTP response prior to
closing or resetting the stream.  Clients MUST NOT accept a malformed
response.  Note that these requirements are intended to protect
against several types of common attacks against HTTP; they are
deliberately strict because being permissive can expose
implementations to these vulnerabilities.
Paragraph (version B):
For malformed requests, a server MAY send an HTTP response indicating
the error prior to closing or resetting the stream.  Clients MUST NOT
accept a malformed response.  Note that these requirements are
intended to protect against several types of common attacks against
HTTP; they are deliberately strict because being permissive can
expose implementations to these vulnerabilities.
Paragraph (version A):
All DATA frames on the stream correspond to data sent or received on
the TCP connection.  Any DATA frame sent by the client is transmitted
by the proxy to the TCP server; data received from the TCP server is
packaged into DATA frames by the proxy.  Note that the size and
number of TCP segments is not guaranteed to map predictably to the
size and number of HTTP DATA or QUIC STREAM frames.
Paragraph (version A):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other frame type MUST be treated as a connection error of type
H3_FRAME_UNEXPECTED.
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 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 B):
All DATA frames on the stream correspond to data sent or received on
the TCP connection.  The payload of any DATA frame sent by the client
is transmitted by the proxy to the TCP server; data received from the
TCP server is packaged into DATA frames by the proxy.  Note that the
size and number of TCP segments is not guaranteed to map predictably
to the size and number of HTTP DATA or QUIC STREAM frames.
Paragraph (version B):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other known frame type MUST be treated as a connection error
of type H3_FRAME_UNEXPECTED.
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 close 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 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 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 Section 8.2 of HTTP2, but uses different mechanisms.
Paragraph (version A):
Ordering of a PUSH_PROMISE in relation to certain parts of the
response is important.  The server SHOULD send PUSH_PROMISE frames
prior to sending HEADERS or DATA frames that reference the promised
responses.  This reduces the chance that a client requests a resource
that will be pushed by the server.
Paragraph (version B):
Ordering of a PUSH_PROMISE frame in relation to certain parts of the
response is important.  The server SHOULD send PUSH_PROMISE frames
prior to sending HEADERS or DATA frames that reference the promised
responses.  This reduces the chance that a client requests a resource
that will be pushed by the server.
Paragraph (version A):
Pushed responses that are cacheable (see Section 3 of CACHING) can be
stored by the client, if it implements an HTTP cache.  Pushed
responses are considered successfully validated on the origin server
(e.g., if the "no-cache" cache response directive is present
(Section 5.2.2.3 of CACHING)) at the time the pushed response is
received.
Paragraph (version B):
Pushed responses that are cacheable (see Section 3 of CACHING) can be
stored by the client, if it implements an HTTP cache.  Pushed
responses are considered successfully validated on the origin server
(e.g., if the "no-cache" cache response directive is present; see
Section 5.2.2.3 of CACHING) at the time the pushed response is
received.
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 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 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.  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):
Once all accepted requests and pushes have been processed, the
endpoint can permit the connection to become idle, or MAY initiate an
immediate closure of the connection.  An endpoint that completes a
graceful shutdown SHOULD use the H3_NO_ERROR code when closing the
connection.
Paragraph (version B):
Once all accepted requests and pushes have been processed, the
endpoint can permit the connection to become idle, or MAY initiate an
immediate closure of the connection.  An endpoint that completes a
graceful shutdown SHOULD use the H3_NO_ERROR error code when closing
the connection.
Paragraph (version A):
Some stream types are reserved (stream-grease).  Two stream types are
defined in this document: control streams (control-streams) and push
streams (push-streams).  QPACK defines two additional stream types.
Other stream types can be defined by extensions to HTTP/3; see
extensions for more details.
Paragraph (version B):
Two stream types are defined in this document: control streams
(control-streams) and push streams (push-streams).  QPACK defines two
additional stream types.  Other stream types can be defined by
extensions to HTTP/3; see extensions for more details.  Some stream
types are reserved (stream-grease).
Paragraph (version A):
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):
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
or a reserved error code (http-error-codes), but MUST NOT consider
such streams to be a connection error of any kind.
Paragraph (version A):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type H3_FRAME_ERROR.
Paragraph (version B):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error (errors) of type H3_FRAME_ERROR.
Paragraph (version A):
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with an HTTP request or response payload.
Paragraph (version B):
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with an HTTP request or response payload body.
Paragraph (version A):
HEADERS frames can only be sent on request / push streams.  If a
HEADERS frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
HEADERS frames can only be sent on request or push streams.  If a
HEADERS frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
When a server sends CANCEL_PUSH, it is indicating that it will not be
fulfilling a promise.  The client cannot expect the corresponding
promise to be fulfilled, unless it has already received and processed
the promised response.  A server SHOULD send a CANCEL_PUSH even if it
has opened the corresponding stream.
Paragraph (version A):
Sending CANCEL_PUSH has no direct effect on the state of existing
push streams.  A client SHOULD NOT send a CANCEL_PUSH when it has
already received a corresponding push stream.  A push stream could
arrive after a client has sent CANCEL_PUSH, because a server might
not have processed the CANCEL_PUSH.  The client SHOULD abort reading
the stream with an error code of H3_REQUEST_CANCELLED.
Paragraph (version B):
When a server sends CANCEL_PUSH, it is indicating that it will not be
fulfilling a promise.  The client cannot expect the corresponding
promise to be fulfilled, unless it has already received and processed
the promised response.  A server SHOULD send a CANCEL_PUSH frame even
if it has opened the corresponding stream.
Paragraph (version B):
Sending a CANCEL_PUSH frame has no direct effect on the state of
existing push streams.  A client SHOULD NOT send a CANCEL_PUSH frame
when it has already received a corresponding push stream.  A push
stream could arrive after a client has sent a CANCEL_PUSH frame,
because a server might not have processed the CANCEL_PUSH.  The
client SHOULD abort reading the stream with an error code of
H3_REQUEST_CANCELLED.
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 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 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 server-push.  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):
For clients using a 1-RTT QUIC connection, the initial value of each
server setting is the default value.  1-RTT keys will always become
available prior to SETTINGS arriving, even if the server sends
SETTINGS immediately.  Clients SHOULD NOT wait indefinitely for
SETTINGS to arrive before sending requests, but SHOULD process
received datagrams in order to increase the likelihood of processing
SETTINGS before sending the first request.
Paragraph (version B):
For clients using a 1-RTT QUIC connection, the initial value of each
server setting is the default value.  1-RTT keys will always become
available prior to the packet containing SETTINGS being processed by
QUIC, even if the server sends SETTINGS immediately.  Clients SHOULD
NOT wait indefinitely for SETTINGS to arrive before sending requests,
but SHOULD process received datagrams in order to increase the
likelihood of processing SETTINGS before sending the first request.
Paragraph (version A):
A server MAY use the same Push ID in multiple PUSH_PROMISE frames.
If so, the decompressed request header sets MUST contain the same
fields in the same order, and both the name and the value in each
field MUST be exact matches.  Clients SHOULD compare the request
header sections for resources promised multiple times.  If a client
receives a Push ID that has already been promised and detects a
mismatch, it MUST respond with a connection error of type
H3_GENERAL_PROTOCOL_ERROR.  If the decompressed field sections match
exactly, the client SHOULD associate the pushed content with each
stream on which a PUSH_PROMISE was received.
Paragraph (version A):
Allowing duplicate references to the same Push ID is primarily to
reduce duplication caused by concurrent requests.  A server SHOULD
avoid reusing a Push ID over a long period.  Clients are likely to
consume server push responses and not retain them for reuse over
time.  Clients that see a PUSH_PROMISE that uses a Push ID that they
have already consumed and discarded are forced to ignore the
PUSH_PROMISE.
Paragraph (version B):
A server MAY use the same Push ID in multiple PUSH_PROMISE frames.
If so, the decompressed request header sets MUST contain the same
fields in the same order, and both the name and the value in each
field MUST be exact matches.  Clients SHOULD compare the request
header sections for resources promised multiple times.  If a client
receives a Push ID that has already been promised and detects a
mismatch, it MUST respond with a connection error of type
H3_GENERAL_PROTOCOL_ERROR.  If the decompressed field sections match
exactly, the client SHOULD associate the pushed content with each
stream on which a PUSH_PROMISE frame was received.
Paragraph (version B):
Allowing duplicate references to the same Push ID is primarily to
reduce duplication caused by concurrent requests.  A server SHOULD
avoid reusing a Push ID over a long period.  Clients are likely to
consume server push responses and not retain them for reuse over
time.  Clients that see a PUSH_PROMISE frame that uses a Push ID that
they have already consumed and discarded are forced to ignore the
promise.
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 server-push.  A MAX_PUSH_ID frame cannot reduce the maximum Push
ID; receipt of a MAX_PUSH_ID frame 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; for example, see request-response.
Paragraph (version A):
Similarly, HTTP/3 allows field values that are not valid.  While most
of the values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.4 of SEMANTICS.
Paragraph (version B):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.4 of SEMANTICS.
Paragraph (version A):
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (settings-
parameters) setting to advise peers of limits that might apply on the
size of field sections.  This setting is only advisory, so endpoints
MAY choose to send field sections that exceed this limit and risk
having the request or response being treated as malformed.  This
setting is specific to a connection, so any request or response could
encounter a hop with a lower, unknown limit.  An intermediary can
attempt to avoid this problem by passing on values presented by
different peers, but they are not obligated to do so.
Paragraph (version A):
A server that receives a larger field section than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status
code RFC6585.  A client can discard responses that it cannot process.
Paragraph (version A):
The CONNECT method can be used to create disproportionate load on an
proxy, since stream creation is relatively inexpensive when compared
to the creation and maintenance of a TCP connection.  A proxy might
also maintain some resources for a TCP connection beyond the closing
of the stream that carries the CONNECT request, since the outgoing
TCP connection remains in the TIME_WAIT state.  Therefore, a proxy
cannot rely on QUIC stream limits alone to control the resources
consumed by CONNECT requests.
Paragraph (version B):
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (header-size-
constraints) setting to advise peers of limits that might apply on
the size of field sections.  This setting is only advisory, so
endpoints MAY choose to send field sections that exceed this limit
and risk having the request or response being treated as malformed.
This setting is specific to a connection, so any request or response
could encounter a hop with a lower, unknown limit.  An intermediary
can attempt to avoid this problem by passing on values presented by
different peers, but they are not obligated to do so.
Paragraph (version B):
A server that receives a larger field section than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status
code (RFC6585).  A client can discard responses that it cannot
process.
Paragraph (version B):
The CONNECT method can be used to create disproportionate load on a
proxy, since stream creation is relatively inexpensive when compared
to the creation and maintenance of a TCP connection.  A proxy might
also maintain some resources for a TCP connection beyond the closing
of the stream that carries the CONNECT request, since the outgoing
TCP connection remains in the TIME_WAIT state.  Therefore, a proxy
cannot rely on QUIC stream limits alone to control the resources
consumed by CONNECT requests.
Paragraph (version A):
Implementations communicating on a secure channel MUST NOT compress
content that includes both confidential and attacker-controlled data
unless separate compression dictionaries are used for each source of
data.  Compression MUST NOT be used if the source of data cannot be
reliably determined.
Paragraph (version B):
Implementations communicating on a secure channel MUST NOT compress
content that includes both confidential and attacker-controlled data
unless separate compression contexts are used for each source of
data.  Compression MUST NOT be used if the source of data cannot be
reliably determined.
Paragraph (version A):
This document establishes a registry for HTTP/3 frame type codes.
The "HTTP/3 Frame Type" registry governs a 62-bit space.  This
registry follows the QUIC registry policy; see iana-policy.
Permanent registrations in this registry are assigned using the
Specification Required policy RFC8126, except for values between 0x00
and 0x3f (in hexadecimal; inclusive), which are assigned using
Standards Action or IESG Approval as defined in Section 4.9 and 4.10
of RFC8126.
Paragraph (version B):
This document establishes a registry for HTTP/3 frame type codes.
The "HTTP/3 Frame Type" registry governs a 62-bit space.  This
registry follows the QUIC registry policy; see iana-policy.
Permanent registrations in this registry are assigned using the
Specification Required policy (RFC8126), except for values between
0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
Standards Action or IESG Approval as defined in Section 4.9 and 4.10
of RFC8126.
Paragraph (version A):
This document establishes a registry for HTTP/3 settings.  The
"HTTP/3 Settings" registry governs a 62-bit space.  This registry
follows the QUIC registry policy; see iana-policy.  Permanent
registrations in this registry are assigned using the Specification
Required policy RFC8126, except for values between 0x00 and 0x3f (in
hexadecimal; inclusive), which are assigned using Standards Action or
IESG Approval as defined in Section 4.9 and 4.10 of RFC8126.
Paragraph (version B):
This document establishes a registry for HTTP/3 settings.  The
"HTTP/3 Settings" registry governs a 62-bit space.  This registry
follows the QUIC registry policy; see iana-policy.  Permanent
registrations in this registry are assigned using the Specification
Required policy (RFC8126), except for values between 0x00 and 0x3f
(in hexadecimal; inclusive), which are assigned using Standards
Action or IESG Approval as defined in Section 4.9 and 4.10 of
RFC8126.
Paragraph (version A):
This document establishes a registry for HTTP/3 error codes.  The
"HTTP/3 Error Code" registry manages a 62-bit space.  This registry
follows the QUIC registry policy; see iana-policy.  Permanent
registrations in this registry are assigned using the Specification
Required policy RFC8126, except for values between 0x00 and 0x3f (in
hexadecimal; inclusive), which are assigned using Standards Action or
IESG Approval as defined in Section 4.9 and 4.10 of RFC8126.
Paragraph (version A):
A name for the error code.  Specifying an error code name is
optional.
Paragraph (version A):
The entries in the iana-error-table are registered by this document.
Paragraph (version B):
This document establishes a registry for HTTP/3 error codes.  The
"HTTP/3 Error Code" registry manages a 62-bit space.  This registry
follows the QUIC registry policy; see iana-policy.  Permanent
registrations in this registry are assigned using the Specification
Required policy (RFC8126), except for values between 0x00 and 0x3f
(in hexadecimal; inclusive), which are assigned using Standards
Action or IESG Approval as defined in Section 4.9 and 4.10 of
RFC8126.
Paragraph (version B):
A name for the error code.
Paragraph (version B):
The entries in iana-error-table are registered by this document.
Paragraph (version A):
This document establishes a registry for HTTP/3 unidirectional stream
types.  The "HTTP/3 Stream Type" registry governs a 62-bit space.
This registry follows the QUIC registry policy; see iana-policy.
Permanent registrations in this registry are assigned using the
Specification Required policy RFC8126, except for values between 0x00
and 0x3f (in hexadecimal; inclusive), which are assigned using
Standards Action or IESG Approval as defined in Section 4.9 and 4.10
of RFC8126.
Paragraph (version B):
This document establishes a registry for HTTP/3 unidirectional stream
types.  The "HTTP/3 Stream Type" registry governs a 62-bit space.
This registry follows the QUIC registry policy; see iana-policy.
Permanent registrations in this registry are assigned using the
Specification Required policy (RFC8126), except for values between
0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
Standards Action or IESG Approval as defined in Section 4.9 and 4.10
of RFC8126.
Paragraph (version A):
Specifications for permanent registrations MUST include a description
of the stream type, including the layout semantics of the stream
contents.
Paragraph (version B):
Specifications for permanent registrations MUST include a description
of the stream type, including the layout and semantics of the stream
contents.