W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 14 Dec 2016 11:31:08 +1100
Message-ID: <CABkgnnVmWRnv+Ku2CNLncxKuWHJPL+NTkvr6+BqY3otieXgXLA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 14 December 2016 00:31:47 UTC