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

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