Change:
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> <ins> The "wq-vvv-03" label identifies QUIC used as a protocol for </ins> WebTransport: QuicTransport <del> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31 ("wq-vvv-01") </del> <ins> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x33 ("wq-vvv-03") </ins> 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> <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. <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> <ins> The IANA policy, as described in RFC8126, SHALL be Expert Review. </ins> 9.3.

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