Re: New Version Notification for draft-nottingham-variants-01.txt

> On 30 Oct 2017, at 12:13, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 2017-10-30 05:41, Mark Nottingham wrote:
>> FYI, an update of Variants.
>> This one removes the requirement for conneg mechanisms to identify their own response header ("Content-*"), in favour of a central one -- Variant-Key.
>> Doing so avoids the big problem with Variants-00, where the semantics of a header like Content-Encoding could clash with variants' needs.
>> So, you now have a response that looks something like:
>> Vary: Accept-Encoding, Accept-Language
>> Variants: Accept-Encoding;gzip;br, Accept-Language;fr;en;jp
>> Variant-Key: gzip,en
>> ... which roughly translates to "There are gzip, brotli and identity representations of this resource, in French, English and Japanese; THIS representation is the gzip'd English one."
>> ...
> 
> 
> Looking at the examples, they seem a bit chatty. Can't we collapse this into a single field, like:
> 
> Variants: Accept-Encoding;available="gzip br";selected=gzip, Accept-Language;available="fr en jp";selected=en
> 
> ? (and yes, we could abbreviate the parameter names).

It would also help for the rare cases where there is a conflict, like ‘br’ for compression and ‘br’ the language tag, or something like 
Variant-Key: 1 gzip, 2 en in the example above, where the first number is the index in the Variants header value list.

> 
> Also, looking at my made up syntax using whitespace as separator reminds me that picking the separator is tricky, and in particular the semicolon might not work well in all cases. For instance, what if the server was negotiating on "Accept" and take parameters into account? (see example in <https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.3.2.p.10>).
> 
> So, whatever the syntax is we probably need an escaping mechanism for edge cases...
> 
> Finally, a question about <https://mnot.github.io/I-D/variants/#rfc.section.3>:
> 
>> Note that the contents of Variant-Key are only used to indicate what request attributes are identified with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response. In the example above, it might be that a gzip’d version of the French content is not available, in which case it will not include “Content-Encoding: gzip”, but still have “gzip” in Variant-Key.
> 
> Am I right that this just follows from the syntax that requires Variants and Variant-Keys have the same number of list elements? That might be another reason to collapse things into a single field.
> 
> Best regards, Julian
> 
> 
> 

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

        ~~Yves

Received on Tuesday, 7 November 2017 08:43:52 UTC