CLIENT_SETUP and SERVER_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.

The wire format of the Setup messages are as follows:

CLIENT_SETUP Message {
  Type (i) = 0x40,
  Length (i),
  Number of Supported Versions (i),
  Supported Version (i) ...,
  Number of Parameters (i) ...,
  Setup Parameters (..) ...,
}

SERVER_SETUP Message {
  Type (i) = 0x41,
  Length (i),
  Selected Version (i),
  Number of Parameters (i) ...,
  Setup Parameters (..) ...,
}

Figure 3: MOQT Setup Messages

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

6.2.1. 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.

6.2.2. Setup Parameters

6.2.2.1. ROLE

The ROLE parameter (key 0x00) allows each endpoint to independently specify what functionality they support for the session. It has three possible values, which are of type varint:

0x01: Publisher: The endpoint can process subscriptions and send objects, but not subscribe. The endpoint MUST NOT send a SUBSCRIBE message and an ANNOUNCE MUST NOT be sent to it.
0x02: Subscriber: The endpoint can send subscriptions and receive objects, but not publish. The endpoint MUST NOT send an ANNOUNCE message and a SUBSCRIBE MUST NOT be sent to it.
0x03: PubSub: The endpoint can act as a publisher or subscriber, and can send or process any message type.

Both endpoints MUST send a ROLE parameter with one of the three values specified above. Both endpoints MUST close the session if the ROLE parameter is missing or is not one of the three above-specified values.

6.2.2.2. PATH

The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC ([QUIC]). It MUST NOT be used by the server, or when WebTransport is used. If the peer receives a PATH parameter from the server, or when WebTransport is used, it MUST close the connection. It follows the URI formatting rules [RFC3986].

When connecting to a server using a URI with the "moq" scheme, the client MUST set the PATH parameter to the path-abempty portion of the URI; if query is present, the client MUST concatenate ?, followed by the query portion of the URI to the parameter.

6.2.1. Versions

6.2.2. Setup Parameters

6.2.2.1. ROLE

6.2.2.2. PATH

6.2.2.3. MAX_SUBSCRIBE_ID