Draft: draft-ietf-webtrans-overview

Commentary: Currently , in the W3C API draft , we cite the HTTP/3 draft and RFC 9000 directly . This does not work with WebTransport over HTTP/2 , hence we need for the overview draft to provide a common set of operations that both H3 and H2 versions of the draft are expected to implement . 
 cc 
 How does this square with the set of features that we list in the overview draft -- right now it looks like we 'll just have two lists . Do we want to do anything to relate them / break things down as being part of each feature ? ( Not saying that 's strictly necessary , just curious if we 'd thought about it ) 
 Chair : discussed at 113 , request for folks to review this PR 
 Thanks everyone for the comments ! I 've revised the PR ; please take another look . By features , you mean the requirements in the section above that ? Those are somewhat different in nature , I feel . The features are the list of things that I should be able to do with a WebTransport , whereas the requirements are on how it is supposed to work ( e.g. you must use TLS , etc ) . 
 ( no hats ) overall this LGTM , my comments are minor
Create a new WebTransport session given a URI RFC3986 and the
origin RFC6454 of the requester.
Terminate the session while communicating to the peer an unsigned
32-bit error code and an error reason string of at most 1024
bytes.  The error code and string are optional; the default values
are 0 and "".
Indicates that the WebTransport session has been terminated,
either by the peer or by the local networking stack, and no user
data can be exchanged on it any further.  If the session has been
terminated as a result of the peer performing the "terminate a
session" operation above, a corresponding error code and an error
string can be provided.
In the WebTransport model, all of the outgoing and incoming datagrams
are placed into a size-bound queue (similar to a network interface
card queue).
Enqueues a datagram to be sent to the peer.  This can potentially
result in the datagram being dropped if the queue is full.
Dequeues an incoming datagram, if one is available.
Returns the largest size of the datagram that a WebTransport
session is expected to be able to send.
Data sent on a stream is flow controlled by the transport protocol.
In addition to flow controlling stream data, the creation of new
streams is flow controlled as well: an endpoint may only open a
limited number of streams until the peer explicitly allows creating
more streams.
Data sent on a stream is flow controlled by the transport protocol.
In addition to flow controlling stream data, the creation of new
streams is flow controlled as well: an endpoint may only open a
limited number of streams until the peer explicitly allows creating
more streams.  From the perspective of the client, this is presented
as a size-bounded queue of incoming streams.
Creates an outgoing unidirectional stream; this operation may
block until the flow control of the underlying protocol allows for
it to be completed.
Creates an outgoing bidirectional stream; this operation may block
until the flow control of the underlying protocol allows for it to
be completed.
Add bytes into the stream send buffer.  The sender can also
indicate a FIN, signalling the fact that no new data will be send
on the stream.  Not applicable for incoming unidirectional
streams.
Removes bytes from the stream receive buffer.  FIN can be received
together with the stream data.  Not applicable for outgoing
unidirectional streams.
Sends a signal to the peer that the write side of the stream has
been aborted.  Discards the send buffer; if possible, no currently
outstanding data is transmitted or retransmitted.  An unsigned
8-bit error code can be supplied as a part of the signal to the
peer; if omitted, the error code is presumed to be 0.
Sends a signal to the peer that the read side of the stream has
been aborted.  Discards the receive buffer; the peer is typically
expected to abort the corresponding send side in response.  An
unsigned 8-bit error code can be supplied as a part of the signal
to the peer.
Indicates that the peer has aborted the corresponding receive side
of the stream.  An unsigned 8-bit error code from the peer may be
available.
Indicates that the peer has aborted the corresponding send side of
the stream.  An unsigned 8-bit error code from the peer may be
available.
Indicates that no further data will be transmitted or
retransmitted on the local send side, and that the FIN has been
sent.  Data Recvd implies that aborting send-side is a no-op.