Define a header for subprotocol negotiation

[vasilvv]

To be able to implement w3c/webtransport#536 (see moq-wg/moq-transport#233 for some background, but the problem here is porting applications that rely on ALPN). Client sends a list of supported subprotocols, server responds with one of the selected.

Possible syntax ideas for the client header:

• sf-list of sf-byte-sequences
• sf-list of sf-strings
• sf-list of sf-tokens
• RFC 7639

Possible response syntax:

• one byte-sequence/string/token
• number indicating the index of the selected subprotocol

[DavidSchinazi]

Chair: editor's meeting. Proposal is to have client send ALPN header (using format from RFC 7639) (client can send multiple ALPNs if it wants to). Server then sends a single ALPN header. This would be an optional feature.

Thoughts?

[kixelated]

I think this is good functionality, mirroring what QUIC provides.

MoQ currently does version negotiation itself. We could leverage the CONNECT request and the ALPN for version negotiation instead. Although we'll still need to do extension negotiation, so I'm not 100% certain if MoQ would use the ALPN, but it's still quite useful.

[enygren]

If we use ALPN we clearly need to define how these interact with the "alpn" SvcParam in SVCB/HTTPS DNS RRs and the defined behavior there.

[DavidSchinazi]

Chair: discussed in the WG session at IETF 118. Consensus in the room was to add an ALPN-like feature to WebTransport, but to disconnect it from actual ALPN, in particular not using the ALPN IANA registry and instead build a new registry.

[DavidSchinazi]

And now speaking as individual contributor: I would suggest restricting this new ALPN-like construct to tokens to avoid the encoding footgun that exists in ALPN.