Draft: draft-ietf-masque-h3-datagram

Commentary: In Section 2 : When running over HTTP/1 , requests are strictly serialized in the connection , therefore the first layer of demultiplexing is not needed . Is there any actual possibility to run more than a single request with HTTP datagram support over an transport connection ? When one runs an HTTP request that enables datagram I do n't see how it would be possible to close that request in any other way than closing the underlying transport connection . Or are there a way that I am missing that would enable one to close this request , and then issue another pipelined HTTP request that also uses HTTP datagrams ? Is there a need to clarify this , or make it clear that only a single HTTP request with datagram can be sent ? 
 In section 2 , we 've yet to mention anything about how the rest of the spec operates . So the comment in isolation is correct when talking about the general concept of multiplexin . I see your point but I 'm not sure saying anything more here will help . Section 4.1 provides the details that implementers need to do the right thing . 
 Okay , but lets include Section 4.1 also into this . I assume you are referring to this sentence : In HTTP/1.x , the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section , or the 2xx ( Successful ) response header section . But , per this body length length rules will be those that could govern a closure of a HTTP request enabling datagram . Would it be realistic to actually make it clear that if one enable HTTP Datagram transport close is the only , way or is that just creating additional rules making implementation even more ? Otherwise do we need additional analysis if there are possibility that any of these rules could actually result in a closing a HTTP request ? 
 There is no HTTP content on upgrade requests , we should link to the definition of Upgrade and make things slightly more clear in Section 4.1 . 
 Ok , I guess it becomes a question of which method for enabling datagram one uses , if this is an upgrade or a new method . And I would note that Connect method appears to have some interesting exceptions compared to other methods . Which I think makes this into a requirement on the using method / upgrade that uses HTTP datagrams to actually specify this aspect . 
 I 've written up to clarify that pipelining is not supported .
This specification defines the "data stream" of an HTTP request as
the bidirectional stream of bytes that follow the headers in both
directions.  In HTTP/1.x, the data stream consists of all bytes on
the connection that follow the blank line that concludes either the
request header section, or the 2xx (Successful) response header
section.  In HTTP/2 and HTTP/3, the data stream of a given HTTP
request consists of all bytes sent in DATA frames with the
corresponding stream ID.  The concept of a data stream is
particularly relevant for methods such as CONNECT where there is no
HTTP message content after the headers.
This specification defines the "data stream" of an HTTP request as
the bidirectional stream of bytes that follow the headers in both
directions.  In HTTP/1.x, the data stream consists of all bytes on
the connection that follow the blank line that concludes either the
request header section, or the 2xx (Successful) response header
section.  (Note that only a single HTTP request starting the capsule
protocol can be sent on HTTP/1.x connections.)  In HTTP/2 and HTTP/3,
the data stream of a given HTTP request consists of all bytes sent in
DATA frames with the corresponding stream ID.  The concept of a data
stream is particularly relevant for methods such as CONNECT where
there is no HTTP message content after the headers.