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