Draft: draft-vvv-webtransport-quic

Commentary: We currently use 16 - bit integers for header names . There probably wo n't ever be more than 65,000 headers , but this does not let users add their own custom headers easily . Thus , this commit changes uint16 to string . We currently provide a way for a server to explicitly reject client 's origin , but no way to explicitly accept it . This commit solves this by turning the client indication stream into a bidirectional handshake stream . Server confirms the handshake by sending a FIN on its end of the handshake stream . 
 Reviewing , wrote : I do agree that this is annoying , but at the same time adding a field that 's redundant 90 % of the time feels ... weird ? We should think more seriously about how to make header size limits work at some point ( maybe using ALPS or something like that ) . 
 Closing this issue because the QuicTransport draft has been removed from this repository . 
 In WebTransport over QUIC , when an invalid Client Indication is received , the server treats the connection as an error ( ) . This is an error that occurred in a layer above the QUIC , so I think the connection should be closed with CONNECTION_CLOSE ( 0x1d ) indicating an error in the application using the QUIC . I think it is valuable to define an error code for WebTransport over QUIC . ( saids " the management of application error codes is left to application protocols . " ) and , by specifying the error code that the endpoint uses when it close the connection , the specification becomes clear . for example 
 I realized that using Error Code is related to the . Do not conflict with error codes used by applications above WebTransport . so , I createted . Please point it out if there are any mistakes in my opinion . thanks 
 I agree , CONNECTION_CLOSE should provide an error code indicating why the connection was refused . 
 I seem to remember seeing non - zero error codes from other endpoints when interoperating . If so , I have no clue what those codes were supposed to mean . I think it would be useful to have some defined in the next draft version . 
 I think the non - zero error codes probably were random HTTP/3 error codes , because those are the only codes that Google 's QUIC library supports ( that 's a known bug ) . I see three options for reporting handshake error : 1 ) An application CONNECTIONCLOSE , 2 ) A RESETSTREAM on the handshake stream , 3 ) An error status code on the handshake stream . If we go with 1 , we would have to reserve some of the application error code space . If we go with 2 or 3 , we would have to describe how the server has to keep the connection open for some time in order to allow for retransmission of the  / response error header . 
 Closing this issue because the QuicTransport draft has been removed from this repository .
When a client requests a QuicTransport session to be created, the
user agent establishes a QUIC connection to the specified address.
It verifies that the the server is a QuicTransport endpoint using
ALPN, and additionally sends a client indication containing the
requested path and the origin of the initiating website to the
server.  At that point, the connection is ready from the client's
perspective.  The server MUST wait until the client indication is
received before processing any application data.
When a client requests a QuicTransport session to be created, the
user agent establishes a QUIC connection to the specified address.
It verifies that the the server is a QuicTransport endpoint using
ALPN, and additionally sends a set of headers containing the
requested path and the origin of the initiating website to the
server.  At that point, the connection is ready from the client's
perspective.  The server MUST wait until it processes client headers
before processing any other application data.
In order to establish a QuicTransport session, a QUIC connection must
be established.  From the client perspective, the session becomes
established when the client both have received a TLS Finished message
from the server and has sent a client indication.  From the server
perspective, the session is established after the client indication
has been successfully processed.
In order to identify itself as a WebTransport application,
QuicTransport relies on TLS Application-Layer Protocol Negotiation
RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-01"
and it MUST close the connection unless the server confirms that ALPN
value.
In order to establish a QuicTransport session, a QUIC connection must
be established.  From the client perspective, the session becomes
established when the client both have received a TLS Finished message
from the server and has sent its headers.  From the server
perspective, the session is established after the client headers have
been successfully processed.
In order to identify itself as a WebTransport application,
QuicTransport relies on TLS Application-Layer Protocol Negotiation
RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-03"
and it MUST close the connection unless the server confirms that ALPN
value.
In order to verify that the client's origin is allowed to connect to
the server in question, the user agent has to communicate the origin
to the server.  This is accomplished by sending a special message,
called client indication, on stream 2, which is the first client-
initiated unidirectional stream.
Indicates the field that is being expressed.
Indicates the length of the value (the length of the key and the
length itself are not included).
The value of the field, the semantics of which are determined by
the key.
A FIN on the stream 2 SHALL indicate that the message is complete.
The client MUST send the entirety of the client indication and a FIN
immediately after opening the connection.  The server MUST NOT
process any application data before receiving the entirety of the
client indication.  The total length of the client indication MUST
NOT exceed 65,535 bytes.
In order to ensure that the user agent can send the client indication
immediately, the server MUST set "initial_max_streams_uni" transport
parameter to at least "1".  The user agent MUST close the connection
if the server sets "initial_max_streams_uni" to "0".
The client sends its headers on stream 0.
The client sends FIN on stream 0.  This indicates that all headers
have been sent, and the server can now process them.
The server processes the headers and makes access control decision
based on the origin.  Before this happens, the server MUST NOT
process any non-header application data receiver from the client,
or send its own header block.
The server sends its header block on stream 0, followed by a FIN
indicating that the handshake has been successfully completed.
Indicates the name of the field that is being expressed.  The name
of the field is case-insensitive, and when encoded on the wire, it
MUST consist of ASCII characters in range from "a" to "z", "0" to
"9", "-", or ".".  It MUST begin with an alphanumeric character.
The value of the header field, the semantics of which are
determined by the name.
A FIN on the stream 0 SHALL indicate that the message is complete.
The client MUST send the entirety of the header block and a FIN
immediately after opening the connection.  Before receiving the
entirety of the headers, the server MUST NOT process any datagrams or
any data on streams other than 0.  The total length of a header block
MUST NOT exceed 1,048,576 bytes; implementations MAY impose
additional limit on the header block size.
In order to ensure that the user agent can send the headers
immediately, the server MUST set "initial_max_streams_bidi" transport
parameter to at least "1".  The user agent MUST close the connection
if the server sets "initial_max_streams_bidi" to "0".
The server indicates that it accepts the origin by sending its header
block and a FIN on the stream 0.  If the server does not accept the
origin, it MUST close the connection.
Unlike HTTP, the "authority" portion of the URL is not communicated
in the client indication.  As QuicTransport has its own connection
dedicated to it, the host name portion can be retrieved from the
"server_name" TLS extension RFC6066.
Unlike HTTP, the "authority" portion of the URL is not communicated
in the headers.  As QuicTransport has its own connection dedicated to
it, the host name portion can be retrieved from the "server_name" TLS
extension RFC6066.
The "path-abempty" and the "query" portions of the URI are
communicated to the server in the client indication as described in
path-field.  The "quic-transport" URI scheme supports the "/.well-
known/" path prefix defined in RFC8615.
The "path-abempty" and the "query" portions of the URI are
communicated to the server in the headers as described in path-field.
The "quic-transport" URI scheme supports the "/.well-known/" path
prefix defined in RFC8615.
The 16-bit unique identifier that is used on the wire.
The IANA policy, as described in RFC8126, SHALL be Standards Action
for values between 0x0000 and 0x03ff; Specification Required for
values between 0x0400 and 0xefff; and Private Use for values between
0xf000 and 0xffff.
The IANA policy, as described in RFC8126, SHALL be Expert Review.