Re: Call for Adoption: draft-grigorik-http-client-hints

On 24/08/2015 6:13 p.m., Mark Nottingham wrote:
> We discussed this document in Dallas, and also a bit in Prague:
>  <http://tools.ietf.org/html/draft-grigorik-http-client-hints-02>
> 
> We'd talked about doing this at the same time as Key, but I think that can be decoupled (especially since we have an implementer for Client Hints without Key).
> 
> Based on the discussion so far, I believe that we should adopt this document as a WG product, with a target of Proposed Standard.
> 
> I've discussed it with our Area Director, who agrees that it's a reasonable thing for us to do.
> 
> Please comment on-list; we’ll make a decision about adoption this time next week.
> 

My personal opinion;
  is that this seems like a fertile ground for filling the WG with more
politick.

In the past years its been interesting watching the opinions of those
pushing for these tracking headers to exist formally compete with the
anonymity crowd, the privacy crowd and the anti-surveillance crowd.
 Which kind of highlights that the main use-case, whether acknowledged
or not; will be for enabling surveillance.

If they are going to exist at all, I think a standard format will be a
Good Thing. Much like Forwarded header sweeping away the custom cruft.


(with web developer hat on);

I've always been a little mystified why these were even being asked for.
The tools available for on-device decisions about display are pretty
good, an coding frameworks make development for those easy.


Looking at screen pixel-width I can think of two cases where it would be
useful;

1) a browser fetching the main HTML of a page. Doing so lets the server
elide segments of the HTML doing logic for other screen sizes.

 The purpose of having that in the page in the first place is/was so
that the HTML part is portable between devices without re-downloading it
on each one. The sub-resources downloaded as needed or portable where
possible.

 Having non-portable versions makes the HTML itsef just an instance of
case #2, below.


2) an app of game needing to fetch specific sized images or similar for
display.

 Embedding img size details in the fetched URL, and fetching only the
relevant one is just a far better way to go for latency, portability and
cache friendliness. There is no difference in origin server processing
load between where the detail is placed.



(and with my Squid hat on);

It is funny the draft should point out cache friendliness as a reason
for avoiding alternative use cases. Yes this mechanism is better than
them, but only by degrees.

Realistically negotiated content means using Vary/Key which are also
somewhat in the cache-unfriendly category. Because the logics needed to
identify and cache variants are quite complex and can *double* (or even
triple) the lookup latency for a cache, especially when optimized fast
hashing is used.


The URL-path with values in such places like filenames are just the
optimal form in terms of reduced latency from faster cache aggregation
and lookup. Actively increasing network latency by using negotiated
features seems a daft approach when its unnecessary.

I'm still waiting for someone to present an actual concrete use-case
that proves there is a need for this latency loss just to relay teh
Client-Hints details (and some of the Accept things too). All I'm seeing
so far is that its better than some badly designed old/current systems
who probably wont ever be upgraded to the new mechanism anyway.


There are probably other use-cases on the table I'm not aware of yet.
I'm all ears.

Amos

Received on Monday, 24 August 2015 15:06:48 UTC