Original text:
An HTTP message (request or response) consists of: <del> the header section, sent as a single HEADERS frame (see frame- headers), </del>  optionally, the content, if present, sent as a series of DATA frames (see frame-data), and 4.1.1. <del> 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/>. 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). Like HTTP/2, HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as malformed (malformed). The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain any value other than "trailers". 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). 4.1.1.1. 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. 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. Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests.  Pseudo-header fields MUST NOT appear in trailer sections.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (malformed). All pseudo-header fields MUST appear in the header section before regular header fields.  Any request or response that contains a pseudo-header field that appears in a header section after a regular header field MUST be treated as malformed (malformed). The following pseudo-header fields are defined for requests: All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless the request is a CONNECT request; see connect. If the ":scheme" pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the request MUST contain either an ":authority" pseudo-header field or a "Host" header field.  If these fields are present, they MUST NOT be empty.  If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the ":authority" pseudo-header or "Host" header fields. An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those pseudo-header fields is malformed (malformed). HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line. 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). HTTP/3 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line. 4.1.1.2. 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. To allow for better compression efficiency, the "Cookie" field (RFC6265) MAY be split into separate field lines, each with one or more cookie-pairs, before compression.  If a decompressed field section contains multiple cookie field lines, these MUST be concatenated into a single byte string using the two-byte delimiter of 0x3b, 0x20 (the ASCII string "; ") before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application. 4.1.1.3. An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A server that receives a larger header section than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code (RFC6585).  A client can discard responses that it cannot process.  The size of a field list is calculated based on the uncompressed size of fields, including the length of the name and value in bytes plus an overhead of 32 bytes for each field. 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. 4.1.2. </del> 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 independent of the method or some means to detect that the original request was never applied.  See HTTP for more details. <del> 4.1.3. </del>  A malformed request or response is one that is an otherwise valid sequence of frames but is invalid due to: 4.2.  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 support CONNECT SHOULD restrict its use to a set of known ports or a list of safe request targets; see HTTP for more details. <del> 4.3. </del>  HTTP/3 does not support the HTTP Upgrade mechanism (HTTP) or the 101 (Switching Protocols) informational status code (HTTP). <del> 4.4. </del>  Server push is an interaction mode that permits a server to push a request-response exchange to a client in anticipation of the client Push ID that is greater than the maximum Push ID. The Push ID is used in one or more PUSH_PROMISE frames (frame-push- <del> 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. </del>  The Push ID is then included with the push stream that ultimately fulfills those promises; see push-streams.  The push stream

Reviewer comments:
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 haven'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 Request Pseudo-Header Fields Response Pseudo-Header Fields 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 Request Pseudo-Header Fields Response Pseudo-Header Fields Server Push Push Requests Push Responses The CONNECT Method The Upgrade Header Field URL 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 .

Revised text:
An HTTP message (request or response) consists of:  <ins> the header section, including message control data, sent as a single HEADERS frame (see frame-headers), </ins> optionally, the content, if present, sent as a series of DATA frames (see frame-data), and 4.1.1.  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 independent of the method or some means to detect that the original request was never applied.  See HTTP for more details.  <ins> 4.1.2. </ins> A malformed request or response is one that is an otherwise valid sequence of frames but is invalid due to: 4.2. <ins> 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/>. 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). Like HTTP/2, HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as malformed (malformed). The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain any value other than "trailers". 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). 4.2.1. 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. To allow for better compression efficiency, the "Cookie" field (RFC6265) MAY be split into separate field lines, each with one or more cookie-pairs, before compression.  If a decompressed field section contains multiple cookie field lines, these MUST be concatenated into a single byte string using the two-byte delimiter of 0x3b, 0x20 (the ASCII string "; ") before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application. 4.2.2. An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A server that receives a larger header section than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code (RFC6585).  A client can discard responses that it cannot process.  The size of a field list is calculated based on the uncompressed size of fields, including the length of the name and value in bytes plus an overhead of 32 bytes for each field. 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. 4.3. 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. 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. Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests.  Pseudo-header fields MUST NOT appear in trailer sections.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (malformed). All pseudo-header fields MUST appear in the header section before regular header fields.  Any request or response that contains a pseudo-header field that appears in a header section after a regular header field MUST be treated as malformed (malformed). 4.3.1. The following pseudo-header fields are defined for requests: All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless the request is a CONNECT request; see connect. If the ":scheme" pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the request MUST contain either an ":authority" pseudo-header field or a "Host" header field.  If these fields are present, they MUST NOT be empty.  If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the ":authority" pseudo-header or "Host" header fields. An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those pseudo-header fields is malformed (malformed). 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". 4.3.2. 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). 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". 4.4. </ins> 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 support CONNECT SHOULD restrict its use to a set of known ports or a list of safe request targets; see HTTP for more details.  <ins> 4.5. </ins> HTTP/3 does not support the HTTP Upgrade mechanism (HTTP) or the 101 (Switching Protocols) informational status code (HTTP).  <ins> 4.6. </ins> Server push is an interaction mode that permits a server to push a request-response exchange to a client in anticipation of the client Push ID that is greater than the maximum Push ID. The Push ID is used in one or more PUSH_PROMISE frames (frame-push-  <ins> 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. </ins> The Push ID is then included with the push stream that ultimately fulfills those promises; see push-streams.  The push stream