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

Re: Dealing with BLOCKED

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 19 Apr 2014 16:35:24 +1000
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>
Message-Id: <A7FA9385-6121-42EA-94FB-DC6BE53426AE@mnot.net>
To: 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>, "William Chan (陈智昌)" <willchan@chromium.org>, Hasan Khalil <mian.hasan.khalil@gmail.com>, Jeff Pinner <jpinner@twitter.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, 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>

[ 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 ]

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.


Mark Nottingham   http://www.mnot.net/
Received on Saturday, 19 April 2014 06:33:03 UTC

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