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 11 as well as external specifications and are registered in an IANA table Section 14. 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. 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).
Property types are registered in the IANA table 'MOQ Properties'. See Section 14.
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 13) 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.