Draft: draft-ietf-masque-h3-datagram

Commentary: This looks ok 
 I find the difference between HTTP 1.x and  vs HTTP/3 when an endpoint support QUIC datagram quite worrying . So as capsules are sent instead of the message body in requests and response , for HTTP/3 when one have QUIC datagram support a method can be defined to use both the reliable body as well as HTTP datagrams . This is not possible over HTTP/3 when the QUIC stack does n't support QUIC datagram or for HTTP 1.x or HTTP/2 . I think this makes it very hard to define something that will just work . I Think the easy fix for this is to just define in addition to the Datagram capsule a body capsule that carries a fragment of the body , so that one can send over an upgraded path both parts of the body as well as the HTTP Datagrams . The fact that the  protocol does n't give feature parity even for HTTP/3 is deeply worrying in my view . I can understand how this has not come up prior as the existing HTTP methods that been targeted by this mechanism , i.e. Connect results in that the data stream becomes the capsule streams . However , if some other HTTP extension that using Extended Connect are used , then the need for both body and HTTP datagram could arise . 
 Successful CONNECT and extended CONNECT requests convert the request into a data stream , those bytes cease to be HTTP " content " ( the term we should be using instead of " body " ) . Supporting HTTP content over capsules sounds like a sure - fire way to introduce security bugs . I do n't see any reason to do that as part of this specification . Future extensions would need to do the security analysis and probably find that there 's a better design to be had . 
 Okay , but then I think the scope of this extension needs to be made clear to be limited to HTTP Extensions that has this semantics of converting the content . 
 I do n't think that is a hard scope though , and if it is , it is something we need to think hard about and come to consensus on . Currently , if people find they really want to encode HTTP content in capsule , they are free to do so with all the risks that might entail . Being overly restrictive on future uses does n't seem that helpful at this stage . 
 +1 to what Lucas said , a future extension is free to design " HTTP content over capsules " if it needs it . We do n't have a need for it today . The current scope is made clear by the text banning use of datagrams on requests that do n't have known semantics for them 
 I am fine with a clarification that this support is currently not in scope due to reasons , and future HTTP extensions may be define additional capsule for content to enable this . I do n't have a use cases , but currently HTTP/3 can support using both request content and HTTP datagrams simultanously . 
 OK documenting that HTTP/3 is special , as a consideration for future specifications to be aware of , seems reasonable to me . 
 +1 . Marking this as editorial , we 'll write up a PR to clarify that HTTP content ca n't be currently with capsules and that h3 is slightly special . 
 LGTM
By virtue of the definition of the data stream, the Capsule Protocol
is not in use on responses unless the response includes a 2xx
(Successful) status code.
The Capsule Protocol is not in use unless the response includes a
2xx (Successful) status code.
When the Capsule Protocol is in use, the associated HTTP request
and response do not carry HTTP content.  A future extension MAY
define a new capsule type to carry HTTP content.