Re: Fwd: New Version Notification for draft-nottingham-http-availability-hints-01.txt

Rory Hewitt <rory.hewitt@gmail.com> Mon, 08 July 2024 22:30 UTC

Resent-Date: Mon, 08 Jul 2024 22:29:30 +0000
Resent-Message-Id: <E1sQwrS-00BJOg-3A@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2a00:1450:4864:20::32d as permitted sender) client-ip=2a00:1450:4864:20::32d; envelope-from=roryhewitt@gmail.com; helo=mail-wm1-x32d.google.com;
MIME-Version: 1.0
From: Rory Hewitt <rory.hewitt@gmail.com>
Date: Mon, 08 Jul 2024 15:29:10 -0700
Message-ID: <CAEmMwDwFmK_wuQg4gnjj4rbVr5Wb_m+f3MFuTXFmA7ZMCvMKEA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000d91516061cc3f159"
Subject: Re: Fwd: New Version Notification for draft-nottingham-http-availability-hints-01.txt
Archived-At: <https://www.w3.org/mid/CAEmMwDwFmK_wuQg4gnjj4rbVr5Wb_m+f3MFuTXFmA7ZMCvMKEA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hey Mark,

My primary concern with this is the possible proliferation and
over-extensibility of `Avail-*` headers.

This document includes Avail-Encoding|Format|Language|ECT (ECT is a likely
addition eventually) and Cookie-Indices, but those may need to be extended
in the future, leading to a large number of headers.

To use the example you provide in the Introduction section:

Vary: Accept-Encoding, Accept-Language, ECT
Avail-Encoding: gzip, br
Avail-Language: fr, en;d
Avail-ECT: ("slow-2g" "2g" "3g"), ("4g");d


Naively, would it not make more sense to have a single
*Available-Responses* header, like this (apologies if the syntax isn't
quite correct for structured fields):

Vary: Accept-Encoding, Accept-Language, ECT
Available-Responses: enc=gzip,br;lang=en,fr;ect=("4g"),("slow-2g" "2g" "3g")


Of course, this includes some assumptions:

1. The first option is the default - we have traditionally not done that,
and used things like Q-values (ugh!), but with brand new headers, does it
not make sense to start implementing a higher-level standard that where
multiple values are specified, they should be specified in a prioritized
list? For any given listable header, both clients and servers know a
preference order, and that should be implicit in the headers they send and
receive. Is this complete heresy to even suggest this?
2. This may be less efficient when using things like QPACK static tables to
hold 'commonly-used' header values, but I don't believe that's something
that anyone is worrying about yet...

On the plus side, it (kinda) simplifies the header size (not a big issue
with Huffman encoding and first-subsequent responses), but to me, having a
single response which specifies all the available response types is an
improvement to having multiple headers. As new response axes becomes
available, they can simply be added to the existing header.

Additionally, it can be extended to include all the 'holes' and various
axes of preference mentioned - for example, the following shows that the
English-gzip is preferred over the French-brotli version (while still
making it clear that French-gzip and English-brotli versions are available
- the preference order symbolized here is explicitly:

en-gzip
fr-gzip
fr-br
en-br

based on the parenthesized grouping:

Vary: Accept-Encoding, Accept-Language, ECT
Available-Responses:
(enc=gzip;lang=en,fr),(enc=br;lang=fr,en);ect=("4g"),("slow-2g" "2g"
"3g")



To use an example of a 'hole', if a French-gzip version IS NOT available,
you'd have this:

Vary: Accept-Encoding, Accept-Language, ECT Available-Responses:
(enc=br;lang=fr),(enc=gzip,br;lang=en);ect=("4g"),("slow-2g" "2g" "3g")

which identifies the following preference order:

br-fr
en-gzip
en-br

An English client can use *either* gzip or br (gzip is preferred), but a
French client can *only* get a brotli response. Crucially though,
French-brotli is still preferred to either English-gzip or English-brotli,
even though there's only a single encoding option for French.

Rory

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt

Fwd: New Version Notification for draft-nottingha… Mark Nottingham
Re: Fwd: New Version Notification for draft-notti… Rory Hewitt
Re: New Version Notification for draft-nottingham… Mark Nottingham
Re: New Version Notification for draft-nottingham… Rory Hewitt
Re: New Version Notification for draft-nottingham… Mark Nottingham