Agreed, this clarification LGTM. On Wed, Apr 27, 2022 at 1:00 PM Roberto Peon <[email protected]> wrote:
> 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 > > [2] - https://github.com/quicwg/base-drafts/issues/4984 > > [3] - https://github.com/quicwg/base-drafts/pull/4985 >
