Change:
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> <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> <del> 3.1. </del> <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 <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> <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> <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> <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

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!