Re: Working Group Last Call: draft-ietf-httpbis-client-hints-04
Julian Reschke <julian.reschke@gmx.de> Mon, 15 May 2017 14:34 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27364129439 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 May 2017 07:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW-yhfo6BCHs for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 May 2017 07:34:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA2612943E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 15 May 2017 07:30:13 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1dAGxC-0008Em-3y for ietf-http-wg-dist@listhub.w3.org; Mon, 15 May 2017 14:26:30 +0000
Resent-Date: Mon, 15 May 2017 14:26:30 +0000
Resent-Message-Id: <E1dAGxC-0008Em-3y@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <julian.reschke@gmx.de>) id 1dAGx7-0008Bp-Uj for ietf-http-wg@listhub.w3.org; Mon, 15 May 2017 14:26:25 +0000
Received: from mout.gmx.net ([212.227.17.21]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <julian.reschke@gmx.de>) id 1dAGx0-0006fd-N9 for ietf-http-wg@w3.org; Mon, 15 May 2017 14:26:20 +0000
Received: from [192.168.1.102] ([93.217.103.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Maa3B-1dPSPQ26Y5-00K9Wk; Mon, 15 May 2017 16:25:46 +0200
To: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
References: <149258118288.29028.3385696893945926244@ietfa.amsl.com> <D9E568D2-D84E-464F-A619-C2F92DD49B08@mnot.net>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Ilya Grigorik <igrigorik@google.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <624e3e87-43bc-0dc2-d38c-2d69cbb9e93b@gmx.de>
Date: Mon, 15 May 2017 12:33:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <D9E568D2-D84E-464F-A619-C2F92DD49B08@mnot.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:ytdYrqgEDPZqDtJZ7qJn7MHxvWOR1ctEDEIwFEExiIKYlwwtC1I Zmaw9hBR9X/GL4Jf2dr1CxU0nkGv62gbkCSQMSK9hri2Y8DqjOSah8Q42XNIySDzvNdpM6y cRSMAB9d2pD+SNPXdUrninSb+d1zenQ/+TQXfWVkUczytDd1k524p5Rh7gGY5gGziBJ6jk4 7O5Mi59UBOEVYSbLn9qOQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:8RC4qXPhx7k=:ZpzuZxbahSjPt3YN4gaSJl odyJ7YcB+daVhuOUBeff14r1wg8+Qqas+jgVFIXAed6webM4JahRgIeXadj3XiYEq02dv1TRb 5Uc4rOaqdSh0RSGmX7Yu3ogj78P9OwjgFTrblWzqB/dBitJvu5VvAhKDlNpoQGJ6k/VgMmxxG 2ObX1U+B7fGnLcqInR5HqYbty5vh0YMKbeBU90D4fPojuMQW1TWhOvp3Dxn3KoOsUR7KtgD1c TVSHlzzAk55KxTDoiQJa43zJ+7WEJLWp+Jsq9E7DvMW1KKbBRhdI2fQgxd3hJTek1NsjsN/IN RHXtfLzpgStqQ98+5xDqAwUkfPLkb8zQRUr+9hKjU/2pvq4K60AA79+HoL7zh8cYIZGXEhtDz zuec4Ixtp5p8GK4YsHiLU/rPqiLJJVL0MzWAvNXlqc4Iekz8i1QpxJVvMwtKBxJz0V6Rf3AqB 6SPJRc2l3gp2TaPLnzh8bg/5vLkW6CiP0CVA55N9VURglLM2CC9Obet3pNscCti0n5vFfJ8yc Vxy0Swh7wlZ+0VvsZOB64gRGpXCvJn78Dk4MJMcigb8gwzDOzSv8HyQz0mdFjGn0gVervldA0 iOOQIEf+WX7IW7THTdu0cZ+5ggFZJkFruFEzdTviK7hR/kq29m8rEkGJHJtrdZ7Pfo8z4Z8nr MxS/F1L/4C2OQEURVf6ekHQExXYAHQnkX9gyt6WUBd3r7zoHX5gRUAp30Al/j5sXKblG7XLo1 s96cBjdlfW7DkWnMPODJ03JobmPr7qSCouNDgBWqUlu4FbJ8va8KaN7feqqgEb0gyl2hQhFZO Gx0wiUB
Received-SPF: pass client-ip=212.227.17.21; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-7.2
X-W3C-Hub-Spam-Report: AWL=0.630, BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1dAGx0-0006fd-N9 d2970f21b4768497b69ba920b777f95c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Working Group Last Call: draft-ietf-httpbis-client-hints-04
Archived-At: <http://www.w3.org/mid/624e3e87-43bc-0dc2-d38c-2d69cbb9e93b@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33928
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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'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?
- I-D Action: draft-ietf-httpbis-client-hints-04.txt internet-drafts
- Working Group Last Call: draft-ietf-httpbis-clien… Mark Nottingham
- draft-ietf-httpbis-client-hints-04; 2.2.2. The Ac… Kari Hurtta
- Re: draft-ietf-httpbis-client-hints-04; 2.2.2. Th… Mark Nottingham
- Re: draft-ietf-httpbis-client-hints-04; 2.2.2. Th… Ilya Grigorik
- Re: Working Group Last Call: draft-ietf-httpbis-c… Julian Reschke