Subject: [quicwg/base-drafts] Split from HTTP/2 framing? (#81)

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 15:34:29 -0800

Because of a stated goal from some implementers to reuse HTTP/2 framing as much as possible, the draft currently augments the HTTP/2 Frame Type Registry with a "Supported Protocol" column, allowing a frame to be defined for HTTP/2, HTTP/QUIC, or both.  A specification is required for each supported protocol.

However, in the current draft, all but one "Both" frames are *different* between HTTP/2 and HTTP/QUIC.  Small or large, nearly every frame has required some modification to work over QUIC.  If we accept #80 , *all* frames will be different between HTTP/2 and HTTP/QUIC.

At that point, is there really a point in continuing to define HTTP/QUIC in relation to HTTP/2, or should we just admit that it's a new, separate thing that's heavily inspired by HTTP/2?  Separate registry, etc., and future extensions can register themselves with both if appropriate?  Or do we keep the same registry anyway to enforce that you'll never wind up with totally unrelated frames sharing the same value across the two protocols?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/81

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Dec 2016 15:36:25 -0800

It seems like we have a protocol that is inspired and informed by HTTP/2, not congruent with it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/81#issuecomment-266152878

---

From: Patrick McManus <[email-masked]>
Date: Fri, 09 Dec 2016 15:44:43 -0800

On Fri, Dec 9, 2016 at 1:36 PM, Martin Thomson <[email-masked]>
wrote:

> inspired

while true, I can't figure out if that's an argument for 1 registry or 2.

I would paint this one as 1 registry simply because the total data size is
manageable and co-locating them might make people think about how to align
new additions to one or the other given that they have more context staring
them in the face. Not a huge deal either way.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/81#issuecomment-266154182

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Dec 2016 15:48:12 -0800

I think that if we have so many differences, and they are so fundamental, then we're really building a new protocol.  I had hoped that we wouldn't be doing that, but it seems like it's unavoidable.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/81#issuecomment-266154748

---

From: ianswett <[email-masked]>
Date: Fri, 09 Dec 2016 16:43:31 -0800

Agreed, I very much hoped it would not require such substantial changes, but If every frame is different, it is a new thing.  It sounds like there are sound reasons for making every frame different.

In that case, this sounds like HTTP/2.1.  I say that because I believe the featureset(ie: priorities) is identical between it and HTTP/2, but the framing is very different.   In which case, it seems the next question is whether it needs to exist for TCP as well, or is it QUIC only?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/81#issuecomment-266162396

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 16:54:11 -0800

- EXTENDED_SETTINGS was a proposed extension to HTTP/2 the WG decided to defer to the next protocol update.  Clearly not worth a protocol rev by itself.
- PRIORITY needs to be off-stream because frames from different stream can be reordered with respect to each other and priority changes aren't commutative, plus needs some rearranging to accommodate QUIC's larger stream space.  Doesn't apply to TCP, since frames can't be reordered.
- HEADERS change is the sequence number, which isn't needed in TCP because of ordering.  (Plus padding is redundant and the embedded PRIORITY is subject to the previous bullet.)  Modulo any changes we make to HPACK in the future.
- PUSH_PROMISE is the same as HEADERS, plus needs an extra bit to accommodate QUIC's larger stream space.

So no, I don't think there's currently a need to backport any of this into a mapping over TCP.  Now if we modify HPACK to include new features, not just reordering-resiliency, *those* might be worth backporting.  My inclination is to finalize QPACK or whatever, then maybe define HTTP/2.1 with QPACK and maybe EXTENDED_SETTINGS.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/81#issuecomment-266163840