There are a couple of problems with that:
1. The specs serve two completely different purposes (feed history is
not the same as meta expiration)
2. I don't control the feed history proposal
- James
Henry Story wrote:
Would it be possible to merge, or at least have the history extension
[1] use the same
name space as your extension, so that the the history's incremental
and archive tags
can have the same namespace, and the history fh:prev can be
transformed to a link object, thereby:
- reducing the number of namespaces used by an atom feed
- allowing the <link ...> construct to be used by the feed
history proposal
?
Henry Story
[1] http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
history-04.txt
On 26 Sep 2005, at 17:32, James M Snell wrote:
Over the past couple of weeks I've been working on a number of
proposed Atom extensions that I am moving forward with as standards-
track RFC's through individual submission.
I believe that the Expiration extension -- http://www.ietf.org/
internet-drafts/draft-snell-atompub-feed-expires-04.txt -- is
complete and ready for an unofficial last call. Before I submit
this to Scott Hollenbeck asking for it t become a standards-track
RFC, I would like to invite the members of the WG to comment |
praise | complain | improve | all-of-the-above. In >= 2 weeks I'll
make any appropriate changes and submit the draft to Scott.
Summary: introduces a mechanism for specifying a date-time or
maximum age for the informational content of a feed or entry
Example:
<feed>
...
<age:expires>2005-12-12T12:00:00Z</age:expires>
<entry>
...
<updated>2005-11-11T12:00:00Z</updated>
<age:max-age>20000</age:max-age>
</entry>
</feed>
The metadata in the feed element expires at noon on Dec , 12 2005,
The metadata in the entry element expires 20000 miliseconds after
noon on Nov, 11, 2005.
- James
