Original text:
6.  WebTransport over HTTP/3 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 7. </del>  <del> 7.1. </del>  The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230: This document and <del> 7.2. </del>  The following entry is added to the "HTTP/3 Settings" registry established by HTTP3: This document <del> 7.3. </del>  The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3: This document <del> 7.4. </del>  The following entry is added to the "HTTP/3 Stream Type" registry established by HTTP3: Both <del> 7.5. </del>  The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3: This document. <del> 7.6. </del>  This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM.

Reviewer comments:
This change both describes the existing mechanism (SETTINGS). It also adds a header in the unlikely scenario that we would need to change capsule stream format (instead of just defining new capsules).

Revised text:
6. <ins> [[RFC editor: please remove this section before publication.]] WebTransport over HTTP/3 uses two different mechanisms to negotiate versions for the different parts of the draft. The hop-by-hop wire format aspects of the protocol are negotiated by changing the codepoint used for the SETTINGS_ENABLE_WEBTRANSPORT parameter.  Because of that, any WebTransport endpoint MUST wait for the peer's SETTINGS frame before sending or processing any WebTransport traffic.  When multiple versions are supported by both of the peers, the most recent version supported by both is selected. The data exchanged over the CONNECT stream is transmitted across intermediaries, and thus cannot be versioned using a SETTINGS parameter.  To indicate support for different versions of the protocol defined in this draft, the clients SHALL send a header for each version of the draft supported.  The header corresponding to the version described in this draft is "Sec-Webtransport-Http3-Draft02"; its value SHALL be "1".  The server SHALL reply with a "Sec- Webtransport-Http3-Draft" header indicating the selected version; its value SHALL be "draft02" for the version described in this draft. 7. </ins> WebTransport over HTTP/3 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  <ins> 8. </ins>  <ins> 8.1. </ins> The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230: This document and  <ins> 8.2. </ins> The following entry is added to the "HTTP/3 Settings" registry established by HTTP3: This document  <ins> 8.3. </ins> The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3: This document  <ins> 8.4. </ins> The following entry is added to the "HTTP/3 Stream Type" registry established by HTTP3: Both  <ins> 8.5. </ins> The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3: This document.  <ins> 8.6. </ins> This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM.