Re: Feed History -02

[Henry Story <henry.story@xxxxxxxxxxx>]

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.