Script updating archive at 2022-04-10T00:08:11Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2022-04-07T00:08:00.364102+00:00",
+  "timestamp": "2022-04-10T00:08:05.998930+00:00",
   "repo": "quicwg/base-drafts",
   "labels": [
     {
@@ -139973,7 +139973,7 @@
       ],
       "body": "https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-21#section-4.2\r\n\r\n>    These streams MUST NOT be closed.  Closure of either unidirectional\r\n   stream type MUST be treated as a connection error of type\r\n   H3_CLOSED_CRITICAL_STREAM.\r\n\r\nI'd like to clarify that whether this effectively says that receiver is not allowed to send STOP_SENDING.\r\nSTOP_SENDING is elicit RESET_STREAM that closes a stream.\r\n\r\n> An endpoint that receives a STOP_SENDING frame\r\n   MUST send a RESET_STREAM frame if the stream is in the \"Ready\" or\r\n   \"Send\" state. \r\n\r\nSTOP_SENDING itself does not close a stream, but it is an action to request a closure.\r\nI found in interop runner test, one implementation sends STOP_SENDING to QPACK streams.\r\nMy implementation sends RESET_STREAM when it is received as mandated by spec, and upon stream closure, the connection is closed because QPACK streams are closed, then the test fails.\r\n\r\nHTTP draft explicitly says that requesting closure for the control stream is prohibited:\r\n\r\n> The sender MUST NOT close the control stream, and the receiver MUST NOT\r\n   request that the sender close the control stream.\r\n\r\nIt would be nice to add the similar statement to QPACK streams.",
       "createdAt": "2022-04-06T23:54:31Z",
-      "updatedAt": "2022-04-07T00:02:01Z",
+      "updatedAt": "2022-04-07T16:10:39Z",
       "closedAt": null,
       "comments": [
         {
@@ -139982,6 +139982,34 @@
           "body": "It's super-late in the process, but maybe the editors can see a way to squeeze an editorial change in.",
           "createdAt": "2022-04-07T00:02:01Z",
           "updatedAt": "2022-04-07T00:02:01Z"
+        },
+        {
+          "author": "LPardue",
+          "authorAssociation": "MEMBER",
+          "body": "Thanks Tatsuhiro. I agree, IMO the intention was always for consistent treatment of open control streams and open qpack streams when it comes to not closing them.\r\n\r\nFinding a way to address this during AUTH48 would be nice.",
+          "createdAt": "2022-04-07T00:19:48Z",
+          "updatedAt": "2022-04-07T00:20:10Z"
+        },
+        {
+          "author": "MikeBishop",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "I agree, this was the intention -- closing the stream is treated as an error, and being asked to commit an error is itself an error.  One could squint and say it's covered by the existing text -- upon receipt of the STOP_SENDING, the send is required to close the stream; closure of the stream is already required to be treated as an error.\r\n\r\nIt's technically a normative change, but there's no effective change in behavior.",
+          "createdAt": "2022-04-07T14:05:38Z",
+          "updatedAt": "2022-04-07T14:05:38Z"
+        },
+        {
+          "author": "afrind",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "If it's a normative change, is it still OK to change in auth48 just with a WG consensus call or is more process required?",
+          "createdAt": "2022-04-07T15:52:27Z",
+          "updatedAt": "2022-04-07T15:52:27Z"
+        },
+        {
+          "author": "mirjak",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "The AD has to decide what to do and approve this change to the RFC editor.",
+          "createdAt": "2022-04-07T16:10:39Z",
+          "updatedAt": "2022-04-07T16:10:39Z"
         }
       ]
     }