Code change:
HTTP message content after the headers. Note that use of the Capsule Protocol is not required to use HTTP <del> Datagrams.  If a new HTTP Method or Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol.  However, new HTTP Method or Upgrade Tokens SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Datagrams.  If a new HTTP Upgrade Token is only defined over transports that support QUIC DATAGRAM frames, they might not need a stream encoding.  Additionally, definitions of new HTTP Upgrade Tokens can use HTTP Datagrams with their own data stream protocol. However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </ins> 4.1. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> Definitions of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </ins> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST

Related discussion:
text: NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose.