Yeah, this just captures original design intent. I'm fairly sure that's the way we've implemented it and I'd be surprised if anyone else did differently (except unintentionally). Close the hole.
On Wed, Apr 27, 2022, at 05:57, David Schinazi wrote: > I support this change. > David > > On Tue, Apr 26, 2022 at 12:00 PM Lucas Pardue > <[email protected]> wrote: >> 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 >> [2] - https://github.com/quicwg/base-drafts/issues/4984 >> [3] - https://github.com/quicwg/base-drafts/pull/4985
