Reload operations

Document how to achieve each of:

(reload) I want a firsthand response from the origin server.
(revalidate) I want a response that has been validated with the origin server after I made this request.
(specific revalidate) I want to validate my own cached response with the origin server.
(conditional method) 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)
(normal method) I want a fresh response.

Roy's draft:

	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

Proposal:

       	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

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:").

Roy,
	The text in 10.8 of draft-ietf-http-v11-spec-01.html seems
to indicate that no-cache from a client to a server always requests
an authoritative version:

"The 'no-cache' directive on a request message requires any cache to
forward the request toward the origin server even if it has a cached
copy of what is being requested.  This allows a client to insist upon
receiving an authoritative response to its request.  It also allows a
client to refresh a cached copy which is known to be corrupted or stale."

	If including an "If-Modified-Since" modifies that behavior to
mean that the client is request an authoritative copy only if the copy
on the server has been modified since some date, then we need to say
so in the text describing cache-control.  I don't really think it
should mean that, frankly; no-cache already over-rides the other
cache-control directives, and it makes sense to me for it to override
"If-Modified-Since".  

	This, of course, makes it effectively a "Reload" command when
sent from the client.  Using that term for the client-initiated
direction and "no-cache" for the server-initiated direction seems to
clarify a key difference between the behavior expected of the cache
when receiving this directive.  Would it break any existing
implementations to make that change?

	On a related note, does cache-control: max-age 0 also force
a reload (by asking for a copy of the resource that is no older than
0 seconds old?).