Re: Our Schedule

+1. I will note that many of the issues have been raised before (e.g. HPACK
complexity) but few have been adequately dealt with, IMHO. I know there is
a strong desire to just finish, but I think rushing to last call in the
specs current state is folly.
On May 24, 2014 2:48 AM, "Greg Wilkins" <gregw@intalio.com> wrote:

>
> Mark et al,
>
> Having only recently re-engaged with this process, the jetty team
> represents both fresh eyes looking at the draft, but also a wealth of
> experience in implementing HTTP, Websocket and SPDY.   I do not see a draft
> that is anywhere near to being ready for LC.
>
> At the very least in the WG there currently exists a level confusion on
> fundamental matters that should not result from a clear specification.  But
> my feel is that many current threads actually represent a lingering level
> of dissatisfaction.    Perhaps these issues have already been put to
> consensus calls, so the resistance has now be reduced to the occasional
> "+1", but the fact that new eyes can read the draft and still raise such
> concerns means that protocol is too complex; the draft insufficiently clear
> or both!
>
> Important issues for me include:
>
>    - The state machine in section 5.1 is essentially a fantasy that
>    describes an idealised protocol that the draft does not represent.   In my
>    work I very frequently lookup the TCP/IP state machine diagram that is a
>    great reference and rarely do I need to go beyond it to understand any
>    issue I have. However, if developers with HTTP/2 problems try to use the
>    state machine in 5.1 as a reference, they are only going to be more
>    confused. For example, the ES transitions are not atomic and the closed
>    state is described as "the terminal state", but is then followed by 5
>    paragraphs of dense complex text describing exceptions and how some frames
>    received in closed state have to be handled!  I have posted what I think is
>    the real state machine (
>    http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/att-0720/http2state.txt)
>    and it is a much more complex beastie.
>
>    - There is also ongoing objections raised to hpack, both in it's
>    complexity and it's impact on the rest of the protocol.  Hpack has been
>    designed to be streaming, but since common fields will only be emitted at
>    the end, receivers are forced to buffer the entire header anyway.  There
>    are significant concerns that hpack will be able to be correctly
>    implemented and/or tested and there is a high probability of many incorrect
>    implementations that may expose the protocol to security and/or DOS issues.
>
>    - Users of the protocol, are able to send data as headers, which is
>    unconstrained by size, flow control or segmentation.   Client-side and
>    Server-side applications are bound to collude to exploit this to obtain an
>    unfair share of any shared HTTP/2 connections/infrastructure, which will
>    eventually break the fundamental paradigm around which the protocol is
>    based and eventually force the use of multiple connections again.
>
>    - There is no clear layering of the protocol. SPDY has a well defined
>    framing layer that can be separately implemented and tested.  HTTP is only
>    a semantic layered on top of that framing layer.  HTTP/2 should do the same
>    and it is a MASSIVE mistake verging on hubris to give up this fundamental
>    good protocol practise in the name of speculative efficiency gains.
>
> I respect the IETF process and if all these issues have been raised
> before, discussed and put to consensus, then I'm put myself on mute and get
> on with implementing the protocol.   But the process does sometimes get it
> wrong and we really don't want to have a HTTP/2.1 any time soon.  So
> perhaps for a such an important protocol, rather than rush forward to LC
> and an RFC by the end of the year, perhaps pause, step back for a while,
> solicit some wider review and listen to some new voices and be prepared to
> re-evaluate if all the complexity is really justified?
>
>
> regards
>
>
>
>
>
>
> On 24 May 2014 01:23, Mark Nottingham <mnot@mnot.net> wrote:
>
>> In a little less than two weeks, we have an interim in NYC.
>>
>> We’ve designated that as an interop event for draft -12 (and associated
>> specs), and so far we seem to have good representation (reminder: if you
>> haven’t already, please update <
>> https://github.com/http2/http2-spec/wiki/Implementations>).
>>
>> Our agenda for the interim is to go (yet again) through our open issues:
>>
>> https://github.com/http2/http2-spec/issues?labels=design&page=1&state=open
>>
>> Assuming we can close those at or soon after the interim, we’ll issue
>> another draft around mid-June.
>>
>> My current thinking — again, assuming we leave the interim with no open
>> issues (or a plan to close them) — is to:
>>
>> * Mark that draft as an Implementation Draft, with the interop targeted
>> at our meeting in Toronto
>> * Issue a Working Group Last Call with a deadline in mid-July
>> * Based upon WGLC feedback and interop feedback, make a decision about
>> submitting the documents to the IESG at our Toronto meeting.
>>
>> The IETF LC will last at least two weeks, and then it goes to the IESG
>> for their consideration. Personally, I think that if we follow the plan
>> above, we have every chance of having an RFC well before the end of the
>> calendar year.
>>
>> All of this is contingent on being able to close out our issues in a
>> timely manner, and not discovering significant new issues in WGLC, of
>> course. If that happens, we’re going to need more rounds of interop, we’ll
>> likely need more meetings, and the schedule will slip (perhaps
>> significantly).
>>
>> We’ll discuss all of this in more detail in NYC, but I wanted to give
>> people a heads-up on the list as to where I think we’re heading.
>>
>> So far, I’ve heard strong preferences across the board for keeping the
>> schedule tight, and the above reflects that.  Going into NYC and Toronto,
>> we need to keep this in mind as we make decisions; every change we make and
>> especially every feature we add has the potential to delay us.
>>
>> Regards,
>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>