Re: Working Group Last Call: draft-ietf-httpbis-client-hints-04

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.


2.2.2.  The Accept-CH-Lifetime header field

    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?

Received on Monday, 15 May 2017 14:26:26 UTC