§2.1.

Objects

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 9). 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:

  1. The Object is known to not exist. This state is permanent. All signals that an Object does not exist are authoritative.

  2. The Object is known to exist. From this state, it can transition to not existing, but not vice versa.

  3. The state of the Object is unknown, either because it has not yet been received, or it has not been produced yet.

Since Objects can be delivered out of order, an endpoint can receive an Object after it has already recorded that the Object does not exist (e.g., via a FETCH gap from one source and later delivery via a subscription). This is not a protocol error and the Track is not malformed.

Whenever the publisher communicates that certain objects do not exist, this fact is expressed as a contiguous range of non-existent objects and by including Properties indicating the group/object gaps; MOQT implementers should take that into account when selecting appropriate data structures.

This is one section of the MoQT specification, rendered per-section for quick reference and citation. The authoritative text is draft-ietf-moq-transport-18 at the IETF.