Code change:
large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <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 that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.

Related discussion:
text: So I think at the bottom this issue is really the question about the possibility to convert between HTTP/3 Datagram and Datagram capsule. I think we need to settle that question first. It is a question of what requirements one have on endpoints vs intermediaries. Lets start in that end.
I actually think I prefer your option 3, caveated by saying "if you're an intermediary and you don't know the upgrade token, don't insert datagram capsules" . What concern do you have about option 3?
Okay, I am skeptical against 3) on how it may make deployment of future extensions that require HTTP Datagram but doesn't need other than Intermediary forwarding. In that case deployment could be hampered if not all HTTP intermediaries are also HTTP/3 capable. It appears that using capsule protocol would be easier to enable over a legacy system. That might be a misconception from my part.
NAME Thank you for clarifying, now I understand where the disconnect is. The draft currently says and you interpreted that as but that's not what we intended, we meant . I've written up to remedy this
NAME great that we managed to sort out what was the issue. As Lucas noted in the PR unless all HTTP Datagram implementation support and accept receiving Datagram capsule, even if not intended by the HTTP Extension, if unaware of HTTP extension transformation is allowed, it can fail. I think we need a bit more feedback on where people stand in this aspect.
Thanks NAME If the HTTP extension doesn't use capsules, then the implementation won't parse the data stream as capsules so there is no risk of accidentally receiving capsules. We added text to to clarify the risks of not using the capsule protocol.
I think this was closed prematurely because the issue originally was about MUST or SHOULD and I don't think we concluded on this. If the argument is that this is not enforceable, I think we should not use normatively language at all (and say something like "intermediaries are expected ..."). However, using SHOULD were we actually mean MUST, weakens the requirement and risk that this is misunderstood to be optional (while I think this is the core of the whole capsule protocol).
Reopening to discuss SHOULD vs MUST.
I'd consider capsules to be similar to header fields (headers specifically, not trailers).