A relay that negotiated this extension on a downstream session MUST include the HOP_PATH parameter on every PUBLISH_NAMESPACE and NAMESPACE it sends on that session
Or else what? Fail request? Close session?
PUBLISH_NAMESPACE and SUBSCRIBE_NAMESPACE carry a Parameters field in {{moqt}} regardless, and per {{moqt}} an unknown Key-Value-Pair Type is ignored;
Because the value is a variable-length list, HOP_PATH uses an odd Type so that it is length-prefixed:
Unknown parameters are no longer parseable in MOQT since draft 16 -- they don't use the even/odd trick present in extensible Setup Options and Track/Object Properties. Instead, all parameters have bespoke parsing that the receiver MUST understand, or the message is unparseable. I recommend keeping this convention for NAMESPACE, otherwise it's quite odd, and contrasts with PUBLISH_NAMESPACE.
An endpoint SHOULD draw a full-width random value (up to the 64-bit varint maximum) so that the probability of two endpoints choosing the same Hop ID is negligible.
I would restate this to say - the ID MUST be unique, or bad things (TM) will happen. Deployments often have unique identifiers that can be used here via config, and the receiver can't tell if the id was randomly generated anyways. I would keep the fallback logic and say that an endpoint choosing a random 64 bit value if it has no other unique ID ought to work, it just shouldn't be recommended.
upstream peer
Otherwise the relay MAY forward it downstream,
You should define upstream / downstream in this context. In MOQT, they are defined relative to the original publisher, but in a relay mesh, that may no longer be the correct thinking.
Number of Parameters (vi64),
Technically this field is redundant (as your parsing suggests, you can just use the message length), but shrug, it’s fine (and MOQT does that in some/most places)
origin publisher
nit: original publisher
Editorial: I find the pedantry about how to parse the fields a bit of overkill, but it’s also fine, I guess.
Or else what? Fail request? Close session?
Unknown parameters are no longer parseable in MOQT since draft 16 -- they don't use the even/odd trick present in extensible Setup Options and Track/Object Properties. Instead, all parameters have bespoke parsing that the receiver MUST understand, or the message is unparseable. I recommend keeping this convention for NAMESPACE, otherwise it's quite odd, and contrasts with PUBLISH_NAMESPACE.
I would restate this to say - the ID MUST be unique, or bad things (TM) will happen. Deployments often have unique identifiers that can be used here via config, and the receiver can't tell if the id was randomly generated anyways. I would keep the fallback logic and say that an endpoint choosing a random 64 bit value if it has no other unique ID ought to work, it just shouldn't be recommended.
You should define upstream / downstream in this context. In MOQT, they are defined relative to the original publisher, but in a relay mesh, that may no longer be the correct thinking.
Technically this field is redundant (as your parsing suggests, you can just use the message length), but shrug, it’s fine (and MOQT does that in some/most places)
nit: original publisher
Editorial: I find the pedantry about how to parse the fields a bit of overkill, but it’s also fine, I guess.