This is fairly quick and off-the-cuff, but here's an initial draft to
get the ball rolling..
http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt
- James
Henry Story wrote:
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.
