- From: Alcides Viamontes E <alcidesv@shimmercat.com>
- Date: Thu, 9 Mar 2017 20:18:49 +0100
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: "quic@ietf.org" <quic@ietf.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
- Message-ID: <CAAMqGzbXdQ9tj76xbf_dFKj9YPu_8XRgS0CDhGMaVEQLA7z9Yw@mail.gmail.com>
Hello Mike, I have server implementations of SPDY and then later HTTP/2, which was supposed to be very close to SPDY with just a few refinements. Well it turned out that these "minor refinements" of HTTP/2 required a completely different software architecture. If I had known from the outset that HTTP/2 was that different from SPDY, I could have saved some time by implementing HTTP/2 from scratch on first instance. We have also considered to implement QUIC for a time, but the protocol and the draft describing it look quite complex, and this thing of QUIC being a transport for HTTP/2 being a transport for HTTP/1 doesn't make it easier. So my dream scenario would be to have a standard which only mentions HTTP/2 in passing. Of course QUIC being a transport for HTTP/1 semantics is completely acceptable and to a point, expected. On Thu, Mar 9, 2017 at 7:53 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > At Patrick’s suggestion, I’m restating this question and addressing it to > both the HTTP and QUIC working groups. Apologies if you’re already > following along in QUIC and get this twice after having already seen it the > first time. > > > > HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session on > QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3. > A number of HTTP/2 frames weren’t necessary, since they were duplicative of > services QUIC provides. In draft -01, we removed the full mux layer from > Stream 3, instead letting QUIC deal with all the stream management. This > necessitated changes to several of the remaining frames. By the current > editor’s copy, *no* HTTP/2 frame exists unmodified in HTTP/QUIC, though > several frames of the same name and purpose exist. Likewise, RFC7540 > defines six settings, three of which are inapplicable in HTTP/QUIC. > > > > However, the draft currently still attempts to define them as close > cousins. It updates the HTTP/2 frame and setting registries with > additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification if > applicable) and attempts to coexist with HTTP/2 in the same registry. > (QUIC defines a unified error space, which means a separate registry of > error codes for HTTP/QUIC regardless.) > > > > In PR #363 <https://github.com/quicwg/base-drafts/pull/363>, I’ve > consolidated almost all of the “different from HTTP/2” text into a new > top-level section and excised a lot of “HTTP/2 has this, but HTTP/QUIC > doesn’t need it” text from the main body of the document. Martin has > advocated making a clean break from HTTP/2 and defining our own IANA > registry for frame types and settings, just as we already have for errors. > We can, out of respect for our cousin, use the same values where > appropriate and reserve existing values currently in use on the HTTP/2 side. > > > > I think that’s a good idea, and it’s a fairly small step from the current > state of #363. I’ve created PR #376 > <https://github.com/quicwg/base-drafts/pull/376> to actually make that > split. > > > > Comments from both WGs about the two PRs would be welcome. (Feedback so > far from the QUIC side seems to mostly be “separate with regrets,” but not > universally.) > -- Alcides Viamontes E. Chief Executive Officer, Zunzun AB (+46) 722294542 (www.shimmercat.com is a property of Zunzun AB)
Received on Thursday, 9 March 2017 19:19:22 UTC