I don't think we should be as explicit as Wendy suggests because we're re-specifying HTTP semantics (e.g what if the response contains Cache-Control: max-age less than the Expires header, etc).
However, it may be worth having a statement around expected polling frequency. E.g. That Atom spec utilises HTTP caching by layering on HTTP but doesn't contain any mechanism to explicitly state a desired polling frequency and contains no statement recommending how to handle signalling such desire. There are many questions on stackiverflow and the like asking how cliebts should behave. Best current practice is to only to poll as often as you would revalidate the content (i.e. no more frequently than the instant the content becomes stale according to RFC2616). We could advise something similar explicitly. There would be nothing to stop client polling more often if they needed but one would expect a server to apply an appropriate caching lifetime to it's responses according to how frequently it thinks they may change. Thoughts? Ben On 15 May 2013, at 17:47, Richard Alimi <[email protected]> wrote: > > > On Wed, May 15, 2013 at 6:55 AM, Wendy Roome <[email protected]> > wrote: >> I don't think we've addressed the issue of how frequently a client should >> refresh cached data, such as the IRD, the network map, or the cost map. >> >> How about saying something like, >> >> "The ALTO Server SHOULD send an HTTP Expires header [RFC2616] in the >> response, as well as a Date header, to indicate the expected lifetime of >> the information. The client SHOULD refresh the data sometime after that. >> Note that the Expires date is a guideline, not a contract; the ALTO server >> may change the data at any time." >> >> I guess that should go in Section 8, but I'm not sure which subsection. > > We used to have statements like this (guiding how to use HTTP), except we > received feedback that its better to just leave this out of the ALTO spec. > > Rich > >> >> - Wendy Roome >> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
