| draft-nottingham-atompub-feed-history-11.txt |  | draft-nottingham-atompub-feed-history-rfc.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
|  |  | Request for Comments: 5005 August 2007 |
| Intended status: Standards Track |  | Category: Standards Track |
| Expires: December 27, 2007 |  |  |
| Feed Paging and Archiving |  | Feed Paging and Archiving |
| draft-nottingham-atompub-feed-history-11 |  |  |
| Status of This Memo |  | Status of This Memo |
| By submitting this Internet-Draft, each author represents that any |  | This document specifies an Internet standards track protocol for the |
| applicable patent or other IPR claims of which he or she is aware |  | Internet community, and requests discussion and suggestions for |
| have been or will be disclosed, and any of which he or she becomes |  | improvements. Please refer to the current edition of the "Internet |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | Official Protocol Standards" (STD 1) for the standardization state |
|  |  | and status of this protocol. Distribution of this memo is unlimited. |
| Internet-Drafts are working documents of the Internet Engineering |  |  |
| Task Force (IETF), its areas, and its working groups. Note that |  |  |
| other groups may also distribute working documents as Internet- |  |  |
| Drafts. |  |  |
| Internet-Drafts are draft documents valid for a maximum of six months |  |  |
| and may be updated, replaced, or obsoleted by other documents at any |  |  |
| time. It is inappropriate to use Internet-Drafts as reference |  |  |
| material or to cite them other than as "work in progress." |  |  |
| The list of current Internet-Drafts can be accessed at |  |  |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  |  |
| The list of Internet-Draft Shadow Directories can be accessed at |  |  |
| http://www.ietf.org/shadow.html. |  |  |
| This Internet-Draft will expire on December 27, 2007. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2007). |
| Abstract |  | Abstract |
| This specification defines three types of syndicated Web feeds that |  | This specification defines three types of syndicated Web feeds that |
| enable publication of entries across one or more feed documents. |  | enable publication of entries across one or more feed documents. |
| This includes "paged" feeds for piecemeal access, "archived" feeds |  | This includes "paged" feeds for piecemeal access, "archived" feeds |
| skipping to change at page 3, line 7 |  | skipping to change at page 3, line 7 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 |
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 |  | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 |
| 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 |  | 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 |
| Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 |  | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 |
| Appendix B. Use in RSS 2.0 . . . . . . . . . . . . . . . . . . . 12 |  | Appendix B. Use in RSS 2.0 . . . . . . . . . . . . . . . . . . . 12 |
| 1. Introduction |  | 1. Introduction |
| Syndicated Web feeds (using such formats as Atom [1]) are often split |  | Syndicated Web feeds (using formats such as Atom [1]) are often split |
| up into multiple documents to save bandwidth, allow "sliding window" |  | into multiple documents to save bandwidth, allow "sliding window" |
| access, or for other purposes. |  | access, or for other purposes. |
| This specification formalizes two types of feeds that can span one or |  | This specification formalizes two types of feeds that can span one or |
| more feed documents; "paged" feeds and "archived" feeds. |  | more feed documents; "paged" feeds and "archived" feeds. |
| Additionally, it defines "complete" feeds to cover the case when a |  | Additionally, it defines "complete" feeds to cover the case when a |
| single feed document explicitly represents all of the feed's entries. |  | single feed document explicitly represents all of the feed's entries. |
| Each has different properties and trade-offs: |  | Each has different properties and trade-offs: |
| o Complete feeds contain the entire set of entries in one document, |  | o Complete feeds contain the entire set of entries in one document, |
| and can be useful when it isn't desirable to "remember" |  | and can be useful when it isn't desirable to "remember" |
| previously-seen entries. |  | previously-seen entries. |
| o Paged feeds split the entries among multiple temporary documents. |  | o Paged feeds split the entries among multiple temporary documents. |
| This can be useful when entries in the feed are not long-lived or |  | This can be useful when entries in the feed are not long-lived or |
| stable, and the client needs to access an arbitrary portion of |  | stable, and the client needs to access an arbitrary portion of |
| them, usually in close succession. |  | them, usually in close succession. |
| o Archived feeds split them among multiple permanent documents, and |  | o Archived feeds split the entries among multiple permanent |
| can be useful when entries are long-lived and it is important for |  | documents and can be useful when entries are long-lived, and it is |
| clients to see every one. |  | important for clients to see every one. |
| The semantics of a feed that combines these types is undefined by |  | The semantics of a feed that combines these types is undefined by |
| this specification. |  | this specification. |
| Although they refer to Atom normatively, the mechanisms described |  | Although they refer to Atom normatively, the mechanisms described |
| herein can be used with similar syndication formats; see Appendix B |  | herein can be used with similar syndication formats; see Appendix B |
| for one such use. |  | for one such use. |
| 1.1. Notational Conventions |  | 1.1. Notational Conventions |
| skipping to change at page 4, line 8 |  | skipping to change at page 4, line 8 |
| 1.2. Terminology |  | 1.2. Terminology |
| In this specification, "feed document" refers to an Atom Feed |  | In this specification, "feed document" refers to an Atom Feed |
| Document or similar syndication instance document. It may contain |  | Document or similar syndication instance document. It may contain |
| any number of entries, and may or may not be a complete |  | any number of entries, and may or may not be a complete |
| representation of the logical feed. |  | representation of the logical feed. |
| A "logical feed" is the complete set of entries associated with a |  | A "logical feed" is the complete set of entries associated with a |
| feed (as contrasted with a feed document, which may contain a subset |  | feed (as contrasted with a feed document, which may contain a subset |
| of them). |  | of entries). |
| "Head section" refers to a document's feed-wide metadata container; |  | "Head section" refers to a document's feed-wide metadata container; |
| e.g., the child elements of the atom:feed element in an Atom Feed |  | e.g., the child elements of the atom:feed element in an Atom Feed |
| Document. |  | Document. |
| This specification uses terms from the XML Infoset [4]. However, |  | This specification uses terms from the XML Infoset [4]. However, |
| this specification uses a shorthand; the phrase "Information Item" is |  | this specification uses a shorthand; the phrase "Information Item" is |
| omitted when naming Element Information Items. Therefore, when this |  | omitted when naming Element Information Items. Therefore, when this |
| specification uses the term "element," it is referring to an Element |  | specification uses the term "element," it is referring to an Element |
| Information Item in Infoset terms. |  | Information Item in Infoset terms. |
| skipping to change at page 4, line 33 |  | skipping to change at page 4, line 33 |
| for more information about specific values. |  | for more information about specific values. |
| Note that URI references in link relation values may be relative, and |  | Note that URI references in link relation values may be relative, and |
| when they are used they must be absolutised, as described in Section |  | when they are used they must be absolutised, as described in Section |
| 5.1 of [5]. |  | 5.1 of [5]. |
| 2. Complete Feeds |  | 2. Complete Feeds |
| A complete feed is a feed document that contains all of the entries |  | A complete feed is a feed document that contains all of the entries |
| of a logical feed; any entry not actually in the feed document SHOULD |  | of a logical feed; any entry not actually in the feed document SHOULD |
| NOT be considered to be part of that feed. |  | NOT be considered part of that feed. |
| For example, a feed that represents a ranking that varies over time |  | For example, a feed that represents a ranking that varies over time |
| (such as "Top Twenty Records" or "Most Popular Items") should not |  | (such as "Top Twenty Records" or "Most Popular Items") should not |
| have newer entries displayed alongside older ones. By marking this |  | have newer entries displayed alongside older ones. By marking this |
| type feeds as complete, old entries are discarded when it is |  | feed as complete, old entries are discarded when it is refreshed. |
| refreshed. |  |  |
| The fh:complete element, when present in a feed's head section, |  | The fh:complete element, when present in a feed's head section, |
| indicates that the feed document it occurs in is a complete |  | indicates that the feed document it occurs in is a complete |
| representation of the logical feed's entries. It is an empty |  | representation of the logical feed's entries. It is an empty |
| element; this specification does not define any content for it. |  | element; this specification does not define any content for it. |
| Example: Atom-formatted Complete Feed |  | Example: Atom-formatted Complete Feed |
| <?xml version="1.0" encoding="utf-8"?> |  | <?xml version="1.0" encoding="utf-8"?> |
| <feed xmlns="http://www.w3.org/2005/Atom" |  | <feed xmlns="http://www.w3.org/2005/Atom" |
| skipping to change at page 5, line 37 |  | skipping to change at page 5, line 37 |
| </entry> |  | </entry> |
| </feed> |  | </feed> |
| This specification does not address duplicate entries in complete |  | This specification does not address duplicate entries in complete |
| feeds. |  | feeds. |
| 3. Paged Feeds |  | 3. Paged Feeds |
| A paged feed is a set of linked feed documents that together contain |  | A paged feed is a set of linked feed documents that together contain |
| the entries of a logical feed, without any guarantees about the |  | the entries of a logical feed, without any guarantees about the |
| stability of the documents' contents. |  | stability of each document's contents. |
| Paged feeds are lossy; that is, it is not possible to guarantee that |  | Paged feeds are lossy; that is, it is not possible to guarantee that |
| clients will be able to reconstruct the contents of the logical feed |  | clients will be able to reconstruct the contents of the logical feed |
| at a particular time. Entries may be added or changed as the pages |  | at a particular time. Entries may be added or changed as the pages |
| of the feed are accessed, without the client becoming aware of them. |  | of the feed are accessed, without the client becoming aware of them. |
| Therefore, clients SHOULD NOT present paged feeds as coherent or |  | Therefore, clients SHOULD NOT present paged feeds as coherent or |
| complete, or make assumptions to that effect. |  | complete, or make assumptions to that effect. |
| Paged feeds can be useful when the number of entries is very large, |  | Paged feeds can be useful when the number of entries is very large, |
| skipping to change at page 9, line 20 |  | skipping to change at page 9, line 20 |
| is the most recent complete archive; although another archive |  | is the most recent complete archive; although another archive |
| ("2003/12") may be under construction, it would be an error to link |  | ("2003/12") may be under construction, it would be an error to link |
| to it before completion. |  | to it before completion. |
| 4.1. Publishing Archived Feeds |  | 4.1. Publishing Archived Feeds |
| The requirement that archive documents be stable allows clients to |  | The requirement that archive documents be stable allows clients to |
| safely assume that if they have retrieved one in the past, it will |  | safely assume that if they have retrieved one in the past, it will |
| not meaningfully change in the future. As a result, if an archive |  | not meaningfully change in the future. As a result, if an archive |
| document's contents are changed, some clients may not become aware of |  | document's contents are changed, some clients may not become aware of |
| it. |  | the changes. |
| Therefore, if a publisher requires a change to be visible to all |  | Therefore, if a publisher requires a change to be visible to all |
| users (e.g., correcting factual errors), they should consider |  | users (e.g., correcting factual errors), they should consider |
| publishing the revised entry in the subscription document, in |  | publishing the revised entry in the subscription document, in |
| addition to (or instead of) the appropriate archive document. |  | addition to (or instead of) the appropriate archive document. |
| Conversely, unimportant changes (e.g., spelling corrections) might be |  | Conversely, unimportant changes (e.g., spelling corrections) might be |
| only effected in archive documents. |  | only effected in archive documents. |
| Publishers SHOULD construct their feed documents in such a way as to |  | Publishers SHOULD construct their feed documents in such a way as to |
| make duplicate removal unambiguous (see Section 4.2). |  | make duplicate removal unambiguous (see Section 4.2). |
| Publishers are not required to make all archive documents available; |  | Publishers are not required to make all archive documents available; |
| they may refuse to serve (e.g., with HTTP status code 403 or 410), or |  | they may refuse to serve (e.g., with HTTP status code 403 or 410) or |
| be unable to serve (e.g., with HTTP status code 404) an archive |  | be unable to serve (e.g., with HTTP status code 404) an archive |
| document. |  | document. |
| 4.2. Consuming Archived Feeds |  | 4.2. Consuming Archived Feeds |
| Typically, clients will "subscribe" to an archived feed by polling |  | Typically, clients will "subscribe" to an archived feed by polling |
| the subscription document for recent changes. If URI contained in |  | the subscription document for recent changes. If a URI contained in |
| the prev-archive link relation has not been processed in the past, |  | the prev-archive link relation has not been processed in the past, |
| the client can "catch up" with any missed entries by dereferencing it |  | the client can "catch up" with any missed entries by dereferencing it |
| and adding the contained entries to the logical feed. This process |  | and adding the contained entries to the logical feed. This process |
| should be repeated recursively until the client encounters a prev- |  | should be repeated recursively until the client encounters a prev- |
| archive link relation that has been processed, the end of the archive |  | archive link relation that has been processed (the end of the archive |
| is indicated by a missing prev-archive link relation, or an error is |  | is indicated by a missing prev-archive link relation) or an error is |
| encountered. |  | encountered. |
| If duplicate entries are found, clients SHOULD consider only the most |  | If duplicate entries are found, clients SHOULD consider only the most |
| recently updated entry to be part of the logical feed. If duplicate |  | recently updated entry to be part of the logical feed. If duplicate |
| entries have the same update time-stamp, or none is available, the |  | entries have the same update time-stamp, or no time-stamps are |
| entry sourced from the most recently updated feed document SHOULD |  | available, the entry sourced from the most recently updated feed |
| replace all other duplicates of that entry. |  | document SHOULD replace all other duplicates of that entry. |
| In Atom-formatted archived feeds, two entries are duplicates if they |  | In Atom-formatted archived feeds, two entries are duplicates if they |
| have the same atom:id element. The update time of an entry is |  | have the same atom:id element. The update time of an entry is |
| determined by its atom:updated element, and likewise the update time |  | determined by its atom:updated element, and likewise the update time |
| of a feed document is determined by its feed-level atom:updated |  | of a feed document is determined by its feed-level atom:updated |
| element. |  | element. |
| Clients SHOULD warn users when they are not able to reconstruct the |  | Clients SHOULD warn users when they are not able to reconstruct the |
| entire logical feed (e.g., by alerting the user that an archive |  | entire logical feed (e.g., by alerting the user that an archive |
| document is unavailable, or displaying pseudo-entries that inform the |  | document is unavailable, or displaying pseudo-entries that inform the |
| user that some entries may be missing). |  | user that some entries may be missing). |
| 5. IANA Considerations |  | 5. IANA Considerations |
| This specification defines the following new relations, to be added |  | This specification defines the following new relations that have been |
| to the Link Relations registry: |  | added to the Link Relations registry: |
| o Attribute Value: prev-archive |  | o Attribute Value: prev-archive |
| o Description: A URI that refers to the immediately |  | o Description: A URI that refers to the immediately |
| preceding archive document. |  | preceding archive document. |
| o Expected display characteristics: none |  | o Expected display characteristics: none |
| o Security considerations: See [ this document ] |  | o Security considerations: See [RFC5005] |
| o Attribute Value: next-archive |  | o Attribute Value: next-archive |
| o Description: A URI that refers to the immediately |  | o Description: A URI that refers to the immediately |
| following archive document. |  | following archive document. |
| o Expected display characteristics: none |  | o Expected display characteristics: none |
| o Security considerations: See [ this document ] |  | o Security considerations: See [RFC5005] |
| Additionally, the "previous," "next" and "current" link relations |  | Additionally, the "previous," "next", and "current" link relations |
| should be updated to refer to this document. |  | should be updated to refer to this document. |
| 6. Security Considerations |  | 6. Security Considerations |
| Feeds using this mechanism have the same security considerations as |  | Feeds using this mechanism have the same security considerations as |
| Atom [1]. Encryption and authentication security services can be |  | Atom [1]. Encryption and authentication security services can be |
| obtained by encrypting and/or signing the feed, as described in [1], |  | obtained by encrypting and/or signing the feed, as described in [1], |
| and may also be obtained through channel-based mechanisms (e.g., TLS |  | and may also be obtained through channel-based mechanisms (e.g., TLS |
| [6], HTTP authentication [7]) and/or transport (e.g., IPSec [8]). |  | [6], HTTP authentication [7]) and/or transport (e.g., IPsec [8]). |
| Feeds using these mechanisms could be crafted in such a way as to |  | Feeds using these mechanisms could be crafted in such a way as to |
| cause a client to initiate excessive (or even an unending sequence |  | cause a client to initiate excessive (or even an unending sequence |
| of) network requests, causing denial of service (either to the |  | of) network requests, causing denial of service (either to the |
| client, the target server, and/or intervening networks). Clients can |  | client, the target server, and/or intervening networks). Clients can |
| mitigate this risk by requiring user intervention after a certain |  | mitigate this risk by requiring user intervention after a certain |
| number of requests, or by limiting requests either according to a |  | number of requests, or by limiting requests either according to a |
| hard limit, or with heuristics. Servers can mitigate this risk by |  | hard limit, or with heuristics. Servers can mitigate this risk by |
| denying requests that they consider abusive (e.g., by closing the |  | denying requests that they consider abusive (e.g., by closing the |
| connection, or generating an error). |  | connection or generating an error). |
| Clients should be mindful of resource limits when storing feed |  | Clients should be mindful of resource limits when storing feed |
| documents. To reiterate, they are not required to always store or |  | documents. To reiterate, they are not required to always store or |
| reconstruct the feed when conforming to this specification; they only |  | reconstruct the feed when conforming to this specification; they only |
| need inform the user when the reconstructed feed is not complete. |  | need to inform the user when the reconstructed feed is not complete. |
| This specification does not define what it means when a logical |  | This specification does not define what it means when a logical |
| feed's component feed documents have different security mechanisms |  | feed's component feed documents have different security mechanisms |
| applied. |  | applied. |
| 7. References |  | 7. References |
| 7.1. Normative References |  | 7.1. Normative References |
| [1] Nottingham, M. and R. Sayre, "The Atom Syndication Format", |  | [1] Nottingham, M. and R. Sayre, "The Atom Syndication Format", |
| skipping to change at page 11, line 49 |  | skipping to change at page 11, line 49 |
| [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) |  | [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) |
| Protocol Version 1.1", RFC 4346, April 2006. |  | Protocol Version 1.1", RFC 4346, April 2006. |
| [7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |  | [7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |
| Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: |  | Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: |
| Basic and Digest Access Authentication", RFC 2617, June 1999. |  | Basic and Digest Access Authentication", RFC 2617, June 1999. |
| [8] Kent, S. and K. Seo, "Security Architecture for the Internet |  | [8] Kent, S. and K. Seo, "Security Architecture for the Internet |
| Protocol", RFC 4301, December 2005. |  | Protocol", RFC 4301, December 2005. |
| [9] Winer, D., "RSS 2.0 Specification", 2005. |  | [9] Winer, D., "RSS 2.0 Specification", 2005, |
|  |  | <http://www.rssboard.org/rss-specification>. |
| Appendix A. Acknowledgements |  | Appendix A. Acknowledgements |
| The author would like to thank the following people for their |  | The author would like to thank the following people for their |
| contributions, comments and help: Danny Ayers, Thomas Broyer, Lisa |  | contributions, comments, and help: Danny Ayers, Thomas Broyer, Lisa |
| Dusseault, Stefan Eissing, David Hall, Bill de Hora, Vidya Narayanan, |  | Dusseault, Stefan Eissing, David Hall, Bill de Hora, Vidya Narayanan, |
| Aristotle Pagaltzis, John Panzer, Dave Pawson, Garrett Rooney, Robert |  | Aristotle Pagaltzis, John Panzer, Dave Pawson, Garrett Rooney, Robert |
| Sayre, James Snell, Henry Story, Franklin Tse. |  | Sayre, James Snell, Henry Story, and Franklin Tse. |
| Any errors herein remain the author's, not theirs. |  | Any errors herein remain the author's, not theirs. |
| Appendix B. Use in RSS 2.0 |  | Appendix B. Use in RSS 2.0 |
| As previously noted, while this specification's extensions are |  | As previously noted, while this specification's extensions are |
| described in terms of the Atom feed format, they are also useful in |  | described in terms of the Atom feed format, they are also useful in |
| similar formats. This informative appendix demonstrates how they can |  | similar formats. This informative appendix demonstrates how they can |
| be used in an RSS 2.0-formatted [9] feed. |  | be used in an RSS 2.0-formatted [9] feed. |
End of changes. 24 change blocks.
| 55 lines changed or deleted |  | 36 lines changed or added |
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/