The CLIENT_SETUP and SERVER_SETUP messages are the first messages exchanged
by the client and the server; they allow the endpoints to agree on the initial
configuration before any control messsages are exchanged. The messages contain
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 Setup Parameters.
The wire format of the Setup messages are as follows:
CLIENT_SETUP Message {
Type (i) = 0x20,
Length (16),
Number of Parameters (i),
Setup Parameters (..) ...,
}
SERVER_SETUP Message {
Type (i) = 0x21,
Length (16),
Number of Parameters (i),
Setup Parameters (..) ...,
}
The available Setup parameters are detailed in the next sections.
9.3.1. Setup Parameters
9.3.1.2. 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.
9.3.1.3. 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.
9.3.1.4. 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 endpoint 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.
9.3.1.5. AUTHORIZATION TOKEN
The AUTHORIZATION TOKEN setup parameter (Parameter Type 0x03)) is funcionally equivalient to the AUTHORIZATION TOKEN message parameter, see Section 9.2.2.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 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).
9.3.1.6. MOQT IMPLEMENTATION
The MOQT_IMPLEMENTATION parameter (Parameter Type 0x07) identifies the name and version of the sender's MOQT implementation. This SHOULD be a UTF-8 encoded string [RFC3629], though the message does not carry information, such as language tags, that would aid comprehension by any entity other than the one that created the text.