The basic data element of MOQT is an object. An object is an addressable unit whose payload is a sequence of bytes. All objects belong to a group, indicating ordering and potential dependencies (see Section 2.3). An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved. An Object can become unavailable, but its contents MUST NOT change over time.
Objects are comprised of two parts: metadata and a payload. The metadata is never encrypted and is always visible to relays (see Section 8). The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers. The Original Publisher is solely responsible for the content of the object payload. This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads.
Objects within a Group are in ascending order by Object ID.
From the perspective of a subscriber or a cache, an Object can be in three possible states:
-
The Object is known to not exist. This state is permanent. MOQT has multiple ways to communicate that a certain range of objects does not exist, including the Object Status field, and the use of gaps in FETCH responses.
-
The Object is known to exist. From this state, it can transition to not existing, but not vice versa.
-
The state of the Object is unknown, either because it has not been yet received, or it has not been produced yet.
Whenever the publisher communicates that certain objects do not exist, this fact is expressed as a contiguous range of non-existent objects and by include extension headers indicating the group/object gaps; MOQT implementers should take that into account when selecting appropriate data structures.