Draft: rfc9114

Commentary: This PR contains ( most ? ) of the changes to the HTTP/3 spec the RFC editor made directly . There are a few I 've chosen not to incorporate here . I will note them on the PR when they affect a particular line ; general ones are : - The tag produces parentheses in the .txt version for me , but apparently not for the RFC Editor . However , the XML still contains the correct output , so I 'm not currently planning to make changes . 
 I ca n't comment on a line I did n't change , but at line 116 , the RFC editor suggested adding a colon to produce : The colon does n't make sense to me , so I currently plan to ignore it , but noting it here for review . 
 supports references to other documents of the form , which renders as one might expect . In multiple locations , the draft makes multiple internal references ( ) which render as " see Section X.Y and Section X.Z " . The RFC Editor asks that these be changed to " Sections X.Y and X.Z " , but I 'm currently unaware of a way to do that within a document in kramdown . - suggestions appreciated . 
 You can use the format= attribute of < xref . So your example becomes Enjoy ! 
 Thank you ! That trick could be useful in a few other places as well . 
 Closed in . 
 Skimmed , but this looks good .
Paragraph (version A):
The QUIC transport protocol has several features that are desirable
in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment.  This document
describes a mapping of HTTP semantics over QUIC.  This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to HTTP/3.
Paragraph (version B):
The QUIC transport protocol has several features that are desirable
in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment.  This document
describes a mapping of HTTP semantics over QUIC.  This document also
identifies HTTP/2 features that are subsumed by QUIC and describes
how HTTP/2 extensions can be ported to HTTP/3.
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 and HTTP/2.  HTTP/1.1 has been used over a variety of
transport and session layers, while HTTP/2 has been used primarily
with TLS over TCP.  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.
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 and HTTP/2.  HTTP/1.1 has been used over a variety of
transport and session layers, while HTTP/2 has been used primarily
with TLS over TCP.  HTTP/3 supports the same semantics over a new
transport protocol: QUIC.
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.
Paragraph (version A):
This document defines HTTP/3, a mapping of HTTP semantics over the
QUIC transport protocol, drawing heavily on the design of HTTP/2.
HTTP/3 relies on QUIC to provide confidentiality and integrity
protection of data; peer authentication; and reliable, in-order, per-
stream delivery.  While delegating stream lifetime and flow control
issues to QUIC, a binary framing similar to the HTTP/2 framing is
used on each stream.  Some HTTP/2 features are subsumed by QUIC,
while other features are implemented atop QUIC.
Paragraph (version B):
This document defines HTTP/3: a mapping of HTTP semantics over the
QUIC transport protocol, drawing heavily on the design of HTTP/2.
HTTP/3 relies on QUIC to provide confidentiality and integrity
protection of data; peer authentication; and reliable, in-order, per-
stream delivery.  While delegating stream lifetime and flow-control
issues to QUIC, a binary framing similar to the HTTP/2 framing is
used on each stream.  Some HTTP/2 features are subsumed by QUIC,
while other features are implemented atop QUIC.
Paragraph (version A):
Multiplexing of requests is performed using the QUIC stream
abstraction, 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 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 A):
Connection Setup and Management (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 and Usage (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):
Error Handling (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 to HTTP/3 (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):
A transport-layer connection between two endpoints, using QUIC as
the transport protocol.
Paragraph (version B):
A transport-layer connection between two endpoints using QUIC as
the transport protocol.
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 B):
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 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 B):
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):
Connectivity problems (e.g., blocking UDP) can result in QUIC
connection establishment failure; clients SHOULD attempt to use TCP-
based versions of HTTP in this case.
Paragraph (version B):
Connectivity problems (e.g., blocking UDP) can result in a failure to
establish a QUIC connection; clients SHOULD attempt to use TCP-based
versions of HTTP in this case.
Paragraph (version A):
An HTTP origin can advertise 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 "h3" ALPN token.
Paragraph (version B):
An HTTP origin can advertise 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 "h3" ALPN token.
Paragraph (version A):
While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, HTTP/3-specific settings are
conveyed in the SETTINGS frame.  After the QUIC connection is
established, a SETTINGS frame (frame-settings) MUST be sent by each
endpoint as the initial frame of their respective HTTP control
stream; see control-streams.
Paragraph (version B):
While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, settings specific to HTTP/3
are conveyed in the SETTINGS frame (frame-settings).  After the QUIC
connection is established, a SETTINGS frame MUST be sent by each
endpoint as the initial frame of their respective HTTP control
stream; see control-streams.
Paragraph (version A):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
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 SEMANTICS.  This
implies that clients will need to retain the server certificate and
any additional information needed to verify that certificate; clients
which do not do so will be unable to reuse the connection for
additional origins.
Paragraph (version A):
If the certificate is not acceptable with regard to the new origin
for any reason, the connection MUST NOT be reused and a new
connection SHOULD be established for the new origin.  If the reason
the certificate cannot be verified might apply to other origins
already associated with the connection, the client SHOULD re-validate
the server certificate for those origins.  For instance, if
validation of a certificate fails because the certificate has expired
or been revoked, this might be used to invalidate all other origins
for which that certificate was used to establish authority.
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 Section 4.3.4 of SEMANTICS.  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):
If the certificate is not acceptable with regard to the new origin
for any reason, the connection MUST NOT be reused and a new
connection SHOULD be established for the new origin.  If the reason
the certificate cannot be verified might apply to other origins
already associated with the connection, the client SHOULD revalidate
the server certificate for those origins.  For instance, if
validation of a certificate fails because the certificate has expired
or been revoked, this might be used to invalidate all other origins
for which that certificate was used to establish authority.
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 SEMANTICS.  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):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections 6.3 and 6.5 of SEMANTICS.  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):
Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where
the field name begins with the ':' character (ASCII 0x3a).  These
pseudo-header fields convey the target URI, the method of the
request, and the status code for the response.
Paragraph (version B):
Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where
the field name begins with the ':' character (ASCII 0x3a).  These
pseudo-header fields convey the target URI, the method of the
request, and the status code for the response.
Paragraph (version B):
Contains the scheme portion of the target URI (Section 3.1 of
URI).
Paragraph (version A):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 15 of SEMANTICS.  This
pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (malformed).
Paragraph (version B):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 15 of SEMANTICS.  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
SEMANTICS.  Because this limit is applied separately by each
implementation which 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 Section 3.7 of
SEMANTICS.  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):
Once a request stream has been opened, the request MAY be cancelled
by either endpoint.  Clients cancel requests if the response is no
longer of interest; servers cancel requests if they are unable to or
choose not to respond.  When possible, it is RECOMMENDED that servers
send an HTTP response with an appropriate status code rather than
canceling a request it has already begun processing.
Paragraph (version B):
Once a request stream has been opened, the request MAY be cancelled
by either endpoint.  Clients cancel requests if the response is no
longer of interest; servers cancel requests if they are unable to or
choose not to respond.  When possible, it is RECOMMENDED that servers
send an HTTP response with an appropriate status code rather than
cancelling a request it has already begun processing.
Paragraph (version A):
When the server cancels a request without performing any application
processing, the request is considered "rejected."  The server 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.
Paragraph (version B):
When the server cancels a request without performing any application
processing, the request is considered "rejected".  The server 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.
Paragraph (version A):
If a stream is canceled 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 SEMANTICS 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 Section 9.2.2 of SEMANTICS for more
details.
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 Section 7.1 of SEMANTICS).
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 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 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):
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 SEMANTICS for more
detail.
Paragraph (version A):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of
SEMANTICS) or 101 (Switching Protocols) informational status code
(Section 15.2.2 of SEMANTICS).
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 Section 9.3.6 of SEMANTICS for more
details.
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of
SEMANTICS) or the 101 (Switching Protocols) informational status code
(Section 15.2.2 of SEMANTICS).
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 uses different mechanisms.
Paragraph (version A):
The Push ID space begins at zero, and ends at a maximum value set by
the MAX_PUSH_ID frame; see frame-max-push-id.  In particular, a
server is not able to push until after the client sends a MAX_PUSH_ID
frame.  A client sends MAX_PUSH_ID frames to control the number of
pushes that a server can promise.  A server SHOULD use Push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
push stream as a connection error of type H3_ID_ERROR (errors) when
no MAX_PUSH_ID frame has been sent or when the stream references a
Push ID that is greater than the maximum Push ID.
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 it uses different mechanisms.
Paragraph (version B):
The Push ID space begins at zero and ends at a maximum value set by
the MAX_PUSH_ID frame; see frame-max-push-id.  In particular, a
server is not able to push until after the client sends a MAX_PUSH_ID
frame.  A client sends MAX_PUSH_ID frames to control the number of
pushes that a server can promise.  A server SHOULD use Push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
push stream as a connection error of type H3_ID_ERROR (errors) when
no MAX_PUSH_ID frame has been sent or when the stream references a
Push ID that is greater than the maximum Push ID.
Paragraph (version A):
Each pushed response is associated with one or more client requests.
The push is associated with the request stream on which the
PUSH_PROMISE frame was received.  The same server push can be
associated with additional client requests using a PUSH_PROMISE frame
with the same Push ID on multiple request streams.  These
associations do not affect the operation of the protocol, but MAY be
considered by user agents when deciding how to use pushed resources.
Paragraph (version B):
Each pushed response is associated with one or more client requests.
The push is associated with the request stream on which the
PUSH_PROMISE frame was received.  The same server push can be
associated with additional client requests using a PUSH_PROMISE frame
with the same Push ID on multiple request streams.  These
associations do not affect the operation of the protocol, but they
MAY be considered by user agents when deciding how to use pushed
resources.
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 (see
Section 4.1 of QUIC-TRANSPORT) to limit the amount of data a server
may commit to the pushed stream.
Paragraph (version A):
Push stream data can also arrive after a client has canceled a push.
In this case, the client can abort reading the stream with an error
code of H3_REQUEST_CANCELLED.  This asks the server not to transfer
additional data and indicates that it will be discarded upon receipt.
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 (Section 4.1 of
QUIC-TRANSPORT) to limit the amount of data a server may commit to
the pushed stream.
Paragraph (version B):
Push stream data can also arrive after a client has cancelled a push.
In this case, the client can abort reading the stream with an error
code of H3_REQUEST_CANCELLED.  This asks the server not to transfer
additional data and indicates that it will be discarded upon receipt.
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 SHOULD do so if approaching the idle timeout; see
Section 10.1 of QUIC-TRANSPORT.
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
Section 10.1 of QUIC-TRANSPORT.
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 request-cancellation and frame-cancel-
push) any requests or pushes that have identifiers greater than or
equal to that 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):
Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the
remote peer can know whether a request has been partially processed
or not.  For example, if an HTTP client sends a POST at the same time
that a server closes a QUIC connection, the client cannot know if the
server started to process that POST request if the server does not
send a GOAWAY frame to indicate what streams it might have acted on.
Paragraph (version B):
Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the
remote peer can know whether or not a request has been partially
processed.  For example, if an HTTP client sends a POST at the same
time that a server closes a QUIC connection, the client cannot know
if the server started to process that POST request if the server does
not send a GOAWAY frame to indicate what streams it might have acted
on.
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 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 it 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):
When HTTP fields and data are sent over QUIC, the QUIC layer handles
most of the stream management.  HTTP does not need to do any separate
multiplexing when using QUIC - data sent over a QUIC stream always
maps to a particular HTTP transaction or to the entire HTTP/3
connection context.
Paragraph (version B):
When HTTP fields and data are sent over QUIC, the QUIC layer handles
most of the stream management.  HTTP does not need to do any separate
multiplexing when using QUIC: data sent over a QUIC stream always
maps to a particular HTTP transaction or to the entire HTTP/3
connection context.
Paragraph (version A):
This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on stream 4, 8, and so on.  In order to
permit these streams to open, an HTTP/3 server SHOULD configure non-
zero minimum values for the number of permitted streams and the
initial stream flow control window.  So as to not unnecessarily limit
parallelism, at least 100 request streams SHOULD be permitted at a
time.
Paragraph (version B):
This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on streams 4, 8, and so on.  In order to
permit these streams to open, an HTTP/3 server SHOULD configure non-
zero minimum values for the number of permitted streams and the
initial stream flow-control window.  So as to not unnecessarily limit
parallelism, at least 100 request streams SHOULD be permitted at a
time.
Paragraph (version A):
and SHOULD provide at least 1,024 bytes of flow control credit to
each stream.
Paragraph (version B):
and SHOULD provide at least 1,024 bytes of flow-control credit to
each stream.
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
or a reserved error code (http-error-codes), 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 the recipients MUST
NOT consider such streams to be a connection error of any kind.
Paragraph (version A):
Because the contents of the control stream are used to manage the
behavior of other streams, endpoints SHOULD provide enough flow
control credit to keep the peer's control stream from becoming
blocked.
Paragraph (version B):
Because the contents of the control stream are used to manage the
behavior of other streams, endpoints SHOULD provide enough flow-
control credit to keep the peer's control stream from becoming
blocked.
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 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):
The HEADERS frame (type=0x01) is used to carry an HTTP field section,
encoded using QPACK.  See QPACK for more details.
Paragraph (version A):
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 B):
The HEADERS frame (type=0x01) is used to carry an HTTP field section
that is encoded using QPACK.  See QPACK for more details.
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 of type H3_FRAME_UNEXPECTED; see
errors.
Paragraph (version A):
When a client sends CANCEL_PUSH, it is indicating that it does not
wish to receive the promised resource.  The server SHOULD abort
sending the resource, but the mechanism to do so depends on the state
of the corresponding push stream.  If the server has not yet created
a push stream, it does not create one.  If the push stream is open,
the server SHOULD abruptly terminate that stream.  If the push stream
has already ended, the server MAY still abruptly terminate the stream
or MAY take no action.
Paragraph (version A):
A server sends CANCEL_PUSH to indicate that it will not be fulfilling
a promise which was previously sent.  The client cannot expect the
corresponding promise to be fulfilled, unless it has already received
and processed the promised response.  Regardless of whether a push
stream has been opened, a server SHOULD send a CANCEL_PUSH frame when
it determines that promise will not be fulfilled.  If a stream has
already been opened, the server can abort sending on the stream with
an error code of H3_REQUEST_CANCELLED.
Paragraph (version B):
When a client sends a CANCEL_PUSH frame, it is indicating that it
does not wish to receive the promised resource.  The server SHOULD
abort sending the resource, but the mechanism to do so depends on the
state of the corresponding push stream.  If the server has not yet
created a push stream, it does not create one.  If the push stream is
open, the server SHOULD abruptly terminate that stream.  If the push
stream has already ended, the server MAY still abruptly terminate the
stream or MAY take no action.
Paragraph (version B):
A server sends a CANCEL_PUSH frame to indicate that it will not be
fulfilling a promise that was previously sent.  The client cannot
expect the corresponding promise to be fulfilled, unless it has
already received and processed the promised response.  Regardless of
whether a push stream has been opened, a server SHOULD send a
CANCEL_PUSH frame when it determines that promise will not be
fulfilled.  If a stream has already been opened, the server can abort
sending on the stream with an error code of H3_REQUEST_CANCELLED.
Paragraph (version A):
SETTINGS frames always apply to an entire HTTP/3 connection, never a
single stream.  A SETTINGS frame MUST be sent as the first frame of
each control stream (see control-streams) by each peer, and MUST NOT
be sent subsequently.  If an endpoint receives a second SETTINGS
frame on the control stream, the endpoint MUST respond with a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
SETTINGS frames always apply to an entire HTTP/3 connection, never a
single stream.  A SETTINGS frame MUST be sent as the first frame of
each control stream (see control-streams) by each peer, and it MUST
NOT be sent subsequently.  If an endpoint receives a second SETTINGS
frame on the control stream, the endpoint MUST respond with a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
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 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):
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):
Setting identifiers which were defined in HTTP2 where there is no
corresponding HTTP/3 setting have also been reserved (iana-settings).
These reserved settings MUST NOT be sent, and their receipt MUST be
treated as a connection error of type H3_SETTINGS_ERROR.
Paragraph (version B):
Setting identifiers that were defined in HTTP2 where there is no
corresponding HTTP/3 setting have also been reserved (iana-settings).
These reserved settings MUST NOT be sent, and their receipt MUST be
treated as a connection error of type H3_SETTINGS_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 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):
When a 0-RTT QUIC connection is being used, the initial value of each
server setting is the value used in the previous session.  Clients
SHOULD store the settings the server provided in the HTTP/3
connection where resumption information was provided, but MAY opt not
to store settings in certain cases (e.g., if the session ticket is
received before the SETTINGS frame).  A client MUST comply with
stored settings - or default values, if no values are stored - when
attempting 0-RTT.  Once a server has provided new settings, clients
MUST comply with those values.
Paragraph (version A):
A server can remember the settings that it advertised, or store an
integrity-protected copy of the values in the ticket and recover the
information when accepting 0-RTT data.  A server uses the HTTP/3
settings values in determining whether to accept 0-RTT data.  If the
server cannot determine that the settings remembered by a client are
compatible with its current settings, it MUST NOT accept 0-RTT data.
Remembered settings are compatible if a client complying with those
settings would not violate the server's current settings.
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 they SHOULD process received datagrams in order to increase the
likelihood of processing SETTINGS before sending the first request.
Paragraph (version B):
When a 0-RTT QUIC connection is being used, the initial value of each
server setting is the value used in the previous session.  Clients
SHOULD store the settings the server provided in the HTTP/3
connection where resumption information was provided, but they MAY
opt not to store settings in certain cases (e.g., if the session
ticket is received before the SETTINGS frame).  A client MUST comply
with stored settings - or default values if no values are stored -
when attempting 0-RTT.  Once a server has provided new settings,
clients MUST comply with those values.
Paragraph (version B):
A server can remember the settings that it advertised or store an
integrity-protected copy of the values in the ticket and recover the
information when accepting 0-RTT data.  A server uses the HTTP/3
settings values in determining whether to accept 0-RTT data.  If the
server cannot determine that the settings remembered by a client are
compatible with its current settings, it MUST NOT accept 0-RTT data.
Remembered settings are compatible if a client complying with those
settings would not violate the server's current settings.
Paragraph (version A):
The GOAWAY frame is always sent on the control stream.  In the server
to client direction, it carries a QUIC Stream ID for a client-
initiated bidirectional stream encoded as a variable-length integer.
A client MUST treat receipt of a GOAWAY frame containing a Stream ID
of any other type as a connection error of type H3_ID_ERROR.
Paragraph (version A):
In the client to server direction, the GOAWAY frame carries a Push ID
encoded as a variable-length integer.
Paragraph (version B):
The GOAWAY frame is always sent on the control stream.  In the
server-to-client direction, it carries a QUIC Stream ID for a client-
initiated bidirectional stream encoded as a variable-length integer.
A client MUST treat receipt of a GOAWAY frame containing a Stream ID
of any other type as a connection error of type H3_ID_ERROR.
Paragraph (version B):
In the client-to-server direction, the GOAWAY frame carries a Push ID
encoded as a variable-length integer.
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
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 which 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 A):
Although the reasons for closing streams and connections are called
"errors," these actions do not necessarily indicate a problem with
the connection or either implementation.  For example, a stream can
be reset if the requested resource is no longer needed.
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 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 B):
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):
Although the reasons for closing streams and connections are called
"errors", these actions do not necessarily indicate a problem with
the connection or either implementation.  For example, a stream can
be reset if the requested resource is no longer needed.
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 B):
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):
The client's stream terminated without containing a fully-formed
request.
Paragraph (version B):
The client's stream terminated without containing a fully formed
request.
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):
This document does not mandate a specific method for negotiating the
use of an extension but notes that a setting (settings-parameters)
could be used for that purpose.  If both peers set a value that
indicates willingness to use the extension, then the extension can be
used.  If a setting is used for extension negotiation, the default
value MUST be defined in such a fashion that the extension is
disabled if the setting is omitted.
Paragraph (version B):
This document does not mandate a specific method for negotiating the
use of an extension, but it notes that a setting (settings-
parameters) could be used for that purpose.  If both peers set a
value that indicates willingness to use the extension, then the
extension can be used.  If a setting is used for extension
negotiation, the default value MUST be defined in such a fashion that
the extension is disabled if the setting is omitted.
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
SEMANTICS).  Requests or responses containing invalid field names
MUST be treated as malformed (malformed).  An intermediary therefore
cannot translate an HTTP/3 request or response containing an invalid
field name into an HTTP/1.1 message.
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 (Section 5.1 of
SEMANTICS).  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):
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 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):
Reserved stream types can be used to give the appearance of sending
traffic even when the connection is idle.  Because HTTP traffic often
occurs in bursts, apparent traffic can be used to obscure the timing
or duration of such bursts, even to the point of appearing to send a
constant stream of data.  However, as such traffic is still flow
controlled by the receiver, a failure to promptly drain such streams
and provide additional flow control credit can limit the sender's
ability to send real traffic.
Paragraph (version B):
Reserved stream types can be used to give the appearance of sending
traffic even when the connection is idle.  Because HTTP traffic often
occurs in bursts, apparent traffic can be used to obscure the timing
or duration of such bursts, even to the point of appearing to send a
constant stream of data.  However, as such traffic is still flow
controlled by the receiver, a failure to promptly drain such streams
and provide additional flow-control credit can limit the sender's
ability to send real traffic.
Paragraph (version A):
This document registers a new ALPN protocol ID (iana-alpn) and
creates new registries that manage the assignment of codepoints in
HTTP/3.
Paragraph (version A):
This document creates a new registration for the identification of
HTTP/3 in the "Application-Layer Protocol Negotiation (ALPN) Protocol
IDs" registry established in RFC7301.
Paragraph (version B):
This document registers a new ALPN protocol ID (iana-alpn) and
creates new registries that manage the assignment of code points in
HTTP/3.
Paragraph (version B):
This document creates a new registration for the identification of
HTTP/3 in the "TLS Application-Layer Protocol Negotiation (ALPN)
Protocol IDs" registry established in RFC7301.
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 [SHALL be/are]
collected under a "Hypertext Transfer Protocol version 3 (HTTP/3)
Parameters" heading.
Paragraph (version A):
The initial allocations in these registries created in this document
are all assigned permanent status and list a change controller of the
IETF and a contact of the HTTP working group (ietf-http-wg@w3.org).
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 Sections 4.9 and 4.10
of RFC8126.
Paragraph (version B):
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):
The initial allocations in these registries are all assigned
permanent status and list a change controller of the IETF and a
contact of the HTTP working group (ietf-http-wg@w3.org).
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 4.9 and 4.10
of RFC8126.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in HTTP2, it is preferable that the assignments parallel each
other where the code spaces overlap.  If an entry is present in only
one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.  Expert reviewers MAY
reject unrelated registrations which would conflict with the same
value in the corresponding registry.
Paragraph (version B):
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in HTTP2, it is preferable that the assignments parallel each
other where the code spaces overlap.  If an entry is present in only
one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.  Expert reviewers MAY
reject unrelated registrations that would conflict with the same
value in the corresponding registry.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Settings" registry
defined in HTTP2, it is preferable that the assignments parallel each
other.  If an entry is present in only one registry, every effort
SHOULD be made to avoid assigning the corresponding value to an
unrelated operation.  Expert reviewers MAY reject unrelated
registrations which would conflict with the same value in the
corresponding registry.
Paragraph (version B):
While this registry is separate from the "HTTP/2 Settings" registry
defined in HTTP2, it is preferable that the assignments parallel each
other.  If an entry is present in only one registry, every effort
SHOULD be made to avoid assigning the corresponding value to an
unrelated operation.  Expert reviewers MAY reject unrelated
registrations that would conflict with the same value in the
corresponding registry.
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 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 4.9 and 4.10 of
RFC8126.
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 Sections 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 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.