To answer my own question
[[
Interesting... but why have a limit of one year? For archives, I
would like a limit of
forever.
]]
I found the following in the HTTP spec
[[
To mark a response as "never expires," an origin server sends an
Expires date approximately one year from the time the response is
sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future.
]]
(though that still does not explain why.)
Now I am wondering if the http mechanism is perhaps all that is needed
for what I want with the unchanging archives. If it is then perhaps this
could be explained in the Feed History RFC. Or are there other
reasons to
add and "expires" tag to the document itself?
Henry Story
On 9 Aug 2005, at 19:09, James M Snell wrote:
rules as atom:author elements.
Here it is: <http://www.intertwingly.net/wiki/pie/PaceCaching>
The expires and max-age elements look fine. I hesitate at bringing
in a caching discussion. I'm much more comfortable leaving the
definition of caching rules to the protocol level (HTTP) rather
than the format extension level. Namely, I don't want to have to
go into defining rules for how HTTP headers that affect caching
interact with the expires and max-age elements... IMHO, there is
simply no value in that.
The expires and max-age extension elements affect the feed / entry
on the application level not the document level. HTTP caching
works on the document level.
Adding max-age also means defining IntegerConstruct and disallowing
white space around it. Formerly, it was OK as a text construct, but
the white space issues change that.
This is easy enough.
Also, we should decide whether cache information is part of the
signature.
I can see arguments either way.
-1. let's let caching be handled by the transport layer.
