- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 14 Dec 2016 11:31:08 +1100
- To: Ilya Grigorik <ilya@igvita.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 6 December 2016 at 08:51, Ilya Grigorik <ilya@igvita.com> wrote: > Background: https://github.com/httpwg/http-extensions/issues/168 > > We didn't intend Save-Data to be a list.. The goal was to allow attributes > on the single token defined in CH. I'll defer to Mark on Key. Whether you have a list or not, Save-Data has some odd semantics when it comes to extension. How do I model the following variants? Save-Data: on Save-Data: on;video-only Save-Data: on;exclude-video Save-Data: on;compress-video-more Assuming that the extensions are not understood, we end up in an odd place. I see several conclusions: 1. unknown extensions are ignored 2. unknown extensions can only increase the amount of compression; and are ignored otherwise (see compress-video-more) 3. unknown extensions cause the entire clause to be ignored Option 1 seems to be what we have right now, but that doesn't give a client any way to request selective compression (the video-only/not-video example). Option 2 might allow a client to request more aggressive compression, but it does nothing to address the case where a client wants video compression, but would prefer not to have images degraded by compression. Option 3 might be combined with a comma-separated list to allow clients to provide a fallback strategy. There's also probably something more complex as well.
Received on Wednesday, 14 December 2016 00:31:40 UTC