Change:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME

Discussion:
1. HTTP/2 RFC7540 transports HTTP messages via a framing layer that <del> includes many technologies and optimizations designed to make communication more efficient between clients and servers.  These include multiplexing of multiple streams on a single underlying transport connection, flow control, stream dependencies and priorities, header compression, and exchange of configuration information between endpoints. </del> <ins> includes many optimizations designed to make communication more efficient between clients and servers.  These include multiplexing of multiple streams on a single underlying transport connection, flow control, priorities, header compression, and exchange of configuration information between endpoints. </ins> Currently, the only mechanism in HTTP/2 for server to client communication is server push.  That is, servers can initiate unidirectional push promised streams to clients, but clients cannot <del> respond to them and either accept or discard them silently. </del> <ins> respond to them; they can only accept them or discard them. </ins> Additionally, intermediaries along the path may have different server push policies and may not forward push promised streams to the downstream client.  This best effort mechanism is not sufficient to <del> reliably deliver content from servers to clients, limiting additional use-cases such as sending messages and notifications from servers to clients immediately when they become available. </del> <ins> reliably deliver messages from servers to clients, limiting server to client use-cases such as chat messages or notifications. </ins> Several techniques have been developed to workaround these limitations: long polling RFC6202, WebSocket RFC8441, and tunneling using the CONNECT method.  All of these approaches layer an application protocol on top of HTTP/2, using HTTP/2 streams as transport connections.  This layering defeats the optimizations <del> provided by HTTP/2.  For example, multiplexing multiple parallel interactions onto one HTTP/2 stream reintroduces head of line blocking.  Also, application metadata is encapsulated into DATA frames, rather than HEADERS frames, making header compression impossible.  Further, user data is framed multiple times at different protocol layers, which offsets the wire efficiency of HTTP/2 binary framing. </del> <ins> provided by HTTP/2.  For example, application metadata is encapsulated in DATA frames rather than HEADERS frames, bypassing the advantages of HPACK header compression.  Further, application data might be framed multiple times at different protocol layers, reducing the wire efficiency of the protocol. </ins> This document defines Http2Transport, a mechanism for multiplexing <del> non-HTTP data with HTTP/2 in a manner that conforms with the WebTransport protocol framework I-D.vvv-webtransport-overview.  Using the mechanism described, multiple Http2Transport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/2 connection. </del> <ins> non-request/response streams with HTTP/2 in a manner that conforms with the WebTransport protocol framework I-D.vvv-webtransport- overview.  Using the mechanism described, multiple Http2Transport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/2 connection. </ins> Section 8.3 of RFC7540 defines the HTTP CONNECT method for HTTP/2, <del> which converts a HTTP/2 stream into a tunnel for arbitrary data. </del> <ins> which converts an HTTP/2 stream into a tunnel for arbitrary data. </ins> RFC8441 describes the use of the extended CONNECT method to negotiate the use of the WebSocket Protocol RFC6455 on an HTTP/2 stream. Http2Transport uses the extended CONNECT handshake to allow <del> WebTransport endpoints to multiplex arbitrary data on HTTP/2 streams. </del> <ins> WebTransport endpoints to multiplex arbitrary data streams on HTTP/2 connections. </ins> <del> In this draft, a new HTTP/2 frame is introduced which has the routing properties of a PUSH_PROMISE frame and the bi-directionality of a HEADERS frame.  The extension provides several benefits: </del> <ins> In this draft, a new HTTP/2 frame is introduced which carries structured metadata like the HEADERS and PUSH_PROMISE frames, but without the constraints of the request/response state machine and semantics. </ins> <del> After a HTTP/2 connection is established, a server can initiate streams to the client at any time, and the client can respond to the incoming streams accordingly.  That is, the communication over HTTP/2 is bidirectional and symmetric. </del> <ins> The WebTransport over HTTP/2 extension: </ins> <del> All of the HTTP/2 technologies and optimizations still apply. Intermediaries also have all the necessary metadata to properly handle the communication between the client and the server. </del> <ins> Enables bidirectional and symmetric communication over HTTP/2. After a WebTransport session is established, a server can initiate a WebTransport stream to the client at any time, and the client can respond to server-initiated streams. </ins> <del> Clients are able to group streams together for routing purposes, such that each individual stream group can be used for a different service, within the same HTTP/2 connection. </del> <ins> Allows WebTransport streams to take advantage of HTTP/2 features such as header compression, prioritization and flow-control. Provides a mechanism for intermediaries to route server initiated messages to the correct client. Allows clients and servers to group streams and route them together. </ins> 2.

