Ugh... let's try to avoid even mentioning RSS3.
According to the RSS 2.0 spec, the ttl specifies a "a number of minutes
that indicates how long a channel can be cached before refreshing from
the source." What the spec does not indicate is the number of minutes
from when? The moment the feed was last pulled? The moment specified by
pubDate? Further, the ttl element is specifically designed for cache
control and provide no semantics over when the metadata content of the
item expires -- only over when a the RSS feed should be polled again.
In contrast, the Expires extension is explicitly NOT for cache-control
and MUST NOT be used for scheduling when the feed should be polled
again; it's sole purpose is to define expiration semantics for metadata
content. The max-age element provides the same basic function as ttl
only at a finer grain (miliseconds vs. seconds/minutes/etc) and with
less ambiguity (e.g. it is calculated from the moment specified in
atom:updated).
- James
Elias Torres wrote:
I tried commenting on your site, but I have to register to comment. :-(
You linked to RSS3 [1] and I spotted something related to this
extension that could be used instead.
<ttl span="days">7</ttl>
It seems more elegant than having to convert to whatever you specified
in your spec.
Just a thought.
Elias
[1] http://www.rss3.org/rss3lite.html
On 8/17/05, James M Snell <[EMAIL PROTECTED]> wrote:
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-00.txt
Example:
<entry>
...
<t:expires xmlns:t="...">2005-08-16T12:00:00Z</t:expires>
...
</entry>
or
<entry>
...
<updated>2005-08-16T12:00:00Z</updated>
<t:max-age>20000</t:max-age>
...
</entry>
This is not to be used for caching of Atom documents; nor is it to be
used as a mechanism for scheduling updates of local copies of Atom
documents.
- James
