Re: why no-cache is not reload

I very much appreciate the time Roy and Jeff have taken to lay out the
various caching scenarios and to match them to the current syntax.  I
found Jeff's summary, in particular, very helpful.  

I also believe that the spec needs to do as good a job as that summary
does in making clear what the various options are and how to achieve
them.  Section 13 of the current spec is a placeholder, and would be
the logical place for such a summary; I encourage plagiarism of Jeff's
grids for that section.

I don't have anything personally wrapped up in what terminology gets
used for each of these, but I will say that I find Jeff's terminology
easier to follow and less liable to misinterpretation.  I also tend to
agree with his <SOAPBOX> section below.  In fact, based on his soapbox
section, I would a (c) to the section on syntax in his consensus
statement:

	(c)Likelihood of mis-implementation based on a failure
to distinguish between behaviors which vary based on which party
to a transaction use a particular syntax.

				regards,
					Ted


Jeff writes:
> After watching this discussion go by, I'd like to agree with Roy
> that (1) the Cache-control directives in his HTTP/1.1 draft
> will work, and (2) they are obviously confusing, because
> a lot of people (myself included) were confused for a long time.
> 
> The question of what names should be used is definitely a secondary
> one, but since lots of people do NOT find the currently-used names
> "meaningful" (in that they unambiguously convey the intended use
> and semantics), if we don't change the names then we must certainly
> improve the specification.  The purpose of an IETF-blessed spec
> is to allow independent implementation of interoperable systems,
> so if an aspect of the spec has been widely misconstrued, it has
> to be fixed.
> 
> Let me see what we have consensus on, and where we are still
> disagreeing.
> 
> I will begin WITHOUT reference to specific syntax, because
> if we cannot agree on the semantics then there's no point
> in debating syntax.
> 
> (1) Semantics: the HTTP protocol needs to support these cases
> in request messages:
> 
> 	(A) I want a firsthand response from the origin server.
> 
> 	(B) I want a response that has been validated with the
> 	origin server after I made this request.
> 
> 	(C) I want to validate my own cached response with
> 	the origin server.
> 	
> 	(D) I want to validate my own cached response, but I'll
> 	accept a non-authoritative answer (i.e., from a cache
> 	that has a still-fresh copy with a matching validator)
> 	
> 	(E) I want a fresh response.
> 
> Note that I've arranged these in roughly decreasing order of "paranoia".
> 
> (2) Terminology: since we seem to spend a lot of time arguing
> about things when we are really just using different definitions
> for terms, let me propose a set of terms that we can use for these
> five cases.
> 
> 	A = Reload
> 	B = Revalidate
> 	C = Specific revalidate
> 	D = Conditional method
> 	E = Normal method
> 
> If someone would like to propose a better set of terms, please do
> so.  Please don't just complain without proposing something else.
> 
> (3) Syntax: if I understand Roy's spec correctly, this is what
> he has proposed:
> 
> 	A = Reload
> 	    GET /home.html HTTP/1.1
> 	    Cache-control: no-cache
> 
> 	B = Revalidate
> 	    GET /home.html HTTP/1.1
> 	    Cache-control: max-age=0
> 
> 	C = Specific revalidate
> 	    GET /home.html HTTP/1.1
> 	    If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
> 	    Cache-control: no-cache
> 
> 	D = Conditional method
> 	    GET /home.html HTTP/1.1
> 	    If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
> 
> 	E = Normal method
> 	    GET /home.html HTTP/1.1
> 
> Of course, "If-Invalid:" would be used if the server has sent an opaque
> validator.
> 
> This is what my proposal was:
> 	A = Reload
> 	    GET /home.html HTTP/1.1
> 	    Cache-control: reload
> 
> 	B = Revalidate
> 	    GET /home.html HTTP/1.1
> 	    Cache-control: revalidate
> 
> 	C = Specific revalidate
> 	    GET /home.html HTTP/1.1
> 	    If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
> 	    Cache-control: revalidate
> 
> 	D = Conditional method
> 	    GET /home.html HTTP/1.1
> 	    If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
> 
> 	E = Normal method
> 	    GET /home.html HTTP/1.1
> 
> <SOAPBOX>
> I'll state for the record that, while I don't think it makes a
> big difference, I think it is unnecessarily confusing and absolutely
> without pragmatic value to use the same tokens (e.g., no-cache
> or max-age) on both request and response, especially when their
> meanings are significantly different depending on the direction.
> 
> While it is true that the current practice with "Pragma: no-cache"
> does make this error, I do not think that this makes it any more
> attractive to compound the error in a brand-new header ("Cache-control:").
> </SOAPBOX>
> 
> Summary of consensus status:
> (1) I believe we have consensus on the underlying semantics for
> this aspect of the protocol.
> 
> (2) We need commonly-held terminology to discuss things, and unless
> someone suggests something better soon, I'll assume we are agreed
> on my proposed terms.
> 
> (3) The debate over syntax, as far as I can, is entirely concerned
> with
> 	(a) different views of what is "meaningful" (or how
> 	meaningful a token name needs to be anyway).
> 
> 	(b) different views of whether the existing syntax of
> 	Pragma: should be carried forward to Cache-control:
> 
> If anyone has a disagreement about this summary of our debate,
> please speak up immediately.  Larry Masinter has asked me to
> prepare a list of items and how we stand on them, and I need
> to do this in the next 48 hours.
> 
> -Jeff
>

Received on Tuesday, 20 February 1996 19:47:07 UTC