W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Making extensibility cheap

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Wed, 4 Jun 2014 05:32:21 +0000
To: Matthew Kerwin <matthew@kerwin.net.au>, Daniel Sommermann <dcsommer@fb.com>
CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <4118ef66782e40269390ffcfa752848e@BL2PR03MB132.namprd03.prod.outlook.com>
The second is what's in my draft -- I just copied your proposed version of DATA, added some extra flags, and called it a COMPRESSED_DATA frame.  I think it's hard to sell it as an end-to-end frame for a couple reasons, but the biggest is that you don't have the opportunity for negotiation with the far side.  That's why I keep coming back to an end-to-end frame that can be down-converted to a DATA frame if it hits a hop that doesn't support the extension.

Sent from Windows Mail

From: Matthew Kerwin<mailto:matthew@kerwin.net.au>
Sent: ?Tuesday?, ?June? ?3?, ?2014 ?9?:?30? ?PM
To: Daniel Sommermann<mailto:dcsommer@fb.com>
Cc: Martin Thomson<mailto:martin.thomson@gmail.com>, HTTP Working Group<mailto:ietf-http-wg@w3.org>

I'm also becoming pretty warm to the idea; as I said in the other thread, I'd like to emphasise noisy errors over silent failure wherever possible.

On 4 June 2014 13:31, Daniel Sommermann <dcsommer@fb.com<mailto:dcsommer@fb.com>> wrote:

I am curious to first see some use cases for end-to-end extensions though.

I agree with the original proposal that ALTSVC and DATA gzip compression would be good candidates to move to extensions.

?If DATA compression was made an extension, there are two ways forward that I can see:

1. Give hop-by-hop extensions the ability to modify existing frames (add flags, maybe add fields, etc.) -- note that this pretty much leaves DATA compression exactly where it is, but with different name for the setting.

2. Mint an extension frame that looks almost exactly like DATA, but includes the compression stuff. If this was a hop-by-hop extension I think there'd be very little disruption to the current spec; however it could also become an end-to-end frame. That idea has much more far-reaching consequences (e.g. does it cross a semantics boundary to move data outside of DATA frames? What do non-extension caching proxies do? Etc.) and I've put no more thought into it than what I've just written, but it's a possibility.

?I'm keen to see Martin's proposed words.?

  Matthew Kerwin
Received on Wednesday, 4 June 2014 05:32:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC