and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. <ins> Object Status: As enumeration used for missing or dropped objects that indicates why data is missing. </ins> Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay. <ins> There is also a status field which help subscribers understand what objects it will not receive due to then being dropped, lost, or never be produced including the case where they will not be produced because they are beyond the end of a group or track.  Every object has an associated "Status" that can have following values: 0x0 := Normal object.  The payload is array of bytes and can by empty. 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. 0x2 := Indicates Group does not exist.  Indicates that objects with this GroupID do not exist at any publisher and they 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.  This SHOULD be cached. 0x4 := Indicates end of Track and Group.  GroupID is one greater than the largest group produced in this track and the ObjectId is one greater than the largest object produced in that group.  This is sent right after the last object in the track.  This SHOULD be cached. 0x5 := Indicates Object was dropped at a relay.  Sent by a relay indicating the object identified by the ObjectId was dropped. This SHOULD NOT be cached. 0x6 := Indicates Group was dropped at a relay.  Sent by a relay indicating some of the objects in the group identified by the GroupId were dropped.  The Object ID is one greater than last object sent and MAY be zero.  This SHOULD NOT be cached. Open Issue: We could make end of track and end of group just be a status set on the last object sent on the group or track.  This would mean the status could no longer optional and only occur when the payload length was zero as it would be needed in non zero length packets.  It would also have the issue that when a P frame is produced, the software getting data from the decoder often does not know if it is the last P frame until the next frame is encoded and the software gets an I frame.  We do not want a solution where we add a whole frame of latency on the encoder waiting for next frame so it can set the end of group field on the last last object in the group. Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation (session-termination). There are times where some of the status information is redundant with information learned at the lower layer.  For example, when using stream per object, the end of Group is redundant. In most cases messages with a non zero status code are sent on the same stream that an object with that GroupID would have been sent on. The exception to this is when that stream has been reset; in that case they are sent on a new stream.  This is to avoid the status message being lost in cases such as a relay dropping a group and reseting the stream the group is being sent on. </ins> 6.3.2. Every Track has a single 'Object Forwarding Preference' and