Parameters

8.2.1.1. AUTHORIZATION TOKEN

The AUTHORIZATION TOKEN parameter (Parameter Type 0x01) identifies a track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES, ANNOUNCE TRACK_STATUS_REQUEST or FETCH message. This parameter is populated for cases where the authorization is required at the track or namespace level.

The AUTHORIZATION TOKEN parameter MAY be repeated within a message.

The TOKEN value is a structured object containing an optional session-specific alias. The Alias allows the client to reference a previously transmitted TOKEN in future messages. The TOKEN value is serialized as follows:

TOKEN {
  Alias Type (i),
  [Token Alias (i),]
  [Token Type (i),]
  [Token Value (..)]
}

• Alias Type - an integer defining both the serialization and the processing behavior of the receiver. This Alias type has the following code points:

• Token Alias - a session-specific integer identifier that references a Token Value. The Token Alias MUST be unique within the Session. Once a Token Alias has been registered, it cannot be re-registered within the Session without first being deleted. Use of the Token Alias is optional.

• Token Type - a numeric identifier for the type of Token payload being transmitted. This type is defined by the IANA table "MOQT Auth Token Type". See Section 12. Type 0 is reserved to indicate that the type is not defined in the table and must be negotiated out-of-band between client and receiver.

• Token Value - the payload of the Token. The contents and serialization of this payload are defined by the Token Type.

The receiver of a message containing an invalid AUTHORIZATION TOKEN parameter MUST reject that message with an Malformed Auth Token error. This can be due to invalid serialization or providing a token value which does not match the declared Token Type. The receiver of a message referencing an alias that is not currently registered MUST reject the message with Unknown Auth Token Alias. The receiver of a message attempting to register an alias which is already registered MUST close the session with Duplicate Auth Token Alias.

Any message carrying an AUTHORIZATION TOKEN with Alias Type REGISTER that does not result in Malformed Auth Token MUST effect the token registration, even if the message fails for other reasons, including Unauthorized. This allows senders to pipeline messages that refer to previously registered tokens.

If a receiver detects that an authorization token has expired, it MUST retain the registered alias until it is deleted by the sender, though it MAY discard other state associated with the token that is no longer needed. Expiration does not affect the size occupied by a token in the token cache. Any message that references the token with Alias Type USE_ALIAS fails with Expired Auth Token.

Using an Alias to refer to a previously registered Token Value is for efficiency only and has the same effect as if the Token Value was included directly. Retiring an Alias that was previously used to authorize a message has no retroactive effect on the original authorization, nor does it prevent that same Token Value being re-registered.

Clients SHOULD only register tokens which they intend to re-use during the session. Client SHOULD retire previously registered tokens once their utility has passed.

By registering a Token, the client is requiring the receiver to store the Token Alias and Token Value until they are retired, or the Session ends. The receiver can protect its resources by sending a SETUP parameter defining the MAX_AUTH_TOKEN_CACHE_SIZE Section 8.3.2.3 limit it is willing to accept. If a registration is attempted which would cause this limit to be exceeded, the receiver MUST termiate the Session with a Auth Token Cache Overflow error.

8.2.1.2. DELIVERY TIMEOUT Parameter

The DELIVERY TIMEOUT parameter (Parameter Type 0x02) MAY appear in a TRACK_STATUS, SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message. It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received. The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference. There is no explicit signal that an Object was not sent because the delivery timeout was exceeded.

If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription. The publisher SHOULD always specify the value received from an upstream subscription when there is one, and nothing otherwise. If an earlier Object arrives later than subsequent Objects, relays can consider the receipt time as that of the next later Object, with the assumption that the Object's data was reordered.

If neither the subscriber or publisher specify DELIVERY TIMEOUT, all Objects in the track matching the subscription filter are delivered as indicated by their Group Order and Priority. If a subscriber exceeds the publisher's resource limits by failing to consume objects at a sufficient rate, the publisher MAY terminate the subscription with error 'Too Far Behind'.

If an object in a subgroup exceeds the delivery timeout, the publisher MUST reset the underlying transport stream (see Section 9.4.3).

When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay that intends to serve multiple subscriptions for the same track.

Publishers SHOULD consider whether the entire Object is likely to be delivered before sending any data for that Object, taking into account priorities, congestion control, and any other relevant information.

8.2.1.3. MAX CACHE DURATION Parameter

The MAX_CACHE_DURATION parameter (Parameter Type 0x04) MAY appear in a SUBSCRIBE_OK, FETCH_OK or TRACK_STATUS message. It is an integer expressing the number of milliseconds an object can be served from a cache. If present, the relay MUST NOT start forwarding any individual Object received through this subscription or fetch after the specified number of milliseconds has elapsed since the beginning of the Object was received. This means Objects earlier in a multi-object stream will expire earlier than Objects later in the stream. Once Objects have expired from cache, their state becomes unknown, and a relay that handles a downstream request that includes those Objects re-requests them.