Re: Editorial notes on p6

Mark Nottingham <mnot@mnot.net> Mon, 29 April 2013 05:15 UTC

Return-Path: <ietf-http-wg-request@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 4DA5A21F9C7F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 28 Apr 2013 22:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxcEPquxUh1B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 28 Apr 2013 22:15:15 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 60BAB21F9CEB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 28 Apr 2013 22:15:11 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWgPI-0007iq-0y for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 05:13:44 +0000
Resent-Date: Mon, 29 Apr 2013 05:13:44 +0000
Resent-Message-Id: <E1UWgPI-0007iq-0y@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UWgP9-0007hk-GY for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 05:13:35 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UWgP8-000521-Ic for ietf-http-wg@w3.org; Mon, 29 Apr 2013 05:13:35 +0000
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4D4C0509B6 for <ietf-http-wg@w3.org>; Mon, 29 Apr 2013 01:13:11 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <AE841BC7-F5EF-405A-AA61-EC0ACD3CD10F@mnot.net>
Date: Mon, 29 Apr 2013 15:13:08 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE85312B-6955-496F-A02C-4B9E18419062@mnot.net>
References: <AE841BC7-F5EF-405A-AA61-EC0ACD3CD10F@mnot.net>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.439, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UWgP8-000521-Ic e047710ef7986e37cbe1f6c5543a1a39
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Editorial notes on p6
Archived-At: <http://www.w3.org/mid/BE85312B-6955-496F-A02C-4B9E18419062@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17651
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>

* 4.1.1 says "When there is more than one value present for a given directive (e.g., two Expires header fields, multiple Cache-Control: max-age directives), it is considered invalid. Caches are encouraged to consider responses that have invalid freshness information to be stale."

This should be moved to or repeated in the various subsections that define those directives, rather than hidden only here.

* 4.2 "... from all responses stored fort he requested URI, if present."  "requested URI" needs to be "primary cache key."

* 4.3 A better section title would be "Calculating Secondary Keys with Vary". Also, this section should probably be higher up, e.g., 4.1.

* 7.2.3 "Whether the directive is specific to requests, responses, or used in both" should be added to the list of considerations for cache control extensions.

* I think that both 
  4.2.1 Freshening Responses with 304 Not Modified
and
  4.4 Combining Partial Content
would sit better as subsections of 
  3.   Storing Responses in Caches
... because they're about how an incoming response affects the cache, not how to satisfy a request from it. 


On 29/04/2013, at 11:49 AM, Mark Nottingham <mnot@mnot.net> wrote:

> [ Yes, I'm talking to myself here... if anyone has a problem with the proposed edits below, please say so; if I don't hear otherwise, I'll incorporate ]
> 
> * 1.1 Purpose doesn't need to be separate from 1 Introduction; suggest combining them into Introduction.
> 
> * 1.1 "message storage, retrieval, and deletion" --> "storage, retrieval, and deletion of messages"
> 
> * 1.1 "A fresh cache response" --> "A fresh response"
> 
> * 1.1 s/transfers/overhead/
> 
> * 1.1 last sentence needs a reference to "serving stale responses"
> 
> * 1.2 p6 is the only part with a separate 'terminology' section; the definitions should be distributed to first use, like the other parts.
> 
> * 1.2 "private cache" is defined as being "dedicated to a single user."  I suspect this should be "... single user agent" to be in keeping with our separation from user concerns.
> 
> * 1.2 "The age of a response is the time since it was sent..." --> "The time since a response was sent..."
> 
> * 1.2 Move the parenthetical "(either explicit or heuristic)" from the definition of "stale" to "freshness lifetime"
> 
> * 1.2 The definition of "strong validator" is too detailed; it should (mostly) rely on the definition in p4.
> 
> * 2. s/locally-desired/local/
> 
> * 2. "Therefore, HTTP cache requirements are focused on preventing..." needs something like this appended to the sentence: "...rather than mandating that caches always store and reuse particular responses."
> 
> * 2. "The default cache key consists of..." --> "The primary cache key consists of..."
> 
> * 2. "...use only the URI as the key." --> "Use only the URI as the primary cache key."
> 
> * 3. bullet point "contains a s-maxage response cache directive..." needs a reference.
> 
> * 3. "...and implements any cache-specific behavior." --> "...and implements all specified caching-related behavior."
> 
> * 3. "...many caches will not store a response..."  s/many/some
> 
> * 4. "For a presented request, a cache MUST NOT use a stored response, unless:"  --> "When presented with a request, a cache MUST NOT reuse a stored response, unless:"
> 
> * 4. "...a cache MUST send a single Age header field..." --> "...a cache MUST generate an Age header field, replacing any present..."
> 
> * 4. "...also forward a request with..." --> "...also forward the request with..."
> 
> * 4. "...revalidating them on every use."  s/on/upon/
> 
> * 4.1 Title "Freshness Model" should just be "Freshness"
> 
> * 4.1 "The freshness_lifetime is defined in Section 4.1.1; the current_age is..."  s/the//
> 
> * 4.1 "...it is considered invalid."  --> "...that directive's value is considered invalid."
> 
> * 4.1.2 "Therefore, servers are encouraged to send explicit directives..." --> "Therefore, origin servers are encouraged to generate explicit directives..."
> 
> * 4.1.3 The text at the end regarding problems in date parsing is not specific to calculating age; it needs to be moved up to the next highest level (freshness), possibly in a new subsection.
> 
> * 4.1.4 Para "If a cache receives..." should be prefixed with "Note that..."
> 
> * 4.2 Title "Validation Model" should just be "Validation"
> 
> * 4.2 "When sending such a conditional request..."  This and the following paragraph are awkward.
> 
> * 4.2 "...whose value is that of the ETag header field(s) from all responses stored..."  s/all/relevant/
> 
> * 4.2.1 "...identifies the selected representation."  append "for update" (3 occurrences) 
> 
> * 4.4 This section should either be incorporated into 3.3, or made a subsection of it.
> 
> * 6 "For example, the request that caused the change at the origin server might not have gone through the cache where a response is stored."  --> "For example, a state-changing request might invalidate responses in the caches it travels through, but responses still might be stored in other caches that is has not."
> 
> * 7.2 "Note: HTTP/1.0 caches might not implement Cache-Control, and might only implement Pragma: no-cache." --> "Note: some HTTP/1.0 caches might not implement Cache-Control."
> 
> * 7.2.1 Request Cache-Control directives should be alphabetically ordered.
> 
> * 7.2.1.4 "expiration time" --> "freshness lifetime" (two instances)
> 
> * 7.2.2 Response Cache-Control directives should be alphabetically ordered.
> 
> * 7.2.2.2 s/standard//  (two instances)
> 
> * 7.2.2.2 "Many HTTP/1.0 caches will not recognize or obey this directive."  --> "Although it has been back-ported to many implementations, some HTTP/1.0 caches will not..."
> 
> * 7.2.3 Split into multiple paragraphs.
> 
> 
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

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