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.

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

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.


<del> Using Datagrams with HTTP </del>  draft-ietf-masque-h3-datagram-latest Abstract <del> The QUIC DATAGRAM extension provides application protocols running over QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames with HTTP/3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del>  <del> 1. The QUIC DATAGRAM extension DGRAM provides application protocols running over QUIC QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames with HTTP/3 H3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. This document is structured as follows: </del>  <del> multiplexing presents core concepts for multiplexing across HTTP versions. </del>  <del> format defines how QUIC DATAGRAM frames are used with HTTP/3. setting defines an HTTP/3 setting that endpoints can use to advertise support of the frame. capsule introduces the Capsule Protocol and the "data stream" concept.  Data streams are initiated using special-purpose HTTP requests, after which Capsules, an end-to-end message, can be sent. </del>  <del> datagram-capsule defines Datagram Capsule types, along with guidance for specifying new capsule types. </del>  1.1. 2. <del> All HTTP Datagrams are associated with an HTTP request. </del>  <del> When running over HTTP/3, multiple exchanges of datagrams need the ability to coexist on a given QUIC connection.  To allow this, the QUIC DATAGRAM frame payload starts with an encoded stream identifier that associates the datagram with a request stream. </del>  When running over HTTP/2, demultiplexing is provided by the HTTP/2 <del> framing layer.  When running over HTTP/1, requests are strictly serialized in the connection, therefore demultiplexing is not needed. 3. </del>  When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM frames uses the following format (using the notation from the parsing the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR. <del> Endpoints MUST NOT send HTTP/3 datagrams unless the corresponding stream's send side is open.  On a given endpoint, once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so the endpoint can release related state.  Endpoints MAY keep state for a short time to account for reordering.  Once the state is released, the endpoint MUST silently drop received associated datagrams. </del>  If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that has not yet been created, the receiver SHALL either drop determining the active stream concurrency limit that is applied by the QUIC layer. <del> HTTP/3 datagrams MUST only be sent with an association to a stream that supports semantics for HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP/3 datagrams cannot be sent associated with GET or POST request streams.  If an endpoint receives an HTTP/3 datagram associated with a method that has no known semantics for HTTP Datagrams, it MUST abort the corresponding stream with H3_DATAGRAM_ERROR.  Future extensions MAY remove these requirements if they define semantics for such HTTP Datagrams and negotiate mutual support. </del>  <del> 3.1. </del>  Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with <del> a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. </del>  <del> Endpoints MUST NOT send QUIC DATAGRAM frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. </del>  When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. <del> 3.1.1. </del>  [[RFC editor: please remove this section before publication.]] Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported <del> by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. </del>  <del> 4. </del>  This specification introduces the Capsule Protocol.  The Capsule <del> Protocol is a sequence of type-length-value tuples that new HTTP Upgrade Tokens (see HTTP) can choose to use.  It allows endpoints to </del>  reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The <del> 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 <del> the bidirectional stream of bytes that follow the headers in both directions.  In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the 2xx (Successful) response header section.  (Note that only a single HTTP request starting the capsule protocol can be sent on HTTP/1.x connections.)  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.  The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. </del>  <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. 4.1. Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the 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 the DATAGRAM capsule; see datagram-capsule.  An intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by understanding the chosen HTTP Upgrade token.  An intermediary that identifies the use of the capsule protocol MAY convert between DATAGRAM capsules and QUIC DATAGRAM frames when forwarding.  Definitions of new Capsule Types MAY specify optional custom intermediary processing. </del>  Endpoints which receive a Capsule with an unknown Capsule Type MUST <del> silently drop that Capsule. </del>  By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses <del> that use the Capsule Protocol. </del>  <del> 4.2. </del>  <del> When an error occurs processing the capsule protocol, the receiver </del>  MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed messages is described in H3.  For HTTP/2, the handling of malformed capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. <del> 4.3. </del>  <del> This document defines the "Capsule-Protocol" header field.  It is an Item Structured Field, see STRUCT-FIELD; its value MUST be a Boolean. Its ABNF is: </del>  <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 ?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </del>  <del> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code different from 2xx (Successful). This specification does not define any parameters for the Capsule- Protocol header field value, but future documents MAY define parameters.  Receivers MUST ignore unknown parameters. </del>  Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. <del> 4.4. </del>  This document defines the DATAGRAM capsule type (see iana-types for <del> the value of the capsule type).  This capsule allows an endpoint to send an HTTP Datagram on a stream using the Capsule Protocol.  This is particularly useful when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </del>  <del> Datagrams sent using the DATAGRAM capsule have the same semantics as datagrams sent in QUIC DATAGRAM frames.  In particular, the </del>  restrictions on when it is allowed to send an HTTP Datagram and how to process them from format also apply to HTTP Datagrams sent and received using the DATAGRAM capsule. be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> 5. Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY. 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>  <del> 6. </del>  Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires sending an HTTP/3 Settings parameter, it "sticks out".  In other Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). <del> 7. </del>  <del> 7.1. </del>  This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 7.2. </del>  This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry: <del> 7.3. </del>  This document will request IANA to register the following entry in the "HTTP Field Name" registry: <del> 7.4. </del>  This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.

NAME thank you for the suggestions over on URL David and I worked through your proposal from top to bottom and turned it into this PR, which accepts many suggestions but not all. Please review and let us know if you're happy with it. NAME we believe some of your comments are addressed here too (unless tracked on a separate ticket). Please take a look.
While the argument in Section 2 "requests are strictly serialised in the connection, therefore demultiplexing is not needed" is technically correct, Section 4. further restricts the use of HTTP/1.1 connections to a single stream of capsules/HTTP datagrams. I would prefer to see this restriction as an argument here.
The sentence "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." seems a little misleading … During the IETF 113 discussions, I understood capsules as general mechanism reliable datagrams/wire encoding over HTTP In the draft however, Section 1 state "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." contradicts this impression. Can we clarify this?
Why is the ebnf instead of ? Should this allow request/upgrade methods to append a list of additional parameters?
Yes, allows parameters but does not. We didn't see a good reason to ban future parameters
Maybe you should mention it and require intermediaries to pass and ignore them in case they don't understand them.
as per recent changes in HTTPland specs, the ABNF adds confusion. My suggestion is to remove the ABNF. That might still leave a question over the structured types, but that is answered by the Structured Field value specs and we are unlikely to need to state anything ourselves. I can take a pass at this.
LGTM, thanks!

<ins> HTTP Datagrams and the Capsule Protocol </ins> draft-ietf-masque-h3-datagram-latest Abstract  <ins> This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. </ins>  <ins> In HTTP/3, HTTP Datagrams can be conveyed natively using the QUIC DATAGRAM extension.  When the QUIC DATAGRAM frame is unavailable or undesirable, they can be sent using the Capsule Protocol, a more general convention for conveying data in HTTP connections. </ins>  <ins> Both are intended for use by HTTP extensions, not applications. </ins>  <ins> 1. </ins>  <ins> HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) to enable desirable features like an unreliable version of the CONNECT method, and unreliable delivery in WebSockets RFC6455 (or its successors). In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and possibly multiplexed exchange of data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT method), and are compatible with all versions of HTTP.  When the underlying transport protocol supports unreliable delivery (such as when the QUIC DATAGRAM extension is available in HTTP/3), they can use that capability. It also describes the HTTP Capsule Protocol in capsule, to allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is unavailable or undesirable, such as when earlier versions of HTTP are in use. </ins> 1.1. 2.  <ins> HTTP Datagrams are a convention for conveying bidirectional and potentially unreliable datagrams inside an HTTP connection, with multiplexing when possible.  All HTTP Datagrams are associated with an HTTP request. </ins>  <ins> When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including unreliable delivery; see format.  Negotiation is achieved using a setting; see setting. </ins> When running over HTTP/2, demultiplexing is provided by the HTTP/2  <ins> framing layer, but unreliable delivery is unavailable.  HTTP Datagrams are negotiated and conveyed using the Capsule Protocol; see datagram-capsule. When running over HTTP/1, requests are strictly serialized in the connection, and therefore demultiplexing is not available. Unreliable delivery is likewise not available.  HTTP Datagrams are negotiated and conveyed using the Capsule Protocol; see datagram- capsule. HTTP Datagrams MUST only be sent with an association to a stream whose HTTP semantics explicitly supports HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be sent associated with GET or POST request streams. If an HTTP Datagram associated with a method that has no known semantics for HTTP Datagrams is received, the receiver MUST abort the corresponding stream; if HTTP/3 is in use, the stream MUST be aborted with H3_DATAGRAM_ERROR.  HTTP extensions can override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams. 2.1. </ins> When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM frames uses the following format (using the notation from the parsing the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR.  <ins> HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's send side is open.  Once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so related state can be released.  State MAY be kept for a short time to account for reordering.  Once the state is released, the received associated datagrams MUST be silently dropped. </ins> If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that has not yet been created, the receiver SHALL either drop determining the active stream concurrency limit that is applied by the QUIC layer.  <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 communicating prioritization preferences. </ins>  <ins> 2.1.1. </ins> Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with  <ins> a value of 1. The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  If the H3_DATAGRAM SETTINGS parameter is received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. </ins>  <ins> QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1. </ins> When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security.  <ins> 2.1.1.1. </ins> [[RFC editor: please remove this section before publication.]] Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported  <ins> by sending multiple values for H3_DATAGRAM.  Once SETTINGS have been sent and received, an implementation that supports multiple drafts MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both peers negotiate the same draft version. </ins>  <ins> 2.2. When HTTP/3 Datagrams are unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, see datagram-capsule. 3. One mechanism to extend HTTP is to introduce new HTTP Upgrade Tokens (see HTTP).  In HTTP/1.x, these tokens are used via the Upgrade mechanism (see HTTP).  In HTTP/2 and HTTP/3, these tokens are used via the Extended CONNECT mechanism (see EXT-CONNECT2 and EXT- CONNECT3). </ins> This specification introduces the Capsule Protocol.  The Capsule  <ins> Protocol is a sequence of type-length-value tuples that definitions of new HTTP Upgrade Tokens can choose to use.  It allows endpoints to </ins> reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The  <ins> Capsule Protocol can be used to exchange HTTP Datagrams, which is necessary when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. 3.1. </ins> This specification defines the "data stream" of an HTTP request as  <ins> the bidirectional stream of bytes that follows the header section of the request message and the final, successful (i.e., 2xx) response message. </ins>  <ins> In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the response header section.  As a result, only a single HTTP request starting the capsule protocol can be sent on HTTP/1.x connections. In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID. The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. Data streams can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY. 3.2. Definitions of new HTTP Upgrade Tokens can state that their associated request's data stream uses the Capsule Protocol.  If they do so, that means that the contents of the associated request's data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): An intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by understanding the chosen HTTP Upgrade token. Because new protocols or extensions might define new capsule types, intermediaries that wish to allow for future extensibility SHOULD forward capsules without modification, unless the definition of the Capsule Type in use specifies additional intermediary processing. One such Capsule Type is the DATAGRAM capsule; see datagram-capsule. In particular, intermediaries SHOULD forward Capsules with an unknown Capsule Type without modification. </ins> Endpoints which receive a Capsule with an unknown Capsule Type MUST  <ins> silently drop that Capsule and skip over it to parse the next Capsule. </ins> By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses  <ins> that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed. </ins>  <ins> 3.3. </ins>  <ins> When an error occurs in processing the Capsule Protocol, the receiver </ins> MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed messages is described in H3.  For HTTP/2, the handling of malformed capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message.  <ins> 3.4. </ins>  <ins> The "Capsule-Protocol" header field is an Item Structured Field, see STRUCT-FIELD; its value MUST be a Boolean; any other value type MUST be handled as if the field were not present by recipients (for example, if this field is included multiple times, its type will become a List and the field will therefore be ignored).  This document does not define any parameters for the Capsule-Protocol header field value, but future documents might define parameters. Receivers MUST ignore unknown parameters. </ins>  <ins> Endpoints indicate that the Capsule Protocol is in use on a data stream by sending a Capsule-Protocol header field with a true value. A Capsule-Protocol header field with a false value has the same semantics as when the header is not present. </ins>  <ins> Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code outside the 2xx range. </ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing.  <ins> 3.5. </ins> This document defines the DATAGRAM capsule type (see iana-types for  <ins> the value of the capsule type).  This capsule allows HTTP Datagrams to be sent on a stream using the Capsule Protocol.  This is particularly useful when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </ins>  <ins> HTTP Datagrams sent using the DATAGRAM capsule have the same semantics as those sent in QUIC DATAGRAM frames.  In particular, the </ins> restrictions on when it is allowed to send an HTTP Datagram and how to process them from format also apply to HTTP Datagrams sent and received using the DATAGRAM capsule. be usable, the implementation SHOULD discard the capsule without buffering its contents into memory.  <ins> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, definitions of new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins>  <ins> 4. </ins> Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires sending an HTTP/3 Settings parameter, it "sticks out".  In other Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers).  <ins> 5. </ins>  <ins> 5.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry:  <ins> 5.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry:  <ins> 5.3. </ins> This document will request IANA to register the following entry in the "HTTP Field Name" registry:  <ins> 5.4. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.


The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code outside the 2xx range. <del> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </del>  3.5.

The text of the draft currently defines how the header works, but there's no RFC 2119 text explaining whether the client MUST or MAY send it (and the corresponding receiver behavior in case the header is missing).
The draft currently states - right now it's up to CONNECT-UDP / WebTransport, etc to define this normative text. Is that acceptable?
Sure, but it's not clear from the current text that the drafts have to give the specific guidance about the use of the header (the WebTransport draft currently does not).
Fair enough. I suggest we replace that sentence with something along the lines of:

The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code outside the 2xx range.  <ins> HTTP endpoints SHOULD use the Capsule-Protocol header field to simplify intermediary processing.  Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY alter this recommendation. </ins> 3.5.


malformed or incomplete message.  In particular, redundant length encodings MUST be verified to be self-consistent. <del> When a stream carrying capsules terminates cleanly, if the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. </del>  3.4.

End of section 3.3. (error handing) says: Not sure I can parse that sentence correctly. Is that ?
"terminates cleanly" is an abstract way of covering all HTTP versions notion of a stream FIN. This is not well defined (maybe lost in one of the restructuring edits?). If we think of HTTP/3 and the request stream being FIN'd at a particular offset, that is independent of a parser acting on the data in the stream. I think the way to make this clearer is to define or reference stream closures in respective HTTP docs.
How about this?
I don't understand the sentence structure here: When ..., if ..., then. Why is there a when and an if with a comma? May this should be: When ... and if ..., then? Sorry if that is grammatically correct but it really confuses me what the sentence is supposed to say... P.S.: clarifying the term "terminates cleanly" is also a good idea though.
We could rephrase as How does that sound?
Yes, that works for me. Thanks!
LGTM modulo nit

malformed or incomplete message.  In particular, redundant length encodings MUST be verified to be self-consistent.  <ins> If the receive side of a stream carrying capsules is terminated cleanly (for example, in HTTP/3 this is defined as receiving a QUIC STREAM frame with the FIN bit set) and the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. </ins> 3.4.


6. <del> "Datagram-Flow-Id" is a Item Structured Field STRUCT-FIELD.  Its value MUST be an Integer.  Its ABNF is: The "Datagram-Flow-Id" header field is used to associate a datagram flow identifier with an HTTP message.  For example, the definition of an HTTP method could instruct the client to use its flow identifier allocation service to allocate a new flow identifier, and then the client will add the "Datagram-Flow-Id" header field to its request to communicate that value to the server.  For example, the resulting header field could look like: Definitions of HTTP features that use the "Datagram-Flow-Id" header field MAY define their own parameters (parameters are defined in Section 3.1.2 of STRUCT-FIELD).  For example, an HTTP method that wishes to use two datagram flow identifiers for the lifetime of its request stream could encode the second flow identifier as a parameter, which could look like this: The "Datagram-Flow-Id" header field MUST NOT be present more than once on a given HTTP message; any HTTP message containing more than one "Datagram-Flow-Id" header field is malformed. Since the QUIC STREAM frame that contains the "Datagram-Flow-Id" header field could be lost or reordered, it is possible that an endpoint will receive an HTTP/3 datagram with a flow identifier that it does not know as it has not yet received the corresponding "Datagram-Flow-Id" header field.  Endpoints MUST NOT treat that as an error; they MUST either silently discard the datagram or buffer it until they receive the "Datagram-Flow-Id" header field. </del>  Note that integer structured fields can only encode values up to <del> 10^15-1, therefore the maximum possible value of the "Datagram-Flow- Id" header field is lower then the theoretical maximum value of a flow identifier which is 2^62-1 due to the QUIC variable length integer encoding.  If the flow identifier allocation service of an endpoint runs out of values lower than 10^15-1, the endpoint MUST treat is as a connection error of type H3_ID_ERROR. </del>  7. field or adhere to the requirements leveraged by that method on intermediaries.  8. This document does not have additional security considerations beyond

This PR switches the header to a list on MT's suggestion to make the semantics clearer.
URL states: The text is a little ambiguous. I presume the intention is that the endpoint that is allocating flows should do what HTTP/3 defines as ? The doesn't cover the case where an endpoint receives a Datagram Flow ID greater than 10^15-1 (either in a request or a DATAGRAM). I think it might help to separate these cases. Receiving a value of 10^15-1 is always a connection error of type H3IDERROR. But I'm not so sure about the sender case, if you really are flow ID exhausted, perhaps it is nicer to just spin up a new connection and leave the current one as is. We might recommend that endpoints initiate an HTTP/3 graceful close followed by an application close - but reusing H3IDERROR for that case seems a bit overkill.
I don't think receiving a DATAGRAM whose flow ID is >= 10^15 is an error, the receiver should just silently drop it as the flow ID is unknown. Either way we should add text to clarify the expected action of the receiver. In the sender case, I agree with you when the sender is the client, because in that case the client should instead just spin up a separate connection. On the server sender however, there is no such escape hatch, so perhaps we should tell the server to fail the operation that requested the flow ID.
Sorry I was not specific in my comment. I meant to speak about receiving the header field e.g. That would lead to an SF Integer parsing error, which would cause the field to be ignored - unless we define different behaviour. Ignoring the header has an interesting interplay with the optional guidance to buffer it until they receive the "Datagram-Flow-Id" header. Ignoring things that are strictly above the known limits seems a little too generous. Is there a reason not to reject such requests and HTTP/3 DATAGRAMS?
Ah, in that case I agree - receipt of a Datagram-Flow-Id header with value >= 10^15 should cause a connection error of type H3IDERROR. I was just thinking that conceptually receiving DATAGRAM with strange flow IDs should not be an error because that might lead implementors to declare than any unknown flow ID is an error which would break valid scenarios in the presence of reordering.
Yeah. However, I think it would be fine to reject such a request with an 4xx response rather than tear down the entire connection...
Fair enough, that works too. I'll just state that in that scenario the request is malformed
Section 6 makes the keen observation that: This is accurate but, when thinking about HTTP/3 APIs, does not cover all possible reasons that might cause a request message to be processed after the corresponding DATAGRAM frame is available. For instance, the message might be blocked by QPACK, or the implementation might present DATAGRAMS before stream headers. We could boil the ocean with describing all possible reasons, so I think it might be better to shuffle the text to focus on describe the symptom (DATAGRAMS before HTTP messages) and the treatment. We can then give non-exhaustive example(s) as already done.
I would prefer to not boil the ocean :) I'll make an editorial change to make it clearer that this is just an example among others.
The document currently uses the following example: Motivating this with an example of how to express multiple flow identifiers. I think that this example is potentially harmful. It implies a lot about a potential extension mechanism as part of an example, but does not commit to properly defining an extension. For examples like this I would much prefer to see something that is very clearly bogus. Otherwise, people might implement that to the point that they even achieve interoperability of a sort. For instance, the following requires a lot more guessing about how to interpret it, to the point that I would guess that pseudo-interoperability would be hard to arrive at by accident: See also .
The goal of this example was to show a way to build an extension. A full example of this being used is . I'm not really sure how to improve this, because making it clearly bogus defeats the purpose. Could you provide a PR?
Maybe we should talk more about the spelling of the ECN extension, which I haven't reviewed. I don't think that you should hide flow identifiers in this fashion. It prevents an intermediary from understanding which requests are actively using flow identifiers. A gateway might need to know that in order to ensure that DATAGRAM frames are consistently forwarded to the right origin server. An alternative spelling that doesn't have that property would be:
To make sure I'm understand you correctly, are you suggesting a structured field list here? That would work, and actually in that case I'd suggest dropping the parameter on the first element to make this simpler.
Yep, that's it. And I considered the same. No parameter works fine.
It's not really clear whether there are any expectations in relation to cardinality of flow identifiers and the field. Can two fields refer to the same flow ID? Can the same request reference multiple flow IDs?
I think the h3 datagram draft should allow both: two requests can reuse the same flow ID if the definition of that HTTP features allows it (this feature is used by the ) one request can reference two flow IDs - I think this is already stated though:
I'm sure that people operating intermediaries might have something to say here. A gateway that routes flows might be unwilling to replicate datagram flows that are bound to requests that go to different origin servers. I agree that one request to many flows is worthwhile, but mention in examples doesn't really count as a specification.
Fair enough, I'll add text to make this clearer. And I'll add a note to the intermediaries section about how the intermediary needs to ensure that if a second request arrives that shares a flow ID with a previous one, the intermediary MUST either send the new request to the same backend or reject it.

