Subject: I-D Action: draft-ietf-httpbis-client-hints-04.txt

From: [email-masked]
Date: Tue, 18 Apr 2017 22:53:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol of the IETF.

        Title           : HTTP Client Hints
        Author          : Ilya Grigorik
	Filename        : draft-ietf-httpbis-client-hints-04.txt
	Pages           : 14
	Date            : 2017-04-18

Abstract:
   An increasing diversity of Web-connected devices and software
   capabilities has created a need to deliver optimized content for each
   device.

   This specification defines a set of HTTP request header fields,
   colloquially known as Client Hints, to address this.  They are
   intended to be used as input to proactive content negotiation; just
   as the Accept header field allows user agents to indicate what
   formats they prefer, Client Hints allow user agents to indicate
   device and agent specific preferences.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-client-hints-04

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 19 Apr 2017 16:04:07 +1000

We did a WGLC for this (on revision -02) last year, but there have been some non-trivial changes, so let's have another look at it before we ship it off to the IESG.

Please review this document and bring up any remaining issues on the list, or in the issues list. It would also be helpful to hear whether people have reviewed it even if they have no issues, and whether people support publication. As a reminder, the intent is that this will be published as Experimental.

WGLC will end in two weeks, on 2017-05-03.

Cheers,

> On 19 Apr 2017, at 3:53 pm, [email-masked] wrote:
> 
> 

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

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 19 Apr 2017 19:41:03 +0300 (EEST)

2.2.2.  The Accept-CH-Lifetime header field
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04#section-2.2.2

|   Servers can ask the client to remember an origin-wide Accept-CH
|   preference for a specified period of time to enable delivery of
|   Client Hints on all subsequent requests to the origin, and on
|   subresource requests initiated as a result of processing a response
|   from the origin.
|
|     Accept-CH-Lifetime = #delta-seconds
|
|   The field-value indicates that the Accept-CH preference should be
|   considered stale after its age is greater than the specified number
|   of seconds.
|
|     Accept-CH: DPR, Viewport-Width
|     Accept-CH-Lifetime: 86400

It is not very clear why two header fields is needed to pass that information.

2.2.1.  Advertising Support via Accept-CH header field
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04#section-2.2.1

|   Servers can advertise support for Client Hints using the Accept-CH
|   header field or an equivalent HTML meta element with http-equiv
|   attribute ([W3C.REC-html5-20141028]).

Is it assumed that "Accept-CH" is given in http-equiv
attribute, but "Accept-CH-Lifetime" on http response ?

Or is that needed so that "Accept-CH" can be given
on several times?

What happens if there is several "Accept-CH-Lifetime"
on response?

/ Kari Hurtta