Original text:
The context ID to register. <del> A string of comma-separated key-value pairs to enable extensibility.  Keys are registered with IANA, see iana-keys. The ABNF for the Extension String field is as follows (using syntax from Section 3.2.6 of RFC7230): </del>  Note that these registrations are unilateral and bidirectional: the sender of the frame unilaterally defines the semantics it will apply semantics of datagrams associated with this stream.  Its Capsule Data field consists of: <del> A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. </del>  Note that this registration is unilateral and bidirectional: the client unilaterally defines the semantics it will apply to the The context ID to close. <del> A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. </del>  Note that this close is unilateral and bidirectional: the sender of the frame unilaterally informs its peer of the closure.  Endpoints initially registered by either themselves, or by their peer. Endpoints MAY use the CLOSE_DATAGRAM_CONTEXT capsule to immediately reject a context that was just registered using a <del> REGISTER_DATAGRAM_CONTEXT capsule if they find its Extension String to be unacceptable. </del>  After an endpoint has either sent or received a CLOSE_DATAGRAM_CONTEXT frame, it MUST NOT send any DATAGRAM frames MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR.  4.4. The DATAGRAM capsule (type=0x02) allows an endpoint to send a 5.  Implementations of HTTP/3 that support this mechanism can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. <del> 6. </del>  Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY define signaling to allow endpoints to communicate their prioritization preferences. <del> 7. </del>  We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. TODO: Refactor this document into "HTTP Datagrams" with definitions for HTTP/1.x, HTTP/2, and HTTP/3. <del> 8. </del>  Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 9. </del>  <del> 9.1. </del>  This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: <del> 9.2. </del>  This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 9.3. </del>  <del> This document establishes a registry for HTTP/3 frame type codes. </del>  The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: This registry initially contains the following entries: <del> 9.4. </del>  <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>  <del> The key (see register-capsule).  Keys MUST be valid tokens as defined in Section 3.2.6 of RFC7230. </del>  <del> A brief description of the key semantics, which MAY be a summary if a specification reference is provided. </del>  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>  <del> 10.  References </del>  <del> 10.1.  URIs </del>  [1] mailto:masque@ietf.org

Reviewer comments:
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

Revised text:
The context ID to register.  <ins> See context-ext. </ins> Note that these registrations are unilateral and bidirectional: the sender of the frame unilaterally defines the semantics it will apply semantics of datagrams associated with this stream.  Its Capsule Data field consists of:  <ins> See context-ext. </ins> Note that this registration is unilateral and bidirectional: the client unilaterally defines the semantics it will apply to the The context ID to close.  <ins> See context-ext. </ins> Note that this close is unilateral and bidirectional: the sender of the frame unilaterally informs its peer of the closure.  Endpoints initially registered by either themselves, or by their peer. Endpoints MAY use the CLOSE_DATAGRAM_CONTEXT capsule to immediately reject a context that was just registered using a  <ins> REGISTER_DATAGRAM_CONTEXT capsule if they find its Context Extensions field to be unacceptable. </ins> After an endpoint has either sent or received a CLOSE_DATAGRAM_CONTEXT frame, it MUST NOT send any DATAGRAM frames MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <ins> All CLOSE_DATAGRAM_CONTEXT capsules MUST contain a CLOSE_CODE context extension, see close-code.  If an endpoint receives a CLOSE_DATAGRAM_CONTEXT capsule without a CLOSE_CODE context extension, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. </ins> 4.4. The DATAGRAM capsule (type=0x02) allows an endpoint to send a 5. <ins> In order to facilitate extensibility of contexts, the REGISTER_DATAGRAM_CONTEXT, REGISTER_DATAGRAM_NO_CONTEXT, and the CLOSE_DATAGRAM_CONTEXT capsules carry a Context Extensions field. That field contains a sequence of context extensions: Each context extension is encoded as a (type, length, value) tuple: Context Extension Types are registered with IANA, see iana-ext-types. The Context Extension Length field contains the length of the Context Extension Value field in bytes.  The semantics of the Context Extension Value field are defined by the corresponding Context Extension Type. 5.1. The CLOSE_CODE context extension type (type=0x00) allows an endpoint to provide additional information as to why a datagram context was closed.  This type SHALL only be sent in CLOSE_DATAGRAM_CONTEXT capsules.  Its Context Extension Value field consists of a single variable-length integer which contains the close code.  The following codes are defined: This indicates that the registration was closed without any additional information. This indicates that the sender has rejected the context registration based on its local policy.  The endpoint that had originally registered this context MUST NOT try to register another context with the same context extensions on this stream. This indicates that the context was closed to save resources.  The recipient SHOULD limit its future registration of resource- incentive contexts. Receipt of an unknown close code MUST be treated as if the NO_ERROR code was present.  Close codes are registered with IANA, see iana- close-codes. 5.2. The DETAILS context extension type (type=0x01) allows an endpoint to provide additional details to context capsules.  It is meant for debugging purposes.  Its Context Extension Value field consists of a human-readable string encoded in UTF-8. 6. </ins> Implementations of HTTP/3 that support this mechanism can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1.  <ins> 7. </ins> Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY define signaling to allow endpoints to communicate their prioritization preferences.  <ins> 8. </ins> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. TODO: Refactor this document into "HTTP Datagrams" with definitions for HTTP/1.x, HTTP/2, and HTTP/3.  <ins> 9. </ins> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a the fact that there are applications using HTTP/3 datagrams enabled on this endpoint.  <ins> 10. </ins>  <ins> 10.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Frames" registry:  <ins> 10.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry:  <ins> 10.3. </ins>  <ins> This document establishes a registry for HTTP/3 capsule type codes. </ins> The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: This registry initially contains the following entries:  <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>  <ins> Type: </ins>  <ins> A name or label for the close code. </ins>  <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  <ins> same Type nor Value. This registry initially contains the following entries: </ins>  <ins> 11.  References </ins>  <ins> 11.1.  URIs </ins> [1] mailto:masque@ietf.org