| draft-nottingham-atompub-feed-history-09.txt |  | draft-nottingham-atompub-feed-history-10.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Intended status: Standards Track |  | Intended status: Standards Track |
| Expires: October 24, 2007 |  | Expires: November 22, 2007 |
| Feed Paging and Archiving |  | Feed Paging and Archiving |
| draft-nottingham-atompub-feed-history-09 |  | draft-nottingham-atompub-feed-history-10 |
| Status of This Memo |  | Status of This Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 34 |  | skipping to change at page 1, line 34 |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on October 24, 2007. |  | This Internet-Draft will expire on November 22, 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 |
|  |  | that allow reconstruction of the feed's contents, and feeds that are |
|  |  | explicitly "complete". |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 |  | 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 |
| 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 |  | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 2. Complete Feeds . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 2. Complete Feeds . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 3. Paged Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 3. Paged Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 4. Archived Feeds . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 4. Archived Feeds . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 4.1. Publishing Archived Feeds . . . . . . . . . . . . . . . . 9 |  | 4.1. Publishing Archived Feeds . . . . . . . . . . . . . . . . 9 |
| 4.2. Consuming Archived Feeds . . . . . . . . . . . . . . . . . 9 |  | 4.2. Consuming Archived Feeds . . . . . . . . . . . . . . . . . 9 |
| 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 . . . . . . . . . . . . . . . . . . 11 |  | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 |
| Appendix B. Use in RSS 2.0 . . . . . . . . . . . . . . . . . . . 11 |  | Appendix B. Use in RSS 2.0 . . . . . . . . . . . . . . . . . . . 12 |
| 1. Introduction |  | 1. Introduction |
| Syndicated Web feeds (using such formats as Atom [RFC4287]) are often |  | Syndicated Web feeds (using such formats as Atom [1]) are often split |
| split up into multiple documents to save bandwidth, allow "sliding |  | up into multiple documents to save bandwidth, allow "sliding window" |
| 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" |
| skipping to change at page 3, line 40 |  | skipping to change at page 3, line 40 |
| 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 |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in BCP 14 [RFC2119]. |  | document are to be interpreted as described in RFC 2119 [2]. |
| This specification uses XML Namespaces [W3C.REC-xml-names-19990114] |  | This specification uses XML Namespaces [3] to uniquely identify XML |
| to uniquely identify XML element names. It uses the following |  | element names. It uses the following namespace prefix for the |
| namespace prefix for the indicated namespace URI; |  | indicated namespace URI; |
| "fh": "http://purl.org/syndication/history/1.0" |  | "fh": "http://purl.org/syndication/history/1.0" |
| 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 them). |
| "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 |  | This specification uses terms from the XML Infoset [4]. However, |
| [W3C.REC-xml-infoset-20040204]. However, this specification uses a |  | this specification uses a shorthand; the phrase "Information Item" is |
| shorthand; the phrase "Information Item" is omitted when naming |  | omitted when naming Element Information Items. Therefore, when this |
| Element Information Items. Therefore, when this specification uses |  | specification uses the term "element," it is referring to an Element |
| the term "element," it is referring to an Element Information Item in |  | Information Item in Infoset terms. |
| Infoset terms. |  |  |
| This specification also uses Atom link relations to identify |  | This specification also uses Atom link relations to identify |
| different types of links; see the Atom specification [RFC4287] for |  | different types of links; see the Atom specification [1] for |
| information about their syntax, and the IANA link relation registry |  | information about their syntax, and the IANA link relation registry |
| 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 [RFC3986]. |  | 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 to be 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 |
| skipping to change at page 5, line 11 |  | skipping to change at page 5, line 11 |
| 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" |
| xmlns:fh="http://purl.org/syndication/history/1.0"> |  | xmlns:fh="http://purl.org/syndication/history/1.0"> |
| <title>NetMovies Queue</title> |  | <title>NetMovies Queue</title> |
| <description>The DVDs you'll receive next.</description> |  | <subtitle>The DVDs you'll receive next.</subtitle> |
| <link href="http://example.org/"/> |  | <link href="http://example.org/"/> |
| <fh:complete/> |  | <fh:complete/> |
| <link rel="self" |  | <link rel="self" |
| href="http://netmovies.example.org/jdoe/queue/index.atom"/> |  | href="http://netmovies.example.org/jdoe/queue/index.atom"/> |
| <updated>2003-12-13T18:30:02Z</updated> |  | <updated>2003-12-13T18:30:02Z</updated> |
| <author> |  | <author> |
| <name>John Doe</name> |  | <name>John Doe</name> |
| </author> |  | </author> |
| <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> |  | <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> |
| <entry> |  | <entry> |
| skipping to change at page 7, line 27 |  | skipping to change at page 7, line 27 |
| o "prev-archive" - A URI that refers to the immediately preceding |  | o "prev-archive" - A URI that refers to the immediately preceding |
| archive document. |  | archive document. |
| o "next-archive" - A URI that refers to the immediately following |  | o "next-archive" - A URI that refers to the immediately following |
| archive document. |  | archive document. |
| o "current" - A URI that, when dereferenced, returns a feed document |  | o "current" - A URI that, when dereferenced, returns a feed document |
| containing the most recent entries in the feed. |  | containing the most recent entries in the feed. |
| Subscription documents and archive documents MUST have a "prev- |  | Subscription documents and archive documents MUST have a "prev- |
| archive" link relation, unless there are no preceding archives |  | archive" link relation, unless there are no preceding archives |
| available. Additionally, archive documents SHOULD have "next- |  | available. Archive documents SHOULD also have a "next-archive" link |
| archive" and "current" link relations. |  | relation, unless there are no following archives available. |
| Archive document SHOULD also contain an fh:archive element in their |  | Archive documents SHOULD indicate their associated subscription |
|  |  | documents using the "current" link relation. |
|  |  | Archive documents SHOULD also contain an fh:archive element in their |
| head sections to indicate that they are archives. fh:archive is an |  | head sections to indicate that they are archives. fh:archive is an |
| empty element; this specification does not define any content for it. |  | empty element; this specification does not define any content for it. |
| Example: Atom-formatted Subscription Document |  | Example: Atom-formatted Subscription Document |
| <?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"> |
| <title>Example Feed</title> |  | <title>Example Feed</title> |
| <link href="http://example.org/"/> |  | <link href="http://example.org/"/> |
| <link rel="self" href="http://example.org/index.atom"/> |  | <link rel="self" href="http://example.org/index.atom"/> |
| skipping to change at page 9, line 4 |  | skipping to change at page 9, line 4 |
| </author> |  | </author> |
| <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> |  | <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> |
| <entry> |  | <entry> |
| <title>Atom-Powered Robots Scheduled To Run Amok</title> |  | <title>Atom-Powered Robots Scheduled To Run Amok</title> |
| <link href="http://example.org/2003/11/24/robots_coming"/> |  | <link href="http://example.org/2003/11/24/robots_coming"/> |
| <id>urn:uuid:cdef5c6d5-gff8-4ebb-assa-80dwe44efkjo</id> |  | <id>urn:uuid:cdef5c6d5-gff8-4ebb-assa-80dwe44efkjo</id> |
| <updated>2003-11-24T12:00:00Z</updated> |  | <updated>2003-11-24T12:00:00Z</updated> |
| <summary>Some text from an old, different entry.</summary> |  | <summary>Some text from an old, different entry.</summary> |
| </entry> |  | </entry> |
| </feed> |  | </feed> |
|  |  | In this example, the feed archives are split into monthly chunks, and |
|  |  | the subscription document points to the most recent complete archive |
|  |  | "http://example.org/2003/11/index.atom" using the "prev-archive" |
|  |  | relation. That document, in turn points to the previous archive |
|  |  | "http://example.org/2003/10/index.atom", and so on. Note that the |
|  |  | "2003/11" archive does not have a "next-archive" relation, because it |
|  |  | is the most recent complete archive; although another archive |
|  |  | ("2003/12") may be under construction, it would be an error to link |
|  |  | 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. |  | it. |
| 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 feed, in addition to |  | publishing the revised entry in the subscription document, in |
| (or instead of) the appropriate archive feed. Conversely, |  | addition to (or instead of) the appropriate archive document. |
| unimportant changes (e.g., spelling corrections) might be only |  | Conversely, unimportant changes (e.g., spelling corrections) might be |
| effected in archive feeds. |  | 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 |
| skipping to change at page 10, line 10 |  | skipping to change at page 10, line 20 |
| 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 |
| The "previous", "next" and "current" link relations have been |  |  |
| previously registered, and no IANA action regarding them is required. |  |  |
| This specification defines the following new relations, to be added |  | This specification defines the following new relations, to be added |
| to the Link Relations registry: |  | 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 [ this document ] |
| 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 [ this document ] |
|  |  | Additionally, the "previous," "next" and "current" link relations |
|  |  | should be updated to refer to this document. |
| 6. Security Considerations |  | 6. Security Considerations |
| Feeds using this mechanism have the same authentication and channel |  | Feeds using this mechanism have the same security considerations as |
| security concerns as explained in Atom [RFC4287]. |  | Atom [1]. Encryption and authentication security services can be |
|  |  | obtained by encrypting and/or signing the feed, as described in [1], |
|  |  | and may also be obtained through channel-based mechanisms (e.g., TLS |
|  |  | [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 inform the user when the reconstructed feed is not complete. |
|  |  | This specification does not define what it means when a logical |
|  |  | feed's component feed documents have different security mechanisms |
|  |  | applied. |
| 7. References |  | 7. References |
| 7.1. Normative References |  | 7.1. Normative References |
| [RFC2119] Bradner, S., "Key words for use in |  | [1] Nottingham, M. and R. Sayre, "The Atom Syndication Format", |
| RFCs to Indicate Requirement Levels", |  | RFC 4287, December 2005. |
| BCP 14, RFC 2119, March 1997. |  |  |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. |  | [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement |
| Masinter, "Uniform Resource |  | Levels", BCP 14, RFC 2119, March 1997. |
| Identifier (URI): Generic Syntax", |  |  |
| STD 66, RFC 3986, January 2005. |  |  |
| [RFC4287] Nottingham, M. and R. Sayre, "The |  | [3] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C |
| Atom Syndication Format", RFC 4287, |  | REC REC-xml-names-19990114, January 1999. |
| December 2005. |  |  |
| [W3C.REC-xml-infoset-20040204] Cowan, J. and R. Tobin, "XML |  | [4] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", |
| Information Set (Second Edition)", |  | W3C REC REC-xml-infoset-20040204, February 2004. |
| W3C REC REC-xml-infoset-20040204, |  |  |
| February 2004. |  |  |
| [W3C.REC-xml-names-19990114] Bray, T., Hollander, D., and A. |  | [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Layman, "Namespaces in XML", W3C |  | Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, |
| REC REC-xml-names-19990114, |  | January 2005. |
| January 1999. |  |  |
| 7.2. Informative References |  | 7.2. Informative References |
| [RSS2] Winer, D., "RSS 2.0 Specification", |  | [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) |
| 2005, <http://blogs.law.harvard.edu/ |  | Protocol Version 1.1", RFC 4346, April 2006. |
| tech/rss>. |  |  |
|  |  | [7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |
|  |  | Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: |
|  |  | Basic and Digest Access Authentication", RFC 2617, June 1999. |
|  |  | [8] Kent, S. and K. Seo, "Security Architecture for the Internet |
|  |  | Protocol", RFC 4301, December 2005. |
|  |  | [9] Winer, D., "RSS 2.0 Specification", 2005. |
| 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. |  | Sayre, James Snell, Henry Story, 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 [RSS2] feed. |  | be used in an RSS 2.0-formatted [9] feed. |
| In RSS 2.0-formatted feeds, two entries are duplicates if they have |  | In RSS 2.0-formatted feeds, two entries are duplicates if they have |
| the same guid element. The update time of an entry is not defined by |  | the same guid element. The update time of an entry is not defined by |
| RSS 2.0, but the feed-level update time can be determined by the |  | RSS 2.0, but the feed-level update time can be determined by the |
| pubDate element. |  | pubDate element. |
| RSS 2.0-formatted Complete Feed |  | RSS 2.0-formatted Complete Feed |
| <?xml version="1.0"?> |  | <?xml version="1.0"?> |
| <rss version="2.0" |  | <rss version="2.0" |
| skipping to change at page 13, line 28 |  | skipping to change at page 14, line 28 |
| <managingEditor>editor@example.com</managingEditor> |  | <managingEditor>editor@example.com</managingEditor> |
| <webMaster>webmaster@example.com</webMaster> |  | <webMaster>webmaster@example.com</webMaster> |
| <atom:link rel="next" |  | <atom:link rel="next" |
| href="http://liftof.nasa.gov/index.rss?page=2"/> |  | href="http://liftof.nasa.gov/index.rss?page=2"/> |
| <item> |  | <item> |
| <title>Star City</title> |  | <title>Star City</title> |
| <link>http://liftoff.nasa.gov/2003/06/news-starcity</link> |  | <link>http://liftoff.nasa.gov/2003/06/news-starcity</link> |
| <description>How do Americans get ready to work with Russians |  | <description>How do Americans get ready to work with Russians |
| aboard the International Space Station? They take a crash course |  | aboard the International Space Station? They take a crash course |
| in culture, language and protocol at Russia's <a |  | in culture, language and protocol at Russia's <a |
| href="http://howe.iki.rssi.ru/GCTC/gctc_e.htm"&amp;gt;Star |  | href="http://howe.iki.rssi.ru/GCTC/gctc_e.htm">Star |
| City</a>.</description> |  | City</a>.</description> |
| <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> |  | <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> |
| <guid>http://liftoff.nasa.gov/2003/06/03.html#item573</guid> |  | <guid>http://liftoff.nasa.gov/2003/06/03.html#item573</guid> |
| </item> |  | </item> |
| </channel> |  | </channel> |
| </rss> |  | </rss> |
| RSS 2.0-formatted Subscription Document |  | RSS 2.0-formatted Subscription Document |
| <?xml version="1.0"?> |  | <?xml version="1.0"?> |
| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> |  | <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> |
| skipping to change at page 14, line 28 |  | skipping to change at page 15, line 28 |
| <webMaster>webmaster@example.com</webMaster> |  | <webMaster>webmaster@example.com</webMaster> |
| <atom:link rel="prev-archive" |  | <atom:link rel="prev-archive" |
| href="http://liftoff.nasa.gov/2003/05/index.rss"/> |  | href="http://liftoff.nasa.gov/2003/05/index.rss"/> |
| <item> |  | <item> |
| <title>Star City</title> |  | <title>Star City</title> |
| <link>http://liftoff.nasa.gov/2003/06/news-starcity</link> |  | <link>http://liftoff.nasa.gov/2003/06/news-starcity</link> |
| <description>How do Americans get ready to work with Russians |  | <description>How do Americans get ready to work with Russians |
| aboard the International Space Station? They take a crash course |  | aboard the International Space Station? They take a crash course |
| in culture, language and protocol at Russia's <a |  | in culture, language and protocol at Russia's <a |
| href="http://howe.iki.rssi.ru/GCTC/gctc_e.htm"&amp;gt;Star |  | href="http://howe.iki.rssi.ru/GCTC/gctc_e.htm">Star |
| City</a&amp;gt;.</description> |  | City</a>.</description> |
| <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> |  | <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> |
| <guid>http://liftoff.nasa.gov/2003/06/03.html#item573</guid> |  | <guid>http://liftoff.nasa.gov/2003/06/03.html#item573</guid> |
| </item> |  | </item> |
| </channel> |  | </channel> |
| </rss> |  | </rss> |
| RSS 2.0-formatted Archive Document |  | RSS 2.0-formatted Archive Document |
| <?xml version="1.0"?> |  | <?xml version="1.0"?> |
| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" |  | <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" |
| xmlns:fh="http://purl.org/syndication/history/1.0"> |  | xmlns:fh="http://purl.org/syndication/history/1.0"> |
End of changes. 30 change blocks.
| 59 lines changed or deleted |  | 81 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/