Re: Proposed text for erratum on PRIORITY in RFC 7540

On Thu, Jan 19, 2017 at 7:59 PM, Martin Thomson <>

> 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:
Section 6.3? Section 6.4 is RST_STREAM right?

> > Sending or receiving a PRIORITY frame does not affect the state of the
> 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.
> 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.

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

Received on Friday, 20 January 2017 17:16:21 UTC