6.  <ins> "Datagram-Flow-Id" is a List Structured Field STRUCT-FIELD, whose members MUST all be Items of type Integer.  Its ABNF is: The "Datagram-Flow-Id" header field is used to associate one or more datagram flow identifiers with an HTTP message.  As a simple example using a single identifier, the definition of an HTTP method could instruct the client to use its flow identifier allocation service to allocate a new flow identifier, and then the client will add the "Datagram-Flow-Id" header field to its request to communicate that value to the server.  In this example, the resulting header field could look like: List members are flow identifier elements, which can be named or unnamed.  One element in the list is allowed to be unnamed, but all but one elements MUST carry a name.  The name of an element is encoded in the key of the first parameter of that element (parameters are defined in Section 3.1.2 of STRUCT-FIELD).  Each name MUST NOT appear more than once in the list.  The value of the first parameter of each named element (whose corresponding key conveys the element name) MUST be of type Boolean and equal to true.  The value of the first parameter of the unnamed element MUST NOT be of type Boolean. The ordering of the list does not carry any semantics.  For example, an HTTP method that wishes to use four datagram flow identifiers for the lifetime of its request stream could look like this: In this example, 42 is the unnamed flow identifier, 44 represents the name "ecn-ect0", 46 represents "ecn-ect1", and 48 represents "ecn- ce".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: Even if a sender attempts to communicate the meaning of a flow identifier before it uses it in an HTTP/3 datagram, it is possible that its peer will receive an HTTP/3 datagram with a flow identifier that it does not know as it has not yet received the corresponding "Datagram-Flow-Id" header field.  (For example, this could happen if the QUIC STREAM frame that contains the "Datagram-Flow-Id" header field is reordered and arrives afer the DATAGRAM frame.)  Endpoints MUST NOT treat that scenario as an error; they MUST either silently discard the datagram or buffer it until they receive the "Datagram- Flow-Id" header field. Distinct HTTP requests MAY refer to the same flow identifier in their respective "Datagram-Flow-Id" header fields. </ins> Note that integer structured fields can only encode values up to  <ins> 10^15-1, therefore the maximum possible value of an element of the "Datagram-Flow-Id" header field is lower then the theoretical maximum value of a flow identifier which is 2^62-1 due to the QUIC variable length integer encoding.  If the flow identifier allocation service of an endpoint runs out of values lower than 10^15-1, the endpoint MUST fail the flow identifier allocation.  An HTTP message that carries a "Datagram-Flow-Id" header field with a flow identifier value above 10^15-1 is malformed (see Section 8.1.2.6 of H2). </ins> 7. field or adhere to the requirements leveraged by that method on intermediaries. <ins> If an intermediary processes distinct HTTP requests that refer to the same flow identifier in their respective "Datagram-Flow-Id" header fields, it MUST ensure that those requests are routed to the same backend. </ins> 8. This document does not have additional security considerations beyond


