Re: I-D Action: draft-ietf-httpbis-client-hints-03.txt

> On 24 Dec 2016, at 2:14 am, Mark Nottingham <> wrote:
>> On 13 Dec. 2016, at 7:31 pm, Martin Thomson <> wrote:
>> On 6 December 2016 at 08:51, Ilya Grigorik <> wrote:
>>> Background:
>>> 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.
> I think there's also an Option 4: extensions can only be defined by a sd-token, when it is defined. I.e., this extension syntax is for the use of future sd-tokens, not for arbitrary extension independent of them.
> That's what I'd assumed when we defined the syntax; regardless of the intent, we should write something down about how the extension point is used.

Is this workable for everyone?

Mark Nottingham

Received on Tuesday, 31 January 2017 07:28:49 UTC