We¡¯d implement it if part of the next implementation draft.
Jeroen
From: Jeff Pinner [mailto:jpinner@twitter.com]
Sent: Sunday, April 20, 2014 4:34 PM
To: Shigeki Ohtsu
Cc: Mark Nottingham; Tatsuhiro Tsujikawa; G¨¢bor Moln¨¢r; Patrick McManus; Ludin, Stephen; William Chan (³ÂÖDzý); Hasan Khalil; Salvatore Loreto; jxc k; Adrian Cole; matsumoto_r@net.ist.i.kyoto-u.ac.jp; Ilya Grigorik; Cory Benfield; Daniel Stenberg; Flack, Martin; ietf-http-wg@w3.org; Brian Raymor (MS OPEN TECH)
Subject: Re: Dealing with BLOCKED
Will implement if it is in the spec.
On Sun, Apr 20, 2014 at 7:12 AM, Shigeki Ohtsu <ohtsu@iij.ad.jp<mailto:ohtsu@iij.ad.jp>> wrote:
Yes, I will implement BLOCKED.
I wish we should have had it more earlier because I had several bugs of flow control in the past interops.
Adding a new frame is easier for me rather than adding a new semantic.
(2014/04/19 15:35), Mark Nottingham 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 ]
On 19 Apr 2014, at 7:10 am, Brian Raymor (MS OPEN TECH) <Brian.Raymor@microsoft.com<mailto:Brian.Raymor@microsoft.com>> wrote:
On April 17 2014 11:37 PM, <mnot@mnot.net<mailto: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/