Subject: [quicwg/base-drafts] STOP_SENDING to QPACK streams (Issue #4984)

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 06 Apr 2022 16:54:51 -0700

https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-21#section-4.2

>    These streams MUST NOT be closed.  Closure of either unidirectional
   stream type MUST be treated as a connection error of type
   H3_CLOSED_CRITICAL_STREAM.

I'd like to clarify that whether this effectively says that receiver is not allowed to send STOP_SENDING.
STOP_SENDING is elicit RESET_STREAM that closes a stream.

> An endpoint that receives a STOP_SENDING frame
   MUST send a RESET_STREAM frame if the stream is in the "Ready" or
   "Send" state. 

STOP_SENDING itself does not close a stream, but it is an action to request a closure.
I found in interop runner test, one implementation sends STOP_SENDING to QPACK streams.
My 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.

HTTP draft explicitly says that requesting closure for the control stream is prohibited:

> The sender MUST NOT close the control stream, and the receiver MUST NOT
   request that the sender close the control stream.

It would be nice to add the similar statement to QPACK streams.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4984
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/issues/[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Apr 2022 17:02:20 -0700

It's super-late in the process, but maybe the editors can see a way to squeeze an editorial change in.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4984#issuecomment-1090940829
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/issues/4984/[email-masked]>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Apr 2022 17:20:08 -0700

Thanks Tatsuhiro. IMO the intention was always for consist treatment of open control streams and open qpack streams when it comes to not closing them.

Finding a way to address this during AUTH48 would be nice.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4984#issuecomment-1090951704
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/issues/4984/[email-masked]>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 07 Apr 2022 07:05:57 -0700

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.

It's technically a normative change, but there's no effective change in behavior.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4984#issuecomment-1091782495
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/issues/4984/[email-masked]>

---

From: afrind <[email-masked]>
Date: Thu, 07 Apr 2022 08:52:47 -0700

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?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4984#issuecomment-1091905705
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/issues/4984/[email-masked]>

---

From: mirjak <[email-masked]>
Date: Thu, 07 Apr 2022 09:10:59 -0700

The AD has to decide what to do and approve this change to the RFC editor.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4984#issuecomment-1091930003
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/issues/4984/[email-masked]>