Change:
capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. <del> 4.3. </del> <ins> 3.4. </ins> <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> <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> <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> <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> <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> <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. <del> 4.4. </del> <ins> 3.5. </ins> 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> <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> <del> Datagrams sent using the DATAGRAM capsule have the same semantics as datagrams sent in QUIC DATAGRAM frames.  In particular, the </del> <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.

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!