Draft: rfc9114

Commentary: The diff looks larger than it is ; I moved some sections around to more closely resemble the TOC of the HTTP/2 spec , and changed a section title that seemed a bit odd a year later . The relocated sections have n't changed . Old TOC : HTTP Request Lifecycle HTTP Message Exchanges Field Formatting and Compression Request Cancellation and Rejection Malformed Requests and Responses The CONNECT Method HTTP Upgrade Server Push New TOC : Expressing HTTP Semantics in HTTP/3 HTTP Message Framing Request Cancellation and Rejection Malformed Requests and Responses HTTP Fields HTTP Control Data           The CONNECT Method HTTP Upgrade Server Push Comparison H2 TOC : Expressing HTTP Semantics in HTTP/2 HTTP Message Framing Malformed Messages HTTP Fields Field Validity Connection - Specific Header Fields Compressing the Cookie Header Field HTTP Control Data          Fields Server Push Push Requests Push Responses The CONNECT Method The Upgrade Header Field then some further sections as well . 
 Http - core introduces a new term , " control data , " and HTTP/2 has been updated to use this term . HTTP/3 has not . While it was not raised in Auth48 , it might be appropriate to align this terminology before we publish these documents together . 
 This seems like a good change for consistency , even if it might cause the document editor some short term pain . 
 Closed in .
Paragraph (version A):
the header section, sent as a single HEADERS frame (see frame-
headers),
Paragraph (version B):
the header section, including message control data, sent as a
single HEADERS frame (see frame-headers),
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 A):
Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in this
document; however, an extension could negotiate a modification of
this restriction; see extensions.
Paragraph (version A):
HTTP/3 does not define a way to carry the version identifier that is
included in the HTTP/1.1 request line.
Paragraph (version A):
HTTP/3 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line.
Paragraph (version A):
QPACK describes a variation of HPACK that gives an encoder some
control over how much head-of-line blocking can be caused by
compression.  This allows an encoder to balance compression
efficiency with latency.  HTTP/3 uses QPACK to compress header and
trailer sections, including the pseudo-header fields present in the
header section.
Paragraph (version B):
QPACK describes a variation of HPACK that gives an encoder some
control over how much head-of-line blocking can be caused by
compression.  This allows an encoder to balance compression
efficiency with latency.  HTTP/3 uses QPACK to compress header and
trailer sections, including the control data present in the header
section.
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 message control data; see HTTP.
Paragraph (version B):
Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in this
document.  However, an extension could negotiate a modification of
this restriction; see extensions.
Paragraph (version B):
HTTP/3 does not define a way to carry the version identifier that is
included in the HTTP/1.1 request line.  HTTP/3 requests implicitly
have a protocol version of "3.0".
Paragraph (version B):
HTTP/3 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line.  HTTP/3 responses
implicitly have a protocol version of "3.0".
Paragraph (version A):
The Push ID is used in one or more PUSH_PROMISE frames (frame-push-
promise) that carry the header section of the request message.  These
frames are sent on the request stream that generated the push.  This
allows the server push to be associated with a client request.  When
the same Push ID is promised on multiple request streams, the
decompressed request field sections MUST contain the same fields in
the same order, and both the name and the value in each field MUST be
identical.
Paragraph (version B):
The Push ID is used in one or more PUSH_PROMISE frames (frame-push-
promise) that carry the control data and header fields of the request
message.  These frames are sent on the request stream that generated
the push.  This allows the server push to be associated with a client
request.  When the same Push ID is promised on multiple request
streams, the decompressed request field sections MUST contain the
same fields in the same order, and both the name and the value in
each field MUST be identical.