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: Any namespace remapping from XXX -> YYY is business logic and not signaled over the wire. If you don't want any remapping, then that's a business agreement between you and the CDN, wherein you may need to encode namespaces in a vendor-specific way.
I think we have agreement on that from past discussions. Can the catalog draft have a mechanism to inherit the namespace for tracks from somewhere else, like a relative URL in an HTML page? I'm not sure this is relevant for how relays perform matching between SUBSCRIBE and ANNOUNCE though. The only available information in announce is the namespace.
Yeah I'm probably rambling about something unrelated. But in order to support namespace remapping, the downstream ANNOUCE/SUBSCRIBE won't necessarily match the upstream ANNOUCE/SUBSCRIBE.
This is a useful property. I opened to address this issue and PR URL to fix it.
So if the input full track name does not equal output full track name ( for some version of matching the two ), what is it that tells the relays there is mapping between the two. I'm not objecting to some other way to do this, I just don't understand what it is that tells the relays to do that. Keep in mind relays do not need to read the catalog.
To clarify the "bitwise compare" ... yes I mean exact matching the entire namespace field from announce to the one in subscribe? If the namespace was utf-8 or even a url restricted utf-8, that would match. I am just aruging that a relay should not have to verify every string is a valid utf-8 string, it should just match the bits.
HTTP proxies will not modify the path by default. A downstream request for arrives, there's some rules to match it to a backend, and then an upstream request for is sent. A simple MoQ relay would work the same way. However, you can configure a HTTP proxy to perform special behavior, including rewriting the path. Note that a the HTTP server does rewrite the HLS/DASH playlist provided they are using relative URLs since both the playlist and segment would match the same prefix rules. For example, here's a simple nginx configuration: I would allow the same exact thing for MoQ, but of course use our terminology instead. I think a key improvement with MoQ over HTTP is actually the namespace/name tuple.