Subject: Git Issues: Reserved Stream-ID Bit

From: James M Snell <[email-masked]>
Date: Sat, 20 Apr 2013 12:43:06 -0700

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.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 20 Apr 2013 14:04:04 -0700

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.