Re: HTTP/QUIC Diverging from HTTP/2

Hi Mike

for the benefit of those of us who maybe aren't so familiar with QUIC, 
are there any good resources you can refer us to which deal with the 
bigger picture such as why even have QUIC?

So far our experience with QUIC (as a proxy) has been to simply block 
it, since it provides a bypass mechanism for proxy control.

Regards

Adrien


------ Original Message ------
From: "Mike Bishop" <Michael.Bishop@microsoft.com>
To: "quic@ietf.org" <quic@ietf.org>; "HTTP working group mailing list" 
<ietf-http-wg@w3.org>
Sent: 10/03/2017 3:09:57 PM
Subject: RE: HTTP/QUIC Diverging from HTTP/2

>Summary of feedback on this so far:
>
>Ekr:  “Hoping we can converge, or at least maximize overlap”Stefan:  
>“any hope to [converge] needs to be abandoned”Ian:  “not excited… but 
>it may… be the right thing to do”Patrick:  “separate protocols”Martin:  
>“keep the differences minimal” but “we're really building a new 
>protocol”Alcides:  if it’s different, make the differences clear
>
>
>If I’ve misconstrued anyone’s response, please speak now; and 
>obviously, more opinions are welcome.  I would also appreciate reviews 
>on the text of the PRs themselves.
>
>
>
>Unless there’s strong pushback in the next ~14 hours, I expect to 
>incorporate both PRs tomorrow, prior to the -02 publication.  As Mark 
>noted recently, that doesn’t claim full consensus has been reached, but 
>there appears to be general support for considering these separate 
>protocols which are closely related, rather than two variants of a 
>single protocol.
>
>
>
>From: Mike Bishop
>Sent: Thursday, March 9, 2017 10:54 AM
>To:quic@ietf.org; HTTP working group mailing list <ietf-http-wg@w3.org>
>Subject: HTTP/QUIC Diverging from HTTP/2
>
>
>
>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.)
>