W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: I-D Action: draft-ietf-httpbis-client-hints-12.txt

From: Ben Schwartz <bemasc@google.com>
Date: Wed, 11 Mar 2020 10:49:32 -0400
Message-ID: <CAHbrMsBr6e7qrAzsM-121_e7ny_e8ewBaJWr+2fuYy2gOz0R3g@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
One thought from an outside perspective on this draft:
>
>    Therefore, features relying on this document to define Client Hint
>    headers MUST NOT provide new information that is otherwise not
>    available to the application via other means, such as existing
>    request headers, HTML, CSS, or JavaScript.


I understand the goal of this paragraph, but surely we would also like to
reduce information exposure via those channels, in order to channel
information through the client-hints mechanism, where it can be audited and
limited?  Perhaps "MUST NOT provide information that is otherwise not
avaliable at the time of standardization" would be clearer, or a sentence
like "However, reducing information exposure through other means does not
require deprecating the corresponding Client-Hint if one has already been
defined.".

On Wed, Mar 11, 2020 at 5:28 AM <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the HTTP WG of the IETF.
>
>         Title           : HTTP Client Hints
>         Authors         : Ilya Grigorik
>                           Yoav Weiss
>         Filename        : draft-ietf-httpbis-client-hints-12.txt
>         Pages           : 12
>         Date            : 2020-03-11
>
> Abstract:
>    HTTP defines proactive content negotiation to allow servers to select
>    the appropriate response for a given request, based upon the user
>    agent's characteristics, as expressed in request headers.  In
>    practice, clients are often unwilling to send those request headers,
>    because it is not clear whether they will be used, and sending them
>    impacts both performance and privacy.
>
>    This document defines an Accept-CH response header that servers can
>    use to advertise their use of request headers for proactive content
>    negotiation, along with a set of guidelines for the creation of such
>    headers, colloquially known as "Client Hints."
>
>
> 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-12
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-client-hints-12
>
>
> 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/
>
>
>
>

Received on Wednesday, 11 March 2020 14:49:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 11 March 2020 14:50:00 UTC