W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Our Schedule

From: Roland Zink <roland@zinks.de>
Date: Sat, 24 May 2014 22:57:58 +0200
Message-ID: <538107D6.3010303@zinks.de>
To: ietf-http-wg@w3.org
+1

On 24.05.2014 22:52, Mike Sweet wrote:
> +1
>
> Sent from my iPhone
>
> On May 24, 2014, at 9:51 AM, James M Snell <jasnell@gmail.com 
> <mailto: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 
>> <mailto: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
>>     <mailto: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 <mailto: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.
>>
Received on Saturday, 24 May 2014 20:58:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC