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

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) <
Brian.Raymor@microsoft.com> wrote:

> On April 13, 2013 11:13 AM, "Roberto Peon" < grmocg@gmail.com> 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.
> > It was originally for control vs data.
>
> >> On Apr 12, 2013 11:50 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
> >> 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...
>
> <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
>
>
>
>
>