Re: Git Issues: Reserved Stream-ID Bit

[William Chan (陈智昌) <[e-mail]>]

Let's kill this thread. There's already another email thread on this:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0135.html.
Respond there?

And I don't grok your proposal. Even/odd is distinguished via a single bit.
Your proposal seems to suggest using a single bit to indicate
directionality. That sounds like the same thing, except maybe you're
changing which bit is getting used. And I guess you're arguing that you
want to use the reserved bit to get twice the stream id space. I don't see
any compelling argument which says the factor of 2 difference will matter
much either way.

If no one wants to use the reserved bit, sure, let's use it for the stream
id space. Whatever. But if we foresee use (like SPDY/4 proposes to do so
with reprioritization), then maybe we want to reserve that bit. I don't
care if it gets removed from the current draft spec.

Anyway, let's move this back to the other thread rather than forking
threads unnecessarily.


On Sat, Apr 20, 2013 at 12:43 PM, James M Snell <[e-mail]> wrote:

> Per: https://github.com/http2/http2-spec/issues/67
>
> The question is: "R: A reserved 1-bit field. The semantics of this bit
> are not defined...What is the purpose for this field?...Why not just
> have a 32-bit stream identifier?
>
> Currently, the spec mandates that stream ID's originating from the
> client must be odd, and stream ID's originating from the server must
> be even. This makes for a much more restricted range of stream id's
> and ensures that they'll be used up much faster. Personally, I'd
> prefer that this extra reserved bit be used to indicate the
> "directionality" of the stream. All streams originating from the
> client would have this bit unset, all streams originating from the
> server would have this bit set. This gives each side a total of
> (2^32)-1 streams to work with. That ought to be more than enough.
>
>