+1, I'd also highly recommend introducing an "archive" link relation that can be used to cleanly separate paged feed documents used for state reconstruction from paged feed documents used for other purposes (e.g. searching)
=== Attribute Value: archive Description: A URI that, when dereferenced, returns a feed document containing a fixed set of entries that does not change over time. Expected display characteristics: The archive relation may be used for background processing without displaying its value, or, a user agent may support displaying a hyperlink, button or other GUI element for accessing or subscribing to the linked feed document. Security Considerations: Automated agents should take care when this relation crossed administrative domains (e.g. the URI has a different authority than the current document) === Example; <link rel="archive" href="http://example.org/archive?when=2006/04"; /> - James David Powell wrote: > > Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote: > >> If you use URIs like >> http://example.com/feed?start=5&num=10 >> changing the directionality of "next" and "previous" will not make >> what you're doing compatible with feed history. > >> Such URIs have a much more fundamental problem -- they don't refer to >> a stable set of entries, and therefore only act as a snapshot of the >> *current* feed, chopped up into chunks. If the feed changes between >> accesses, the client will be in an inconsistent state. The client >> also has to walk through all of the pages every time it fetches the >> feed; it can't cache them -- which is a primary requirement for feed >> history. > > I think it would be worth recommending the use of stable URIs in the > draft. > >
