Object Headers — MoQT draft-09 §8.1.

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

8.1.1. Canonical Object Fields

A canonical MoQ Object has the following information:

Track Namespace and Track Name: The track this object belongs to.
Group ID: The object is a member of the indicated group ID Section 2.3 within the track.
Object ID: The order of the object within the group. The IDs starts at 0, increasing sequentially for each object within the group.
Publisher Priority: An 8 bit integer indicating the publisher's priority for the Object Section 5.
Object Forwarding Preference: An enumeration indicating how a publisher sends an object. The preferences are Subgroup and Datagram. An Object MUST be sent according to its Object Forwarding Preference, described below.
Subgroup ID: The object is a member of the indicated subgroup ID (Section 2.2) within the group. This field is omitted if the Object Forwarding Preference is Track or Datagram.
Object Status: As enumeration used to indicate missing objects or mark the end of a group or track. See Section 8.1.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 8.1.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).

8.1.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. ObjectId is one greater that the largest object produced in the group identified by the GroupID. This is sent right after the last object in the group. If the ObjectID 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.
0x4 := Indicates end of Track and Group. GroupID is the largest group produced in this track and the ObjectId is one greater than the largest object produced in that group. An object with this status that has a Group ID less than any other Group ID, or an Object ID less than or equal to the largest in the group, is a protocol error, and the receiver MUST terminate the session. This SHOULD be cached.
0x5 := Indicates end of Track. GroupID is one greater than the largest group produced in this track and the ObjectId is zero. An object with this status that has a Group ID less than or equal to any other Group ID, or an Object ID other than zero, is a protocol error, and the receiver MUST terminate the session. This SHOULD be cached.

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

Though some status information could be inferred from QUIC stream state, that information is not reliable and cacheable.

8.1.1.2. Object Extension Header

Object Extension Headers are visible to relays and allow the transmission of future metadata relevant to MOQT Object distribution. Any Object metadata never 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 10. These specifications define the type and value of the header, along with any rules concerning processing, modification, caching and forwarding. A relay which is coded to implement these rules is said to "support" the extension.

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 defined below:

Extension Header {
  Header Type (i),
  [Header Value (i)]
  [Header Length (i),
   Header Value (..)]
}

Figure 28: Object Extension Header Format

Header type: an unsigned integer, encoded as a varint, identifying the type of the extension and also the subsequent serialization.
Header values: even types are followed by a single varint encoded value. Odd types are followed by a varint encoded length and then the header value. Header types are registered in the IANA table 'MOQ Extension Headers'. See Section 10.