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'm not sure there are many cases when one allocates all sub-flows up front AND needs to use a header to do that in a flexible way. If an application needs multiple sub-flows, but they're fixed in number/format(ie: data and control), I don't think there's a need for a header or a "Message", since the application can consider that part of its internal format.
During the 2021-04 MASQUE Interim, we discussed having the ability to accept or reject registration of context IDs. An important motivation for this is the fact that context ID registrations take up memory (for example it could be a compression context which contains the data that is elided) and therefore we need to prevent endpoints from arbitrarily making their peer allocate memory. While we could flow control context ID registration, a much simpler solution would be to have a way for endpoints to close/shutdown a registration.
IIUC there's an opposing view that the constraints can be negotiated apiori. Either statically (such as defining an extension which states that there can only be N contenxts of a given type) or dynamically using something like a HTTP header. Failure to meet these constraints could lead to an HTTP/3 stream or connection error rather than a flow rejection.
NAME I've filed to discuss whether to register/negotiate at request start or mid-stream.
I think that if there is the ability to register mid-stream (), we need the ability to close/de-register/reject mid-stream as well. If we don't have mid-stream changes, then no need to negotiate. However, someone trying to register something needs to be able to know whether or not the thing they registered will be accepted.
I agree that notification of the registration status is particularly important if we allow mid-stream registration.
In draft-ietf-masque-h3-datagram-00, flow IDs are bidirectional. During the 2021-04 MASQUE Interim, we discussed the possibility of making them unidirectional. Here are the differences: Bidirectional single shared namespace for both endpoints (even for client, odd for server) it's easier to refer to peer's IDs, which makes negotiation easier Unidirectional one namespace per direction every bidirectional use needs to associate both directions somehow I'm personally leaning towards keeping them bidirectional.