Subject: [quicwg/base-drafts] HTTP extension mechanisms (#242)

From: Lucas Pardue <[email-masked]>
Date: Wed, 25 Jan 2017 23:41:14 -0800

The HTTP/QUIC mapping document is missing consideration for HTTP/2 extension mechanisms. This is part of the charter text:

> This mapping will accommodate the extension mechanisms defined in the HTTP/2 specification.

RFC 7540 (https://tools.ietf.org/html/rfc7540#section-5.5) defines three extension mechanisms, lets order these as:

1. New frame types
2. New error codes
3. New settings

I can see how 1 and 2 might work out, following Mike's example of augmenting existing definitions and allowing for things that exist in the HTTP/2 and HTTP/QUIC spaces to be managed somewhat independently. A concrete use case I have is the ALTSVC frame (especially when used on stream 0), so I'm happy to contribute towards this issue with some guidance.

3 has some problems related to proposed SETTINGS changes.

Finally, extensions that coulf change of semantics are a bit problematic (does it change the HTTP or the QUIC semantic, if that either of those is even possible). Additionally,  the negotiation of these is trickier given the additional negotation concerns of QUIC (0-RTT etc).

-- 
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/242

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Jan 2017 17:40:21 -0800

I don't read the charter text as requiring that every individual extension work unmodified in HTTP/QUIC, simply that equivalent extension mechanisms exist.  If people feel differently, we may need broader discussion to reach consensus on that part first.

I suspect 3 will work out the same way that 1 already works -- modify the registry to have additional columns saying whether the setting is supported in HTTP/2 or HTTP/QUIC, and if so, the specification that describes how it works.  That will take some text.

For 2, an extension can define new error codes, but we're currently making no guarantees that the same error code can be applied in both places.  We'll have to think about how much consistency we want.  HTTP/QUIC will probably accommodate semantic-changing extensions the same way HTTP/2 did -- by stating that peers can implement whatever modifications they want via explicit agreement.

-- 
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/242#issuecomment-275568130

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 27 Jan 2017 16:39:44 -0800

I agree with your assessment of the charter text. It's an accommodation of
H2 extensions, not a guarantee of like-for-like.

I confused myself with some of the changes to the treatment of stream IDS.
Rereading the HTTP/QUIC spec, I can see that stream 3 is still reserved. So
an ALTSVC frame for "H2 stream 0" would be sent on stream 3. Presumably an
ALTSVC frame for "H2 stream > 0" simply maps to the appropriate response
control stream.

Here's a can of worms idea, which is likely a non-starter but I'll throw it
out there. Would the QUIC core transport itself support extension frames?
If it did, how about the creation of QUIC extension frames to elide H2
extension frames? For example, a new ALTSVC frame for QUIC. This could
allow other mappings to indicate other services (pretend that it's not
called HTTP Alternative Services :) ).

On 27 Jan 2017 01:40, "Mike Bishop" <[email-masked]> wrote:

I don't read the charter text as requiring that every individual extension
work unmodified in HTTP/QUIC, simply that equivalent extension mechanisms
exist. If people feel differently, we may need broader discussion to reach
consensus on that part first.

I suspect 3 will work out the same way that 1 already works -- modify the
registry to have additional columns saying whether the setting is supported
in HTTP/2 or HTTP/QUIC, and if so, the specification that describes how it
works. That will take some text.

For 2, an extension can define new error codes, but we're currently making
no guarantees that the same error code can be applied in both places. We'll
have to think about how much consistency we want. HTTP/QUIC will probably
accommodate semantic-changing extensions the same way HTTP/2 did -- by
stating that peers can implement whatever modifications they want via
explicit agreement.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/issues/242#issuecomment-275568130>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGRFtfyWaL1jLNhHIS-UncHbKEK3gHO8ks5rWUsFgaJpZM4LuXmB>
.

-- 
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/242#issuecomment-275811564

---

From: Mike Bishop <[email-masked]>
Date: Fri, 27 Jan 2017 20:44:53 -0800

QUIC frames, unlike HTTP frames, do not include a length field – you have to understand every frame you see, or it's a fatal error.  So, not as easily.  We could define an “OTHER” frame or something like that, which includes a length.  But there's no obvious advantage to doing Alt-Svc in the transport layer.  For connection migration, the ability to advertise that a session may be seamlessly continued at another endpoint (in either direction) might be interesting, but we're not there yet.

Sent from my Windows 10 phone

From: Lucas Pardue<mailto:[email-masked]>
Sent: Friday, January 27, 2017 7:39 PM
To: quicwg/base-drafts<mailto:[email-masked]>
Cc: Mike Bishop<mailto:[email-masked]>; Comment<mailto:[email-masked]>
Subject: Re: [quicwg/base-drafts] HTTP extension mechanisms (#242)

—

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/242#issuecomment-275811564>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEE2hY35n30MNFZzq21NV5ATlZu-Q5tWks5rWo5QgaJpZM4LuXmB>.

-- 
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/242#issuecomment-275827171

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 31 Jan 2017 17:49:59 -0800

Thanks for the illumination. I'll put a pin in my ALTSVC thoughts for now, more important things to focus on.

It seems like there is some text to add around HTTP extensions, should we keep this issue open to track that?

-- 
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/242#issuecomment-276550892