2.1.1. <del> Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1. </del>  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or <del> 1.  A value of 0 indicates that HTTP Datagrams are not supported.  If the H3_DATAGRAM SETTINGS parameter is received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. </del>  QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1.

The current text talks about "supporting" HTTP/3 datagrams. It seems we could tighten this up to be more about the willingness to receive datagrams a la URL
SGTM

2.1.1.  <ins> Implementations of HTTP/3 that are willing to receive HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1. </ins> The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or  <ins> 1.  A value of 0 indicates that the implementation is not willing to receive HTTP Datagrams.  If the H3_DATAGRAM SETTINGS parameter is received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. </ins> QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1.


2.1.1. Implementations of HTTP/3 that are willing to receive HTTP Datagrams <del> can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1. </del>  <del> The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that the implementation is not willing to receive HTTP Datagrams.  If the H3_DATAGRAM SETTINGS parameter is </del>  received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. <del> QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1. </del>  When clients use 0-RTT, they MAY store the value of the server's <del> H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send </del>  QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept <del> 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater </del>  than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client <del> stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. </del>  It is RECOMMENDED that implementations that support receiving HTTP <del> Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter </del>  with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the <del> H3_DATAGRAM Settings Parameter.  This allows new draft revisions to </del>  make incompatible changes.  Multiple draft versions MAY be supported <del> by sending multiple values for H3_DATAGRAM.  Once SETTINGS have been sent and received, an implementation that supports multiple drafts MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both peers negotiate the same draft version. </del>  2.2. 4. Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires <del> sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP </del>  Datagrams over QUIC DATAGRAM frames.  As some servers might wish to obfuscate the fact that they offer application services that use HTTP datagrams, it's best for all implementations that support this <del> feature to always send this Settings parameter, see setting. </del>  Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those

