Subject: p6-caching: commentary from -05 to -06

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Mar 2009 16:02:27 -0700

I compiled this list of notes on the major differences, from the  
perspective of -05, to help reviewers. Apologies for sending it out  
late; I've been sick for a few days.

1. Introduction
Shortened.

1.1. Purpose
"expiration mechanism" -> "freshness mechanism"
Small editorial changes (e.g., getting rid of "we")
Removed concept of "semantic transparency"

1.2 Terminology
Changed definition of "first-hand"
Slight disambiguation of "stale"
Added definition of "shared cache"

1.3 Requirements
No change.

2. Notational Conventions and Generic Grammar
Changed to 1.4 Syntax Notation and subsections.

3. Overview
Changed to "Cache Operation"
Substantially restructured into 2.1 Response Cacheability and 2.2  
Constructing Responses from Caches.

3.1 Cache Correctness
Removed concept of "cache correctness"
Moved requirement related to most recent response to 2.2 Constructing  
Responses from Caches.
Move requirement related to in-transit stale responses to 2.3.3  
Serving Stale Responses.

3.2 Warnings
Most Warning-related text moved to Warning header definition
Downgraded most requirements for sending and displaying Warning to  
SHOULD

3.3 Cache-control Mechanisms
Removed.

3.4 Explicit User Agent Warnings
Mostly removed; requirement to display downgraded to a SHOULD; see  
Warning header definition.

3.5 Exceptions to the Rules and Warnings
Moved to 2.3.3 Serving Stale Responses. Requirements here in conflict  
with those elsewhere.

3.6 Client-Controlled Behaviour
Moved to 2.3 Freshness Model; still in progress.

4. Expiration Model
Changed to "freshness model"

4.1. Server-Specified Expiration
Moved into 4. Expiration Model; substantially reworked.

4.2 Heuristic Expiration
Moved to 2.3.1.1 Calculating Heuristic Expiration

4.3 Age Calculations
Substantially shorted (probably can be more); now 2.3.2 Calculating Age.

4.4 Expiration Calculations
Moved to 2.3.1 Calculating Freshness Lifetime
Algorithm re-specified

4.5 Disambiguating Expiration Values
Subsumed by other requirement to always use most recent response; see  
2.2 Constructing Responses from Cache

4.6 Disambiguation Multiple Responses
Subsumed by other requirement to always use most recent response; see  
2.2 Constructing Responses from Cache

5. Validation Model
See 2.4 Validation Model.
Rewritten for clarity.

6. Response Cacheability
See 2.1 Response Cacheability

7. Constructing Responses from Caches
See below.

7.1 End-to-End and Hop-by-Hop Headers
Removed, as it's specific to proxies, not caches. TODO for p1.

7.2 Non-Modifiable Headers
Removed, as it's specific to proxies, not caches. TODO for p1.

7.3 Combining Headers
See 2.7 Combining Responses.
Scope slightly broadened to include non-conditional 206 responses.

8. Caching Negotiated Responses
See 2.6 Caching Negotiated Responses.

9. Shared and Non-Shared Caches
Moved to 1.2 Terminology

10. Errors or Incomplete Responses Cache Behaviour
Split into 2.1.1 Storing Partial and Incomplete Responses, and 2.4  
Validation Model

11. Side Effects of GET and HEAD
Removed and now in p2-semantics.

12. Invalidations after Updates or Deletions
See 2.5 Request Methods that Invalidate

13. Write-Through Mandatory
See 2.2 Constructing Responses from Cache
Changed from GET and HEAD to unsafe methods.

14. Cache Replacement
Subsumed by requirement to use most recent response; see 2.2  
Constructing Responses from Cache
15. History Lists
See 4. History Lists

16. Header Field Definitions

16.1 Age
Minor edits and shuffling from the age calculations section.

16.2 Cache-Control (and subsections to 16.2.5)
Flattened organisation to request and response directives.
Rewrite directives for clarity.

16.2.6 Cache Control Extensions
No substantive changes.

16.3 Expires
Cut down duplication with the freshness model section.

16.4 Pragma
Removed redundant requirements.
Deprecated Pragma.

16.5 Vary
Minor rewrite to reduce duplication.

16.6 Warning
Major rewrite to reduce duplication.
Reduced most requirements to SHOULD.

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

---

From: Yves Lafon <[email-masked]>
Date: Wed, 25 Mar 2009 05:01:42 -0400 (EDT)

On Thu, 12 Mar 2009, Mark Nottingham wrote:

> Downgraded most requirements for sending and displaying Warning to SHOULD

It is good to keep some of them as MUST,
214 Transformation Applied is still a MUST which is a good thing.
However 110 Response is stale should be back to MUST instead of SHOULD, 
otherwise the client doesn't have a way to differentiate the response. 
(but I know that IRL it's almost never done).
One thing would be to require a MUST only when the expiration time is 
_not_ an heuristic one (as in this case, the staleness property is already 
heuristic).

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Mar 2009 16:56:56 +1100

On 25/03/2009, at 8:01 PM, Yves Lafon wrote:

> However 110 Response is stale should be back to MUST instead of  
> SHOULD, otherwise the client doesn't have a way to differentiate the  
> response. (but I know that IRL it's almost never done).

If the response is stale, shouldn't that be detectable regardless by  
calculating its freshness lifetime and age independently?

Cheers,