Change:
1. <del> This protocol satisfies the WebTransport protocol framework's requirements using HTTP semantics to provide support for </del> <ins> WebTransport OVERVIEW is designed to provide generic communication capabilities to Web clients that use HTTP/3 HTTP3.  The HTTP/3 WebTransport protocol WEBTRANSPORT-H3 allows Web clients to use QUIC QUIC features such as streams or datagrams DATAGRAM.  However, there are some environments where QUIC cannot be deployed. This document defines a protocol that provides all of the core functions of WebTransport using HTTP semantics.  This includes </ins> unidirectional streams, bidirectional streams, and datagrams. <del> By using HTTP semantics, this protocol allows deployment using any HTTP version, although this document in particular focuses on HTTP/2 as the current most common TCP-based fallback to HTTP/3 running over QUIC RFC9000. 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 respond to them; they can only accept them or discard them. 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 reliably deliver messages from servers to clients, limiting server to client use-cases such as chat messages or notifications. Several techniques have been developed to workaround these limitations: long polling RFC6202, WebSocket RFC8441, and tunneling using the CONNECT method.  All of these approaches have limitations. This document defines a mechanism for establishing bidirectional communication using HTTP semantics in a manner that conforms with the WebTransport protocol requirements and semantics OVERVIEW.  When running with HTTP/2, multiple WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/2 connection. It is important to note that, while it is possible to have the WebTransport session remain entirely "self contained" within a given HTTP flow, certain HTTP versions may provide native features, such as datagram support, which can allow for a better performing implementation of the WebTransport client's requirements. </del> <ins> By relying only on generic HTTP semantics, this protocol might allow deployment using any HTTP version.  However, this document only defines negotiation for HTTP/2 H2 as the current most common TCP- based fallback to HTTP/3. </ins> 1.1.

Discussion:
There is a long and proud legacy of drafts that carry introductions concentrating on the motivations for the last design change rather than the true reasons for the protocol. This is my attempt to bring things back on the level. I didn't stop there though. I think that we should make this about HTTP/2 because we don't currently have an extended CONNECT defined for HTTP/1.1. This walks back some of the "generic HTTP" language. More changes might be needed later in the document for that to be complete, but I wanted to keep this fix localized. I did cut stuff that I think the document should still contain. I just don't think that these need to be in the introduction. That is: you can multiplex multiple sessions other protocols might take stuff from this session and transmit them in different, better ways