Draft: rfc9114

Commentary: Of note : Replace the BCP14 boilerplate with the bcp14 - tagged invocation , which causes all the BCP14 terms to get the appropriate tags by kramdown - rfc2629 Change all instance of to Add angle brackets to the one bare URL in the document The removal of backticks was apparently a tooling issue , not a deliberate change -- their XML still places around these segments , which the backticks map to , but their text output does not include which my text output does when the backticks are present . I 've restored them , to have the XML correct , and they can finagle the text output as desired . Remove any unused figure / table anchors , except one place where I a reference instead to match the parallel sections . Use the same format for the Acknowledgements list as RFC9000 ( albeit a bit different from what the RFC Editor changed it to ) . 
 I went the other way when it came to figure references , but this is fine .
Paragraph (version A):
Multiplexing of requests is performed using the QUIC stream
abstraction, which is described in Section 2 of QUIC-TRANSPORT.  Each
request-response pair consumes a single QUIC stream.  Streams are
independent of each other, so one stream that is blocked or suffers
packet loss does not prevent progress on other streams.
Paragraph (version B):
Multiplexing of requests is performed using the QUIC stream
abstraction, which is described in QUIC-TRANSPORT.  Each request-
response pair consumes a single QUIC stream.  Streams are independent
of each other, so one stream that is blocked or suffers packet loss
does not prevent progress on other streams.
Paragraph (version A):
"<<connection-setup" (connection-setup) covers how an HTTP/3
endpoint is discovered and an HTTP/3 connection is established.
Paragraph (version A):
"<<http-request-lifecycle" (http-request-lifecycle) describes how
HTTP semantics are expressed using frames.
Paragraph (version A):
"<<connection-closure" (connection-closure) describes how HTTP/3
connections are terminated, either gracefully or abruptly.
Paragraph (version A):
"<<stream-mapping" (stream-mapping) describes the way QUIC streams
are used.
Paragraph (version A):
"<<http-framing-layer" (http-framing-layer) describes the frames
used on most streams.
Paragraph (version A):
"<<errors" (errors) describes how error conditions are handled and
expressed, either on a particular stream or for the connection as
a whole.
Paragraph (version A):
"<<extensions" (extensions) describes how new capabilities can be
added in future documents.
Paragraph (version B):
"connection-setup" (connection-setup) covers how an HTTP/3
endpoint is discovered and an HTTP/3 connection is established.
Paragraph (version B):
"http-request-lifecycle" (http-request-lifecycle) describes how
HTTP semantics are expressed using frames.
Paragraph (version B):
"connection-closure" (connection-closure) describes how HTTP/3
connections are terminated, either gracefully or abruptly.
Paragraph (version B):
"stream-mapping" (stream-mapping) describes the way QUIC streams
are used.
Paragraph (version B):
"http-framing-layer" (http-framing-layer) describes the frames
used on most streams.
Paragraph (version B):
"errors" (errors) describes how error conditions are handled and
expressed, either on a particular stream or for the connection as
a whole.
Paragraph (version B):
"extensions" (extensions) describes how new capabilities can be
added in future documents.
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version A):
An abrupt termination of a connection or stream, possibly due to
an error condition.
Paragraph (version A):
The endpoint that initiates an HTTP/3 connection.  Clients send
HTTP requests and receive HTTP responses.
Paragraph (version A):
A transport-layer connection between two endpoints using QUIC as
the transport protocol.
Paragraph (version A):
An error that affects the entire HTTP/3 connection.
Paragraph (version A):
Either the client or server of the connection.
Paragraph (version A):
The smallest unit of communication on a stream in HTTP/3,
consisting of a header and a variable-length sequence of bytes
structured according to the frame type.  Protocol elements called
"frames" exist in both this document and QUIC-TRANSPORT.  Where
frames from QUIC-TRANSPORT are referenced, the frame name will be
prefaced with "QUIC".  For example, "QUIC CONNECTION_CLOSE
frames".  References without this preface refer to frames defined
in frames.
Paragraph (version A):
A QUIC connection where the negotiated application protocol is
HTTP/3.
Paragraph (version A):
An endpoint.  When discussing a particular endpoint, "peer" refers
to the endpoint that is remote to the primary subject of
discussion.
Paragraph (version A):
An endpoint that is receiving frames.
Paragraph (version A):
An endpoint that is transmitting frames.
Paragraph (version A):
The endpoint that accepts an HTTP/3 connection.  Servers receive
HTTP requests and send HTTP responses.
Paragraph (version A):
A bidirectional or unidirectional bytestream provided by the QUIC
transport.  All streams within an HTTP/3 connection can be
considered "HTTP/3 streams", but multiple stream types are defined
within HTTP/3.
Paragraph (version A):
An application-level error on the individual stream.
Paragraph (version A):
The term "content" is defined in Section 6.4 of HTTP.
Paragraph (version A):
Finally, the terms "resource", "message", "user agent", "origin
server", "gateway", "intermediary", "proxy", and "tunnel" are defined
in Section 3 of HTTP.
Paragraph (version A):
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 B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.
Paragraph (version B):
The term "content" is defined in HTTP.
Paragraph (version B):
Finally, the terms "resource", "message", "user agent", "origin
server", "gateway", "intermediary", "proxy", and "tunnel" are defined
in HTTP.
Paragraph (version B):
Packet diagrams in this document use the format defined in QUIC-
TRANSPORT to illustrate the order and size of fields.
Paragraph (version A):
HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin
server identified within the target URI.  Locating an authoritative
server for an HTTP URI is discussed in Section 4.3 of HTTP.
Paragraph (version A):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URI.  Upon receiving a
server certificate in the TLS handshake, the client MUST verify that
the certificate is an acceptable match for the URI's origin server
using the process described in Section 4.3.4 of HTTP.  If the
certificate cannot be verified with respect to the URI's origin
server, the client MUST NOT consider the server authoritative for
that origin.
Paragraph (version B):
HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin
server identified within the target URI.  Locating an authoritative
server for an HTTP URI is discussed in HTTP.
Paragraph (version B):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URI.  Upon receiving a
server certificate in the TLS handshake, the client MUST verify that
the certificate is an acceptable match for the URI's origin server
using the process described in HTTP.  If the certificate cannot be
verified with respect to the URI's origin server, the client MUST NOT
consider the server authoritative for that origin.
Paragraph (version A):
Once a connection to a server endpoint exists, this connection MAY be
reused for requests with multiple different URI authority components.
To use an existing connection for a new origin, clients MUST validate
the certificate presented by the server for the new origin server
using the process described in Section 4.3.4 of HTTP.  This implies
that clients will need to retain the server certificate and any
additional information needed to verify that certificate; clients
that do not do so will be unable to reuse the connection for
additional origins.
Paragraph (version B):
Once a connection to a server endpoint exists, this connection MAY be
reused for requests with multiple different URI authority components.
To use an existing connection for a new origin, clients MUST validate
the certificate presented by the server for the new origin server
using the process described in HTTP.  This implies that clients will
need to retain the server certificate and any additional information
needed to verify that certificate; clients that do not do so will be
unable to reuse the connection for additional origins.
Paragraph (version A):
A server that does not wish clients to reuse HTTP/3 connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 7.4 of HTTP.
Paragraph (version B):
A server that does not wish clients to reuse HTTP/3 connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see HTTP.
Paragraph (version A):
A client sends an HTTP request on a request stream, which is a
client-initiated bidirectional QUIC stream; see request-streams.  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 15 of HTTP for a description of interim and final HTTP
responses.
Paragraph (version B):
A client sends an HTTP request on a request stream, which is a
client-initiated bidirectional QUIC stream; see request-streams.  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 HTTP for a description of interim and final HTTP responses.
Paragraph (version A):
Header and trailer sections are described in Sections 6.3 and 6.5 of
HTTP; the content is described in Section 6.4 of HTTP.
Paragraph (version B):
Header and trailer sections are described in Sections HTTP and HTTP
of HTTP; the content is described in HTTP.
Paragraph (version A):
Transfer codings (see Section 7 of HTTP11) are not defined for
HTTP/3; the Transfer-Encoding header field MUST NOT be used.
Paragraph (version A):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see Section 15.2 of HTTP) precede a
final response to the same request.  Interim responses do not contain
content or trailer sections.
Paragraph (version B):
Transfer codings (see HTTP11) are not defined for HTTP/3; the
Transfer-Encoding header field MUST NOT be used.
Paragraph (version B):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see HTTP) precede a final response to
the same request.  Interim responses do not contain content or
trailer sections.
Paragraph (version A):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections 6.3 and 6.5 of HTTP.  For a listing of
registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP)
Field Name Registry" maintained at <https://www.iana.org/assignments/
http-fields/>.
Paragraph (version A):
Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more
detail in Section 5.1 of HTTP.  As in HTTP/2, characters in field
names MUST be converted to lowercase prior to their encoding.  A
request or response containing uppercase characters in field names
MUST be treated as malformed (malformed).
Paragraph (version B):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections HTTP and HTTP of HTTP.  For a listing of
registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP)
Field Name Registry" maintained at <https://www.iana.org/assignments/
http-fields/>.
Paragraph (version B):
Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more
detail in HTTP.  As in HTTP/2, characters in field names MUST be
converted to lowercase prior to their encoding.  A request or
response containing uppercase characters in field names MUST be
treated as malformed (malformed).
Paragraph (version A):
An intermediary transforming an HTTP/1.x message to HTTP/3 MUST
remove connection-specific header fields as discussed in
Section 7.6.1 of HTTP, or their messages will be treated by other
HTTP/3 endpoints as malformed (malformed).
Paragraph (version B):
An intermediary transforming an HTTP/1.x message to HTTP/3 MUST
remove connection-specific header fields as discussed in HTTP, or
their messages will be treated by other HTTP/3 endpoints as malformed
(malformed).
Paragraph (version A):
Contains the scheme portion of the target URI (Section 3.1 of
URI).
Paragraph (version A):
":scheme" is not restricted to URIs with scheme "http" and
"https".  A proxy or gateway can translate requests for non-HTTP
schemes, enabling the use of HTTP to interact with non-HTTP
services.
Paragraph (version A):
See other-schemes for guidance on using a scheme other than
"https".
Paragraph (version A):
Contains the authority portion of the target URI (Section 3.2 of
URI).  The authority MUST NOT include the deprecated "userinfo"
subcomponent for URIs of scheme "http" or "https".
Paragraph (version A):
To ensure that the HTTP/1.1 request line can be reproduced
accurately, this pseudo-header field MUST be omitted when
translating from an HTTP/1.1 request that has a request target in
origin or asterisk form; see Section 7.1 of HTTP.  Clients that
generate HTTP/3 requests directly SHOULD use the ":authority"
pseudo-header field instead of the Host field.  An intermediary
that converts an HTTP/3 request to HTTP/1.1 MUST create a Host
field if one is not present in a request by copying the value of
the ":authority" pseudo-header field.
Paragraph (version A):
Contains the path and query parts of the target URI (the "path-
absolute" production and optionally a '?' character followed by
the "query" production; see Sections 3.3 and 3.4 of URI.  A
request in asterisk form includes the value '*' for the ":path"
pseudo-header field.
Paragraph (version A):
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'.  The exception to this rule is an
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field
with a value of '*'; see Section 7.1 of HTTP.
Paragraph (version A):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 15 of HTTP.  This pseudo-
header field MUST be included in all responses; otherwise, the
response is malformed (see malformed).
Paragraph (version B):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see HTTP.  This pseudo-header field
MUST be included in all responses; otherwise, the response is
malformed (see malformed).
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 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, an HTTP message can traverse one or more
intermediaries before reaching the origin server; see Section 3.7 of
HTTP.  Because this limit is applied separately by each
implementation that processes the message, 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, an HTTP message can traverse one or more
intermediaries before reaching the origin server; see HTTP.  Because
this limit is applied separately by each implementation that
processes the message, messages below this limit are not guaranteed
to be accepted.
Paragraph (version A):
Implementations SHOULD cancel requests by abruptly terminating any
directions of a stream that are still open.  To do so, an
implementation resets the sending parts of streams and aborts reading
on the receiving parts of streams; see Section 2.4 of QUIC-TRANSPORT.
Paragraph (version B):
Implementations SHOULD cancel requests by abruptly terminating any
directions of a stream that are still open.  To do so, an
implementation resets the sending parts of streams and aborts reading
on the receiving parts of streams; see QUIC-TRANSPORT.
Paragraph (version A):
If a stream is cancelled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Only idempotent actions such as GET,
PUT, or DELETE can be safely retried; a client SHOULD NOT
automatically retry a request with a non-idempotent method unless it
has some means to know that the request semantics are idempotent
independent of the method or some means to detect that the original
request was never applied.  See Section 9.2.2 of HTTP for more
details.
Paragraph (version B):
If a stream is cancelled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Only idempotent actions such as GET,
PUT, or DELETE can be safely retried; a client SHOULD NOT
automatically retry a request with a non-idempotent method unless it
has some means to know that the request semantics are idempotent
independent of the method or some means to detect that the original
request was never applied.  See HTTP for more details.
Paragraph (version A):
A request or response that is defined as having content when it
contains a Content-Length header field (Section 6.4.1 of HTTP), is
malformed if the value of a Content-Length header field does not
equal the sum of the DATA frame lengths received.  A response that is
defined as never having content, even when a Content-Length is
present, can have a non-zero Content-Length field even though no
content is included in DATA frames.
Paragraph (version B):
A request or response that is defined as having content when it
contains a Content-Length header field (HTTP), is malformed if the
value of a Content-Length header field does not equal the sum of the
DATA frame lengths received.  A response that is defined as never
having content, even when a Content-Length is present, can have a
non-zero Content-Length field even though no content is included in
DATA frames.
Paragraph (version A):
The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target; see
Section 9.3.6 of HTTP.  It is primarily used with HTTP proxies to
establish a TLS session with an origin server for the purposes of
interacting with "https" resources.
Paragraph (version B):
The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target; see
HTTP.  It is primarily used with HTTP proxies to establish a TLS
session with an origin server for the purposes of interacting with
"https" resources.
Paragraph (version A):
The ":authority" pseudo-header field contains the host and port to
connect to (equivalent to the authority-form of the request-target
of CONNECT requests; see Section 7.1 of HTTP).
Paragraph (version B):
The ":authority" pseudo-header field contains the host and port to
connect to (equivalent to the authority-form of the request-target
of CONNECT requests; see HTTP).
Paragraph (version A):
A proxy that supports CONNECT establishes a TCP connection (RFC0793)
to the server identified in the ":authority" pseudo-header field.
Once this connection is successfully established, the proxy sends a
HEADERS frame containing a 2xx series status code to the client, as
defined in Section 15.3 of HTTP.
Paragraph (version B):
A proxy that supports CONNECT establishes a TCP connection (RFC0793)
to the server identified in the ":authority" pseudo-header field.
Once this connection is successfully established, the proxy sends a
HEADERS frame containing a 2xx series status code to the client, as
defined in HTTP.
Paragraph (version A):
Since CONNECT creates a tunnel to an arbitrary server, proxies that
support CONNECT SHOULD restrict its use to a set of known ports or a
list of safe request targets; see Section 9.3.6 of HTTP for more
details.
Paragraph (version A):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of
HTTP) or the 101 (Switching Protocols) informational status code
(Section 15.2.2 of HTTP).
Paragraph (version B):
Since CONNECT creates a tunnel to an arbitrary server, proxies that
support CONNECT SHOULD restrict its use to a set of known ports or a
list of safe request targets; see HTTP for more details.
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (HTTP) or the 101
(Switching Protocols) informational status code (HTTP).
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 Section 8.2 of HTTP2, but it 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 HTTP2, but it uses different mechanisms.
Paragraph (version A):
Due to reordering, push stream data can arrive before the
corresponding PUSH_PROMISE frame.  When a client receives a new push
stream with an as-yet-unknown Push ID, both the associated client
request and the pushed request header fields are unknown.  The client
can buffer the stream data in expectation of the matching
PUSH_PROMISE.  The client can use stream flow control (Section 4.1 of
QUIC-TRANSPORT) to limit the amount of data a server may commit to
the pushed stream.  Clients SHOULD abort reading and discard data
already read from push streams if no corresponding PUSH_PROMISE frame
is processed in a reasonable amount of time.
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; see
Section 5.2.2.3 of CACHING) at the time the pushed response is
received.
Paragraph (version B):
Due to reordering, push stream data can arrive before the
corresponding PUSH_PROMISE frame.  When a client receives a new push
stream with an as-yet-unknown Push ID, both the associated client
request and the pushed request header fields are unknown.  The client
can buffer the stream data in expectation of the matching
PUSH_PROMISE.  The client can use stream flow control (QUIC-
TRANSPORT) to limit the amount of data a server may commit to the
pushed stream.  Clients SHOULD abort reading and discard data already
read from push streams if no corresponding PUSH_PROMISE frame is
processed in a reasonable amount of time.
Paragraph (version B):
Pushed responses that are cacheable (see 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 CACHING) at the
time the pushed response is received.
Paragraph (version A):
Each QUIC endpoint declares an idle timeout during the handshake.  If
the QUIC connection remains idle (no packets received) for longer
than this duration, the peer will assume that the connection has been
closed.  HTTP/3 implementations will need to open a new HTTP/3
connection for new requests if the existing connection has been idle
for longer than the idle timeout negotiated during the QUIC
handshake, and they SHOULD do so if approaching the idle timeout; see
Section 10.1 of QUIC-TRANSPORT.
Paragraph (version A):
HTTP clients are expected to request that the transport keep
connections open while there are responses outstanding for requests
or server pushes, as described in Section 10.1.2 of QUIC-TRANSPORT.
If the client is not expecting a response from the server, allowing
an idle connection to time out is preferred over expending effort
maintaining a connection that might not be needed.  A gateway MAY
maintain connections in anticipation of need rather than incur the
latency cost of connection establishment to servers.  Servers SHOULD
NOT actively keep connections open.
Paragraph (version B):
Each QUIC endpoint declares an idle timeout during the handshake.  If
the QUIC connection remains idle (no packets received) for longer
than this duration, the peer will assume that the connection has been
closed.  HTTP/3 implementations will need to open a new HTTP/3
connection for new requests if the existing connection has been idle
for longer than the idle timeout negotiated during the QUIC
handshake, and they SHOULD do so if approaching the idle timeout; see
QUIC-TRANSPORT.
Paragraph (version B):
HTTP clients are expected to request that the transport keep
connections open while there are responses outstanding for requests
or server pushes, as described in QUIC-TRANSPORT.  If the client is
not expecting a response from the server, allowing an idle connection
to time out is preferred over expending effort maintaining a
connection that might not be needed.  A gateway MAY maintain
connections in anticipation of need rather than incur the latency
cost of connection establishment to servers.  Servers SHOULD NOT
actively keep connections open.
Paragraph (version A):
The information in the GOAWAY frame enables a client and server to
agree on which requests or pushes were accepted prior to the shutdown
of the HTTP/3 connection.  Upon sending a GOAWAY frame, the endpoint
SHOULD explicitly cancel (see Sections <request-cancellation and
<frame-cancel-push) any requests or pushes that have identifiers
greater than or equal to the one indicated, in order to clean up
transport state for the affected streams.  The endpoint SHOULD
continue to do so as more requests or pushes arrive.
Paragraph (version B):
The information in the GOAWAY frame enables a client and server to
agree on which requests or pushes were accepted prior to the shutdown
of the HTTP/3 connection.  Upon sending a GOAWAY frame, the endpoint
SHOULD explicitly cancel (see Sections request-cancellation and
frame-cancel-push) any requests or pushes that have identifiers
greater than or equal to the one indicated, in order to clean up
transport state for the affected streams.  The endpoint SHOULD
continue to do so as more requests or pushes arrive.
Paragraph (version A):
If there are open streams that have not been explicitly closed, they
are implicitly closed when the connection is closed; see Section 10.2
of QUIC-TRANSPORT.
Paragraph (version B):
If there are open streams that have not been explicitly closed, they
are implicitly closed when the connection is closed; see QUIC-
TRANSPORT.
Paragraph (version A):
QUIC streams can be either unidirectional, carrying data only from
initiator to receiver, or bidirectional, carrying data in both
directions.  Streams can be initiated by either the client or the
server.  For more detail on QUIC streams, see Section 2 of QUIC-
TRANSPORT.
Paragraph (version B):
QUIC streams can be either unidirectional, carrying data only from
initiator to receiver, or bidirectional, carrying data in both
directions.  Streams can be initiated by either the client or the
server.  For more detail on QUIC streams, see QUIC-TRANSPORT.
Paragraph (version A):
Stream types of the format 0x1f * N + 0x21 for non-negative integer
values of N are reserved to exercise the requirement that unknown
types be ignored.  These streams have no semantics, and they can be
sent when application-layer padding is desired.  They MAY also be
sent on connections where no data is currently being transferred.
Endpoints MUST NOT consider these streams to have any meaning upon
receipt.
Paragraph (version B):
Stream types of the format "0x1f * N + 0x21" for non-negative integer
values of "N" are reserved to exercise the requirement that unknown
types be ignored.  These streams have no semantics, and they can be
sent when application-layer padding is desired.  They MAY also be
sent on connections where no data is currently being transferred.
Endpoints MUST NOT consider these streams to have any meaning upon
receipt.
Paragraph (version A):
A variable-length integer that identifies the frame type.
Paragraph (version A):
A variable-length integer that describes the length in bytes of
the Frame Payload.
Paragraph (version A):
A payload, the semantics of which are determined by the Type
field.
Paragraph (version A):
The default value is unlimited.  See header-size-constraints for
usage.
Paragraph (version A):
Setting identifiers of the format 0x1f * N + 0x21 for non-negative
integer values of N are reserved to exercise the requirement that
unknown identifiers be ignored.  Such settings have no defined
meaning.  Endpoints SHOULD include at least one such setting in their
SETTINGS frame.  Endpoints MUST NOT consider such settings to have
any meaning upon receipt.
Paragraph (version B):
Setting identifiers of the format "0x1f * N + 0x21" for non-negative
integer values of "N" are reserved to exercise the requirement that
unknown identifiers be ignored.  Such settings have no defined
meaning.  Endpoints SHOULD include at least one such setting in their
SETTINGS frame.  Endpoints MUST NOT consider such settings to have
any meaning upon receipt.
Paragraph (version A):
A variable-length integer that identifies the server push
operation.  A Push ID is used in push stream headers (server-push)
and CANCEL_PUSH frames (frame-cancel-push).
Paragraph (version A):
QPACK-encoded request header fields for the promised response.
See QPACK for more details.
Paragraph (version A):
Frame types of the format 0x1f * N + 0x21 for non-negative integer
values of N are reserved to exercise the requirement that unknown
types be ignored (extensions).  These frames have no semantics, and
they MAY be sent on any stream where frames are allowed to be sent.
This enables their use for application-layer padding.  Endpoints MUST
NOT consider these frames to have any meaning upon receipt.
Paragraph (version B):
Frame types of the format "0x1f * N + 0x21" for non-negative integer
values of "N" are reserved to exercise the requirement that unknown
types be ignored (extensions).  These frames have no semantics, and
they MAY be sent on any stream where frames are allowed to be sent.
This enables their use for application-layer padding.  Endpoints MUST
NOT consider these frames to have any meaning upon receipt.
Paragraph (version A):
When a stream cannot be completed successfully, QUIC allows the
application to abruptly terminate (reset) that stream and communicate
a reason; see Section 2.4 of QUIC-TRANSPORT.  This is referred to as
a "stream error".  An HTTP/3 implementation can decide to close a
QUIC stream and communicate the type of error.  Wire encodings of
error codes are defined in http-error-codes.  Stream errors are
distinct from HTTP status codes that indicate error conditions.
Stream errors indicate that the sender did not transfer or consume
the full request or response, while HTTP status codes indicate the
result of a request that was successfully received.
Paragraph (version A):
If an entire connection needs to be terminated, QUIC similarly
provides mechanisms to communicate a reason; see Section 5.3 of QUIC-
TRANSPORT.  This is referred to as a "connection error".  Similar to
stream errors, an HTTP/3 implementation can terminate a QUIC
connection and communicate the reason using an error code from http-
error-codes.
Paragraph (version B):
When a stream cannot be completed successfully, QUIC allows the
application to abruptly terminate (reset) that stream and communicate
a reason; see QUIC-TRANSPORT.  This is referred to as a "stream
error".  An HTTP/3 implementation can decide to close a QUIC stream
and communicate the type of error.  Wire encodings of error codes are
defined in http-error-codes.  Stream errors are distinct from HTTP
status codes that indicate error conditions.  Stream errors indicate
that the sender did not transfer or consume the full request or
response, while HTTP status codes indicate the result of a request
that was successfully received.
Paragraph (version B):
If an entire connection needs to be terminated, QUIC similarly
provides mechanisms to communicate a reason; see QUIC-TRANSPORT.
This is referred to as a "connection error".  Similar to stream
errors, an HTTP/3 implementation can terminate a QUIC connection and
communicate the reason using an error code from http-error-codes.
Paragraph (version A):
No error.  This is used when the connection or stream needs to be
closed, but there is no error to signal.
Paragraph (version A):
Peer violated protocol requirements in a way that does not match a
more specific error code or endpoint declines to use the more
specific error code.
Paragraph (version A):
An internal error has occurred in the HTTP stack.
Paragraph (version A):
The endpoint detected that its peer created a stream that it will
not accept.
Paragraph (version A):
A stream required by the HTTP/3 connection was closed or reset.
Paragraph (version A):
A frame was received that was not permitted in the current state
or on the current stream.
Paragraph (version A):
A frame that fails to satisfy layout requirements or with an
invalid size was received.
Paragraph (version A):
The endpoint detected that its peer is exhibiting a behavior that
might be generating excessive load.
Paragraph (version A):
A Stream ID or Push ID was used incorrectly, such as exceeding a
limit, reducing a limit, or being reused.
Paragraph (version A):
An endpoint detected an error in the payload of a SETTINGS frame.
Paragraph (version A):
No SETTINGS frame was received at the beginning of the control
stream.
Paragraph (version A):
A server rejected a request without performing any application
processing.
Paragraph (version A):
The request or its response (including pushed response) is
cancelled.
Paragraph (version A):
The client's stream terminated without containing a fully formed
request.
Paragraph (version A):
An HTTP message was malformed and cannot be processed.
Paragraph (version A):
The TCP connection established in response to a CONNECT request
was reset or abnormally closed.
Paragraph (version A):
The requested operation cannot be served over HTTP/3.  The peer
should retry over HTTP/1.1.
Paragraph (version A):
Error codes of the format 0x1f * N + 0x21 for non-negative integer
values of N are reserved to exercise the requirement that unknown
error codes be treated as equivalent to H3_NO_ERROR (extensions).
Implementations SHOULD select an error code from this space with some
probability when they would have sent H3_NO_ERROR.
Paragraph (version B):
Error codes of the format "0x1f * N + 0x21" for non-negative integer
values of "N" are reserved to exercise the requirement that unknown
error codes be treated as equivalent to H3_NO_ERROR (extensions).
Implementations SHOULD select an error code from this space with some
probability when they would have sent H3_NO_ERROR.
Paragraph (version A):
The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS.  However, many of the considerations from
Section 10 of HTTP2 apply to QUIC-TRANSPORT and are discussed in that
document.
Paragraph (version A):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in
Section 17.1 of HTTP.
Paragraph (version B):
The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS.  However, many of the considerations from HTTP2
apply to QUIC-TRANSPORT and are discussed in that document.
Paragraph (version B):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in HTTP.
Paragraph (version A):
This does not guarantee protection from all cross-protocol attacks.
Section 21.5 of QUIC-TRANSPORT describes some ways in which the
plaintext of QUIC packets can be used to perform request forgery
against endpoints that don't use authenticated transports.
Paragraph (version A):
The HTTP/3 field encoding allows the expression of names that are not
valid field names in the syntax used by HTTP (Section 5.1 of HTTP).
Requests or responses containing invalid field names MUST be treated
as malformed (malformed).  Therefore, an intermediary cannot
translate an HTTP/3 request or response containing an invalid field
name into an HTTP/1.1 message.
Paragraph (version B):
This does not guarantee protection from all cross-protocol attacks.
QUIC-TRANSPORT describes some ways in which the plaintext of QUIC
packets can be used to perform request forgery against endpoints that
don't use authenticated transports.
Paragraph (version B):
The HTTP/3 field encoding allows the expression of names that are not
valid field names in the syntax used by HTTP (HTTP).  Requests or
responses containing invalid field names MUST be treated as malformed
(malformed).  Therefore, an intermediary cannot translate an HTTP/3
request or response containing an invalid field name into an HTTP/1.1
message.
Paragraph (version A):
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 0x0d), line feed (LF, ASCII 0x0a), and the
zero character (NUL, ASCII 0x00) 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.5 of HTTP.
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 0x0d), line feed (LF, ASCII 0x0a), and the
zero character (NUL, ASCII 0x00) 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 HTTP.
Paragraph (version A):
Compression of field sections also offers some opportunities to waste
processing resources; see Section 7 of QPACK for more details on
potential abuses.
Paragraph (version B):
Compression of field sections also offers some opportunities to waste
processing resources; see QPACK for more details on potential abuses.
Paragraph (version A):
Compression can allow an attacker to recover secret data when it is
compressed in the same context as data under attacker control.
HTTP/3 enables compression of fields (header-formatting); the
following concerns also apply to the use of HTTP compressed content-
codings; see Section 8.4.1 of HTTP.
Paragraph (version B):
Compression can allow an attacker to recover secret data when it is
compressed in the same context as data under attacker control.
HTTP/3 enables compression of fields (header-formatting); the
following concerns also apply to the use of HTTP compressed content-
codings; see HTTP.
Paragraph (version A):
Where HTTP/2 employs PADDING frames and Padding fields in other
frames to make a connection more resistant to traffic analysis,
HTTP/3 can either rely on transport-layer padding or employ the
reserved frame and stream types discussed in Sections <frame-reserved
and <stream-grease.  These methods of padding produce different
results in terms of the granularity of padding, how padding is
arranged in relation to the information that is being protected,
whether padding is applied in the case of packet loss, and how an
implementation might control padding.
Paragraph (version B):
Where HTTP/2 employs PADDING frames and Padding fields in other
frames to make a connection more resistant to traffic analysis,
HTTP/3 can either rely on transport-layer padding or employ the
reserved frame and stream types discussed in Sections frame-reserved
and stream-grease.  These methods of padding produce different
results in terms of the granularity of padding, how padding is
arranged in relation to the information that is being protected,
whether padding is applied in the case of packet loss, and how an
implementation might control padding.
Paragraph (version A):
New registries created in this document operate under the QUIC
registration policy documented in Section 22.1 of QUIC-TRANSPORT.
These registries all include the common set of fields listed in
Section 22.1.1 of QUIC-TRANSPORT.  These registries are collected
under the "Hypertext Transfer Protocol version 3 (HTTP/3)" heading.
Paragraph (version B):
New registries created in this document operate under the QUIC
registration policy documented in QUIC-TRANSPORT.  These registries
all include the common set of fields listed in QUIC-TRANSPORT.  These
registries are collected under the "Hypertext Transfer Protocol
version 3 (HTTP/3)" heading.
Paragraph (version A):
This document establishes a registry for HTTP/3 frame type codes.
The "HTTP/3 Frame Types" 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 Sections 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 Types" 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 Sections RFC8126 and
RFC8126 of RFC8126.
Paragraph (version A):
A name or label for the frame type.
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 Sections 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 Sections RFC8126 and RFC8126 of
RFC8126.
Paragraph (version A):
A symbolic name for the setting.  Specifying a setting name is
optional.
Paragraph (version A):
The value of the setting unless otherwise indicated.  A default
SHOULD be the most restrictive possible value.
Paragraph (version A):
This document establishes a registry for HTTP/3 error codes.  The
"HTTP/3 Error Codes" 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 Sections 4.9 and 4.10 of
RFC8126.
Paragraph (version B):
This document establishes a registry for HTTP/3 error codes.  The
"HTTP/3 Error Codes" 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 Sections RFC8126 and RFC8126 of
RFC8126.
Paragraph (version A):
A name for the error code.
Paragraph (version A):
A brief description of the error code semantics.
Paragraph (version A):
Standards Action or IESG Approval as defined in Sections 4.9 and 4.10
of RFC8126.
Paragraph (version A):
A name or label for the stream type.
Paragraph (version A):
Which endpoint on an HTTP/3 connection may initiate a stream of
this type.  Values are "Client", "Server", or "Both".
Paragraph (version A):
The entries in the following table are registered by this document.
Paragraph (version B):
Standards Action or IESG Approval as defined in Sections RFC8126 and
RFC8126 of RFC8126.
Paragraph (version B):
The entries in iana-stream-type-table are registered by this
document.