Re: Issue re. HTTP2 STREAM and HEADER block use same end bit polarity

reserved: https://github.com/http2/http2-spec/pull/137


On Tue, Jun 18, 2013 at 4:49 PM, James M Snell <jasnell@gmail.com> wrote:

> +1 to END_STREAM and END_HEADERS, +1 to reserving 0x2 for END_MESSAGE
> later on but -1 to including it in this implementation draft.
>
> On Tue, Jun 18, 2013 at 11:39 AM, Jeff Pinner <jpinner@twitter.com> wrote:
> > A suggestion for the HEADERS frame flags that incorporates "FINAL",
> > "MSG_DONE", and changes the polarity of "CONTINUES:"
> >
> > 0x1: END_STREAM - indicates that this frame is the last the endpoint will
> > send on the identified stream.
> > 0x2: END_MESSAGE - indicates that this frame comprises a message
> boundary.
> > 0x4: END_HEADERS - indicates that this frame marks the end of the encoded
> > header block.
> >
> > For compression, the text can then read something like "a header block is
> > compressed and encoded according to <link header compression spec> and
> > serialized in a sequence of HEADERS frames... frames that comprise an
> > encoded header block must be written sequentially and cannot be
> interleaved
> > with other frames... the final frame in the sequence must be identified
> by
> > setting the END_HEADERS flag" (re-written by our editors to make it
> easier
> > to understand)
> >
> >
> >
> > On Sat, Jun 15, 2013 at 9:45 PM, Amos Jeffries <squid3@treenet.co.nz>
> wrote:
> >>
> >> From an implementation point of view a default value of 0 for both flags
> >> is easiest of all to implement, with polarity of 1 being set for the
> >> exceptional cases.
> >>
> >> The bulk of frames in a stream will *not* be the FINAL frame. Likewise
> the
> >> bulk of headers delivered will likely be small enough to *not* have a
> >> CONTINUES necessary.
> >>
> >> So to me the existing polarity seems to be correct. I propose renaming
> the
> >> CONTINUES flag to "EXTEND" (extended headers present) or "LARGE" (large
> >> header set) or "MULTI" (multiple header blocks) or something else
>  avoiding
> >> the unfortunate wording overlap with the FINAL semantics description.
> >>
> >> Amos
> >>
> >>
> >> On 16/06/2013 12:49 p.m., Roberto Peon wrote:
> >>>
> >>> no objections here with the proposal.
> >>>
> >>>
> >>> On Sat, Jun 15, 2013 at 5:15 PM, James M Snell <jasnell@gmail.com
> >>> <mailto:jasnell@gmail.com>> wrote:
> >>>
> >>>     And fwiw, I already had a note for this in my list of todos
> >>>     following the interim.
> >>>
> >>>     On Jun 15, 2013 5:13 PM, "James M Snell" <jasnell@gmail.com
> >>>     <mailto:jasnell@gmail.com>> wrote:
> >>>
> >>>         +1... consistency makes the most sense.
> >>>
> >>>         On Jun 15, 2013 5:06 PM, "William Chan (陈智昌)"
> >>>         <willchan@chromium.org <mailto:willchan@chromium.org>> wrote:
> >>>
> >>>             I don't particularly care. I just want to point out that
> >>>             the reason it "natural" to do it the way it's already
> >>>             done, is FINAL and CONTINUES are the exceptional cases. So
> >>>             to the degree that it's nicer to by default have no flags
> >>>             set, the current approach is better. I don't have any
> >>>             paint to waste on this bike shed though.
> >>>
> >>>             On Sat, Jun 15, 2013 at 4:57 PM, Mike Belshe
> >>>             <mike@belshe.com <mailto:mike@belshe.com>> wrote:
> >>>
> >>>                 I agree on the consistency issue Dave presents.  I
> >>>                 also like Dave's suggestion to use 1 to mean final
> >>>                 everywhere.
> >>>
> >>>                 Mike
> >>>
> >>>                 process question:  is it valuable to reply in github?
> >>>                  or is the list preferred?
> >>>
> >>>
> >>>             Always the list. If you see much discussion on github,
> >>>             yell at them to bring it to the list. And any
> >>>             commits/issues/updates on github should reference the
> >>>             rough consensus from the mailing list.
> >>>
> >>>
> >>>
> >>>
> >>>                 On Sat, Jun 15, 2013 at 4:14 PM, David Morris
> >>>                 <dwm@xpasc.com <mailto:dwm@xpasc.com>> wrote:
> >>>
> >>>
> >>>
> >>>                     This issue:
> >>>
> >>>                     https://github.com/http2/http2-spec/issues/129
> >>>
> >>>                     describes my concern that the polarity is reversed
> >>>                     between STREAM FINAL
> >>>                     and HEADER CONTINUES which are both flag bits used
> >>>                     to manage continuation.
> >>>
> >>>                     I think this will introduce confusion to folks
> >>>                     analyzing wire level bits
> >>>                     as well as reading code.
> >>>
> >>>                     I do acknowledge the the current flag names match
> >>>                     the sense of the
> >>>                     polarity so the names probably should change.
> >>>
> >>>                     Dave Morris
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
>