Change:
… avoiding confusion with individual frame payloads (editorial). This is related to the Semantics issue URL
NAME has created URL on http-core Semantics draft, which describes how the term "payload" is overloaded when considered with the H2 and H3 docs. Roy's has a proposal to change that term in Semantics, which impacts the HTTP/3 draft. But he was kind enought to submit PR URL, which demonstrates the impact of that change. This issue is mainly for visibility and tracking purposes.
With or without NAME suggestion. I need to do the same for h2, so it is good to see URL suggestion

Discussion:
An application-level error on the individual stream. <del> The term "payload data" is defined in Section 6.4 of SEMANTICS. </del> <ins> The term "content" is defined in Section 6.4 of SEMANTICS. </ins> Finally, the terms "resource", "message", "user agent", "origin server", "gateway", "intermediary", "proxy", and "tunnel" are defined

the header field section, sent as a single HEADERS frame (see frame-headers), <del> optionally, the payload data, if present, sent as a series of DATA </del> <ins> optionally, the content, if present, sent as a series of DATA </ins> frames (see frame-data), and optionally, the trailer field section, if present, sent as a single HEADERS frame. Header and trailer field sections are described in Sections 6.3 and <del> 6.5 of SEMANTICS; the payload data is described in Section 6.4 of </del> <ins> 6.5 of SEMANTICS; the content is described in Section 6.4 of </ins> SEMANTICS. Receipt of an invalid sequence of frames MUST be treated as a

A response MAY consist of multiple messages when and only when one or more interim responses (1xx; see Section 15.2 of SEMANTICS) precede a final response to the same request.  Interim responses do not contain <del> payload data or trailers. </del> <ins> content or trailers. </ins> An HTTP request/response exchange fully consumes a client-initiated bidirectional QUIC stream.  After sending a request, a client MUST

the inclusion of invalid characters in field names or values. <del> A request or response that includes payload data can include a Content-Length header field.  A request or response is also malformed if the value of a Content-Length header field does not equal the sum of the DATA frame lengths that form the payload data.  A response that is defined to have no payload, as described in Section 6.4 of SEMANTICS, can have a non-zero Content-Length field, even though no </del> <ins> A request or response that is defined as having content when it contains a Content-Length header field (Section 6.4.1 of SEMANTICS), 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 </ins> content is included in DATA frames. Intermediaries that process HTTP requests or responses (i.e., any

7.2.1. DATA frames (type=0x0) convey arbitrary, variable-length sequences of <del> bytes associated with HTTP request or response payload data. </del> <ins> bytes associated with HTTP request or response content. </ins> DATA frames MUST be associated with an HTTP request or response.  If a DATA frame is received on a control stream, the recipient MUST