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

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Oct 2017 15:41:57 +1100

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

Variant-Key is required to have the same number of members in the same order as Variants. Some space could be saved by using the same trick with Variants and Vary, but I don't think the overhead is that bad, and if support for this gets good, it'd be very tempting to send Vary:* sometimes.

A nice side benefit of this approach is that the definition of specific conneg mechanisms is much simpler, and it might be possible to put in some cool optimisations/tricks (TBD).

Comments welcome. Pretty version at:
  https://mnot.github.io/I-D/variants/

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-variants-01.txt
> Date: 30 October 2017 at 3:34:59 pm AEDT
> To: "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-variants-01.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-variants
> Revision:	01
> Title:		HTTP Representation Variants
> Document date:	2017-10-30
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-variants-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-variants/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-variants-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-variants-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nottingham-variants-01
> 
> Abstract:
>   This specification introduces the HTTP "Variants" response header
>   field to communicate what representations are available for a given
>   resource, and the companion "Variant-Key" response header field to
>   indicate which representation was selected.  It is an augmentation of
>   the "Vary" mechanism in HTTP caching.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Oct 2017 12:13:14 +0100

On 2017-10-30 05:41, Mark Nottingham wrote:
> 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.
> 
> ... 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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 Oct 2017 10:08:19 +1100

On 30 Oct 2017, at 10:13 pm, Julian Reschke <[email-masked]> wrote:
> 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
> 

I considered that, but it seems like making them separate will make at least the Variants header (in the current design) more likely to get a hit in HPACK. Also, even with shorter parameter names, it seems like this approach is actually more verbose, in terms of character counts -- especially when the list gets long.

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

Yes (and that's another reason for separating the headers, I think). However, keep in mind that available-values doesn't *have* to be the values sent in the request headers; it can be computed to something else.

Also, I very much wonder whether including parameters is a good idea for Accept.

> Finally, a question about <https://mnot.github.io/I-D/variants/#rfc.section.3>:
> 
> 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.

Yes.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Oct 2017 08:55:56 +0100

> I considered that, but it seems like making them separate will make at least the Variants header (in the current design) more likely to get a hit in HPACK. Also, even with shorter parameter names,…

Hmmm.

You get the additional complexity of two header fields potentially out 
of sync. My gut feeling is that eliminating that problem would be worth 
a few bytes.

And if optimizing *that* is the goal, one can of course choose a bit 
more obscure syntax, such as:

   Accept-Encoding;gzip,gzip,br, Accept-Language;en;fr;en;jp

(where the first parameter indicates the selected variant)

> Yes (and that's another reason for separating the headers, I think).

Why? The escaping problem exists in both cases...

> However, keep in mind that available-values doesn't *have* to be the values sent in the request headers; it can be computed to something else.
> 

Yes, but that's a separate discussion. I believe it would be good if the 
draft addressed negotiating on type (no matter whether we think it's a 
good idea).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Oct 2017 12:13:57 +0100

On 2017-10-31 00:08, Mark Nottingham wrote:
> I considered that, but it seems like making them separate will make at least the Variants header (in the current design) more likely to get a hit in HPACK. (...)

Just checking: that's mainly true when multiple UAs share the same 
connection, right? For a single UA, I would assume that during normal 
operation, most of the time the same variant would be selected, so 
inlining the "selected" information wouldn't hurt...

Best regards, Julian