Change:
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> <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> <del> 4. </del> <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 <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> <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 <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> <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 <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> <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> <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> <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 <del> silently drop that Capsule. </del> <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

Discussion:
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!