Re: Stream State and PRIORITY Frames

[Scott Mitchell <[e-mail]>]

>From my perspective I would like to see two clarifications:

1. It is clear to me that PRIORITY doesn't impact state. However Section
5.1.1 states "first use of a new stream identifier" which makes no
reference to stream state. If stream state is important/implied here better
to be specific about it. I don't think the one-off example below this text
is sufficient to convey the intended implications of this statement.

2. Section 5.1.2 states "Streams in either of the 'reserved' states do not
count toward the stream limit." which seems to conflict with section 8.2.2 "A
client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit the
number of responses that can be concurrently pushed by a server.". These
two statements appear to contradict each other. Since
SETTINGS_MAX_CONCURRENT_STREAMS
is really the only mechanism to limit resources due to server push I'm
assuming section 5.1.2 is overly restrictive.


On Tue, Jan 17, 2017 at 2:27 PM, Martin Thomson <[e-mail]>
wrote:

> On 18 January 2017 at 01:37, Tatsuhiro Tsujikawa <[e-mail]>
> wrote:
> > If my understanding is correct, this only refers to the new stream ID
> used
> > by HEADERS, and PUSH_PROMISE frames which open or reserve streams.  The
> > example text following that statement uses HEADERS which opens new
> stream.
> > PRIORITY frame does not change stream state, and there is no reason to
> close
> > all unused streams lower than bearing stream ID.  That said, I agree that
> > this is not crystal clear in the document.  In practice, this is probably
> > rather rare case.
>
> This is, I think, the expectation.
>
> I think that we probably want to clarify the point by explicitly
> saying that PRIORITY doesn't affect stream states.  We say that it can
> be sent in any state, but we don't also mention that important point.
> Do people here agree that an erratum on this point is appropriate
> here?
>