Original text:
6.  QuicTransport supports most of WebTransport features as described in properties. <del> 7. </del>  QuicTransport satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework opened.  The server MAY limit the amount of connections open by the same client. <del> 8. </del>  <del> 8.1. </del>  The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: This document <del> 8.2. </del>  IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff. <del> 9.  References </del>  <del> 9.1.  URIs </del>  [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin  4.3.  In order to create a new Http3Transport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field MUST be set to "webtransport".  The ":scheme" field MUST be "https".  Both logically independent of each other even if some transports can share same connection underneath. <del> A transport protocol (WebTransprot protocol in context where this </del>  might be ambiguos) is a protocol that can be used to back a transport on the wire.  It can provide the transport features described in this document, and is expected to fulfill all of the Any transport protocol used MUST provide a way for the server to filter the clients that can access it by the origin RFC6454.  3. WebTransport session establishment is in general asynchronous,

Reviewer comments:
This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.

Revised text:
6. <ins> NOTE: the URI scheme defintion in this section is provisional and subject to change, especially the name of the scheme. QuicTransport uses the "quic-transport" URI scheme for identifying QuicTransport servers. The syntax definition below uses Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of "host", "port", "path-abempty", "query" and "fragment" are adopted from RFC3986.  The syntax of a QuicTransport URI SHALL be: This document does not define any semantics to "path-abempty", "query" or "fragment" portions of the URI, nor does it delegate those to the host owners.  Any QuicTransport implementation MUST ignore those until a subsequent specification assigns semantics to those. The "host" component MUST NOT be empty.  If the "port" component is missing, the port SHALL be assumed to be 0. NOTE: this effectively requires the port number to be specified. This specification may include an actually usable default port number in the future. In order to connect to a QuicTransport server identified by a given URI, the user agent SHALL establish a QUIC connection to the specified "host" and "port" as described in connection.  It MUST immediately signal an error to the client if the port value is 0. 7. </ins> QuicTransport supports most of WebTransport features as described in properties.  <ins> 8. </ins> QuicTransport satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework opened.  The server MAY limit the amount of connections open by the same client.  <ins> 9. </ins>  <ins> 9.1. </ins> The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: This document  <ins> 9.2. </ins> IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff.  <ins> 9.3. </ins>  <ins> This document contains the request for the registration of the URI scheme "quic-transport".  The registration request is in accordance with RFC7595. quic-transport Permanent QuicTransport IETF Chair chair@ietf.org [2] IESG iesg@ietf.org [3] uri of this document. 10.  References 10.1.  URIs </ins> [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin <ins> [2] mailto:chair@ietf.org [3] mailto:iesg@ietf.org </ins> 4.3. <ins> As Http3Transport sessions are established over HTTP/3, they are identified using the "https" URI scheme RFC7230. </ins> In order to create a new Http3Transport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field MUST be set to "webtransport".  The ":scheme" field MUST be "https".  Both logically independent of each other even if some transports can share same connection underneath.  <ins> A transport protocol (WebTransport protocol in context where this </ins> might be ambiguos) is a protocol that can be used to back a transport on the wire.  It can provide the transport features described in this document, and is expected to fulfill all of the Any transport protocol used MUST provide a way for the server to filter the clients that can access it by the origin RFC6454. <ins> Any transport protocol used MUST provide a way for a server endpoint location to be described using a URI RFC3986.  They can be used for integration with various Web platform features that represent resources as URIs, such as Content Security Policy CSP. </ins> 3. WebTransport session establishment is in general asynchronous,