Change:
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 NAME NAME NAME NAME
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

Discussion:
4.1. <ins> Any WebTransport protocol SHALL provide the following operations on the session: 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 "". Any WebTransport protocol SHALL provide the following events: 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. 4.2. </ins> A datagram is a sequence of bytes that is limited in size (generally to the path MTU) and is not expected to be transmitted reliably.  The general goal for WebTransport datagrams is to be similar in behavior

it can send.  The size SHOULD be derived from the result of performing path MTU discovery. <del> 4.2. </del> <ins> 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). Any WebTransport protocol SHALL provide the following operations on the session: 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. 4.3. </ins> A unidirectional stream is a one-way reliable in-order stream of bytes where the initiator is the only endpoint that can send data.  A

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 <del> more streams. </del> <ins> more streams.  From the perspective of the client, this is presented as a size-bounded queue of incoming streams. Any WebTransport protocol SHALL provide the following operations on the session: 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. Removes a stream from the queue of incoming unidirectional streams, if one is available. Removes a stream from the queue of incoming unidirectional streams, if one is available. Any WebTransport protocol SHALL provide the following operations on an individual stream: 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. Any WebTransport protocol SHALL provide the following events for an individual stream: 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. </ins> 5.