RE: HTTP/QUIC Diverging from HTTP/2

FWIW, my opinion as "not an implementer".

I support a clean break.

The background thinking on my part has been in relation to the ALTSVC extension frame, and where its registration should be defined. An independent HTTP/QUIC frame type table (that ports over the non-extension RFC 7540 frame types) simplifies this problem, shifting the responsibility to the extension documents (or their updates). As others have pointed out, there may be a burden with the single table approach of requiring new HTTP/2 extensions to consider HTTP/QUIC.

I'd also say ALTSVC is a good case study for another reason. It defines a new HTTP semantic that is mapped to both an HTTP Header Field and an HTTP/2 extension frame, which are registered differently.

The one risk with separate tables is that the Frame type codes diverge over time. A pragmatic mitigation might be to reserve the code in both tables, even if this is a placeholder for future work.

In considering this topic, I was reminded of Mike's earlier work on decomposing HTTP, captured in the I-D draft-bishop-decomposing-http<https://tools.ietf.org/html/draft-bishop-decomposing-http-01>.

Lucas

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop
Sent: 09 March 2017 18:54
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.)