Split from HTTP/2 framing?

[MikeBishop]

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?

[martinthomson]

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

[mcmanus]

On Fri, Dec 9, 2016 at 1:36 PM, Martin Thomson ***@***.***> 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.

[martinthomson]

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.

[ianswett]

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?

[MikeBishop]

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

[martinthomson]

Marking as of interest for discussion in Chicago, if the mailing list discussion doesn't resolve before then.