idnits 2.17.1 draft-nottingham-atompub-feed-history-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 223. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2005) is 6880 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft June 24, 2005 4 Expires: December 26, 2005 6 Feed History: Enabling Stateful Syndication 7 draft-nottingham-atompub-feed-history-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 26, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document specifies mechanisms that allow feed publishers to give 41 hints about the nature of the feed's statefulness, and a means of 42 retrieving "missed" entries from a stateful feed. 44 1. Introduction 46 RFCxxxx describes a Feed Document as 'a representation of an Atom 47 feed, including metadata about the feed, and some or all of the 48 entries associated with it'. Because Feed Documents usually only 49 contain the last several entries in a logical feed, consuming 50 software often keeps copies of all entries that have been previously 51 seen, effectively keeping a history of its contents. 53 However, not all feeds benefit from this practice; in some, old 54 entries are not relevant to the current contents of the feed. For 55 example, it's not desireable to keep history in this manner with a 56 "top ten" feed; it is not desireable to show old entries, because it 57 would imply that the previous number one is now number eleven, and so 58 forth. 60 Feeds that encourage this practice have a different problem. If 61 consuming software does not poll often enough, some entries may be 62 missed, causing them to be silently omitted. For some applications, 63 this is a serious error on its own. Even in non-critical 64 applications, this phenomenon can cause publishers to make Feed 65 Documents contain more entries than reasonably necessary, just to 66 assure that consumers have an amply large window in which to 67 reconstruct the feed's state. 69 This document specifies mechanisms that allow feed publishers to give 70 hints as to the nature of the feed with regard to state, and a means 71 of retrieving "missed" entries from a stateful feed. 73 2. Notational Conventions 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in BCP 14, [RFC2119], as 78 scoped to those conformance targets. 80 In this specification, "Feed Document" refers to an Atom Feed 81 Document. Note that these mechanisms MAY also be used in other XML- 82 based syndication formats, such as the various flavours of RSS. 84 In this specification, "head section" refers to the children of the 85 Feed Document's document-wide metadata container; e.g., the child 86 elements of the atom:feed element in an Atom Feed Document. 88 This specification uses XML Namespaces to uniquely identify XML 89 element names. It uses the following namespace prefix for the 90 indicated namespace URI; 92 "atom": [[TBD]] 94 "fh": [[TBD]] 96 3. The Stateful Flag 98 The stateful flag is an XML element in a Feed Document's head section 99 whose content is either "0" or "1". Whitespace in its content MUST 100 be ignored by processors. 102 For example, 104 1 106 If the content of the stateful flag is "0", it indicates that the 107 Feed Document is a complete representation of the entire feed; 108 previous entries SHOULD NOT be considered part of the feed by 109 consumers. 111 For example, a feed that represents a ranking that varies over time, 112 such as "Top Twenty Records" or "Most Popular Items" should be marked 113 with a stateful flag of "0". 115 If the content of the stateful flag is "1", it indicates that the 116 Feed Document is a potentially partial representation of the entire 117 feed; previous entries MUST be considered part of the feed by 118 consumers. 120 For example, a feed that represents a chronological list, such as 121 "ExampleCo Press Releases" or "Widget Project Updates" should be 122 marked with a stateful flag of "1". 124 4. The 'this' and 'prev' Link Relations 126 A Feed Document containing a stateful flag with the content "1" 127 SHOULD also contain an atom:link element with the relation "this", 128 and optionally a Link element with the relation "prev", in its head 129 section. 131 The value of the "this" link relation's href attribute MUST be a URI 132 indicating a permanent location that is unique to that Feed Document 133 instance; i.e., the content obtained by dereferencing that URI SHOULD 134 NOT change over time. This URI can be thought of as pointing to a 135 snapshot of the feed at a particular point in time. 137 The value of the "prev" link relation's href attribute MUST be a URI 138 indicating the location of the previous representation of the feed; 139 i.e., the last Feed Document's "this" URI. 141 For example, 143 144