Original text:
An HTTP message (request or response) consists of: <del> the message header (see RFC7230, Section 3.2), sent as a single </del>  HEADERS frame (see frame-headers), <del> optionally, the payload body, if present (see RFC7230, Section 3.3), sent as a series of DATA frames (see frame-data), </del>  <del> optionally, trailing headers, if present (see RFC7230, Section 4.1.2), sent as a single HEADERS frame. </del>  A server MAY send one or more PUSH_PROMISE (see frame-push-promise) or DUPLICATE_PUSH (see frame-duplicate-push) frames before, after, or MUST NOT be used. A response MAY consist of multiple messages when and only when one or <del> more informational responses (1xx; see RFC7231, Section 6.2) precede a final response to the same request.  Non-final responses do not contain a payload body or trailers. </del>  If an endpoint receives an invalid sequence of frames on either a request or a push stream, it MUST respond with a connection error of more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as <del> described in HTTP2, Section 8.1.2.5. </del>  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 4.2. <del> The pseudo-method CONNECT (RFC7231, Section 4.3.6) is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources.  In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel to a remote host.  In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes. </del>  A CONNECT request in HTTP/3 functions in the same manner as in <del> HTTP/2.  The request MUST be formatted as described in HTTP2, Section 8.3.  A CONNECT request that does not conform to these restrictions is malformed (see malformed).  The request stream MUST NOT be closed at the end of the request. </del>  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 <del> defined in RFC7231, Section 4.3.6. </del>  All DATA frames on the stream correspond to data sent or received on the TCP connection.  Any DATA frame sent by the client is transmitted 4.3. <del> HTTP/3 does not support the HTTP Upgrade mechanism (RFC7230, Section 6.7) or 101 (Switching Protocols) informational status code (RFC7231, Section 6.2.2). </del>  4.4.

Reviewer comments:
Martin flagged this on some imported text in , but others have crept in other places, mostly also as text imported from RFC7540. For future reference, (({{])), (Section d+(.d+)*) => 1

Revised text:
An HTTP message (request or response) consists of:  <ins> the message header (see Section 3.2 of RFC7230), sent as a single </ins> HEADERS frame (see frame-headers),  <ins> optionally, the payload body, if present (see Section 3.3 of RFC7230), sent as a series of DATA frames (see frame-data), </ins>  <ins> optionally, trailing headers, if present (see Section 4.1.2 of RFC7230), sent as a single HEADERS frame. </ins> A server MAY send one or more PUSH_PROMISE (see frame-push-promise) or DUPLICATE_PUSH (see frame-duplicate-push) frames before, after, or MUST NOT be used. A response MAY consist of multiple messages when and only when one or  <ins> more informational responses (1xx; see Section 6.2 of RFC7231) precede a final response to the same request.  Non-final responses do not contain a payload body or trailers. </ins> If an endpoint receives an invalid sequence of frames on either a request or a push stream, it MUST respond with a connection error of more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as  <ins> described in Section 8.1.2.5 of HTTP2. </ins> 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 4.2.  <ins> The pseudo-method CONNECT (Section 4.3.6 of RFC7231) is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources.  In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel to a remote host.  In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes. </ins> A CONNECT request in HTTP/3 functions in the same manner as in  <ins> HTTP/2.  The request MUST be formatted as described in Section 8.3 of HTTP2.  A CONNECT request that does not conform to these restrictions is malformed (see malformed).  The request stream MUST NOT be closed at the end of the request. </ins> 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  <ins> defined in Section 4.3.6 of RFC7231. </ins> All DATA frames on the stream correspond to data sent or received on the TCP connection.  Any DATA frame sent by the client is transmitted 4.3.  <ins> HTTP/3 does not support the HTTP Upgrade mechanism (Section 6.7 of RFC7230) or 101 (Switching Protocols) informational status code (Section 6.2.2 of RFC7231). </ins> 4.4.