W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Dealing with BLOCKED

From: <MIAN.HASAN.KHALIL@GMAIL.COM>
Date: Sat, 19 Apr 2014 06:38:29 +0000
Message-ID: <CAOfQJteXkU9ffZxMM5wuaMHFsURpgO_h4gAemuWA0gUi6xVfdg@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>, Mark Nottingham <mnot@mnot.net>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Gábor Molnár <gabor.molnar@sch.bme.hu>, Patrick McManus <mcmanus@ducksong.com>, Shigeki Ohtsu <ohtsu@iij.ad.jp>, "Ludin, Stephen" <sludin@akamai.com>, Jeff Pinner <jpinner@twitter.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, jxc k <block.rxckin.beats@gmail.com>, Adrian Cole <adrian.f.cole@gmail.com>, matsumoto_r@net.ist.i.kyoto-u.ac.jp, Ilya Grigorik <igrigorik@google.com>, Cory Benfield <cory@lukasa.co.uk>, Daniel Stenberg <daniel@haxx.se>, "Flack, Martin" <mflack@akamai.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>
GFE of course will implement BLOCKED as well.
On Sat, Apr 19, 2014 at 2:34 AM, William Chan (陈智昌) <willchan@chromium.org>
wrote:

> On Fri, Apr 18, 2014 at 11:35 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> [ If you're on the To: line, please respond to the question below --
>> 'yes', 'no' or "don't know/care/plan to implement" is fine ]
>>
>
> Yes - Chromium plans to implement.
>
>
>>
>>
>> On 19 Apr 2014, at 7:10 am, Brian Raymor (MS OPEN TECH) <
>> Brian.Raymor@microsoft.com> wrote:
>>
>> > On April 17 2014 11:37 PM,  <mnot@mnot.net> wrote:
>> >>
>> >> There's been a lot of discussion of this issue, but (predictably) no
>> more data.
>> >>
>> >> As indicated earlier, I think the best way to decide about this
>> proposal is to
>> >> get some operational experience with it, and one way to do that is to
>> include
>> >> it in the next implementation draft with a note to the effect that
>> it's an "at
>> >> risk" feature -- i.e. we'll pull it in the next draft if we don't
>> agree to keep it in
>> >> NYC.
>> >>
>> >> Please comment on this in the next ~3 days; if we don't hear convincing
>> >> arguments as to why this is a bad idea, we'll follow that plan.
>> >>
>> >
>> > Two comments:
>> >
>> > 1. Practical.  Are there multiple implementations committed to
>> implementing and experimenting with this feature to gain the operational
>> experience? My sense was that most responses were neutral/skeptical and not
>> planning to implement.  We would not implement in Katana.
>>
>> That's a good question.
>>
>> Implementers on the To: line -- if BLOCKED is included in the next
>> implementation draft, will you implement it and give feedback to let us
>> make this decision?
>>
>>
>> > 2. Philosophical. If HTTP/2-12 is intended to be the (almost) last
>> implementation draft prior to WGLC, then let's raise the bar, become more
>> ruthless, and only  consider critical features and design changes going
>> forward. For example, is revisiting -
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0242.html -
>> a previous decision  - https://github.com/http2/http2-spec/issues/260 -
>> critical or "preferable" (nice-to-have)?
>>
>> I see I forgot to send my reply to that thread; it will appear
>> momentarily.
>>
>>
>> > We've successfully executed to this point based by being data-driven
>> (header compression bake-off) and date-driven (aggressive schedule in
>> charter, intensive interim meetings). I'd hate to lose our momentum and
>> continue to slip. Can we channel the energy and unproven ideas into the
>> HTTP/3 wish list and stabilize HTTP/2?
>>
>> That's where we're going, yes. We have a few issues to clean up and we'll
>> hopefully get there. I think BLOCKED deserves some consideration because
>> it's been asserted it can help deploy the protocol and get feedback about
>> its operation; if HTTP/2 falls on its face because people get flow control
>> wrong all of the time, HTTP/3 will be harder to do.
>>
>> Regards,
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
Received on Saturday, 19 April 2014 06:38:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC