Change:
<del> Using Datagrams with HTTP </del> <ins> HTTP Datagrams and the Capsule Protocol </ins> 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> <ins> This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. </ins> <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> <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> <del> multiplexing presents core concepts for multiplexing across HTTP versions. </del> <ins> Both are intended for use by HTTP extensions, not applications. </ins> <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> <ins> 1. </ins> <del> datagram-capsule defines Datagram Capsule types, along with guidance for specifying new capsule types. </del> <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.

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!