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