Original text:
unreliable delivery to WebSockets RFC6455. In datagrams, this document describes HTTP Datagrams, a convention <del> 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. </del>  When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is 2.1.1. <del> Implementations of HTTP/3 that are willing to receive HTTP Datagrams can indicate that to their peer by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </del>  The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 indicates that the implementation is not willing to the maximum permitted value of the SETTINGS_H3_DATAGRAM setting parameter is 1. <del> It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the SETTINGS_H3_DATAGRAM setting with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. </del>  2.1.1.1. request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams, which is necessary when HTTP is running over a transport that does not support <del> the QUIC DATAGRAM frame. </del>  3.1.

Reviewer comments:
Editorial suggestions from WGLC review
This protocol is being introduced with one use case, and that case is a generalisation that's capable of incorporating almost anything (datagrams). Is this a case of premature abstraction? While from an implementation standpoint this abstraction might not be expensive, adding a new abstraction to HTTP's core data model isn't something we should do lightly; the road is littered with failed and poorly-integrated attempts.
At the MASQUE Interim in April 2021, the WG reached consensus on strongly associating HTTP Datagrams with requests, and the fact that HTTP Datagrams would work across intermediaries. We also established that there was a need to register context semantics end-to-end. That same day, Ben Schwartz proposed the name capsule for such a system and we've kept it since. In the past year, we've thoroughly discussed capsules among the Working Group, and the possibility of premature optimization was discussed. The Working Group decided that this was a useful abstraction, and CONNECT-IP and WebTransport both started using the abstraction, confirming that it was useful. The final design of the Capsule Protocol came out of the HTTP Datagrams design team, was presented at the February 2022 MASQUE Interim and Working Group consensus was declared by the chairs . Unless you have any new information that would warrant revisiting this consensus, I'd suggest closing this issue with no action.
Closing this based on the comment above since today marks the end of WGLC
LGTM, thanks! Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric

Revised text:
unreliable delivery to WebSockets RFC6455. In datagrams, this document describes HTTP Datagrams, a convention  <ins> that supports the bidirectional and optionally 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. </ins> When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is 2.1.1.  <ins> Endpoints can indicate to their peer that they are willing to receive HTTP/3 Datagrams by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </ins> The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 indicates that the implementation is not willing to the maximum permitted value of the SETTINGS_H3_DATAGRAM setting parameter is 1.  <ins> It is RECOMMENDED that implementations that support receiving HTTP/3 Datagrams always send the SETTINGS_H3_DATAGRAM setting with a value of 1, even if the application does not intend to use HTTP/3 Datagrams.  This helps to avoid "sticking out"; see security. </ins> 2.1.1.1. request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams, which is necessary when HTTP is running over a transport that does not support  <ins> the QUIC DATAGRAM frame.  The Capsule Protocol can also be used to communicate reliable and bidirectional control messages associated with a datagram-based protocol even when HTTP/3 Datagrams are in use. </ins> 3.1.