- From: Scott Mitchell <scott.k.mitch1@gmail.com>
- Date: Tue, 24 Jan 2017 18:44:28 -0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAFn2buBA59v9L9kQ0F09hDiQzsgZVRdSHUk6KHBrRYT9aaMH7g@mail.gmail.com>
On Mon, Jan 23, 2017 at 3:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 21 January 2017 at 02:15, Scott Mitchell <scott.k.mitch1@gmail.com> > wrote: > > The bit I think needs clarification is that a PRIORITY frame doesn't > impact > > state of ANY stream (if this is the intention of the RFC). The ambiguity > > comes from the language "first use of a new stream identifier" in section > > 5.1.1 (see below). Is it possible to directly resolve this issue? > Updating > > other sections is great, but this creates an implicit dependency between > > different sections which leaves room for error. > > How about: > > Sending or receiving a PRIORITY frame does not affect the state of any > stream (Section 5.1), This language is much more clear. only the priority of the identified stream is > altered. > > This part of the statement may unintentionally cause confusion for other reasons. A PRIORITY frame references 2 streams, and if the "exclusive" bit is set the priority of other streams may also be altered. I think that the "first use of a new stream identifier" text is still > problematic, but I don't know how to deal with that without performing > more surgery. > I would like to try to flush this out to get more clarify if possible. Based upon the previous clarification we know PRIORITY frames are excluded from consideration as "new stream identifier" in this context. Does this "new stream identifier" include the Promised Stream ID from PUSH_PROMISE frames?
Received on Wednesday, 25 January 2017 02:45:01 UTC