Always use ALPN for version negotiation #499
Conversation
| @@ -375,6 +375,14 @@ There is no definition of the protocol over other transports, | |||
| such as TCP, and applications using MoQ might need to fallback to | |||
| another protocol when QUIC or WebTransport aren't available. | |||
|
|
|||
| MoQ uses ALPN in QUIC and "WT-Available-Protocols" in WebTransport | |||
|
The group thinks this is a good direction, but we want to wait until Chrome supports this to merge this PR. |
| configuration before any objects are exchanged. It is a sequence of key-value | ||
| pairs called Setup parameters; the semantics and format of which can vary based | ||
| on whether the client or server is sending. To ensure future extensibility of | ||
| MOQT, the peers MUST ignore unknown setup parameters. |
There was a problem hiding this comment.
This is one part I feel pretty strongly about.
I think we need a way of naming keys or adding a flag to them that indicates that they are mandatory to understand and if the peer does not understand them it MUST end the connection with an error. It does not cost of anything to makes it far easier to roll out new features across clients that don't all upgrade to the same implementation every 6 weeks.
There was a problem hiding this comment.
This text isn't new in this PR, the paragraph reflowed when to establish the mutually supported version and was removed. Can you open a separate issue or PR about MTI setup params?
Or the WebTransport equivalent, "WT-Available-Protocols".
Removes version negotiation from the MoQ SETUP messages.
Fixes #242
Fixes #243
Fixes #346
Related to #83