Change:
Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility

Discussion:
5. <ins> The WebTransport framework I-D.vvv-webtransport-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. 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 RFC7540, is used underneath HTTP/2 and TLS.  Without such support, Http2Transport connections cannot survive network transitions. 6. </ins> WebTransport Streams established by the CONNECT handshake and the WTHEADERS frame are expected to be protected with a TLS connection. They inherit the security properties of this cryptographic context,

share of controlled resources, both when sending data and opening new streams. <del> 6. </del> <ins> 7. </ins> 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 defined in RFC7540.  It also registers an HTTP upgrade token in the registry established by RFC7230. <del> 6.1. </del> <ins> 7.1. </ins> The following entry is added to the "HTTP/2 Frame Type" registry established by Section 11.2 of RFC7540.

_RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.2. </del> <ins> 7.2. </ins> The following entry is added to the "HTTP/2 Settings" registry that was established by Section 11.3 of RFC7540.

_RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.3. </del> <ins> 7.3. </ins> The following entries are added to the "HTTP/2 Error Code" registry that was established by Section 11.2 of RFC7540.

_RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.4. </del> <ins> 7.4. </ins> The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230.

_RFC Editor: Please fill in this value with the RFC number for this document_ and <del> 7.  References </del> <ins> 8.  References </ins> <del> 7.1.  URIs </del> <ins> 8.1.  URIs </ins> [1] https://www.iana.org/assignments/http-upgrade-tokens/