This looks big but it consists of some minor operations H3DATAGRAM -> SETTINGSH3_DATAGRAM SETTINGS parameter -> setting Tweak the security considerations so it is explicit and grammar ain't borke
We deviate from the usual way of referring to settings, this will likely get picked up later on so may as well fix it now.

2.1.1. Implementations of HTTP/3 that are willing to receive HTTP Datagrams  <ins> can indicate that to their peer by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </ins>  <ins> The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 indicates that the implementation is not willing to receive HTTP Datagrams.  If the SETTINGS_H3_DATAGRAM setting is </ins> received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR.  <ins> QUIC DATAGRAM frames MUST NOT be sent until the SETTINGS_H3_DATAGRAM setting has been both sent and received with a value of 1. </ins> When clients use 0-RTT, they MAY store the value of the server's  <ins> SETTINGS_H3_DATAGRAM setting.  Doing so allows the client to send </ins> QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept  <ins> 0-RTT data, they MUST send a SETTINGS_H3_DATAGRAM setting greater </ins> than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client  <ins> stores the value of the SETTINGS_H3_DATAGRAM setting with their 0-RTT state, they MUST validate that the new value of the SETTINGS_H3_DATAGRAM setting sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the SETTINGS_H3_DATAGRAM setting parameter is 1. </ins> It is RECOMMENDED that implementations that support receiving HTTP  <ins> Datagrams using QUIC always send the SETTINGS_H3_DATAGRAM setting </ins> with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the  <ins> SETTINGS_H3_DATAGRAM setting.  This allows new draft revisions to </ins> make incompatible changes.  Multiple draft versions MAY be supported  <ins> by sending multiple values for SETTINGS_H3_DATAGRAM.  Once SETTINGS have been sent and received, an implementation that supports multiple drafts MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both peers negotiate the same draft version. </ins> 2.2. 4. Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires  <ins> sending the HTTP/3 SETTINGS_H3_DATAGRAM setting, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP </ins> Datagrams over QUIC DATAGRAM frames.  As some servers might wish to obfuscate the fact that they offer application services that use HTTP datagrams, it's best for all implementations that support this  <ins> feature to always send this setting, see setting. </ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those


