CLIENT_SETUP and SERVER_SETUP — MoQT draft-12 §8.3.

The CLIENT_SETUP and SERVER_SETUP messages are the first messages exchanged by the client and the server; they allow the endpoints 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, endpoints 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) = 0x20,
  Length (16),
  Number of Supported Versions (i),
  Supported Versions (i) ...,
  Number of Parameters (i),
  Setup Parameters (..) ...,
}

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

Figure 5: MOQT Setup Messages

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

8.3.1. Versions

MOQT 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 with Version Negotiation Failed.

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

8.3.2. Setup Parameters

8.3.2.1. PATH

The PATH parameter (Parameter Type 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. When a PATH parameter is received from a server, or when a PATH parameter is received while WebTransport is used, or when a PATH parameter is received by a server but the server does not support the specified path, the session MUST be closed with Invalid Path.

The PATH parameter follows the URI formatting rules [RFC3986]. When connecting to a server using a URI with the "moqt" 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. If a PATH does not conform to these rules, the session MUST be closed with Malformed Path.

8.3.2.2. MAX_REQUEST_ID

The MAX_REQUEST_ID parameter (Parameter Type 0x02) communicates an initial value for the Maximum Request ID to the receiving endpoint. The default value is 0, so if not specified, the peer MUST NOT send requests.

8.3.2.3. MAX_AUTH_TOKEN_CACHE_SIZE

The MAX_AUTH_TOKEN_CACHE_SIZE parameter (Parameter Type 0x04) communicates the maximum size in bytes of all actively registered Authorization tokens that the server is willing to store per Session. This parameter is optional. The default value is 0 which prohibits the use of token Aliases.

The token size is calculated as 16 bytes + the size of the Token Value field (see Figure 4). The total size as restricted by the MAX_AUTH_TOKEN_CACHE_SIZE parameter is calculated as the sum of the token sizes for all registered tokens (Alias Type value of 0x01) minus the sum of the token sizes for all deregistered tokens (Alias Type value of 0x00), since Session initiation.

8.3.2.4. AUTHORIZATION TOKEN

See Section 8.2.1.1. The endpoint can specify one or more tokens in CLIENT_SETUP or SERVER_SETUP that the peer can use to authorize MOQT session establishment.

If a server receives an AUTHORIZATION TOKEN parameter in CLIENT_SETUP with Alias Type REGISTER_TOKEN that exceeds its MAX_AUTH_TOKEN_CACHE_SIZE, it MUST NOT fail the session with Auth Token Cache Overflow. Instead, it MUST treat the parameter as Alias Type USE_VALUE. A client MUST handle registration failures of this kind by purging any Token Aliases that failed to register based on the MAX_AUTH_TOKEN_CACHE_SIZE parameter in SERVER_SETUP (or the default value of 0).