Re: Rewrite of 13.12 (Cache keys)

Roy T. Fielding:
>
>The entire section 3.12 is wrong, and overspecification anyway, so
>just delete it. 

I agree, delete it.

It is an overspecification, and an overspecification of a wrong
mechanism at that.  Though I was able to more or less fix 13.12.2 and
13.12.3, I think 13.12.1 and 13.12.4 are beyond fixing. I noted
earlier about 13.12.1:

|     QUESTION: does the text below, or does it not, take both 200 and
|     304 responses into account?  If so, how?  Is this in a part of
|     Section 13 I have not read yet?

I read the rest of section 13, and the 200/304 problem is not fixed
there.  The problem, by the way, is that the 13.12 text fails to
address the subtleties of 304 responses updating the headers in cached
200 responses.

I now conclude that 13.12 is beyond salvation, even after selecting
opaque validators are removed.

[Note for Roy: in yesterdays phone conference we decided to require
quoted-string variant-IDs everywhere and to remove selecting opaque
validators]

If 13.12 is removed, this leaves us with the Vary section, which
describes cache lookups, and Section 13.20, which describes cache
replacement.  I mail will simplified text for 13.20 tomorrow (this
section can be simplified because variant-IDs are always required).

I agree with Roy that the spec does not need to talk about entry keys
at all: entry keys are an implementation mechanism invisible from a
protocol user viewpoint. 

> Define the interface, not how its implemented!
>
>Why it is wrong:

[Good explanation of why it is wrong deleted]

>  If the new entity has a 
>content-location, the cache must mark as stale all other Request-URI
>entries which refer to that content-location, but it is not a 
>cache key (it is an entity key, internal to the cache DB operation).

Is this requirement for marking as stale stated somewhere in the spec?
I believe it is not.  I suggest it is added in a rewrite of section
10.16 (Content-Location).  I will try to post such a rewrite tomorrow.

Koen.

Received on Saturday, 27 April 1996 16:00:36 UTC