Re: Making extensibility cheap

On 06/04/2014 12:26 AM, Matthew Kerwin wrote:
>
> 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 think it would be nice to allow extensions to add flags to existing 
frames, but in the proposals there is no segmentation between "reserved 
for RFC" and "experimental" flags, so that could potentially lead to 
conflicts down the road. We may need to go with #2.

I'm still not sold on the usefulness of end-to-end frames. If the goal 
is to avoid unnecessary decompress/recompress in proxies for 
COMPRESSED_DATA frames on each hop, I think that could be avoided just 
as well with a hop-by-hop negotiated compression. If both sides of a 
proxy negotiate the same COMPRESSED_DATA extension, then the frame can 
be forwarded as-is, just as with the end-to-end extension.