Change:
Remove SETTINGSENABLEWEBTRANSPORT in favor of SETTINGSWEBTRANSPORTMAX_SESSIONS.
I can't seem to remember or work out what the purpose of SETTINGSENABLEWEBTRANSPORT is now that we have SETTINGSWEBTRANSPORTMAXSESSIONS. This leads to the following questions: If the server sends SETTINGSWEBTRANSPORTMAXSESSIONS>0 but SETTINGSENABLEWEBTRANSPORT=0, what does that mean? If the client sends SETTINGSENABLEWEBTRANSPORT=0 but sends a WebTransport request, what is the purpose of having the server fail the request?
Yeah, I thought that we would remove SETTINGSENABLEWEBTRANSPORT when the session limit was added. If nothing else, it removes those awkward interactions.
Chair: discussed in editor's meeting, sounds like we should remove SETTINGSENABLEWEBTRANSPORT. We might add another setting to be removed by the RFC editor for versioning between drafts
IIRC, we discussed at IETF 115 and only the server needed to send MAX_SESSIONS, so we kept both. Can spell that either way though.
If we're doing this for H2, should we also do it for H3, since we have SETTINGSMAXWEBTRANSPORT_SESSIONS there, too?
h3 requires SETTINGSENABLEWEBTRANSPORT because it changes the format of server-initiated bidi streams h2 has no such requirement for a setting

Discussion:
Section 4.2.2 of HTTP. When an HTTP/2 connection is established, both the client and server <del> have to send a SETTINGS_ENABLE_WEBTRANSPORT setting to indicate that they both support WebTransport over HTTP/2. The server also needs to send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS setting with a value greater than "0" to indicate the number of concurrent sessions it is willing to receive. </del> <ins> have to send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS setting with a value greater than "0" to indicate that they both support WebTransport over HTTP/2.  For servers, the value of the setting is the number of concurrent sessions the server is willing to receive. Clients cannot receive incoming WebTransport sessions, so any value greater than "0" sent by a client simply indicates support for WebTransport over HTTP/2. </ins> A client initiates a WebTransport session by sending an extended CONNECT request RFC8441.  If the server accepts the request, a

3.1. In order to indicate support for WebTransport, both the client and <del> the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1" in their SETTINGS frame.  Endpoints MUST NOT use any WebTransport- related functionality unless the parameter has been negotiated. </del> <ins> the server MUST send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS value greater than "0" in their SETTINGS frame.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. </ins> 3.2. RFC8441 defines an extended CONNECT method in features, enabled by the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint needs to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and <del> SETTINGS_ENABLE_WEBTRANSPORT for WebTransport to be enabled. </del> <ins> SETTINGS_WEBTRANSPORT_MAX_SESSIONS for WebTransport to be enabled. </ins> 3.3.

10.1. <del> The following entries are added to the "HTTP/2 Settings" registry </del> <ins> The following entry is added to the "HTTP/2 Settings" registry </ins> established by RFC7540: <del> The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the specified HTTP/2 connection is WebTransport-capable. ENABLE_WEBTRANSPORT 0x2b603742 0 This document </del> The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the specified HTTP/2 connection is WebTransport-capable and the number of <del> concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </del> <ins> concurrent sessions an endpoint is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the endpoint is not willing to receive any WebTransport sessions. </ins> WEBTRANSPORT_MAX_SESSIONS