Re: HTTP/QUIC Diverging from HTTP/2

On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> 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.
>
>
>

This seems like pretty weak consensus, so I'd prefer we discuss this in ORD
rather than
having you merge this now.

-Ekr

*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.)
>