Clarify long term plans for clients to signal support for WebTransport

[ekinnear]

Long term, once this has shipped as RFC and all browsers have dropped support for pre-RFC drafts, is the plan to have clients send SETTINGS_WEBTRANSPORT_MAX_SESSIONS forever or to stop sending it? If the goal is to only do this during the draft period, we should have "to be removed by RFC editor" notes explaining that

Originally posted by @DavidSchinazi in https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/129#issuecomment-1585130081

[ekinnear]

Why not use upgrade tokens and update extended connect to support negotiation? Changing semantics of HTTP so that the server can initiate bidirectional streams, that needs to be in a hop-by-hop manner, so a SETTING is needed

Proposal: Server sends SETTINGS_WEBTRANSPORT_MAX_SESSIONS, client doesn't send any settings, but it uses extended connect to ask to use the WebTransport that the server said it supported. If we change the version later, we use a new upgrade token and use a different setting to indicate support, letting the client still pick.

[LPardue]

I like this proposal

[ekinnear]

• Don't use the same frame identifier for different frame layouts (even across WebTransport versions), and you don't need a client setting to let you read those formats (since you can't wait for settings to arrive anymore and streams may arrive before the connect request)

[DavidSchinazi]

Chair: discussed in editor's meeting. Let's discuss at 117. @ekinnear to write slide

[DavidSchinazi]

Chair: discussed at 117. This was quite confused. We see two proposals:

• both client and server send SETTINGS_WEBTRANSPORT_MAX_SESSIONS and then both compute the maximum of the intersection of both sets to pick the version in use
• only server sends SETTINGS_WEBTRANSPORT_MAX_SESSIONS and the clients sends the version in the upgrade token (i.e., if we change the protocol we will change the upgrade token)

Please keep discussing on this issue

[ekinnear]

Discussed in editor's meeting:

SETTINGS

• You cannot mix versions, there is only one version that can be used on the HTTP connection

Server advertises, client chooses

• This is unambiguous after the CONNECT comes in, but there may be WT streams that show up ahead of the connect and, while you still have to pend them until you get the session ID, it would be nice to at least know how to parse that frame. Instead, you have to wait until you know what version you are using.
• This also opens the door to using multiple versions on the same HTTP connection, which is very complicated and not particularly useful.

HTTP syntax is extended by client-initiated bidirectional streams, which is why this matters more than it would otherwise. This raises the question if we should have included a "fake" very high length for the "frame that runs to the end of the stream" so that a parser that's doing the wrong thing won't see the session ID and try to parse out that number of bytes.

Conclusion: Leave this as-is.

[DavidSchinazi]

Chair: discussed in editor's meeting. Does anyone object to leaving this as-is and closing this issue?

[DavidSchinazi]

Chair: closing due to no objections