Original text:
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 <del> ALPN, and additionally sends a client indication containing the </del>  requested path and the origin of the initiating website to the server.  At that point, the connection is ready from the client's <del> perspective.  The server MUST wait until the client indication is received before processing any application data. </del>  WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams 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 <del> 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. </del>  3.1. In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation <del> RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-01" </del>  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 <del> 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. </del>  <del> The client indication is a sequence of key-value pairs that are formatted in the following way: </del>  <del> The pair includes the following fields: </del>  <del> Indicates the field that is being expressed. </del>  <del> Indicates the length of the value (the length of the key and the length itself are not included). </del>  <del> The value of the field, the semantics of which are determined by the key. </del>  <del> 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. </del>  <del> In order to ensure that the user agent can send the client indication immediately, the server MUST set "initial_max_streams_uni" transport </del>  parameter to at least "1".  The user agent MUST close the connection <del> if the server sets "initial_max_streams_uni" to "0". </del>  The server MUST ignore any field it does not recognize.  All of the fields MUST be unique; the server MAY close the connection if any of 3.2.1. In order to allow the server to enforce its origin policy, the user <del> agent has to communicate the origin in the client indication.  This can be accomplished using the "Origin" field: </del>  Origin <del> 0x0000 </del> The origin RFC6454 of the client initiating the connection. The user agent MUST send the "Origin" field.  The "Origin" field MUST serialized as described in the "serializing a request origin" section of FETCH.  3.2.2. In order to allow multiplexing multiple application on the same host- port tuple, QuicTransport allows specifying extra routing information in the path component of the URI.  That component is communicated <del> using the "Path" field in the client indication: </del>  Path <del> 0x0001 </del> The path component of the QuicTransport URI. The user agent MUST send a non-empty "Path" field.  When the abempty" is empty, the value sent SHALL be "/". Unlike HTTP, the "authority" portion of the URL is not communicated <del> 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. </del>  The server MAY use the value of the "Path" field in any way defined by the target application. QuicTransport URI SHALL be: The "path-abempty" and the "query" portions of the URI are <del> 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. </del>  This document does not assign any semantics to the "fragment" portion of the URI.  Any QuicTransport implementation MUST ignore those until The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: <del> The "wq-vvv-01" label identifies QUIC used as a protocol for </del>  WebTransport: QuicTransport <del> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31 ("wq-vvv-01") </del>  This document 9.2. <del> IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the following fields: </del>  The name of the field. <del> The 16-bit unique identifier that is used on the wire. </del> A brief description of what the parameter does. The document that describes the parameter. <del> 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. </del>  9.3.

Reviewer comments:
We currently use 16-bit integers for header names. There probably won'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 , NAME 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 URL . 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 RESET_STREAM/response error header.
Closing this issue because the QuicTransport draft has been removed from this repository.

Revised text:
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  <ins> ALPN, and additionally sends a set of headers containing the </ins> requested path and the origin of the initiating website to the server.  At that point, the connection is ready from the client's  <ins> perspective.  The server MUST wait until it processes client headers before processing any other application data. </ins> WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams 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  <ins> from the server and has sent its headers.  From the server perspective, the session is established after the client headers have been successfully processed. </ins> 3.1. In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation  <ins> RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-03" </ins> 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  <ins> to the server.  This is accomplished by performing a handshake on the first client-initiated bidirectional stream, stream 0.  The handshake is performed as follows: </ins>  <ins> The client sends its headers on stream 0. </ins>  <ins> 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. </ins>  <ins> The QuicTransport header stream payload SHALL be a header block.  A header block is a sequence of key-value pairs that are formatted in the following way: The pair includes the following fields: </ins>  <ins> 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. </ins>  <ins> The value of the header field, the semantics of which are determined by the name. </ins>  <ins> 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. </ins>  <ins> In order to ensure that the user agent can send the headers immediately, the server MUST set "initial_max_streams_bidi" transport </ins> parameter to at least "1".  The user agent MUST close the connection  <ins> if the server sets "initial_max_streams_bidi" to "0". </ins> The server MUST ignore any field it does not recognize.  All of the fields MUST be unique; the server MAY close the connection if any of 3.2.1. In order to allow the server to enforce its origin policy, the user  <ins> agent has to communicate the origin in the handshake.  This can be accomplished using the "Origin" field: </ins> Origin  The origin RFC6454 of the client initiating the connection. The user agent MUST send the "Origin" field.  The "Origin" field MUST serialized as described in the "serializing a request origin" section of FETCH. <ins> 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. </ins> 3.2.2. In order to allow multiplexing multiple application on the same host- port tuple, QuicTransport allows specifying extra routing information in the path component of the URI.  That component is communicated  <ins> using the "Path" header: </ins> Path  The path component of the QuicTransport URI. The user agent MUST send a non-empty "Path" field.  When the abempty" is empty, the value sent SHALL be "/". Unlike HTTP, the "authority" portion of the URL is not communicated  <ins> 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. </ins> The server MAY use the value of the "Path" field in any way defined by the target application. QuicTransport URI SHALL be: The "path-abempty" and the "query" portions of the URI are  <ins> 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. </ins> This document does not assign any semantics to the "fragment" portion of the URI.  Any QuicTransport implementation MUST ignore those until The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301:  <ins> The "wq-vvv-03" label identifies QUIC used as a protocol for </ins> WebTransport: QuicTransport  <ins> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x33 ("wq-vvv-03") </ins> This document 9.2.  <ins> IANA SHALL add a registry for "QuicTransport Header Fields" registry. Every entry in the registry SHALL include the following fields: </ins> The name of the field.  A brief description of what the parameter does. The document that describes the parameter.  <ins> The IANA policy, as described in RFC8126, SHALL be Expert Review. </ins> 9.3.