--On August 9, 2005 9:28:52 AM -0700 James M Snell <jasnell@xxxxxxxxx> wrote: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.
rules as atom:author elements.I missed these proposals. I've been giving some thought to an <expires /> and <max-age /> extension myself and was getting ready to write up a draft. Expires is a simple date construct specifying the exact moment (inclusive) that the entry/feed expires. Max-age is a non negative integer specifying the number of miliseconds (inclusive) from the moment specified by atom:updated when then entry/feed expires. The two cannot appear together within a single entry/feed and follows the same basicI made some proposals for cache control info (expires and max-age). That might work for this.
Here it is: <http://www.intertwingly.net/wiki/pie/PaceCaching>
This is easy enough.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.
-1. let's let caching be handled by the transport layer.Also, we should decide whether cache information is part of the signature. I can see arguments either way.