Code change:
6. <del> "Datagram-Flow-Id" is a List Structured Field STRUCT-FIELD, whose members MUST all be Items of type Integer.  Integers MUST be non- negative.  Its ABNF is: The "Datagram-Flow-Id" header field is used to associate one or more datagram flows with an HTTP message.  As a simple example using a single flow, the definition of an HTTP method could instruct the client to use its flow ID allocation service to allocate a new flow ID, and then the client will add the "Datagram-Flow-Id" header field to its request to communicate that value to the server.  In this example, the resulting header field could look like: List members are flow ID elements, which can be named or unnamed. One element in the list is allowed to be unnamed, but all but one elements MUST carry a name.  The name of an element is encoded in the key of the first parameter of that element (parameters are defined in Section 3.1.2 of STRUCT-FIELD).  Each name MUST NOT appear more than once in the list.  The value of the first parameter of each named element (whose corresponding key conveys the element name) MUST be of type Boolean and equal to true.  The value of the first parameter of the unnamed element MUST NOT be of type Boolean.  The ordering of the list does not carry any semantics.  For example, an HTTP method that wishes to use four datagram flows for the lifetime of its request stream could look like this: In this example, 42 is the unnamed flow, 44 represents the name "foo", 46 represents "bar", and 48 represents "baz".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: Even if a sender attempts to communicate the meaning of a flow before it uses it in an HTTP/3 datagram, it is possible that its peer will receive an HTTP/3 datagram with a flow ID that it does not know as it has not yet received the corresponding "Datagram-Flow-Id" header field.  (For example, this could happen if the QUIC STREAM frame that contains the "Datagram-Flow-Id" header field is reordered and arrives afer the DATAGRAM frame.)  Endpoints MUST NOT treat that scenario as an error; they MUST either silently discard the datagram or buffer it until they receive the "Datagram-Flow-Id" header field. Distinct HTTP requests MAY refer to the same flow in their respective "Datagram-Flow-Id" header fields. Note that integer structured fields can only encode values up to 10^15-1, therefore the maximum possible value of an element of the "Datagram-Flow-Id" header field is lower then the theoretical maximum value of a flow ID which is 2^62-1 due to the QUIC variable length integer encoding.  If the flow allocation service of an endpoint runs out of flow ID values lower than 10^15-1, the endpoint MUST fail the flow ID allocation.  An HTTP message that carries a "Datagram-Flow- Id" header field with a flow ID value above 10^15-1 is malformed (see Section 8.1.2.6 of H2). </del> <ins> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. </ins> <del> 7. </del> <ins> We can provide DATAGRAM support in HTTP/1.x by defining its data stream format to a sequence of length-value capsules. </ins> <del> HTTP/3 DATAGRAM flows are specific to a given HTTP/3 connection. However, in some cases, an HTTP request may travel across multiple HTTP connections if there are HTTP intermediaries involved; see Section 2.3 of RFC7230. If an intermediary has sent the H3_DATAGRAM SETTINGS parameter with a value of 1 on its client-facing connection, it MUST inspect all HTTP requests from that connection and check for the presence of the "Datagram-Flow-Id" header field.  If the HTTP method of the request is not supported by the intermediary, it MUST remove the "Datagram- Flow-Id" header field before forwarding the request.  If the intermediary supports the method, it MUST either remove the header field or adhere to the requirements leveraged by that method on intermediaries. If an intermediary has sent the H3_DATAGRAM SETTINGS parameter with a value of 1 on its server-facing connection, it MUST inspect all HTTP responses from that connection and check for the presence of the "Datagram-Flow-Id" header field.  If the HTTP method of the request is not supported by the intermediary, it MUST remove the "Datagram- Flow-Id" header field before forwarding the response.  If the intermediary supports the method, it MUST either remove the header field or adhere to the requirements leveraged by that method on intermediaries. If an intermediary processes distinct HTTP requests that refer to the same flow ID in their respective "Datagram-Flow-Id" header fields, it MUST ensure that those requests are routed to the same backend. </del> <ins> TODO: Refactor this document into "HTTP Datagrams" with definitions for HTTP/1.x, HTTP/2, and HTTP/3. </ins> <del> 8. </del> <ins> 7. </ins> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a

Related discussion:
text: This PR aims to take the design discussions we had at the last interim, and propose a potential solution. This PR should in theory contain enough information to allow folks to implement this new design. That will allow us to perform interop testing and confirm whether the design is sound.
I'm confused by this pull request (probably because I was out of the loop for a while). My understanding, at least when I first read the proposal a month ago was that we would separate multiplexing streams and multiplexing contexts into different layers, so that methods that need context would get it (CONNECT-UDP), and features that don't (WebTransport/extended CONNECT) could use stream-associated datagrams directly.
NAME you're referring to which this PR isn't trying to address. That'll happen in a subsequent PR.
In , capsules, contexts and context IDs are explicitly defined as end-to-end and there are requirements for intermediaries to not modify them, and to not even parse them. The motivation for this was to ensure that we retain the ability to deploy extensions end-to-end without having to modify intermediaries. NAME mentioned that these requirements might be too strict, as he would like to have his intermediary be able to parse the context ID, for logging purposes.
Part of the comment from the PR is also about consistency of interface for generic HTTP libraries that can be used to build either endpoints or intermediaries. If the context ID is always present, it's overly prescriptive to say that an intermediary can't parse it, and such a requirement couldn't be enforced anyways. If context IDs are negotiated on/off, whether this is possible depends on the negotiation mechanism.
I think its fine for a component that has bytes passing through it to look at those bytes. The import thing to do is set expectations on what that means for the protocol behaviour we are defining. We don't expect intermediaries to do anything with a context ID; they should not enforce the protocol semantic rules (odd, even, reuse etc). H2 and H3 somewhat solve this problem by decoupling frame parsing from frame payload interpretation. E.g. if the form of a request or response is invalid, an intermediary shouldn't pass it on. DATAGRAM is different because it isn't defined as an actual HTTP/3 frame with frame headers and frame payload.