undesirable, they can be sent using the Capsule Protocol, a more general convention for conveying data in HTTP connections. <del> Both are intended for use by HTTP extensions, not applications. </del>  1.

In Abstract: "Both are intended for use by HTTP extensions, not applications." I think instead of using Both which is unclear, rather say HTTP Datagram and Capsule Protocol. That is at least what I interpret it to be in reference to.
Agree, we should just write this out explicitly.
SGTM

undesirable, they can be sent using the Capsule Protocol, a more general convention for conveying data in HTTP connections.  <ins> HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. </ins> 1.


negotiated and conveyed using the Capsule Protocol; see datagram- capsule. <del> HTTP Datagrams MUST only be sent with an association to a stream whose HTTP semantics explicitly supports HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be sent associated with GET or POST request streams. If an HTTP Datagram associated with a method that has no known semantics for HTTP Datagrams is received, the receiver MUST abort the corresponding stream; if HTTP/3 is in use, the stream MUST be aborted with H3_DATAGRAM_ERROR.  HTTP extensions can override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams. </del>  2.1.

... and indirectly associated with streams
Section 2: "HTTP Datagrams MUST only be sent with an association to a stream whose HTTP semantics explicitly supports HTTP Datagrams." I think the reference to "stream" is unclear here. Is the intention here to refer to "HTTP Message" or "HTTP Method" that would then in HTTP/2 and HTTP/3 map to a stream? Anyway align with next paragraph that uses "Method".
The subsequent use of "method" is not great. I would substitute both with "request" e.g. "HTTP Datagrams MUST only be sent with an association to an HTTP request that explicitly supports them." ... "If an HTTP Datagram is received and it is associated with a request that does not support HTTP Datagrams, the receiver MUST terminate the request...."
Agreed, switching to request would be clearer

negotiated and conveyed using the Capsule Protocol; see datagram- capsule.  <ins> HTTP Datagrams MUST only be sent with an association to an HTTP request that explicitly supports them.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be sent associated with GET or POST request streams. If an HTTP Datagram is received and it is associated with a request that has no known semantics for HTTP Datagrams, the receiver MUST terminate the request; if HTTP/3 is in use, the request stream MUST be aborted with H3_DATAGRAM_ERROR.  HTTP extensions can override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams. </ins> 2.1.


When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including <del> unreliable delivery; see format.  Negotiation is achieved using a setting; see setting. </del>  When running over HTTP/2, demultiplexing is provided by the HTTP/2 framing layer, but unreliable delivery is unavailable.  HTTP

Using a slight variation of David's proposed text on the issue.
In Section 2: "Negotiation is achieved using a setting; see Section 2.1.1." So first I though this was just lacking an "HTTP" prior to the setting. But, I think this glosses over the general negotiation complications across versions. In this section when the high level functionality is defined, I think actually the question of negotiation in general needs to be discussed, not only for HTTP/3.
I don't understand this issue, could you elaborate? I'm assuming you are talking about Section 2 para 2, which says: The remaining paragraphs deal with consideration of other versions, and mention negotiation.
I think we can improve clarity here. Right now we have in the "HTTP Datagrams" section. We should spell it out better, maybe:
WFM

When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including  <ins> unreliable delivery; see format.  Negotiating the use of QUIC DATAGRAM frames for HTTP Datagrams is achieved via the exchange of HTTP/3 settings; see setting. </ins> When running over HTTP/2, demultiplexing is provided by the HTTP/2 framing layer, but unreliable delivery is unavailable.  HTTP


HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) <del> to enable desirable features like an unreliable version of the CONNECT method, and unreliable delivery in WebSockets RFC6455 (or its successors). </del>  In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and possibly multiplexed exchange of

Section 1: To my understanding WebSockets have no partial reliability features per that specification. So I think the formulation is missleading. To enable this in WebSockets, would it not require an update to WebSockets. I thought WebTrans is basically that update. So why not reference WebTrans here instead, it will anyway be an informational reference.
These are examples of potential future extensions that serve to illustrate the motivation. The fact that we're not planning on building such examples does not diminish their usefulness. Readers might be more familiar with WebSocket than with WebTransport at this point.

HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM)  <ins> to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </ins> In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and possibly multiplexed exchange of


data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT <del> method), and are compatible with all versions of HTTP.  When the underlying transport protocol supports unreliable delivery (such as when the QUIC DATAGRAM extension is available in HTTP/3), they can use that capability. </del>  This document also describes the HTTP Capsule Protocol in capsule, to <del> allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is unavailable or undesirable, such as when earlier versions of HTTP are in use. </del>  1.1.

Section 1. "When the underlying transport protocol supports unreliable delivery (such as when the QUIC DATAGRAM extension is available in HTTP/3), they can use that capability." "This document also describes the HTTP Capsule Protocol in Section 3, to allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is unavailable or undesirable, such as when earlier versions of HTTP are in use." To me there is a bit of mismatch between these two sentences and what HTTP/3 is prior to this extension. The first indicate that datagram support is a capability of the underlying transport for the HTTP version but then link it hard to HTTP/3. While the HTTP/3 support is dependent on this extension in addition to a QUIC stack having Datagram support. While the second takes it as a property of the HTTP version, where it is assumed that earlier version can't support this, i.e. those that are defined to use TCP only. Technically a HTTP/3 endpoint with a QUIC stack without datagram support can use capsules and this document does not require an endpoint to support QUIC datagram. And the second statement should likely use a statement saying like … unavailable or undesirable, such as when TCP is used as transport protocol as with HTTP/1.x and HTTP/2.
Fair point, HTTP 1 and 2 don't strictly require TCP either. I think we can tweak these opening paragraphs a little to be more consistent and clear.
SGTM
Looks great modulo one tweak

