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> 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 http://matthew.kerwin.net.au/
Received on Wednesday, 4 June 2014 04:27:01 UTC