Subject: Proposed text for erratum on PRIORITY in RFC 7540

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Jan 2017 16:59:47 +1300

I figure that I might try to nut this out here before opening an
erratum.  It's not clear from the thread that we all understand this.

I think that suggesting two additions is the right thing here.  It's
an erratum, so we don't have to do a proper edit, we can leave that
for some future revision of the spec to get precisely right.

In Section 5.3 (Stream Priority) a new paragraph:

> The information that an endpoint maintains for stream priority is separate from other state. Importantly, this includes stream states (Section 5.1).  A stream in any state can have its priority changed with a PRIORITY frame. The state of a stream is not changed as a result of changing its priority.  The number of streams for which state is remembered is at the discretion of an endpoint, see Section 5.3.4 for details.

In Section 6.4 (PRIORITY) a new sentence at the end of the first paragraph:

> Sending or receiving a PRIORITY frame does not affect the state of the identified stream (Section 5.1), only its priority is altered.

I think that we only really need one piece of clarification (the
second would be enough), but it doesn't hurt to make it clear in both
places that one might go to learn this.

---

From: Cory Benfield <[email-masked]>
Date: Fri, 20 Jan 2017 13:38:30 +0000

> On 20 Jan 2017, at 03:59, Martin Thomson <[email-masked]> wrote:
> 

Agreed. I’m happy with both proposed texts.

---

From: laike9m <[email-masked]>
Date: Fri, 20 Jan 2017 22:08:45 +0800

Wouldn't it be better to explicitly state that "sending PRIORITY frame
doesn't close unused streams"?

On Fri, Jan 20, 2017 at 11:59 AM, Martin Thomson <[email-masked]>
wrote:

> > The information that an endpoint maintains for stream priority is
> separate from other state. Importantly, this includes stream states
> (Section 5.1).  A stream in any state can have its priority changed with a
> PRIORITY frame. The state of a stream is not changed as a result of
> changing its priority.  The number of streams for which state is remembered
> is at the discretion of an endpoint, see Section 5.3.4 for details.
>
> > Sending or receiving a PRIORITY frame does not affect the state of the
> identified stream (Section 5.1), only its priority is altered.
>

---

From: Scott Mitchell <[email-masked]>
Date: Fri, 20 Jan 2017 09:15:47 -0800

> In Section 6.4 (PRIORITY) a new sentence at the end of the first paragraph:
Section 6.3? Section 6.4 is RST_STREAM right?

> identified stream (Section 5.1), only its priority is altered.
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.

https://tools.ietf.org/html/rfc7540#section-5.1.1
> The first use of a new stream identifier implicitly closes all streams in
the "idle" state that might have been initiated by that peer with a
lower-valued stream identifier.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Jan 2017 08:32:59 +0900

> 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), only the priority of the identified stream is
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.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 25 Jan 2017 09:31:34 +0900

sgtm

---

From: Scott Mitchell <[email-masked]>
Date: Tue, 24 Jan 2017 18:44:28 -0800

On Mon, Jan 23, 2017 at 3:32 PM, Martin Thomson <[email-masked]>
wrote:

> 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.

> problematic, but I don't know how to deal with that without performing

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?