Code change:
the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 9. </del> <ins> 8. 8.1. This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: </ins> <del> 9.1. </del> <ins> 8.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 9.2. </del> <ins> 8.3. </ins> <del> This document will request IANA to register the "Datagram-Flow-Id" header field in the "Permanent Message Header Field Names" registry maintained at <<https://www.iana.org/assignments/message-headers>>. </del> <ins> This document establishes a registry for HTTP/3 frame type codes. The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: Type: A name or label for the capsule type. The value of the Capsule Type field (see capsule-frame) is a 62bit integer. An optional reference to a specification for the type.  This field MAY be empty. Registrations follow the "First Come First Served" policy (see Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Type. </ins> <del> 9.3. </del> <ins> This registry initially contains the following entries: </ins> <del> This document will request IANA to create an "HTTP Datagram Flow Parameters" registry.  Registrations in this registry MUST include the following fields: </del> <ins> 8.4. </ins> <del> The key of a parameter that is associated with a datagram flow list member (see header).  Keys MUST be valid structured field parameter keys (see Section 3.1.2 of STRUCT-FIELD). </del> <ins> REGISTER_DATAGRAM_CONTEXT capsules carry key-value pairs, see register-capsule.  This document will request IANA to create an "HTTP Datagram Context Extension Keys" registry.  Registrations in this registry MUST include the following fields: </ins> <del> A brief description of the parameter semantics, which MAY be a summary if a specification reference is provided. </del> <ins> The key (see register-capsule).  Keys MUST be valid tokens as defined in Section 3.2.6 of RFC7230. </ins> <del> This field MUST be either Yes or No.  Yes indicates that this parameter is the name of a named element (see header).  No indicates that it is a parameter that is not a name. </del> <ins> A brief description of the key semantics, which MAY be a summary if a specification reference is provided. </ins> An optional reference to a specification for the parameter.  This field MAY be empty.

Related discussion:
text: The contents of the QUIC DATAGRAM frame would now look like: While the flow ID in the draft was per-hop, the proposal has better separation: the stream ID is per-hop, it maps to an HTTP request the context ID is end-to-end, it maps to context information inside that request Intermediaries now only look at stream IDs and can be blissfully ignorant of context IDs. In the room at the 2021-04 MASQUE Interim, multiple participants spoke in support of this design and no one raised objections. This issue exists to ensure that we have consensus on this change - please speak up if you disagree.
I am fine with the 2-layer design for CONNECT-UDP, but I am not sure if the second identifier should be in H3 DATAGRAM or should be specific to CONNECT-UDP. As I indicated to the list, webtrans and httpbis might weigh in on this with broader consideration of other use cases.
Hi NAME the topic of the optionality of context IDs is discussed in issue .
I think this is a good design, because it minimizes the core functionality of the draft, but avoids every application that needs multiple dynamically created sub-flows from re-inventing a different mechanism. Nit: I would not call this a 'Frame', since it's not an HTTP(TLV) frame.
I think this is a good change. Thanks! There are some things that I think we should still discuss, but we shouldn't hold up this change on those details.