Original text:
4.1.  Because WebTransport over TCP-based HTTP semantics relies on the underlying protocols to provide in order and reliable delivery, there are some notable differences from the way in which QUIC handles <del> application data. Endpoints MUST send stream data in order.  As there is no ordering mechanism available for the receiver to reassemble incoming data, receivers assume that all data arriving in capsules is contiguous and in order. DATAGRAM capsules are delivered to the remote WebTransport endpoint reliably, however this does not require that the receiving implementation deliver that data to the application in a reliable manner. </del>  4.2. for flow control purposes and MUST generate and send appropriate flow control signals for their limits. <del> 6. </del>  WebTransport over HTTP/2 uses the DATAGRAM capsule defined in Section 3.5 of HTTP-DATAGRAM to carry datagram traffic. intermediaries follow the requirements in WEBTRANSPORT-H3 to use native QUIC datagrams. <del> 7. </del>  An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the The only difference here is the endpoint that sends the first capsule. <del> 8. </del>  An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 9. The WebTransport capsulework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols. Below are details about support in Http2Transport for those properties. Http2Transport does not support stream independence, as HTTP/2 inherently has head of line blocking. Http2Transport does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via Http2Transport will be retransmitted regardless of the preference of the application.  The receiver is permitted to drop them, however, if it is unable to buffer them. Http2Transport supports pooling, as multiple transports using Http2Transport may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context. Http2Transport does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS. Without such support, Http2Transport connections cannot survive network transitions. 10. </del>  WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 11. </del>  <del> 11.1. </del>  The following entries are added to the "HTTP/2 Settings" registry established by RFC7540: This document <del> 11.2. </del>  The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: None <del> 12.  References </del>  <del> 12.1.  URIs </del>  [1] mailto:webtransport@ietf.org

Reviewer comments:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.

Revised text:
4.1. <ins> The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols. </ins> Because WebTransport over TCP-based HTTP semantics relies on the underlying protocols to provide in order and reliable delivery, there are some notable differences from the way in which QUIC handles  <ins> application data.  For example, endpoints send stream data in order. As there is no ordering mechanism available for the receiver to reassemble incoming data, receivers assume that all data arriving in capsules is contiguous and in order. Below are details about support in WebTransport over HTTP/2 for the properties defined by the WebTransport framework. WebTransport over HTTP/2 does not support stream independence, as HTTP/2 inherently has head-of-line blocking. WebTransport over HTTP/2 does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via WebTransport over HTTP/2 will be retransmitted regardless of the preference of the application.  The receiver is permitted to drop them, however, if it is unable to buffer them. WebTransport over HTTP/2 supports pooling, as multiple transports using WebTransport over HTTP/2 may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context.  Note that WebTransport streams over HTTP/2 are contained within a single HTTP/2 stream and do not compete with other pooled WebTransport sessions for per-stream resources. WebTransport over HTTP/2 does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS. Without such support, WebTransport over HTTP/2 connections cannot survive network transitions. </ins> 4.2. for flow control purposes and MUST generate and send appropriate flow control signals for their limits.  <ins> 5.11. </ins> WebTransport over HTTP/2 uses the DATAGRAM capsule defined in Section 3.5 of HTTP-DATAGRAM to carry datagram traffic. intermediaries follow the requirements in WEBTRANSPORT-H3 to use native QUIC datagrams.  <ins> 6. </ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the The only difference here is the endpoint that sends the first capsule.  <ins> 7. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session.  <ins> 8. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  <ins> 9. </ins>  <ins> 9.1. </ins> The following entries are added to the "HTTP/2 Settings" registry established by RFC7540: This document  <ins> 9.2. </ins> The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: None  <ins> 10.  References </ins>  <ins> 10.1.  URIs </ins> [1] mailto:webtransport@ietf.org