Change:
This registry initially contains the following entries: <del> 9.4. </del> <ins> 10.4. This document establishes a registry for HTTP/3 datagram context extension type codes.  The "HTTP Context Extension Types" registry governs a 62-bit space.  Registrations in this registry MUST include the following fields: Type: A name or label for the context extension type. The value of the Context Extension Type field (see context-ext) is a 62bit integer. An optional reference to a specification for the parameter.  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 nor Value. This registry initially contains the following entries: 10.5. This document establishes a registry for HTTP/3 context extension type codes.  The "HTTP Context Close Codes" registry governs a 62-bit space.  Registrations in this registry MUST include the following fields: </ins> <del> 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: </del> <ins> Type: </ins> <del> The key (see register-capsule).  Keys MUST be valid tokens as defined in Section 3.2.6 of RFC7230. </del> <ins> A name or label for the close code. </ins> <del> A brief description of the key semantics, which MAY be a summary if a specification reference is provided. </del> <ins> The value of the CLOSE_CODE Context Extension Value field (see close-code) is a 62bit integer. </ins> An optional reference to a specification for the parameter.  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 <del> same Key.  This registry is initially empty. </del> <ins> same Type nor Value. This registry initially contains the following entries: </ins> <del> 10.  References </del> <ins> 11.  References </ins> <del> 10.1.  URIs </del> <ins> 11.1.  URIs </ins> [1] mailto:masque@ietf.org

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks