Change:
2. <del> All HTTP Datagrams are associated with an HTTP request. </del> <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> <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> <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 <del> framing layer.  When running over HTTP/1, requests are strictly serialized in the connection, therefore demultiplexing is not needed. 3. </del> <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

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!