- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 18 Jun 2013 21:52:47 -0700
- To: Jeff Pinner <jpinner@twitter.com>
- Cc: James M Snell <jasnell@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
And merged. On 18 June 2013 18:02, Jeff Pinner <jpinner@twitter.com> wrote: > 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 >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> > > >
Received on Wednesday, 19 June 2013 04:53:15 UTC