Subject: 3.3.1 Frame Header: Purpose of 1-bit reserved field?

From: "Brian Raymor (MS OPEN TECH)" <[email-masked]>
Date: Sat, 13 Apr 2013 00:48:46 +0000

3.3.1.  Frame Header

  |R|                 Stream Identifier (31)                      |

   R: A reserved 1-bit field.  The semantics of this bit are not defined.

I was curious about the purpose for the 1-bit reserved field.  Can it be deleted and the Stream Identifier increased to 32 bits?

https://github.com/http2/http2-spec/issues/67

Brian Raymor
Senior Program Manager
Microsoft Open Technologies, Inc. 
A subsidiary of Microsoft Corporation

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Sat, 13 Apr 2013 05:43:12 +0000

future proofing?  E.g. if we need to move to another format or size for 
stream ID?

------ Original Message ------
From: "Brian Raymor (MS OPEN TECH)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Sent: 13/04/2013 12:48:46 p.m.
Subject: 3.3.1 Frame Header: Purpose of 1-bit reserved field?
>I was curious about the purpose for the 1-bit reserved field. Can it be 
>deleted and the Stream Identifier increased to 32 bits?
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 13 Apr 2013 16:48:22 +1000

Looking at the minutes from Tokyo, this was originally for control vs. data (as in SPDY).

I think there's been some discussion about discarding the control bit; OTOH, if people are going to define extension frames, it'd be nice for intermediaries to know whether they count against flow control without having to understand their semantics...

Cheers,

On 13/04/2013, at 3:43 PM, Adrien W. de Croy <[email-masked]> wrote:

> 
> future proofing?  E.g. if we need to move to another format or size for stream ID?
> 
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Roberto Peon <[email-masked]>
Date: Sat, 13 Apr 2013 11:13:21 -0700

This is for prioritization experimentation in the future. The bit allows
for priority level vs resource ordering without bloating the payload of a
reprint frame.
It was originally for control vs data.

-=R
On Apr 12, 2013 11:50 PM, "Mark Nottingham" <[email-masked]> wrote:

> I think there's been some discussion about discarding the control bit;
> OTOH, if people are going to define extension frames, it'd be nice for
> intermediaries to know whether they count against flow control without
> having to understand their semantics...
>
> Cheers,
>
>

---

From: Brian Pane <[email-masked]>
Date: Mon, 15 Apr 2013 09:15:42 -0700

I recommend keeping that bit reserved and leaving Stream ID at 31 bits for
an additional reason: there are some very common programming languages with
only signed 32-bit integers, and inattentive implementors who try to
enforce assertions like "stream IDs must increase monotonically" will
encounter surprises.  Or, more likely, their users will encounter
surprises, years later.

On Saturday, April 13, 2013, Roberto Peon wrote:

> On Apr 12, 2013 11:50 PM, "Mark Nottingham" <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
> wrote:
>
>> On 13/04/2013, at 3:43 PM, Adrien W. de Croy <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
>> wrote:
>>
>> >
>> > From: "Brian Raymor (MS OPEN TECH)" <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
>> >
>> > To: "[email-masked] <javascript:_e({}, 'cvml',
>> [email-masked]');>'" <[email-masked] <javascript:_e({},
>> 'cvml', [email-masked]');>>
>> >> I was curious about the purpose for the 1-bit reserved field. Can it
>> be deleted and the Stream Identifier increased to 32 bits?
>> >>

---

From: "Brian Raymor (MS OPEN TECH)" <[email-masked]>
Date: Wed, 17 Apr 2013 23:53:35 +0000

On April 13, 2013 11:13 AM, "Roberto Peon" < [email-masked]> wrote:

> This is for prioritization experimentation in the future. The bit allows for priority level vs resource ordering without bloating the payload of a reprint frame.

>>  I think there's been some discussion about discarding the control bit; OTOH, if people are going to define extension frames, it'd be nice for intermediaries to know whether they count against flo…

<snip>

Roberto, are you referring to the stream dependency/reprioritization proposal discussed in Tokyo (https://github.com/http2/http2-spec/issues/7) ? Also did automatic error correction morph "REPRI" into "reprint"?

My preference would be for a implementation draft to reflect "complete" features. As future experiments demonstrate their value and reach consensus, then the entire logical set of changes could be adopted together. We had a pretty good discussion about informal/minimalist principles in Tokyo. It might be worth a few minutes at the next interim meeting in June to discuss further and clarify the bar for inclusion.  Since we're iterating on a series of experimental implementations, it seems easy enough to add changes in the future?

Thanks,
...Brian

---

From: Roberto Peon <[email-masked]>
Date: Wed, 17 Apr 2013 18:17:32 -0700

Yes, autocorrect mangled that, and the correct spelling was "repri", for
reprioritize.

I'm not suggesting that this is spec'd. I was just answering why that bit
is reserved for now.

-=R

On Wed, Apr 17, 2013 at 4:53 PM, Brian Raymor (MS OPEN TECH) <
[email-masked]> wrote:

> Roberto, are you referring to the stream dependency/reprioritization
> proposal discussed in Tokyo (https://github.com/http2/http2-spec/issues/7)
> ? Also did automatic error correction morph "REPRI" into "reprint"?
>
> My preference would be for a implementation draft to reflect "complete"
> features. As future experiments demonstrate their value and reach
> consensus, then the entire logical set of changes could be adopted
> together. We had a pretty good discussion about informal/minimalist
> principles in Tokyo. It might be worth a few minutes at the next interim
> meeting in June to discuss further and clarify the bar for inclusion.
>  Since we're iterating on a series of experimental implementations, it
> seems easy enough to add changes in the future?
>
> Thanks,
> ...Brian
>
>
>
>
>