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: I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
During the 2021-04 MASQUE Interim, we discussed multiple options for registering context IDs. Without going into the specific of the encoding, there are two broad classes of solutions: "Header" design Once-at-setup registration This happens during the HTTP request/response Simplest solution is to use an HTTP header such as (encoding TBD) Example use-case: CONNECT-UDP without extensions "Message" design Mid-stream registration This can happen at any point during the lifetime of the request stream This would involve some sort of "register" message (encoding TBD, see separate issue) Example use-case: CONNECT-IP on-the-fly compression (this can't be done at tunnel setup time because the bits top be compressed aren't always known at that time) It's possible to implement once-at-setup registration using the Message design, but it isn't possible to implement mid-stream registration. Therefore I think we should go with the Message design. It would also be possible to implement both but I don't think that provides much value.
I'd like to here some more from the WebTransport use case on the issue. My understanding is that the Requests are used to create WebTransport sessions and that creation of datagram flows(contexts) could be a lot more ad-hoc / server generated after the request phase, when compared to the CONNECT-UDP case. Cc NAME
Personally, I'd vote for either "message" or "message + header" (a la priorities), but not just "header". Mid-stream annotation of context/flow/etc is quite useful.
I prefer "Message" only, since the dynamic use case seems like a fairly compelling use of sub-flows(contexts?).