Draft: draft-ietf-webtrans-http3

Commentary: . 
 cc 
 Looks great ! 
 For a simple application that wants to send " hello world " over a WebTransport stream , it would take a minimum of 2.5 round trips for the data to arrive on the server . This is still an improvement over WebSockets but I 'm wondering if we could do better . If the client is able to create streams prior to receiving the CONNECT response , then it would remove a round trip . The server would need to buffer any data received on streams associated with an unknown WebTransport session . If the server responds with a non-200 status code , then these streams are discarded . I believe 0 - RTT is disabled for WebTransport because CONNECT is not idempotent and would be subject to replay attacks . An idempotent CONNECT would remove a round trip when 0 - RTT is used ... although I 'm not sure this is a good idea . 
 I think this is a reasonable optimization 
 The client requirement is odd in comparison to MASQUE / CONNECT - UDP which says " client can risk sending datagrams before getting a 200 response , a different response means that datagrams will be discarded " . What is the motivation for the requirement in WebTransport ? If you need some kind of ordering guarantees , then stream IDs provide that . 
 Discussed at IETF 110 . There were no objections to buffering ( with some limits ) , so I think we should go ahead and add it . 
 After the client initiates the WebTransport session by sending a CONNECT request , the server sends a 200 response and is free to create streams . This means that a server - initiated stream may arrive prior to the CONNECT response . Is the client able to infer that the session was successfully established , or does the client need to buffer this stream until it receives a proper response ? 
 Since there are no ordering guarantees across streams on the receiver side , I 'd say you have to buffer until the 200 is processed . 
 I agree with Lucas here . We also had a similar problem in QuicTransport ( server has to buffer streams before checking the origin ) , and we handled it by buffering . 
 Discussed at IETF 110 . There were no objections to buffering ( with some limits ) , so I think we should go ahead and add it .
From the client's perspective, a WebTransport session is established
when the client receives a 200 response.  From the server's
perspective, a session is established once it sends a 200 response.
Both endpoints MUST NOT open any streams or send any datagrams on a
given session before that session is established.  WebTransport over
HTTP/3 does not support 0-RTT.
From the client's perspective, a WebTransport session is established
when the client receives a 200 response.  From the server's
perspective, a session is established once it sends a 200 response.
WebTransport over HTTP/3 does not support 0-RTT.
In WebTransport over HTTP/3, the client MAY send its SETTINGS frame,
as well as multiple WebTransport CONNECT requests, WebTransport data
streams and WebTransport datagrams, all within a single flight.  As
those can arrive out of order, a WebTransport server could be put
into a situation where it receives a stream or a datagram without a
corresponding session.  Similarly, a client may receive a server-
initiated stream or a datagram before receiving the CONNECT response
headers from the server.
To handle this case, WebTransport endpoints SHOULD buffer streams and
datagrams until those can be associated with an established session.
To avoid resource exhaustion, the endpoints MUST limit the number of
buffered streams and datagrams.  When the number of buffered streams
is exceeded, a stream SHALL be closed by sending a RESET_STREAM and/
or STOP_SENDING with the "H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED"
error code.  When the number of buffered datagrams is exceeded, a
datagram SHALL be dropped.  It is up to an implementation to choose
what stream or datagram to discard.
WebTransport data stream rejected due to lack of associated
session.