Script updating archive at 2023-10-12T01:12:45Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2023-10-10T01:14:28.892295+00:00",
+  "timestamp": "2023-10-12T01:12:44.534943+00:00",
   "repo": "core-wg/corrclar",
   "labels": [
     {
@@ -1364,6 +1364,37 @@
           "updatedAt": "2023-09-07T18:43:25Z"
         }
       ]
+    },
+    {
+      "number": 30,
+      "id": "I_kwDOJ-N8wM5zTak7",
+      "title": "RFC 9175 - Request Tag - List or Set? ",
+      "url": "https://github.com/core-wg/corrclar/issues/30",
+      "state": "OPEN",
+      "author": "boaks",
+      "authorAssociation": "NONE",
+      "assignees": [],
+      "labels": [],
+      "body": "Should a server distinguish requests with multiple `Request Tag` processing them as list (obey order) or set (no order)?\r\n\r\n[RFC9175 3.3](https://www.rfc-editor.org/rfc/rfc9175.html#section-3.3) uses `list`, but I want to ensure, that the interpretation is right.",
+      "createdAt": "2023-10-10T06:15:54Z",
+      "updatedAt": "2023-10-10T09:35:44Z",
+      "closedAt": null,
+      "comments": [
+        {
+          "author": "mrdeep1",
+          "authorAssociation": "NONE",
+          "body": "The server treats each Request Tag as opaque. \r\n\r\nRFC7252 does refer to \"The set of request options that is used for matching the cache entry\r\n   is also collectively referred to as the \"Cache-Key\".\r\n\r\nHowever, certainly the Uri-Host option has to be calculated in order for the cache-key, so I would be doing the same for any options that are repeated.  But, at the end of the day, it is up to the server as to how it builds the cache-key, what matters is that it always does it the same way.",
+          "createdAt": "2023-10-10T09:16:01Z",
+          "updatedAt": "2023-10-10T09:16:01Z"
+        },
+        {
+          "author": "boaks",
+          "authorAssociation": "NONE",
+          "body": "> what matters is that it always does it the same way.\r\n\r\nsure. I also do not assume, that it will be too frequently more than one.\r\nBut on the other side, if it's clear, that it is considered in order or not, then I guess interoperability will be easier. ",
+          "createdAt": "2023-10-10T09:35:44Z",
+          "updatedAt": "2023-10-10T09:35:44Z"
+        }
+      ]
     }
   ],
   "pulls": []