Script updating archive at 2025-01-09T00:55:36Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2025-01-07T00:53:36.378094+00:00",
+  "timestamp": "2025-01-09T00:53:08.984158+00:00",
   "repo": "httpwg/http-extensions",
   "labels": [
     {
@@ -282,6 +282,11 @@
       "name": "no-vary-search",
       "description": "",
       "color": "fbca04"
+    },
+    {
+      "name": "wrap-up",
+      "description": "",
+      "color": "f62681"
     }
   ],
   "issues": [
@@ -66487,7 +66492,7 @@
       "labels": [],
       "body": "### Problem\r\nCurrently, seamless navigation or resource sharing between different domains is not possible even if both domains share the same TLS certificate. This limitation results in degraded user experience and increased complexity for multi-domain applications. For instance, users often face unnecessary page reloads or session resets when transitioning between domains controlled by the same operator.\r\n\r\n### Proposed Solution\r\nIf two domains share a valid TLS certificate, they should be treated as belonging to the same trusted entity. This could allow for seamless cross-domain transitions, such as:\r\n- Maintaining session state across domains without the need for custom mechanisms (e.g., cross-domain cookies or local storage hacks).\r\n- Enabling browser caching across domains for shared resources.\r\n- Avoiding full page reloads during cross-domain navigation.\r\n\r\nThis could involve:\r\n1. Extending the HTTP specification to allow session context or caching to be shared between domains with the same TLS certificate.\r\n2. Collaboration with TLS standards to ensure the validity and security of shared certificates.\r\n\r\n### Why It Matters for HTTP\r\nThe proposal would directly impact how HTTP handles sessions, caching, and cross-origin policies. By treating such domains as part of the same entity, it aligns with the principles of seamless and efficient web experiences.\r\n\r\n### Call to Action\r\nI\u2019d love to hear the community\u2019s thoughts on this idea. Is this feasible within the scope of HTTP? What potential security or privacy concerns would need to be addressed? Would collaboration with the TLS Working Group be necessary for implementing this?\r\n\r\nThanks in advance for your feedback!\r\nLex",
       "createdAt": "2024-12-16T01:42:16Z",
-      "updatedAt": "2024-12-16T01:42:16Z",
+      "updatedAt": "2025-01-08T23:57:54Z",
       "closedAt": null,
       "comments": []
     },
@@ -66507,7 +66512,7 @@
       ],
       "body": "In draft-18, the first version is used once in the document, the second five times. Shouldn't it be written the same way in all six instances?",
       "createdAt": "2024-12-20T22:24:42Z",
-      "updatedAt": "2025-01-06T16:58:26Z",
+      "updatedAt": "2025-01-07T21:15:12Z",
       "closedAt": "2025-01-06T16:58:26Z",
       "comments": [
         {
@@ -66516,6 +66521,13 @@
           "body": "Yep, agreed. I'll change the singleton into \"case-sensitive\"",
           "createdAt": "2024-12-23T22:27:24Z",
           "updatedAt": "2024-12-23T22:27:24Z"
+        },
+        {
+          "author": "MikeBishop",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "I will point out [this resource](https://proofed.com/writing-tips/a-guide-to-compound-adjectives-and-hyphenation/) as an example. Since this instance does not precede a noun, I'm not sure it needed to be hyphenated. However, we can also let the RFC Editor figure that out.",
+          "createdAt": "2025-01-07T21:15:11Z",
+          "updatedAt": "2025-01-07T21:15:11Z"
         }
       ]
     },