data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT  <ins> method), and are compatible with all versions of HTTP. When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is available to HTTP/3), HTTP Datagrams can use that capability. </ins> This document also describes the HTTP Capsule Protocol in capsule, to  <ins> allow conveyance of HTTP Datagrams using reliable delivery.  This addresses HTTP/3 cases where use of the QUIC DATAGRAM frame is unavailable or undesirable, or where the transport protocol only provides reliable delivery, such as with HTTP/1 or HTTP/2 over TCP. </ins> 1.1.


H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to use HTTP/3 datagrams in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater <del> or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR. </del>  6.

In layspeak I think this is saying "if a server sent the value 1 before, it MUST send 1 now. If a server sent 0 before, it MUST send 0 or 1 now". Could we maybe editorialize this to make it less likely for someone to do and end up sending ?
There is text in the doc stating that only 0 and 1 are valid. But I do agree that the current text is somewhat clunky. Can you send a PR?
Sure, I'll make a PR.

H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to use HTTP/3 datagrams in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater  <ins> than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. </ins> 6.


5.4. This document establishes a registry for HTTP capsule type codes. <del> 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. This registry initially contains the following entry: </del>  Capsule types with a value of the form 41 * N + 23 for integer values of N are reserved to exercise the requirement that unknown capsule types be ignored.  These capsules have no semantics and can carry arbitrary values.  These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.

Seeing support and hearing no pushback, merging this as today marks the end of WGLC
When the first IANA registry was added to this document, it used "First Come First Served" to save time. This got carried over through the various changes and now the new "Capsule Type" registry is still marked that way. But in that corresponding time, the QUIC WG came up with a very good IANA policy for varint registries and documented it in RFC 9000. We should adopt that policy for Capsule Types.
I would like to note that changes like this is not editorial, it is something that should have consensus call.
Hi Magnus, I agree that this issue is not editorial. That's why I brought it up on this list over a week ago in its own thread (). This received two approvals on and no other comments or concerns. Hi MASQUE enthusiasts, While going over draft-ietf-masque-h3-datagram with Lucas to address some WGLC comments, we realized that the document introduced a new IANA 62bit registry for Capsule Types, with a "First Come First Served" registration policy. That was an oversight that was added a long time ago, and we'd like to switch it to using the same policy as the QUIC and HTTP/3 registries. If anyone objects to this change, please let us know on the GitHub issue: URL Thanks, David

5.4. This document establishes a registry for HTTP capsule type codes.  <ins> The "HTTP Capsule Types" registry governs a 62-bit space, and operates under the QUIC registration policy documented in QUIC.  This new registry includes the common set of fields listed in QUIC.  In addition to those common fields, all registrations in this registry MUST include a "Capsule Type" field which contains a short name or label for the capsule type. Permanent registrations in this registry are assigned using the Specification Required policy (IANA-POLICY), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections IANA- POLICY and IANA-POLICY of IANA-POLICY. </ins> Capsule types with a value of the form 41 * N + 23 for integer values of N are reserved to exercise the requirement that unknown capsule types be ignored.  These capsules have no semantics and can carry arbitrary values.  These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. <ins> This registry initially contains the following entry: </ins>


unreliable delivery to WebSockets RFC6455. In datagrams, this document describes HTTP Datagrams, a convention <del> that supports the bidirectional and possibly multiplexed exchange of data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT method), and are compatible with all versions of HTTP. </del>  When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is 2.1.1. <del> Implementations of HTTP/3 that are willing to receive HTTP Datagrams can indicate that to their peer by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </del>  The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 indicates that the implementation is not willing to the maximum permitted value of the SETTINGS_H3_DATAGRAM setting parameter is 1. <del> It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the SETTINGS_H3_DATAGRAM setting with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. </del>  2.1.1.1. request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams, which is necessary when HTTP is running over a transport that does not support <del> the QUIC DATAGRAM frame. </del>  3.1.

Editorial suggestions from WGLC review
This protocol is being introduced with one use case, and that case is a generalisation that's capable of incorporating almost anything (datagrams). Is this a case of premature abstraction? While from an implementation standpoint this abstraction might not be expensive, adding a new abstraction to HTTP's core data model isn't something we should do lightly; the road is littered with failed and poorly-integrated attempts.
At the MASQUE Interim in April 2021, the WG reached consensus on strongly associating HTTP Datagrams with requests, and the fact that HTTP Datagrams would work across intermediaries. We also established that there was a need to register context semantics end-to-end. That same day, Ben Schwartz proposed the name capsule for such a system and we've kept it since. In the past year, we've thoroughly discussed capsules among the Working Group, and the possibility of premature optimization was discussed. The Working Group decided that this was a useful abstraction, and CONNECT-IP and WebTransport both started using the abstraction, confirming that it was useful. The final design of the Capsule Protocol came out of the HTTP Datagrams design team, was presented at the February 2022 MASQUE Interim and Working Group consensus was declared by the chairs . Unless you have any new information that would warrant revisiting this consensus, I'd suggest closing this issue with no action.
Closing this based on the comment above since today marks the end of WGLC
LGTM, thanks! Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric

unreliable delivery to WebSockets RFC6455. In datagrams, this document describes HTTP Datagrams, a convention  <ins> that supports the bidirectional and optionally multiplexed exchange of data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT method), and are compatible with all versions of HTTP. </ins> When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is 2.1.1.  <ins> Endpoints can indicate to their peer that they are willing to receive HTTP/3 Datagrams by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </ins> The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 indicates that the implementation is not willing to the maximum permitted value of the SETTINGS_H3_DATAGRAM setting parameter is 1.  <ins> It is RECOMMENDED that implementations that support receiving HTTP/3 Datagrams always send the SETTINGS_H3_DATAGRAM setting with a value of 1, even if the application does not intend to use HTTP/3 Datagrams.  This helps to avoid "sticking out"; see security. </ins> 2.1.1.1. request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams, which is necessary when HTTP is running over a transport that does not support  <ins> the QUIC DATAGRAM frame.  The Capsule Protocol can also be used to communicate reliable and bidirectional control messages associated with a datagram-based protocol even when HTTP/3 Datagrams are in use. </ins> 3.1.


silently drop that Capsule and skip over it to parse the next Capsule. <del> By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx (Successful) status code. </del>  The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields.

