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