Script updating archive at 2024-12-31T01:27:40Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2024-12-29T01:41:56.068669+00:00",
+  "timestamp": "2024-12-31T01:26:56.051950+00:00",
   "repo": "moq-wg/moq-transport",
   "labels": [
     {
@@ -20467,7 +20467,7 @@
       ],
       "body": "The subscriber needs to index all of its subscriptions by track_alias, because this is how objects will arrive. After the brief period waiting for SUBSCRIBE_OK/ERROR, the only time it needs to lookup a subscription by subscribe_id is when SUBSCRIBE_DONE arrives.\r\n\r\nThere is no reason this couldn't be the track_alias instead.\r\n\r\nAn implementer could just iterate through all its subscriptions to find the matching ID, or set up a separate map of subscribe_id to subscription. But that's pointless.",
       "createdAt": "2024-10-24T22:37:09Z",
-      "updatedAt": "2024-11-18T17:20:10Z",
+      "updatedAt": "2024-12-29T18:40:27Z",
       "closedAt": null,
       "comments": [
         {
@@ -20525,6 +20525,13 @@
           "body": "FWIW, \r\n\r\nI'm in favor of keeping track alias over subscribe ID. Either way, both are not needed. \r\n\r\ntl;dr\r\n\r\n The original use-case, as I understand it, was that subscribe ID was to support multiple tracks (e.g., full track namespace and name = track alias) at the same time.... but that was when Fetch didn't exist and subscribe was used. The use-case was that you could have multiple fetches taking place at the same time for the same track, hence the need for subscribe id.\r\n \r\nConsidering that fetch exists and that section 6.4 as @martinduke  states that one subscription for a given track namespace/name (e.g, track alias) can only exist, the use-case for subscribe ID as a distinguisher is no longer needed.\r\n\r\nI'm in favor of track alias because we can reject a track alias and request the client to use one that we provide (we being relay).  This allows the relay to use the track alias in a larger scope that may span peering and other clients for the same track. Subscribe Id wouldn't make sense to do that. \r\n \r\n ",
           "createdAt": "2024-11-18T17:20:08Z",
           "updatedAt": "2024-11-18T17:20:08Z"
+        },
+        {
+          "author": "vasilvv",
+          "authorAssociation": "COLLABORATOR",
+          "body": "> I'm in favor of track alias because we can reject a track alias and request the client to use one that we provide (we being relay). This allows the relay to use the track alias in a larger scope that may span peering and other clients for the same track. Subscribe Id wouldn't make sense to do that.\r\n\r\nCould you explain how rejecting the alias helps the relay?  I would understand it if the relay was changing the track alias on the objects it _receives_ (QUIC allows peers to pick CIDs for that reason), but the reject mechanism changes the alias used on the objects relay _sends_ to the clients, which does not seem useful (or at least I can't come up with a way to make it useful) .",
+          "createdAt": "2024-12-29T18:40:25Z",
+          "updatedAt": "2024-12-29T18:40:25Z"
         }
       ]
     },