Subject: Dealing with BLOCKED

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Apr 2014 16:37:18 +1000

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.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Brian Raymor (MS OPEN TECH)" <[email-masked]>
Date: Fri, 18 Apr 2014 21:10:18 +0000

On April 17 2014 11:37 PM,  <[email-masked]> wrote:
> 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.

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)? 

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?

Brian Raymor
Senior Program Manager
Microsoft Open Technologies, Inc. 
A subsidiary of Microsoft Corporation

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Apr 2014 16:35:24 +1000

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

> 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/ske…

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 desig…

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…

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,

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 18 Apr 2014 23:34:41 -0700

On Fri, Apr 18, 2014 at 11:35 PM, Mark Nottingham <[email-masked]> 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.

> > 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)?
>
> > 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,
>
> --

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 19 Apr 2014 06:38:29 +0000

GFE of course will implement BLOCKED as well.
On Sat, Apr 19, 2014 at 2:34 AM, William Chan (陈智昌) <[email-masked]>
wrote:

>> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0242.html -
>> a previous decision  - https://github.com/http2/http2-spec/issues/260 -

---

From: Cory Benfield <[email-masked]>
Date: Sat, 19 Apr 2014 10:58:33 +0100

> 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?

I’m not on the To: line but I’m still an implementer, so I’ll respond anyway: hyper has no plans to implement BLOCKED until and unless it becomes a mandatory part of the standard. I’m an emphatic +0 on BLOCKED.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 19 Apr 2014 20:59:27 +0900

> implementation draft, will you implement it and give feedback to let us
​Yes.​

Best regards,
Tatsuhiro Tsujikawa

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 19 Apr 2014 16:25:24 +0200 (CEST)

>> implementation draft, will you implement it and give feedback to let us 

Yes (for me working on curl, which is using Tatsuhiro's http2 library so I'm 
not sure I count as a separate implementor). I'll let Patrick or Nick answer 
for Firefox.

I could possibly also say yes for adding it to the Wireshark http2 dissector 
as I've been poking a bit on that lately.

-- 

  / daniel.haxx.se

---

From: Shigeki Ohtsu <[email-masked]>
Date: Sun, 20 Apr 2014 23:12:28 +0900

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.

---

From: Jeff Pinner <[email-masked]>
Date: Sun, 20 Apr 2014 16:34:13 -0700

Will implement if it is in the spec.

On Sun, Apr 20, 2014 at 7:12 AM, Shigeki Ohtsu <[email-masked]> wrote:

>>> 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)?
>>>

---

From: Jeroen de Borst <[email-masked]>
Date: Mon, 21 Apr 2014 17:01:51 +0000

We’d implement it if part of the next implementation draft.

Jeroen

From: Jeff Pinner [mailto:[email-masked]]
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 (陈智昌); Hasan Khalil; Salvatore Loreto; jxc k; Adrian Cole; [email-masked]; Ilya Grigorik; Cory Benfield; Daniel Stenberg; Flack, Martin; [email-masked]; Brian Raymor (MS OPEN TECH)
Subject: Re: Dealing with BLOCKED

On Sun, Apr 20, 2014 at 7:12 AM, Shigeki Ohtsu <[email-masked]<mailto:[email-masked]>> 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.

On 19 Apr 2014, at 7:10 am, Brian Raymor (MS OPEN TECH) <[email-masked]<mailto:[email-masked]>> wrote:
On April 17 2014 11:37 PM,  <[email-masked]<mailto:[email-masked]>> wrote:
There's been a lot of discussion of this issue, but (predictably) no more data.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Apr 2014 17:53:36 +1000

Thanks to everyone who replied.

It looks like there are a number of implementations who are interested in this, so let's include it in our next implementation draft.

Martin, please incorporate it, but mark the section(s) as AT RISK, and leave the issue open.

Cheers,