This looks ok
I find the difference between HTTP 1.x and HTP/2 vs HTTP/3 when an endpoint support QUIC datagram quite worrying. So as capsules are sent instead of the message body in requests and response, for HTTP/3 when one have QUIC datagram support a method can be defined to use both the reliable body as well as HTTP datagrams. This is not possible over HTTP/3 when the QUIC stack doesn't support QUIC datagram or for HTTP 1.x or HTTP/2. I think this makes it very hard to define something that will just work. I Think the easy fix for this is to just define in addition to the Datagram capsule a body capsule that carries a fragment of the body, so that one can send over an upgraded path both parts of the body as well as the HTTP Datagrams. The fact that the Capsule protocol doesn't give feature parity even for HTTP/3 is deeply worrying in my view. I can understand how this has not come up prior as the existing HTTP methods that been targeted by this mechanism, i.e. Connect results in that the data stream becomes the capsule streams. However, if some other HTTP extension that using Extended Connect are used, then the need for both body and HTTP datagram could arise.
Successful CONNECT and extended CONNECT requests convert the request into a data stream, those bytes cease to be HTTP "content" (the term we should be using instead of "body"). Supporting HTTP content over capsules sounds like a sure-fire way to introduce security bugs. I don't see any reason to do that as part of this specification. Future extensions would need to do the security analysis and probably find that there's a better design to be had.
Okay, but then I think the scope of this extension needs to be made clear to be limited to HTTP Extensions that has this semantics of converting the content.
I don't think that is a hard scope though, and if it is, it is something we need to think hard about and come to consensus on. Currently, if people find they really want to encode HTTP content in capsule, they are free to do so with all the risks that might entail. Being overly restrictive on future uses doesn't seem that helpful at this stage.
+1 to what Lucas said, a future extension is free to design "HTTP content over capsules" if it needs it. We don't have a need for it today. The current scope is made clear by the text banning use of datagrams on requests that don't have known semantics for them
I am fine with a clarification that this support is currently not in scope due to reasons, and future HTTP extensions may be define additional capsule for content to enable this. I don't have a use cases, but currently HTTP/3 can support using both request content and HTTP datagrams simultanously.
OK documenting that HTTP/3 is special, as a consideration for future specifications to be aware of, seems reasonable to me.
+1. Marking this as editorial, we'll write up a PR to clarify that HTTP content can't be currently with capsules and that h3 is slightly special.
LGTM

silently drop that Capsule and skip over it to parse the next Capsule.  <ins> By virtue of the definition of the data stream: The Capsule Protocol is not in use unless the response includes a 2xx (Successful) status code. When the Capsule Protocol is in use, the associated HTTP request and response do not carry HTTP content.  A future extension MAY define a new capsule type to carry HTTP content. </ins> The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields.


In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header <del> section, or the response header section.  As a result, only a single HTTP request starting the capsule protocol can be sent on HTTP/1.x connections. </del>  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding

Nit from AD review: The original sentence is ambiguously worded, and could be interpreted as saying that there could not be normal HTTP requests prior to the capsule protocol.
Thanks, this is an important clarification that makes clearer the original intent of the statement.

In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header  <ins> section, or the response header section.  As a result, only the last HTTP request on an HTTP/1.x connection can start the capsule protocol. </ins> In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding


and server - only allocation carries separate namespaces to avoid requiring synchronization.  4. When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM

