Re: Our Schedule

+1

Sent from my iPhone

> On May 24, 2014, at 9:51 AM, James M Snell <jasnell@gmail.com> wrote:
> 
> +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.