Tracks and Objects can have additional relay-visible fields, known as Extension Headers, which do not require negotiation, and can be used to alter MoQT Object distribution.
Extension Headers are defined in Section 11 as well as external specifications and are registered in an IANA table Section 13. These specifications define the type and value of the header, along with any rules concerning processing, modification, caching and forwarding.
If unsupported by the relay, Extension Headers MUST NOT be modified, MUST be cached as part of the Track or Object and MUST be forwarded by relays. If a Track or Object arrives with a different set of unknown extensions 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 extensions received in different messages.
If supported by the relay and subject to the processing rules specified in the definition of the extension, Extension Headers MAY be modified, added, removed, and/or cached by relays.
Extension Headers are serialized as Key-Value-Pairs (see Figure 2).
Header types are registered in the IANA table 'MOQ Extension Headers'. See Section 13.