Draft: draft-ietf-webtrans-http3

Commentary: 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 
 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 !
A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM.
A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM.
In order to indicate support for WebTransport, both the client and
the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1"
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
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.
Upon receiving an extended CONNECT request with a ":protocol" field
set to "webtransport", the HTTP/3 server can check if it has a
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
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.
The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as
defined in HTTP-DATAGRAM.
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.
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.
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.
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.
0x52e4a40fa8db to 0x52e4a40fa9e2 inclusive, with the exception of
0x52e4a40fa8f9, 0x52e4a40fa918, 0x52e4a40fa937, 0x52e4a40fa956,
0x52e4a40fa975, 0x52e4a40fa994, 0x52e4a40fa9b3, and
0x52e4a40fa9d2.
WebTransport application error codes.