introduced the following text: There are 2 problems with this, in each direction: In the send-direction, this can only be ascertained in the case of no packet loss, when all packets have been acknowledged. If any packet is not acknowledged, this could be due to this packet actually having been lost or just reordered delayed. While it's possible to ascertain that all sent packets have been acknowledged, this is not possible for packets sent by the peer. Reusing a flow identifier opens up an attack vector: An attacker could delay the delivery of a packet containing the old flow identifier until it has been retired and reused. This would lead to a reinterpretation of the DATAGRAM contents in a new application context.
If your HTTP/3 code is closely coupled with your QUIC code, this can be solved by looking at QUIC packet numbers. If we take the CONNECT-UDP example, receiving a RESETSTREAM frame for the CONNECT-UDP stream ensures that the peer will not send subsequent DATAGRAM frames with this flow ID. If you record the packet number of the packet that carried the RESETSTREAM frame, you can then drop any DATAGRAM frames with that flow ID whose packet number is lower. That solves both problems you've described.
It is not, my implementation separates the two layers. In the design of QUIC transport, we went a long way to avoid looking at the packet number at all. If this design principle applied to the transport, it should even more so apply to applications built on top of QUIC. That only applies for the server side, doesn't it? The client still wouldn't know if a packet it receives was sent before or after the ID was reassigned.
This feature is optional, so you could choose to not implement it. Or are you proposing a different mechanism that works? I agree that we shouldn't violate this design principle in the mandatory parts of the spec, but doing so in optional features seems acceptable to me. This isn't really about client or server, but more about who sent the RESETSTREAM frame. The receiver of RESETSTREAM can key on the packet number that carried that frame, whereas its peer can key on the packet number of the first acknowledgement for that RESET_STREAM.
How so? How do I prevent the peer from reusing a flow identifier? Actually, I'm not quite sure I understand the issue that NAME raised in . I see flow identifiers as analogues to stream IDs. For stream IDs, we never even considered reusing them, even though that wouldn't have required a layer violation in that case. Why are the 3 additional bytes (I'm assuming you're using fewer than 1073741823/2 identifiers on a typical connection, otherwise it's 7) too expensive in one case, but not the other?
Why would you want to prevent the peer from reusing a flow identifier? The peer ensures the security properties of reuse. Because the payload of DATAGRAM frames needs to fit in a single QUIC packet, whereas STREAM frames allows splitting the payload across packets. When you're tunneling, this means that the overhead impacts your MTU when using DATAGRAMs.
I'd like to raise the attention towards the idea that reliably supporting reuse of flow identifiers can become quite complicated when in large-scale installations. Consider a large scale point of presence, where a large number of servers are sharing the same public IPs: In such scenario, multiple datagrams that share the same flow identifier may be served by several distinct physical servers. In order for these servers to be able to route the datagrams in a consistent way, the flow id allocation service must be able to provide some sort of consistency guarantees: when the flow identifier expires, any server that may serve the flow needs to agree that the flow has indeed expired. In other words, there is a consensus problem lurking behind the scenes. While there are several ways to achieve such consensus, all share some propagation delay. Clients don't have a good way to estimating such delay (except for the observation that it's unlikely to be significantly shorter than the retransmit timeout). It may be worth at least mentioning that reusing the flow identifiers rapidly is not recommended. (edit: changed the wording that has mistakenly projected an argument as a known fact).
Hi NAME , this is an interesting scenario but I'm not sure I understand it: are you saying that multiple servers can send the same datagram flow ID on the same connection? How does that work? Given that QUIC uses incremental packet numbers as the encryption nonce, you're going to need a synchronization point in the server-to-client datapath anyway, or am I misunderstanding something?
Hi NAME I was probably unclear. It is also possible that I am missing something. Let me try to clarify my comment. EDIT: I have reformatted / rephrased and clarified the comment. Again, I may be missing something, and will be glad to learn more in this case. I think the main point of my comment - if the flow id is known to the applications, then it would be hard to communicate the retirement of the flow ID. In particular, in some situations it would be impossible for an endpoint to infer that a particular flow id has been successfully "retired" by the peer endpoint, because the application can retain the state associated with that flow id.
Maybe the draft isn't clear: the idea is that the application is responsible for knowing that the flow ID is no longer in use, and ensuring that the application on the peer also knows that it is no longer in use, before retiring it - the application tells the flow allocation service to retire, the flow allocation service doesn't do it on its own.
There is a certain advantage to being able to use small flow identifiers, but there are only 32 of the smallest available for any given usage. Would it be possible for a particular usage to reuse a value? I ask because CONNECT-UDP has a distinct start and end and could possibly take advantage of this. That would have some small, but likely meaningful, impact on efficiency.
I agree, this feature might make a real performance difference. The only caveat is reordering, we'll have to be careful that if receiving a RESET_STREAM frame for the CONNECT-UDP stream makes a flow ID available and a datagram with that flow ID gets reordered to arrive after, we'll need to check the packet number to make sure that this datagram is dropped instead of routed to its new owner.
I don't like looking at packet numbers and would be opposed to that. It's a pretty serious layering violation. A guard interval to minimize the potential for overlap might help, but I would prefer that we only allow reuse if the protocol that is carried has some sort of protection against receiving bad packets. Tunneled QUIC should work fine for that (though Version Negotiation packets are still a little bit of a concern), as would tunneled STUN/TURN and WebRTC. More analysis would be required if the protocol did not provide its own integrity protection, but as this is primarily a tunneling protocol, we might be safe in advising against that.

and server - only allocation carries separate namespaces to avoid requiring synchronization. <ins> The flow allocation service SHOULD also provide a mechanism for applications to indicate they have completed their usage of a flow identifier and will no longer be using that flow identifier, this process is called "retiring" a flow identifier.  Applications MUST NOT retire a flow identifier until after they have received confirmation that the peer has also stopped using that flow identifier.  The flow identifier allocation service MAY reuse previously retired flow identifiers once they have ascertained that there are no packets with DATAGRAM frames using that flow identifier still in flight.  Reusing flow identifiers can improve performance by transmitting the flow identifier using a shorter variable-length integer encoding. </ins> 4. When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM


BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  2. HTTP Datagrams are a convention for conveying bidirectional and 2.1. When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM <del> frames uses the following format (using the notation from the "Notational Conventions" section of QUIC): </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 Definitions of new HTTP Upgrade Tokens can state that their associated request's data stream uses the Capsule Protocol.  If they do so, that means that the contents of the associated request's data <del> stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del>  An intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by

Inspired by Martin Duke's suggestion to reference integer encoding more directly, this change just sticks it all in one place and makes it clear that there is no expectation to minimally-encode varints. Styled on similar references to QUIC made in URL

BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses terminology from QUIC. Where this document defines protocol types, the definition format uses the notation from QUIC.  Where fields within types are integers, they are encoded using the variable-length integer encoding from QUIC.  Integer values do not need to be encoded on the minimum number of bytes necessary. </ins> 2. HTTP Datagrams are a convention for conveying bidirectional and 2.1. When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM  <ins> frames uses the following format: </ins> 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 Definitions of new HTTP Upgrade Tokens can state that their associated request's data stream uses the Capsule Protocol.  If they do so, that means that the contents of the associated request's data  <ins> stream uses the following format: </ins> An intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by


1. <del> HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </del>  In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and optionally multiplexed exchange

Issue created in reponse to considerations section seems straightforward. extensions" at first, but from context, I'm guessing it's used loosely to mean any addition to HTTP? I found RFC 2774 when I was looking to see if it meant something specific, but I'm guessing it's not a reference to a 20+ year old experimental RFC? The term HTTP extensions is defined in . Since we already have a normative reference to that document, I propose to resolve this issue by adding a reference to that section in our introduction.
Lgtm Reviewer: David Mandelberg Review result: Ready I did not notice any security issues with this document, and the security considerations section seems straightforward. (nit / question / feel free to ignore) I was a bit confused by the term "HTTP extensions" at first, but from context, I'm guessing it's used loosely to mean any addition to HTTP? I found RFC 2774 when I was looking to see if it meant something specific, but I'm guessing it's not a reference to a 20+ year old experimental RFC?

1.  <ins> HTTP extensions (as defined in HTTP) sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </ins> In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and optionally multiplexed exchange


Data streams can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY.  3.2. Definitions of new HTTP Upgrade Tokens can state that their that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed.  3.3. When an error occurs in processing the Capsule Protocol, the receiver large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory.  Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports

This adds a few statements through the text that explains that data streams are subject to any flow control provided by layers lower down. Wih that in mind, the potential for problem deadlocks should be clearer when we state it.
This is a non-blocking comment from AD review. I have no concerns if the authors choose to close it with no action. It might be worthwhile to discuss the interaction of stream flow control with capsule/datagram conversions. With other HTTP transactions, intermediaries can deliver whatever in-order bytes of the stream they have. When receiving capsules and emitting datagrams, if the stream flow control window is too small to accept the datagram size, there can be a deadlock. A sentence about this special case could avoid a silly implementer mistake.
I think this goes beyond just intermediaries. Instead it applies to any consumer of capsules where they might be tempted to try and buffer the capsule, in the data stream, in its entirety before processing or consuming it. That might be obvious as a "bad thing" for implementers that are already used to handling H2 or H3 frames. However, you identify that the DATAGRAM capsule is particularly tempting to buffer because it should be handled atomically. So I think it might help to briefly point out some deadlock considerations about flow window sizes in relation to capsule sizes, and processing / release of further window credits.
Adding a little bit of text to warn against such cases SGTM

Data streams can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY. <ins> Data streams are subject to the flow control mechanisms of the underlying layers (for example, HTTP/2 stream flow control, HTTP/2 connection flow control, and TCP flow control). </ins> 3.2. Definitions of new HTTP Upgrade Tokens can state that their that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed. <ins> When processing capsules, a receiver might tempted to accumulate the full length of the capsule value in the data stream before handling it.  This approach can consume flow control in underlying layers, which might lead to deadlocks if the capsule data exhausts the flow control window. </ins> 3.3. When an error occurs in processing the Capsule Protocol, the receiver large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <ins> Since QUIC DATAGRAM frames are required to fit within a QUIC packet, implementations that reencode DATAGRAM capsules into QUIC DATAGRAM frames might be tempted to accumulate the entire capsule before reencoding it.  This can cause flow control problems; see capsule- protocol. </ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports