Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always use ALPN for version negotiation #499

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+25 −44
Open

Always use ALPN for version negotiation #499

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
52f01b4
Always use ALPN for version negotiation
ianswett Aug 5, 2024
fc77620
Merge branch 'main' into ianswett-use-alpn
ianswett Mar 29, 2025
010f475
Update draft-ietf-moq-transport.md
ianswett Mar 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 26 additions & 44 deletions draft-ietf-moq-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
to negotiate the version of MoQ.

The ALPN value {{!RFC7301}} for the final version of this specification
is `moq`. ALPNs used to identify IETF drafts are created by appending
the draft number to "moq-". For example, draft-ietf-moq-transport-13
would be identified as "moq-13".

### WebTransport

A MOQT server that is accessible via WebTransport can be identified
Expand Down Expand Up @@ -405,25 +413,23 @@ given URI by setting up a QUIC connection to the host and port
identified by the `authority` section of the URI. The `path-abempty`
and `query` portions of the URI are communicated to the server using the
PATH parameter ({{path}}) which is sent in the CLIENT_SETUP message at the
start of the session. The ALPN value {{!RFC7301}} used by the protocol
is `moq-00`.
start of the session.

## Version and Extension Negotiation {#version-negotiation}
## Extension Negotiation {#version-negotiation}

Endpoints use the exchange of Setup messages to negotiate the MOQT version and
any extensions to use.
Endpoints use the exchange of Setup messages to negotiate any MOQT extensions
to use.

The client indicates the MOQT versions it supports in the CLIENT_SETUP message
(see {{message-setup}}). It also includes the union of all Setup Parameters
{{setup-params}} required for a handshake by any of those versions.
The client includes all Setup Parameters {{setup-params}} required for the
negotiated MoQ version in CLIENT_SETUP.

Within any MOQT version, clients request the use of extensions by adding Setup
parameters corresponding to that extension. No extensions are defined in this
document.

The server replies with a SERVER_SETUP message that indicates the chosen
version, includes all parameters required for a handshake in that version, and
parameters for every extension requested by the client that it supports.
The server replies with a SERVER_SETUP message that includes all parameters
required for a handshake in that version, and parameters for every extension
requested by the client that it supports.

New versions of MOQT MUST specify which existing extensions can be used with
that version. New extensions MUST specify the existing versions with which they
Expand Down Expand Up @@ -894,54 +900,30 @@ handles a subscription that includes those Objects re-requests them.
## CLIENT_SETUP and SERVER_SETUP {#message-setup}

The `CLIENT_SETUP` and `SERVER_SETUP` messages are the first messages exchanged
by the client and the server; they allows the peers to establish the mutually
supported version and agree on the initial 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. TODO: describe GREASE for those.
by the client and the server; they allow the peers to agree on the initial
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


TODO: describe GREASE for those.

The wire format of the Setup messages are as follows:

~~~
CLIENT_SETUP Message Payload {
Number of Supported Versions (i),
Supported Version (i) ...,
Number of Parameters (i) ...,
Setup Parameters (..) ...,
}

SERVER_SETUP Message Payload {
Selected Version (i),
Number of Parameters (i) ...,
Setup Parameters (..) ...,
}
~~~
{: #moq-transport-setup-format title="MOQT Setup Messages"}

The available versions and Setup parameters are detailed in the next sections.

### Versions {#setup-versions}

MoQ Transport versions are a 32-bit unsigned integer, encoded as a varint.
This version of the specification is identified by the number 0x00000001.
Versions with the most significant 16 bits of the version number cleared are
reserved for use in future IETF consensus documents.

The client offers the list of the protocol versions it supports; the
server MUST reply with one of the versions offered by the client. If the
server does not support any of the versions offered by the client, or
the client receives a server version that it did not offer, the
corresponding peer MUST close the session.

\[\[RFC editor: please remove the remainder of this section before
publication.]]

The version number for the final version of this specification (0x00000001), is
reserved for the version of the protocol that is published as an RFC.
Version numbers used to identify IETF drafts are created by adding the draft
number to 0xff000000. For example, draft-ietf-moq-transport-13 would be
identified as 0xff00000D.
The available Setup parameters are detailed in the next sections.

### Setup Parameters {#setup-params}

Expand Down Expand Up @@ -1780,7 +1762,7 @@ reaching a resource limit.

TODO: fill out currently missing registries:

* MOQT version numbers
* MOQT ALPN values
* Setup parameters
* Subscribe parameters
* Subscribe Error codes
Expand Down
Loading