Original text:
5. HTTP messages use key/value pairs to convey data about the message, <del> its payload, the target resource, or the connection (i.e., control data).  They are called "HTTP fields" or just " </del>  ". <del> Every message can have two separate areas that such fields can occur within; the " </del>  <del> " (or just "header section") preceding the message body and containing "header fields" (or just "headers", colloquially) and the " </del>  <del> " (or just "trailer section") after the message body containing "trailer fields" (or just "trailers" colloquially).  Header fields are more common; see trailer.fields for discussion of the applicability and limitations of trailer fields. </del>  Both sections are composed of any number of "

Reviewer comments:
Does this mean it's now valid to interleave HTTP/2 DATA frames and HEADER frames?
Does this mean we cannot implement this on HTTP/2?
The feature was removed during WGLC, but no -- it would have required a new frame type.
Okay, so chunk extensions remains a unique feature of HTTP/1 chunked encoding and there is no plan to expand that further?
Yes.
As discussed in and URL, mid-stream trailers (i.e., those that arrive before the end of the payload body) are interesting. A few things to discuss: [ ] What are some potential use cases?[ ] We recently stopped automatically combining trailers into headers, as that created a lot of issues. What about these -- are they yet again distinct from trailers as well as headers? Or can they be "downgraded" into trailers automatically? In other words, when transitioning from a hop that supports these from one that doesn't, are they just dropped onto the floor?[ ] Related - is the expectation that implementations will create separate APIs for these, or would it be that trailers are just available / writable early?[ ] What relationship does one of these have to the payload body? E.g., could I write one that "knows" exactly where in the body it occurs, so that it could sign a chunk of the body relative to it? Or could a handling implementation change its ordering in relation to body bytes?
Some preliminary considerations. Incremental checksums eg. Service management (eg. convey the ETA of the transfer, ...) Sending signatures of partial body (in mid-stream) has some complexities respect to sending a signature of the whole message in the header/trailer section, and requires a security URL trailers, when used for integrity can't be dropped without informing the user agent They probably need to be defined as 1#field-item because mid-stream trailers will be sent multiple times (eg. one per chunk) Whenever they are tied to the partial transmitted representation, they will eventually be unuseful when merged, unless they have some associative propertyThey will be especially useful when tied to a portion of the body They will be significantly less useful when not tied to a portion of the body
Potential use cases mostly limited to long-lived streaming traffic, i.e. long-lived "uploading/downloading" in-band signaling support such as load reporting, app-level flow-control, authn update etc Semantics trailers are a special case of mid-stream metadata, e.g. only trailers are able to convey the status of the entire transaction or the entire resource (body) our experience is that in-order delivery is useful and often assumed, since the underlying transport (for HTTP body) is in-order and reliable. Out-of-order metadata is likely a use case for connection-level metadata, IMO with the above assumption on in-order delivery, you really only need one API for delivering in-stream or trailer metadata Multi-part without in-stream metadata, you would have to use multipart (with all the overhead) for structured data, the original content-type can be preserved, e.g. JSON stream; and for media data, the content-type may have to be application/octet-stream
Copying over the questions from NAME over in URL, as they are good ones:
The semantic model of trailers is that they provide additional metadata that may (or may not) be useful to recipients but was not available prior to the initial body data sent. How the are useful and what they might contain would be defined by the field name. A recipient is free to drop the trailer metadata. A mid-stream trailer frame would have the same role in flow control as a HEADERS frame, which is none at the current time. The proposed frames would not have any specific position, but the values inside trailer fields might identify specific positions (on their own, regardless of framing). A cache would either drop the values or store them separately as trailer fields in the order received.
HTTP/2's flow control only cares about DATA frames. But all frames are subject to TCP's flow control. In HTTP/3, all frames are sent on streams which is subject to QUIC's flow control. Responding to the original question, I don't know what a "new form of flow control" would look like and I don't see how one would improve things.
What's the minimal change that would need to happen to semantics to enable this in a future version of HTTP (or an extension to an existing one)?
I think you would need to make "trailer part" less special, and simply say that a version of HTTP can define a way to carry additional field sections during or after the body. H1-H3 currently define a way to carry only one such block, but an extension could provide more.

Revised text:
5. HTTP messages use key/value pairs to convey data about the message,  <ins> its payload, the target resource, or the connection.  They are called "HTTP fields" or just " </ins> ".  <ins> Fields that are sent/received before the message body are referred to as "header fields" (or just "headers", colloquially) and are located within the " </ins>  <ins> " of a message.  We refer to some named fields specifically as a "header field" when they are only allowed to be sent in the header section. Fields that are sent/received after the header section has ended (usually after the message body begins to stream) are referred to as "trailer fields" (or just "trailers", colloquially) and located within a " </ins>  <ins> ".  One or more trailer sections are only possible when supported by the version of HTTP in use and enabled by an extensible mechanism for framing message sections. </ins> Both sections are composed of any number of "