Draft: draft-ietf-webtrans-http2

Commentary: Remove SETTINGSENABLEWEBTRANSPORT in favor of SETTINGSWEBTRANSPORTMAX_SESSIONS . 
 I ca n'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 SETTINGSWEBTRANSPORTMAXSESSIONS0 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 . 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 MAXSESSIONS , 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
When an HTTP/2 connection is established, both the client and server
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.
When an HTTP/2 connection is established, both the client and server
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.
In order to indicate support for WebTransport, both the client and
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.
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
SETTINGS_ENABLE_WEBTRANSPORT for WebTransport to be enabled.
In order to indicate support for WebTransport, both the client and
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.
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
SETTINGS_WEBTRANSPORT_MAX_SESSIONS for WebTransport to be enabled.
The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the
specified HTTP/2 connection is WebTransport-capable.
The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the
specified HTTP/2 connection is WebTransport-capable and the number of
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.
The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the
specified HTTP/2 connection is WebTransport-capable and the number of
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.