Code change:
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. <del> model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application 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. </del> <ins> model-group 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 it's 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.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application 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. </ins> 2.2.

Related discussion:
text: SUBSCRIBEOK would be equivalent to HTTP 100 CONTINUE, which is truly useless, and there would be no equivalent to 200 OK or 404 Not Found. Pub/sub doesn't mean black hole simulator either. I've only used RabbitMQ a long time ago, but if you tried to bind a queue (ie. SUBSCRIBE) to an exchange (ie. ANNOUNCE) it will return an error if the exchange doesn't exist. Is the justification that pub/sub protocols are supposed to black hole, or is this behavior that you actually want? Instead of hanging indefinitely if a relay can't route a SUBSCRIBE, wouldn't it just be better to receive a 404 Not Found? You're allowed to try again, but now there's no timers or guess work as to if the SUBSCRIBE could be routed to an origin.
It's for higher latency targets. HLS/DASH clients don't start at the latest segment, but rather start further back based on the target latency. If I understand correctly, you're saying the relay: has an empty cache. receives a and . issues issues a live subscription upstream: waits for the first OBJECT to arrive for that subscribe, using it as the live playhead: issues a backfill subscribe upstream: forwards any objects based on the mapping from relative to absolute. It works for relays, but at the cost of an extra round-trip to origin. However, it won't work for clients that want to start playback N groups back (jitter buffer size), because the player doesn't know when/what to render without first receiving N distinct groups. Here's what we would like: has an empty cache. receives a and . (re)issues a subscription upstream: waits for forwards any objects based on the mapping from relative to absolute.
Individual Comment: I think SUBSCRIBEOK needs to resolve all relative Subscribe Hints that were passed in the Subscribe. Otherwise, I'm really not sure how my library will know when an Object arrives if it belongs to a particular subscription or not -- the OBJECTs that arrive have only track name and absolute group/object numbers. I see the use case for some relays wanting to optimistically SUBSCRIBEOK, but then there would need to be a follow up message that resolves the relative hints when the relay finds out where they map.