Change:
7. <ins> WebTransport over HTTP/2 uses the "WebTransport-Init" HTTP header field to communicate the initial values of the flow control windows, similar to how QUIC uses transport parameters.  The "WebTransport- Init" is a Dictionary Structured Field (Section 3.2 of RFC8941).  If any of the fields cannot be parsed correctly or do not have the correct type, the peer MUST reset the CONNECT stream.  The following keys are defined for the "WebTransport-Init" header field: The initial flow control limit for unidirectional streams opened by the recipient of this header field.  MUST be an Integer. The initial flow control limit for the bidirectional streams opened by the sender of this header field.  MUST be an Integer. The initial flow control limit for the bidirectional streams opened by the recipient of this header field.  MUST be an Integer. 8. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 8. </del> <ins> 9. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a

Discussion:
Chair: discussed during editors' call, plan is to go with Martin's simpler proposed encoding. We might want to discuss non-zero defaults later, but that'll be its own separate issue.
The document currently does not specify what the initial flow control windows are, nor how to change those. We have two options: Add WT_SETTINGS capsule Put those into headers
Discussed in editor's meeting, initial thinking is to put these values into the headers on the CONNECT message, rather than defining a new capsule or otherwise polluting HTTP/2's settings
Is there any reason that you want to avoid settings? The main thing that using settings would do is to provide the client with non-zero initial flow control limits on WT streams, so that it can send application data with zero latency. You can't get that without using settings. Functionally speaking, there is no real difference between a new capsule and a field, except that you can be a little more efficient with a capsule, modulo some issues regarding sequencing (do you allow it to appear anywhere? how do you manage changing values? etc...)
If we're talking about H2-connection level settings, then those are scoped to the entire connection. Using those would bring us closer to how H3 behaves (where connection-level stream configuration applies to WebTransport stream due to WT streams also being QUIC streams). On the other hand, we have designed WebTransport over HTTP/2 so that everything that happens within the CONNECT stream, so using headers/capsule instead of settings would be consistent with that. It would also mean you can transparently proxy WT-H2 to WT-H2 without parsing it (I do realize we currently say that you're not supposed to do that). Agreed. I have a mild preference for header fields since those are guaranteed to always arrive before any payload, making reasoning about their properties slightly easier.
The problem, as I see it, is that fields or capsules both lead to a situation where the client is unable to send any application data in its first flight (that is, along with the CONNECT-wossname request). What I want to avoid is the case where clients decide to improve performance by remembering initial values. I'm very much inclined to implement that caching, if only because it means that we can start using a session more quickly (for anything other than 0-RTT).

Perhaps the right answer is that we need some sort of way to encapsulate origin-wide per-resource configuration (that is, a baseline configuration that applies to all resources on the origin) and - until then - we stick with populating each resource with fields.
Chair: discussed during editors' call, see URL
Any reason why you did not do a single header field, like: Then at least the common repetitive stuff isn't repeated.