Original text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  2. frames uses the following format (using the notation from the "Notational Conventions" section of QUIC): <del> A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated with, divided by four (the division by four stems from the fact that HTTP requests are sent on client-initiated bidirectional streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 -1, so the largest legal value of Quarter Stream ID is 2 -1.  Receipt of a frame that includes a larger value MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR. The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. </del> Receipt of a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR. This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that new HTTP <del> Upgrade Tokens (see Section 16.7 of HTTP) can choose to use.  It allows endpoints to reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </del>  This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): <del> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST silently skip over that capsule. The length of the Capsule Value field following this field, encoded as a variable-length integer.  Note that this field can have a value of zero. The payload of this capsule.  Its semantics are determined by the value of the Capsule Type field. </del> Because new protocols or extensions may involve defining new capsule types, intermediaries that wish to allow for future extensibility SHOULD forward capsules unmodified.  One exception to this rule is When an error occurs processing the capsule protocol, the receiver MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed <del> messages is described in Section 4.1.3 of H3.  For HTTP/2, the handling of malformed messages is described in Section 8.1.1 of H2. For HTTP/1.1, the handling of incomplete messages is described in Section 8 of H1. </del>  Each capsule's payload MUST contain exactly the fields identified in its description.  A capsule payload that contains additional bytes MAY use the Capsule-Protocol header field to simplify intermediary processing. <del> "Capsule-Protocol" is an Item Structured Header (see Section 3.3 of STRUCTURED-FIELDS.  Its value MUST be a Boolean.  Its ABNF is: </del>  Endpoints indicate that the Capsule Protocol is in use on the data stream by sending the Capsule-Protocol header field with a value of is particularly useful when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. <del> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. </del> Datagrams sent using the DATAGRAM capsule have the same semantics as datagrams sent in QUIC DATAGRAM frames.  In particular, the restrictions on when it is allowed to send an HTTP Datagram and how Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see <del> Section 11 of PRIORITY. </del>  Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 0xffd277 (note that this will switch to a lower value before publication) H3_DATAGRAM 0 provisional (permanent if this document is approved) This Document IETF HTTP_WG; HTTP working group; ietf-http-wg@w3.org </del> 7.2. This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry: <del> 0x4A1268 (note that this will switch to a lower value before publication) H3_DATAGRAM_ERROR Datagram or capsule protocol parse error provisional (permanent if this document is approved) This Document IETF HTTP_WG; HTTP working group; ietf-http-wg@w3.org </del> 7.3. This document will request IANA to register the following entry in the "HTTP Field Name" registry: <del> Capsule-Protocol None provisional (permanent if this document is approved) This document None </del> 7.4. This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: <del> A name or label for the capsule type. The value of the Capsule Type field (see capsule-protocol) is a 62-bit integer. An optional reference to a specification for the type.  This field MAY be empty. </del> Registrations follow the "First Come First Served" policy (see Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Type.

Reviewer comments:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.

Revised text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2. frames uses the following format (using the notation from the "Notational Conventions" section of QUIC):  Receipt of a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR. This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that new HTTP  <ins> Upgrade Tokens (see HTTP) can choose to use.  It allows endpoints to reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </ins> This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC):  Because new protocols or extensions may involve defining new capsule types, intermediaries that wish to allow for future extensibility SHOULD forward capsules unmodified.  One exception to this rule is When an error occurs processing the capsule protocol, the receiver MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed  <ins> messages is described in H3.  For HTTP/2, the handling of malformed messages is described in H2.  For HTTP/1.1, the handling of incomplete messages is described in H1. </ins> Each capsule's payload MUST contain exactly the fields identified in its description.  A capsule payload that contains additional bytes MAY use the Capsule-Protocol header field to simplify intermediary processing.  <ins> "Capsule-Protocol" is an Item Structured Header (see STRUCTURED- FIELDS.  Its value MUST be a Boolean.  Its ABNF is: </ins> Endpoints indicate that the Capsule Protocol is in use on the data stream by sending the Capsule-Protocol header field with a value of is particularly useful when HTTP is running over a transport that does not support the QUIC DATAGRAM frame.  Datagrams sent using the DATAGRAM capsule have the same semantics as datagrams sent in QUIC DATAGRAM frames.  In particular, the restrictions on when it is allowed to send an HTTP Datagram and how Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see  <ins> PRIORITY. </ins> Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY This document will request IANA to register the following entry in the "HTTP/3 Settings" registry:  7.2. This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry:  7.3. This document will request IANA to register the following entry in the "HTTP Field Name" registry:  7.4. This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields:  Registrations follow the "First Come First Served" policy (see Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Type.