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

Discussion:
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