Original text:
Data streams can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY.  3.2. Definitions of new HTTP Upgrade Tokens can state that their that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed.  3.3. When an error occurs in processing the Capsule Protocol, the receiver large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory.  Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports

Reviewer comments:
This adds a few statements through the text that explains that data streams are subject to any flow control provided by layers lower down. Wih that in mind, the potential for problem deadlocks should be clearer when we state it.
This is a non-blocking comment from AD review. I have no concerns if the authors choose to close it with no action. It might be worthwhile to discuss the interaction of stream flow control with capsule/datagram conversions. With other HTTP transactions, intermediaries can deliver whatever in-order bytes of the stream they have. When receiving capsules and emitting datagrams, if the stream flow control window is too small to accept the datagram size, there can be a deadlock. A sentence about this special case could avoid a silly implementer mistake.
I think this goes beyond just intermediaries. Instead it applies to any consumer of capsules where they might be tempted to try and buffer the capsule, in the data stream, in its entirety before processing or consuming it. That might be obvious as a "bad thing" for implementers that are already used to handling H2 or H3 frames. However, you identify that the DATAGRAM capsule is particularly tempting to buffer because it should be handled atomically. So I think it might help to briefly point out some deadlock considerations about flow window sizes in relation to capsule sizes, and processing / release of further window credits.
Adding a little bit of text to warn against such cases SGTM

Revised text:
Data streams can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY. <ins> Data streams are subject to the flow control mechanisms of the underlying layers (for example, HTTP/2 stream flow control, HTTP/2 connection flow control, and TCP flow control). </ins> 3.2. Definitions of new HTTP Upgrade Tokens can state that their that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed. <ins> When processing capsules, a receiver might tempted to accumulate the full length of the capsule value in the data stream before handling it.  This approach can consume flow control in underlying layers, which might lead to deadlocks if the capsule data exhausts the flow control window. </ins> 3.3. When an error occurs in processing the Capsule Protocol, the receiver large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <ins> Since QUIC DATAGRAM frames are required to fit within a QUIC packet, implementations that reencode DATAGRAM capsules into QUIC DATAGRAM frames might be tempted to accumulate the entire capsule before reencoding it.  This can cause flow control problems; see capsule- protocol. </ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports