Draft: draft-ietf-masque-h3-datagram

Commentary: End of section 3.5 ( ) says : First of all this paragraph seems to be in the wrong section because it 's more generally about the capsule protocol and not the datagram capsule . However , it 's also confusing . I believe if you negotiate http datagram with the H3DATAGRAM SETTINGS parameter , you always need to also support capsules even if QUIC datagrams are supported , as the other end ( e.g. an intermediary ) could send you anyway a capsule . Or is this text meant to say that new extensions that use the http datagram but have a new settings parameter for negotiation may not need to support the capsule protocol ? I think it would be good to clarify both : what this sentence / paragraph means and what is required if you negotiate http datagrams using the H3DATAGRAM SETTINGS parameter . 
 I want to extended on this issue a bit more . A lot about the implementation requirement on different nodes are implied rather than being explicit . " Secondly , I will note that the above text combined with what is written in Section 3.4 : Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown HTTP   ; note that this is only possible for HTTP Upgrade or Extended CONNECT . " If an intermediary is doing this unaware re - encoding and the HTTP extension is an extended connect version it can result in interoperability failure when a Datagram capsule arrives at the endpoint that only supports HTTP/3 Datagrams over QUIC Datagram . 
 If we build off the notion that H3DATAGRAM setting communicates a willingness to receive the HTTP/3 datagrams ( in QUIC datagrams ) , they still require some request to bootstrap the association , otherwise those datagrams would be ignored . In theory , I could define a new method called " ALWAYSUNRELIABLE " that can be used to bootstrap a request stream and it be defined to never use a capsule protocol . If a server sends me data on that stream , I could ignore it or throw an error . I do n't need a new setting to caveat this behaviour . 
 but then you ca n't have " blind " re - encoding of HTTP/3 Datagram to Datagram capsules , I think it is that simple . So we need to choose if HTTP Intermediaries can re - encode when they do n't know the Upgrade Token or if they ca n't and must be aware and thus enable cases where some have different behaviors . See 
 There is no such thing as " blind re - encoding " . Intermediaries can only perform re - encoding when they know that the capsule protocol is in use . Intermediaries can learn that by knowing the HTTP Upgrade Token , or by watching for the Capsule - Protocol header . But I think we can make that clearer by spelling out in the " DATAGRAM Capsule " section that intermediaries MUST NOT re - encode to capsules unless they know for sure that the capsule protocol is in use . 
 PR did not address the editorial point that this paragraph is in the wrong section . 
 I do n't agree with that editorial point . The paragraph is about the interaction between HTTP datagrams and the capsule protocol , so having in the DATAGRAM capsule section makes sense to me . 
 It about the interaction about http datagrams ( section 2 ) and the capsule protocol ( section 3 ) . There is nothing related to datagram capsules ( section 3.5 ) in this paragraph . I guess you could just add a new subsection 3.6 if you prefer to have it at the end . 
 LGTM
An intermediary can reencode HTTP Datagrams as it forwards them.  In
other words, an intermediary MAY send a DATAGRAM capsule to forward
an HTTP Datagram which was received in a QUIC DATAGRAM frame, and
vice versa.
An intermediary can reencode HTTP Datagrams as it forwards them.  In
other words, an intermediary MAY send a DATAGRAM capsule to forward
an HTTP Datagram that was received in a QUIC DATAGRAM frame, and vice
versa.  Intermediaries MUST NOT perform this reencoding unless they
have identified the use of the Capsule Protocol on the corresponding
request stream; see capsule-protocol.