Allowing query-args to be transferred to catalog fields

[wilaw]

It is useful for advertising, watermarking and other per-session behaviors, to have a cacheable catalog with fields which the player then overwrites with information obtained out-of-band, such as via a query arg.

Imagine that the player is given a URL (format TBD) such as

https://example.com/appid?n=name-space-for-the-catalog&sid=custom-video-123456

The cached catalog would be

{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "%sid%",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
   ...
   ]
}

The player would apply the following rules

1. Read the JSON file as a raw text string.
2. Perform a simple string replace using the value of the sid query parameter.
3. Parse the result into the JSON object

leading to the same result as if the catalog had contained

{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "custom-video-12345",
      "namespace": "conference.example.com/conference123/alice",
      "packaging": "loc",
      "isLive": true,
   ...
   ]
}

We would need to prohibit the use of % in the name field to allow this to be robust.

[gwendalsimon]

A player who receives a MOQ_URL with query args is supposed to pass the query args in the AUTHORIZATION_TOKEN parameters when it connects (according to #60). So the idea of query_args to catalog fields is not completely correct. I think that, when the server receives a subscribe to the catalog track, it should extract the possible "args" from the token(s) that it received when the player opened the connection, and not from query_args.

In the comment I wrote here #74 (comment) I mentioned track alias as a possible, but we may lose the cacheability feature if track aliases are different for different subscribers. We may need to review #60 and #74 to make it aligned with https://www.ietf.org/archive/id/draft-ietf-moq-transport-15.html#name-authorization-token-paramet so that we have a consistent workflow: control-plane server sends the right query args in the MOQ_URL, then the player sends the token aliases when it connects, then the publisher stores the right information for the aliases, then the right aliases are used in the catalog.