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

[Mark Nottingham <[e-mail]>]

> On 13 Dec. 2016, at 7:31 pm, Martin Thomson <[e-mail]> wrote:
> 
> On 6 December 2016 at 08:51, Ilya Grigorik <[e-mail]> 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.

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.

Cheers,

--
Mark Nottingham   https://www.mnot.net/