Tracks and Objects can have additional relay-visible fields, known as Properties, which do not require negotiation, and can be used to alter MOQT Object distribution.
Properties are defined in Section 12 as well as external specifications and are registered in an IANA table Section 15. These specifications define the type and value of the property, along with any rules concerning processing, modification, caching and forwarding.
If a Relay does not support a Property, it MUST NOT be modified, MUST be forwarded, and MUST be cached with the Track or Object, unless it is a Mandatory Track Property as described in Section 2.5.1. If a Track or Object arrives with a different set of unknown properties than previously cached, the most recent set SHOULD replace any cached values, removing any unknown values not present in the new set. Relays MUST NOT attempt to merge sets of unknown properties received in different messages.
If a Relay supports a Property, it MAY be modified, added, removed, and/or cached, subject to the processing rules specified in the definition.
Properties are serialized as Key-Value-Pairs (see Figure 2). Track Properties always appear as the final field in the messages that carry them; their length is the remaining bytes of the message after all preceding fields have been consumed. Object Properties (Section 11.2.1.2) are preceded by an explicit length field.
Property types are registered in the IANA table 'MOQ Properties'. See Section 15.
Certain Property type ranges are reserved for application-specific use and will never be allocated by IANA in future MOQT specifications:
-
0x38 to 0x3F (1-byte encoding): 8 code points for applications with tight space constraints
-
0x3800 to 0x3FFF (2-byte encoding): 2048 code points (including grease Section 14) for applications with moderate space constraints
Applications MAY use code points in these ranges without registration for format-specific metadata or other application-defined purposes. Relays that do not understand the application format MUST forward these properties unchanged but MUST NOT attempt to interpret their semantic meaning. Different applications using the same code point in these ranges may assign different meanings; the interpretation depends on the track or application context known to the publisher and subscriber.
2.5.1. Mandatory Track Properties
Property types in the range 0x4000-0x7FFF are designated as Mandatory Track Properties. These properties MUST have Track scope. Mandatory Track Properties have special handling rules that prevent tracks with required extensions from being forwarded to or processed by endpoints that do not understand them.
An Object received with a Mandatory Track Property as an Object Property is malformed (see Section 2.4.2).
When an endpoint receives Track Properties (in PUBLISH, SUBSCRIBE_OK, or FETCH_OK messages) containing a Mandatory Track Property type that it does not understand, it MUST NOT process or forward that track:
-
For PUBLISH messages: the subscriber MUST respond with REQUEST_ERROR with error code UNSUPPORTED_EXTENSION.
-
For SUBSCRIBE_OK messages: the subscriber MUST cancel the subscription (see Section 3.3.2). If the subscriber is a relay with pending downstream subscribers, it MUST send REQUEST_ERROR with error code UNSUPPORTED_EXTENSION to the downstream subscribers.
-
For FETCH_OK messages: the subscriber MUST cancel the fetch (see Section 3.3.2). If the subscriber is a relay and has not yet sent a FETCH_OK or REQUEST_ERROR downstream, it MUST send REQUEST_ERROR with error code UNSUPPORTED_EXTENSION to the downstream fetch requester. If the relay has already forwarded data on a fetch stream, it MUST reset the stream.
A publisher that knows a subscriber does not support a Mandatory Track Property SHOULD take the following action:
-
For SUBSCRIBE: respond with REQUEST_ERROR with error code UNSUPPORTED_EXTENSION.
-
For FETCH: respond with REQUEST_ERROR with error code UNSUPPORTED_EXTENSION.
-
For PUBLISH: do not publish the track to that subscriber.