Subject: Re: RFC: draft-brown-device-stock-ua-00.txt

From: John Kemp <[email-masked]>
Date: Fri, 9 Nov 2012 14:33:39 -0500

> On 11/9/12 2:04 AM, "Ilya Grigorik" <[email-masked]> wrote:
> On Thu, Nov 8, 2012 at 10:36 AM, Mark Nottingham <[email-masked]> wrote:
> 
> > For those who haven't seen it, Ilya (cc:ed) is working on something
> > related that he's calling "client hints".
> >
> > http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0053.html
> 
> Thanks Mark. We had a good discussion on the Clients Hints proposal earlier
> today at the W3C perf workshop.. Will be updating the document with all the
> feedback and suggestions shortly. If anyone has feedback on what's there
> already, please let me know!

One question - what happens in the presence of an intermediary? SHOULD an intermediary pass on the Client-hints HTTP header, if sent by a client?

Regards,

JohnK

> 
> This might lack context without the audio, but a quick presentation on the
> proposal for today's discussion:
> 
> https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/present
> 
> Ilya

---

From: Ilya Grigorik <[email-masked]>
Date: Fri, 9 Nov 2012 12:32:08 -0800

On Fri, Nov 9, 2012 at 11:33 AM, John Kemp <[email-masked]> wrote:

> One question - what happens in the presence of an intermediary? SHOULD an
> intermediary pass on the Client-hints HTTP header, if sent by a client?

Yes. If the intermediary is the doing the adaptation based on the hint,
then theoretically it could drop the header when forwarding the request
(but more likely, just pass it along).

ig

---

From: Eitan Adler <[email-masked]>
Date: Fri, 9 Nov 2012 16:11:41 -0500

On 9 November 2012 15:32, Ilya Grigorik <[email-masked]> wrote:
> Yes. If the intermediary is the doing the adaptation based on the hint, then
> theoretically it could drop the header when forwarding the request (but more
> likely, just pass it along).

Even then, it shouldn't, because whatever is behind it might have more to do.

-- 
Eitan Adler

---

From: "Ludin, Stephen" <[email-masked]>
Date: Tue, 13 Nov 2012 16:26:34 -0600

As an intermediary/surrogate, this makes a lot of sense.  I can see the specific behavior required being very situational.

The combination of client-hints and browser-hits seems extremely powerful and removes a lot of the guesswork that we have all adapted to.  In your proposal you mention the possibility of having a "well defined list of variable."  I think this is particularly important.  Best practice for extending these variable could leverage existing practices for HTTP headers or perhaps javascript API calls.

Compression of this header (ideally in the context of general HTTP/2.0 header compression) is vital for adoption, especially in the mobile context where every byte matters.

-stephen

From: Ilya Grigorik <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 9, 2012 12:32 PM
To: John Kemp <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: RFC: draft-brown-device-stock-ua-00.txt
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Friday, November 9, 2012 12:33 PM

On Fri, Nov 9, 2012 at 11:33 AM, John Kemp <[email-masked]<mailto:[email-masked]>> wrote:
One question - what happens in the presence of an intermediary? SHOULD an intermediary pass on the Client-hints HTTP header, if sent by a client?

Yes. If the intermediary is the doing the adaptation based on the hint, then theoretically it could drop the header when forwarding the request (but more likely, just pass it along).

ig

---

From: Eitan Adler <[email-masked]>
Date: Tue, 13 Nov 2012 22:30:20 -0500

On 13 November 2012 17:26, Ludin, Stephen <[email-masked]> wrote:
> As an intermediary/surrogate, this makes a lot of sense.  I can see the
> specific behavior required being very situational.

When might I ask, would Akamai want to take action based on a browser
the user not using and may not even be installed?

-- 
Eitan Adler

---

From: Ilya Grigorik <[email-masked]>
Date: Wed, 14 Nov 2012 10:05:16 +0100

> The combination of client-hints and browser-hits seems extremely powerful
> and removes a lot of the guesswork that we have all adapted to.  In your
> proposal you mention the possibility of having a "well defined list of
> variable."  I think this is particularly important.  Best practice for
> extending these variable could leverage existing practices for HTTP headers
> or perhaps javascript API calls.
>

