Seems reasonable to me. Supported. -=R From: QUIC <[email protected]> on behalf of Lucas Pardue <[email protected]> Date: Tuesday, April 26, 2022 at 12:00 PM To: QUIC WG <[email protected]> Cc: QUIC WG Chairs <[email protected]> Subject: Consensus Call for STOP_SENDING to QPACK streams (#4984) Hello QUIC WG,
As a reminder, the HTTP/3 and QPACK documents gained IETF consensus and approval to be published as RFCs. They have been in the RFC editor queue a while, while awaiting some other documents in the cluster [1]. These documents are now in AUTH48 and the editors have been working hard at getting us closer to the finish line. Although it's late in the day, Tatsuhiro raised issue #4984 [2] on the QPACK spec. In nutshell, the issue identifies a disparity of normative text between how STOP_SENDING frames are treated for QPACK encoder/decoder streams in comparison to the HTTP/3 control stream. The intention from the outset was for implementations to treat STOP_SENDING similarly. The proposed resolution in the PR #4985 [3], addresses this disparity by aligning the normative text for treatment of STOP_SENDING for the QPACK encoder/decoder stream. Our responsible AD has asked that we run a QUIC WG consensus call for the proposal in PR #4985 [3]. This email marks the start of a 2 week call, ending on May 10 2022, anywhere on Earth. Please send any comments directly to the issue or the PR. Absent any pushback, we'll direct the editors to incorporate this change as part of AUTH48. Cheers Lucas & Matt QUIC WG Chairs [1] - https://www.rfc-editor.org/cluster_info.php?cid=C430<https://www.rfc-editor.org/cluster_info.php?cid=C430> [2] - https://github.com/quicwg/base-drafts/issues/4984 [3] - https://github.com/quicwg/base-drafts/pull/4985
