Re: Our Schedule

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.