Feed Paging and Archiving
Extracted elements (23)
Archived feeds achieve lossless reconstruction by separating a single mutable subscription document (newest entries) from immutable archive documents, allowing clients to catch up by traversing prev-archive links recursively.
If a publisher needs a change visible to all users (e.g., factual corrections), they should publish the revised entry in the subscription document because archive document stability means some clients may never re-fetch updated archives.
Three distinct feed types are defined because each has different trade-offs: complete feeds are useful when old entries should be discarded; paged feeds suit large/infinite/unstable entry sets needing piecemeal access; archived feeds suit long-lived entries where clients must see every one without loss.
Although the feed extensions (fh:complete, fh:archive, link relations) are described in terms of Atom, they can also be used with RSS 2.0 by importing the fh namespace and using Atom link elements. In RSS 2.0, duplicate detection uses the guid element instead of atom:id.
Any entry not actually in a complete feed document SHOULD NOT be considered part of that feed.
Archive documents SHOULD also have a 'next-archive' link relation unless there are no following archives available, and SHOULD indicate their subscription document via the 'current' link relation.
Clients SHOULD NOT present paged feeds as coherent or complete, or make assumptions to that effect, because paged feeds are lossy and entries may be added or changed while pages are being accessed.
Clients SHOULD warn users when they are not able to reconstruct the entire logical feed, such as when an archive document is unavailable.
Paged feed documents MUST have at least one of the 'first', 'last', 'previous', or 'next' link relations present.
Publishers SHOULD construct feed documents to make duplicate removal unambiguous.
Subscription and archive documents MUST have a 'prev-archive' link relation unless there are no preceding archives available.
The set of entries in an archive document published at a particular URI SHOULD NOT change over time, and the URI for a particular archive document SHOULD NOT change over time.
When consuming archived feeds, if duplicate entries are found, clients SHOULD consider only the most recently updated entry to be part of the logical feed. If duplicates have the same update timestamp, the entry from the most recently updated feed document SHOULD replace others.
A subscription document always contains the most recently added or changed entries. Archive documents contain less recent entries; their contents at a given URI SHOULD NOT change over time.
Archived feeds use three link relations: 'prev-archive' (immediately preceding archive document), 'next-archive' (immediately following archive document), and 'current' (the subscription document with most recent entries).
In Atom-formatted archived feeds, two entries are duplicates if they have the same atom:id element. Update time is determined by atom:updated for entries and feed-level atom:updated for documents.
Paged feeds use four link relations to tie feed documents together: 'first' (furthest preceding), 'last' (furthest following), 'previous' (immediately preceding), and 'next' (immediately following document in the series).
The fh:archive element is an empty element placed in an archive document's head section to indicate that it is an archive, using the namespace 'http://purl.org/syndication/history/1.0'.
The fh:complete element, when present in a feed's head section, indicates that the feed document is a complete representation of the logical feed's entries. It is an empty element using the namespace 'http://purl.org/syndication/history/1.0'.
This specification adds 'prev-archive' and 'next-archive' to the IANA Link Relations registry. It also requests that 'previous', 'next', and 'current' be updated to reference this document.
Feeds using these mechanisms could be crafted to cause a client to initiate excessive or unending network requests, causing denial of service to the client, target server, or intervening networks. Clients should mitigate by requiring user intervention or limiting requests; servers by denying abusive requests.
Feeds using this mechanism have the same security considerations as Atom. Encryption and authentication can be obtained by signing/encrypting the feed, through channel mechanisms (TLS, HTTP authentication), or transport (IPsec).
This specification does not define what it means when a logical feed's component feed documents have different security mechanisms applied.