Objects — MoQT draft-15 §10.2.

An Object contains a range of contiguous bytes from the specified track, as well as associated metadata required to deliver, cache, and forward it. Objects are sent by publishers.

10.2.1. Canonical Object Properties

A canonical MoQ Object has the following information:

Track Namespace and Track Name: The track this object belongs to.
Group ID: The identifier of the Object's Group (see Section 2.3) within the Track.
Object ID: The order of the object within the group.
Publisher Priority: An 8 bit integer indicating the publisher's priority for the Object (Section 7).
Object Forwarding Preference: An enumeration indicating how a publisher sends an object. The preferences are Subgroup and Datagram. Note that the Original Publisher determines the Forwarding Preference for the entire Track, and is a Track property that is implicitly signaled by the delivery of any Object using either Subgroups or Datagrams. Once the property is established for one Object of a Track, the same value MUST be used for all Objects of the Track. In a subscription, an Object MUST be sent according to its Object Forwarding Preference.
Subgroup ID: The identifier of the Object's Subgroup (see Section 2.2) within the Group. This field is omitted if the Object Forwarding Preference is Datagram.
Object Status: An enumeration used to indicate missing objects or mark the end of a group or track. See Section 10.2.1.1 below.
Object Extension Length: The total length of the Object Extension Headers block, in bytes.
Object Extensions : A sequence of Object Extension Headers. See Section 10.2.1.2 below.
Object Payload: An opaque payload intended for an End Subscriber and SHOULD NOT be processed by a relay. Only present when 'Object Status' is Normal (0x0).

10.2.1.1. Object Status

The Object Status informs subscribers what objects will not be received because they were never produced, are no longer available, or because they are beyond the end of a group or track.

Status can have following values:

0x0 := Normal object. This status is implicit for any non-zero length object. Zero-length objects explicitly encode the Normal status.
0x1 := Indicates Object Does Not Exist. Indicates that this Object does not exist at any publisher and it will not be published in the future. This SHOULD be cached.
0x3 := Indicates End of Group. Object ID is one greater than the largest Object produced in the Group identified by the Group ID. If the Object ID is 0, it indicates there are no Objects in this Group. This SHOULD be cached. A publisher MAY use an end of Group object to signal the end of all open Subgroups in a Group. A non-zero-length Object can be the End of Group, as signaled in the DATAGRAM or SUBGROUP_HEADER Type field (see Section 10.3.1 and Section 10.4.2).
0x4 := Indicates End of Track. Group ID is either the largest Group produced in this Track with Object ID one greater than the largest Object produced in that Group, or Group ID is one greater than the largest Group produced in this Track with Object ID zero. This status also indicates the specified Group has ended. Publishers MUST NOT publish an Object with a Location larger than this Location (see Section 2.4.2). This SHOULD be cached.

Any other value SHOULD be treated as a protocol error and the session SHOULD be terminated with a PROTOCOL_VIOLATION (Section 3.4). Any object with a status code other than zero MUST have an empty payload.

10.2.1.2. Object Extension Header

Any Object with status Normal can have extension headers. If an endpoint receives extension headers on Objects with status that is not Normal, it MUST close the session with a PROTOCOL_VIOLATION.

Object Extension Headers are visible to relays and allow the transmission of future metadata relevant to MOQT Object distribution. Any Object metadata never intended to be accessed by the transport or Relays SHOULD be serialized as part of the Object payload and not as an extension header.

Extension Headers are defined in external specifications and registered in an IANA table Section 13. These specifications define the type and value of the header, as well as the rules for processing, modification, caching and forwarding. All such specifications MUST specify whether multiple values of the same extension are allowed on a single Object. A relay that enforces these rules is considered to "support" the extension. If a Relay does not support an extension header, it MUST assume multiple values are allowed.

If unsupported by the relay, Extension Headers MUST NOT be modified, MUST be cached as part of the Object and MUST be forwarded by relays.

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.

Object Extension Headers are serialized as Key-Value-Pairs (see Figure 2), prefixed by the length of the serialized Key-Value-Pairs, in bytes.

Extensions {
  Extension Headers Length (i),
  Extension headers (..),
}

Header types are registered in the IANA table 'MOQ Extension Headers'. See Section 13.