Will implement if it is in the spec.
On Sun, Apr 20, 2014 at 7:12 AM, Shigeki Ohtsu <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> 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/
>>
>>
>>
>>
>