Subject: Re: draft-ietf-httpbis-client-hints-04; 2.2.2. The Accept-CH-Lifetime header field

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 May 2017 11:07:03 +1000

Hi Kari,

> On 20 Apr 2017, at 2:41 am, Kari Hurtta <[email-masked]> wrote:
> 
> 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.

Accept-CH is nothing more than a list of other header field names. If you put other information in there, you have exceptional processing, which is awkward (and leads to thinks like registering the fake header field name "close" for the Connection header). 

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

Ilya, any thoughts here? Clarifying these would probably be helpful.

Cheers,

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

---

From: Ilya Grigorik <[email-masked]>
Date: Fri, 12 May 2017 09:45:29 -0700

> > attribute, but "Accept-CH-Lifetime" on http response ?

Yes.

> Or is that needed so that "Accept-CH" can be given

No, that's implicit in its definition as a comma separated list of values.
Correct me if I'm wrong, but my understanding is that default semantics
allow multiple headers with same field-name, as long as the field-value is
defined as a comma separated list.. Meaning, there can be multiple
Accept-CH header fields and they can be combined into a single list.

> Ilya, any thoughts here? Clarifying these would probably be helpful.

For Accept-CH-Lifetime, I guess we just need to specify which one wins,
correct? Any defaults I can point to or reuse? Last one wins?

ig

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 May 2017 12:33:50 +0200

Here's my (late) LC feedback, mostly nits:

2.1.  Sending Client Hints

    Clients control which Client Hints are sent in requests, based on
    their default settings, user configuration and/or preferences.
    Implementers might provide user choice mechanisms so that users may
    balance privacy concerns with bandwidth limitations.  Implementations
    specific to certain use cases or threat models might avoid
    transmitting these headers altogether, or limit them to secure
    contexts or authenticated sessions.  Implementers should be aware
    that explaining the privacy implications of passive fingerprinting or
    network information disclosure may be challenging.

Througout: avoid lowercase BCP14 keywords (may->can, should->ought to, 
...), or actually invoke the new boilerplate defined in 
draft-leiba-rfc2119-update.

2.2.  Server Processing of Client Hints

    When presented with a request that contains one or more client hint
    headers, servers can optimize the response based upon the information

  s/headers/header fields/

    in them.  When doing so, and if the resource is cacheable, the server
    MUST also generate a Vary response header field (Section 7.1.4 of
    [RFC7231]), and optionally Key ([I-D.ietf-httpbis-key]), to indicate
    which hints can affect the selected response and whether the selected
    response is appropriate for a later request.

It's not optimal to mention a draft that for now is work in progress so 
close to a "MUST", even with "optionally" sprinkled in. My 
recommendation continues to move all material that refers to the Key 
header field to an appendix.

    Further, depending on the hint used, the server can generate
    additional response header fields to convey related values to aid
    client processing.  For example, this specification defines "Content-
    DPR" response header field that needs to be returned by the server

/defines/defines the/

    when the "DPR" hint is used to select the response.

    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.

We should define "origin" somewhere (and also explain "subresource").

3.  Client Hints

3.1.  The DPR header field

Througout: uppercase "header field" in section titles.

3.2.  The Width header field

    If the desired resource width is not known at the time of the request
    or the resource does not have a display width, the Width header field
    can be omitted. ...

Isn't that evident because sending the hints is purely OPTIONAL anyway?

3.5.  The Save-Data header field

    The "Save-Data" request header field consists of one or more tokens
    that indicate client's preference for reduced data usage, due to high
    transfer costs, slow connection speeds, or other reasons.

      Save-Data = sd-token *( OWS ";" OWS [sd-token] )
      sd-token = token

Why aren't we using HTTP list syntax here? Also, what does it mean when 
the field appears more than once?

7.  References

7.1.  Normative References

    [W3C.CR-css-values-3-20160929]
               Atkins, T. and E. Etemad, "CSS Values and Units Module
               Level 3", World Wide Web Consortium CR CR-css-values-
               3-20160929, September 2016, <https://www.w3.org/TR/2016/
               CR-css-values-3-20160929>.

I would rename this to "CSSVAL" (or something like that) for 
readability.

    [W3C.REC-html5-20141028]
               Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
               Navara, E., O&#039;Connor, T., and S. Pfeiffer, "HTML5",
               World Wide Web Consortium Recommendation REC-
               html5-20141028, October 2014,
               <http://www.w3.org/TR/2014/REC-html5-20141028>.

I would rename this to "HTML5" (or something like that) for readability. 

7.2.  Informative References

    [I-D.ietf-httpbis-key]
               Fielding, R. and M. Nottingham, "The Key HTTP Response
               Header Field", draft-ietf-httpbis-key-01 (work in
               progress), March 2016.

I would rename this to "KEY" (or something like that) for readability. 

    [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
               DOI 10.17487/RFC6265, April 2011,
               <http://www.rfc-editor.org/info/rfc6265>.

Finally: no Acknowledgements?