Code change:
Other fields: As described in canonical-object-fields. <del> An "OBJECT_PREFER_DATAGRAM" message carries a single object in a datagram or a stream.  There is no explicit length of the payload; it is determined by the length of the datagram or stream.  If this message appears on a stream, it MUST be the only message on a unidirectional stream. An Object received in an "OBJECT_PREFER_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram". </del> <ins> An "OBJECT_DATAGRAM" message carries a single object in a datagram. There is no explicit length of the payload; it is determined by the length of the datagram. </ins> <del> To send an Object with "Object Forwarding Preference" = "Datagram", determine the length of the fields and payload, and compare the length with the maximum datagram size of the session.  If the object size is less than or equal maximum datagram size, send the serialized data as a datagram.  Otherwise, open a stream, send the serialized data and terminate the stream.  An implementation SHOULD NOT send an Object with "Object Forwarding Preference" = "Datagram" on a stream if it is possible to send it as a datagram. </del> <ins> An Object received in an "OBJECT_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram".  To send an Object with "Object Forwarding Preference" = "Datagram", determine the length of the fields and payload and send the Object as datagram.  In certain scenarios where the object size can be larger than maximum datagram size for the session, the Object will be dropped. </ins> 6.3.3.

Related discussion:
text: However, what a distribution network does within the bounds of its own network is up to it. As it restores the original namespace and name at its boundaries (to match the catalog), then external systems cannot tell and distribution intent is preserved. Additionally, there will be business logic and distribution agreements between CDNs, coordinated by the content distributor, to rewrite namespaces between networks. Such namespace rewriting is common between networks and should not be prohibited. Here's how I envisage a scalable solution working. When a twitch user wants to use OBS to publish, they would log in to URL and authenticate against the Twitch CMS. It would vend them two URLS: a connect and publish URL a playback URL to share with their followers The OBS client would use this to The client then publishes twitch/kixelated/catalog, a track which describes two relative tracks - audio and video. The playback client connects to URL and subscribes to premiergaming/gamer34/catalog. After parsing the catalog it subscribes to The Fastly relays have been configured by Twitch, out-of--band, so that when they go forward to origin (which is Akamai), they do a namespace rewrite to The subscriptions make their way back to the OBS instance. The encoder prepare Moqt Objects with in their headers. As these are received by Fastly, business logic rewrites them to , caches them as such and they are delivered to the client.
As per the discussions in person, it is more nuanced than renaming few bits in the header. It might break e2e encryption /auth for example or reencryption in some cases. As this is very application specific, one needs to be take into consideration the costs as it may not be just rewrite few bits in and out of network edges. The more appropriate or clearer framing may be - whenever the name changes, it is ,in a way, republishing the content with a new name ..
just to note, the network wouldn't have access to the catalog
Conclusion is that we'll use exact matching like specified in
Thanks for the update I'm not sure how to wordsmith this but +1 to what it is saying.