Yep. I'm explicitly limiting variables to what's currently already
available in the browser - don't want to get into the business of trying to
define new ones.

> Compression of this header (ideally in the context of general HTTP/2.0
> header compression) is vital for adoption, especially in the mobile context
> where every byte matters.
>

+1. Should have a new spec up soon which will, hopefully, address part of
this problem. The basic idea being that many of the variables are binary
(ex, WebGL on/off), which means that we can pack them very efficiently. The
tricky part is narrowing down the list of "continuos" variables like
viewport sizes, etc.

ig

>  From: Ilya Grigorik <[email-masked]>
> To: John Kemp <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Resent-From: <[email-masked]>

---

From: John Kemp <[email-masked]>
Date: Wed, 14 Nov 2012 10:28:25 -0500

> Yes. If the intermediary is the doing the adaptation based on the hint, then theoretically it could drop the header when forwarding the request (but more likely, just pass it along).

Here's what the Prefer header (http://tools.ietf.org/html/draft-snell-http-prefer-17 which I just happened to take a look at based on the word 'prefer') says about intermediaries:

"The Prefer header field is end-to-end and SHOULD be forwarded by a by a proxy if the request is forwarded. proxy if the request is forwarded unless Prefer is explicitly identified as being hop-by-hop using the Connection header field defined by [I-D.ietf-httpbis-p1-messaging], Section 6.1."

"  In various situations, a proxy might determine that it is capable of honoring a preference independently of the server to which the request has been directed. For instance, an intervening proxy might be capable of providing asynchronous handling of a request using 202 Accepted responses independently of the origin server. Such proxies can choose to honor the "respond-async" preference on their own despite whether the origin is capable or willing to do so."

By the way, I see overlap between the Prefer header, the Device-Stock-UA header and the Client-hints header. Has anyone else looked at these specs. to see why one would use one over the other, or why there is a need for 3 (in addition to the prior work)?
 
JohnK

---

From: "Ludin, Stephen" <[email-masked]>
Date: Wed, 14 Nov 2012 18:03:51 -0600

I am not certain I understand the question, but I'll answer with where the
'situational' part could come in.  The two simplest are:

1) Origin outputs device specific content and uses the intermediary simply
to accelerate and/or cache
2) Origin serve generic content and the intermediary performs the
appropriate adaptation

I the latter example, the origin dose not necessarily need to know the
device details and removing or changing the header may be appropriate.  In
the former the header is less important to the intermediary though they
still may need to for caching the content appropriately of so desired by
the origin.

-stephen

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 15 Nov 2012 14:02:11 +1300

> still may need to for caching the content appropriately of so desired 

Example (using the draft -00 definition):

   Device-Stock-UA: Chrome-Mobile/16.0

How does that determine what screen size is being viewed on:
  * 1-inch mobile
  * 5-inch mobile
  * 7-inch tablet
  * 10.2 inch tablet
  * 10.4 inch tablet
  * netbook
  * virtualized mobile device running in embeded 640x480 window frame
  * USB-enabled 1640x1280 monitor plugged into one of the above
  * ... the list goes on, and on...

How does it determine CPU capacity of the above?

How does it determine graphics capability of the above?

  ... etc.

The simple answer is that it cannot. Stock UA detail is a completely 
useless metric to be announcing for this and the other adaptation 
parameters important to both origins and surrogates.

I realize you said you would be re-writing the draft and gave some 
hints that you would be sending feature-based hints instead of UA 
strings. Looking forward to seeing that update, the -00 draft is not 
useful beyond gathering marketing statistics on non-removable stock 
browsers (ala ChromeOS, Windows MSIE, FirefoxOS). I posit that when you 
put useful device metrics into it instead of UA garbage you will find 
that simplifying the header name to just "Device:" makes a lot more 
sense and the privacy issues decrease (but not disappear).

AYJ

>
> On 11/13/12 7:30 PM, "Eitan Adler" wrote:
>
>>On 13 November 2012 17:26, Ludin, Stephen wrote: