RE: Dealing with BLOCKED

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.

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

Received on Friday, 18 April 2014 21:10:47 UTC