3. <ins> 3.1. After negotiating the use of this extension, clients initiate one or more WebTransport Connect streams to a Http2Transport Server. </ins> Http2Transport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3 <del> respectively).  Http2Transport uses the extended CONNECT handshake to negotiate a new upgrade token, "webtransport".  It also defines an HTTP/2 extension that introduces a new frame, "WTHEADERS", which allows for bidirectional communication between the WebTransport server and the client, and it introduces a new HTTP/2 SETTINGS parameter to negotiate the use of the "WTHEADERS" frame. </del> <ins> respectively).  The client uses the extended CONNECT method with a :protocol token "webtransport" to establish a WebTransport Connect Stream.  This stream is only used to establish a WebTransport session and is not intended for data exchange. </ins> <del> 3.1. </del> <ins> 3.2. Following the establishment of a WebTransport Connect stream, either the client or the server can initiate a WebTransport Stream by sending the "WTHEADERS" frame.  This frame references an open WebTransport Connect stream, which is used by any intermediaries to correctly forward the stream to the destination endpoint.  The only frames allowed on WebTransport Streams are WTHEADERS, CONTINUATION, DATA and any negotiated extension frames. 3.3. Clients negotiate the use of WebTransport ove HTTP/2 using both the SETTINGS frame and one or more extended CONNECT requests as defined in RFC8441. </ins> <del> Use of the extended CONNECT method extension defined in RFC8441 requires the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client prior to its use.  An endpoint that supports receiving the extended CONNECT method SHOULD send this setting with a value of 1. </del> <ins> Use of the extended CONNECT method extension requires the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client prior to its use.  An endpoint that supports receiving the extended CONNECT method SHOULD send this setting with a value of 1. </ins> The extended CONNECT method extension uses the ":protocol" psuedo- header field to negotiate the protocol that will be used on a given

This token is used in the ":protocol" psuedo-header field to indicate that the endpoint wishes to use the WebTransport protocol on the new <del> stream.  If successful, the resulting stream established via the extended CONNECT handshake is referred to as a WebTransport Connect Stream, or simply a Connect Stream. </del> <ins> stream. </ins> <del> 3.2. </del> <ins> 3.4. </ins> <del> A new HTTP/2 frame called "WTHEADERS" is introduced for establishing streams in a bidirectional manner.  A stream opened by a "WTHEADERS" frame is referred to as a WebTransport Stream, and it MAY be continued by CONTINUATION and DATA frames.  WebTransport Streams can be initiated by either clients or servers via a "WTHEADERS" frame that refers to the corresponding client-initiated extended CONNECT stream on which the WebTransport protocol was negotiated. </del> <ins> Clients or servers use a WTHEADERS frame to initate a new WebTransport Stream. </ins> The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2.

closed (remote) stream state.  This allows WebTransport Streams to participate in header compression and flow control. <del> 3.3. </del> <ins> 3.5. </ins> As described in Section 5.5 of RFC7540, SETTINGS parameters allow endpoints to negotiate use of protocol extensions that would

An endpoint that supports receiving the "WTHEADERS" as part of the WebTransport protocol SHOULD send this setting with a value of 1. <del> 3.4. </del> <ins> 3.6. </ins> An endpoint that wishes to establish a WebTransport session over an HTTP/2 stream follows the extended CONNECT handshake procedure

HTTP/2 stream is considered to be that of the WebTransport protocol and follows the semantics defined by that protocol. <del> 3.5. </del> <ins> 3.7. </ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the

Section 10, and Section 10.5.2 especially, apply to this use of the CONNECT method. <del> Http2Transport requires explicit opt-in through the use of a HTTP/2 </del> <ins> Http2Transport requires explicit opt-in through the use of an HTTP/2 </ins> SETTINGS parameter, avoiding potential protocol confusion attacks by ensuring the HTTP/2 server explicitly supports the WebTransport protocol.  It also requires the use of the Origin header, providing

This document adds an entry to the "HTTP/2 Frame Type" registry, the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all <del> defined in RFC7540.  It also registers a HTTP upgrade token in the </del> <ins> defined in RFC7540.  It also registers an HTTP upgrade token in the </ins> registry established by RFC7230. 6.1.