Change:
NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!

Discussion:
Both client and server can create a unidirectional stream using a special stream type. <del> A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM. </del> <ins> A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM. </ins> An WebTransport session is terminated when the CONNECT stream that created it is closed.

in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter value SHALL be either "0" or "1", with "0" being the default; an endpoint that receives a value other than "0" or "1" MUST close the <del> connection with the H3_SETTINGS_ERROR error code.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating QUIC DATAGRAM extension SHALL result in a H3_SETTINGS_ERROR error. HTTP3 requires client's "initial_max_bidi_streams" transport parameter to be set to zero.  Existing implementation might enforce this requirement before negotiating settings; thus, the client MUST send a non-zero MAX_STREAMS for client-initiated bidirectional streams after receiving an appropriate SETTINGS frame from the server. </del> <ins> connection with the H3_SETTINGS_ERROR error code. The client MUST NOT send a WebTransport request until it has received the setting indicating WebTransport support from the server. Similarly, the server MUST NOT process any incoming WebTransport requests until the client settings have been received, as the client may be using a version of WebTransport extension that is different from the one used by the server. </ins> 3.2.

WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by <del> replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del> <ins> replying with a 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </ins> From the client's perspective, a WebTransport session is established <del> when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. </del> <ins> when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. </ins> WebTransport over HTTP/3 does not support 0-RTT. <ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM. </ins> 3.4. From the flow control perspective, WebTransport sessions count

encoded using the QUIC variable length integer scheme described in RFC9000. <ins> If at any point a session ID is received that cannot a valid ID for a client-initiated bidirectional stream, the recepient MUST close the connection with an H3_ID_ERROR error code. </ins> 4.1. Once established, both endpoints can open unidirectional streams.

4.3. <del> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow Identifier is set to the session ID.  In other words, the format of datagrams SHALL be the session ID, followed by the user-specified payload (fig-datagram). </del> <ins> A WebTransport endpoint may send a RESET_STREAM or a STOP_SENDING frame for a WebTransport data stream.  Those signals are propagated by the WebTransport implementation to the application. A WebTransport application SHALL provide an error code for those operations.  Since WebTransport shares the error code space with HTTP/3, WebTransport application errors for streams are limited to an unsigned 8-bit integer, assuming values between 0x00 and 0xff. WebTransport implementations SHALL remap those error codes into an error range where 0x00 corresponds to 0x52e4a40fa8db, and 0xff corresponds to 0x52e4a40fa9e2.  Note that there are code points inside that range of form "0x1f * N + 0x21" that are reserved by Section 8.1 of HTTP3; those have to be accounted for when mapping the error codes by skipping them (i.e. the two HTTP/3 error codepoints adjacent to a GREASE codepoint would map to two adjacent WebTransport application error codepoints).  An example pseudocode can be seen in fig-remap-errors. WebTransport data streams are associated with sessions through a header at the beginning of the stream; resetting a stream may result in that data being discarded.  Because of that, WebTransport application error codes are best effort, as the WebTransport stack is not always capable of associating the reset code with a session.  The only exception is the situation where there is only one session on a given HTTP/3 connection, and no intermediaries between the client and the server. WebTransport implementations SHALL forward the error code for a stream associated with a known session to the application that owns that session; similarly, the intermediaries SHALL reset the streams with corresponding error code when receiving a reset from the peer. If a WebTransport implementation intentionally allows only one session over a given HTTP/3 connection, it SHALL forward the error codes within WebTransport application error code range to the application that owns the only session on that connection. 4.4. Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT HTTP Datagram Format Type (see value in iana-format-type).  When using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport datagram payload is sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.  When sending a registration capsule using the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format Additional Data" field SHALL be empty. </ins> In QUIC, a datagram frame can span at most one packet.  Because of that, the applications have to know the maximum size of the datagram

MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.4. </del> <ins> 4.5. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data

5. <del> An WebTransport session over HTTP/3 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. </del> <ins> A WebTransport session over HTTP/3 is considered terminated when either of the following conditions is met: the CONNECT stream is closed, either cleanly or abruptly, on either side; or a CLOSE_WEBTRANSPORT_SESSION capsule is either sent or received. Upon learning that the session has been terminated, the endpoint MUST reset all of the streams associated with the session; it MUST NOT send any new datagrams or open any new streams. To terminate a session with a detailed error message, an application MAY send an HTTP capsule HTTP-DATAGRAM of type CLOSE_WEBTRANSPORT_SESSION (0x2843).  The format of the capsule SHALL be as follows: CLOSE_WEBTRANSPORT_SESSION has the following fields: A 32-bit error code provided by the application closing the connection. A UTF-8 encoded error message string provided by the application closing the connection.  The message takes up the remainer of the capsule, and its length MUST NOT exceed 1024 bytes. A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the sender side.  If any additional stream data is received on the CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be reset with code H3_MESSAGE_ERROR.  The recipient MUST close the stream upon receiving a FIN.  If the sender of CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it SHOULD send STOP_SENDING on the CONNECT stream. Cleanly terminating a CONNECT stream without a CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has an error code of 0 and an empty error string. </ins> 6.

session. This document. <ins> In addition, the following range of entries is registered: H3_WEBTRANSPORT_APPLICATION_00 ... H3_WEBTRANSPORT_APPLICATION_FF 0x52e4a40fa8db to 0x52e4a40fa9e2 inclusive, with the exception of 0x52e4a40fa8f9, 0x52e4a40fa918, 0x52e4a40fa937, 0x52e4a40fa956, 0x52e4a40fa975, 0x52e4a40fa994, 0x52e4a40fa9b3, and 0x52e4a40fa9d2. WebTransport application error codes. This document. 7.6. This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM. </ins>