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

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).

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

Received on Monday, 30 October 2017 11:13:47 UTC