idnits 2.17.1 draft-snell-atompub-tombstones-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 237. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4287, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4287, updated by this document, for RFC5378 checks: 2004-07-09) -- 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 (April 21, 2008) is 5848 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft April 21, 2008 4 Updates: 4287 (if approved) 5 Intended status: Experimental 6 Expires: October 23, 2008 8 The Atom "deleted-entry" Element 9 draft-snell-atompub-tombstones-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 23, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This specification adds mechanisms to the Atom Syndication Format 43 which Atom Feed publishers can use to explicitly identify Atom 44 entries that have been removed from an Atom feed. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 50 3. The at:deleted-entry element . . . . . . . . . . . . . . . . . 3 51 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 52 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 53 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 54 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 Intellectual Property and Copyright Statements . . . . . . . . . . 7 58 1. Introduction 60 This specification adds a new element to the Atom Syndication Format 61 [RFC4287] that can be used to explicitly indicate that specific 62 entries have been removed from a feed. 64 2. Notational Conventions 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in BCP 14, [RFC2119] 70 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 71 to uniquely identify XML element names. It uses the following 72 namespace prefix for the indicated namespace URI; 74 "at": "http://purl.org/atompub/tombstones/1.0" 76 3. The at:deleted-entry element 78 The at:deleted-entry element MAY appear as a child of atom:feed to 79 represent an Atom Entry that has been removed from a feed. 81 deletedEntry = element at:deleted-entry { 82 atomCommonAttributes, 83 attribute ref { atomUri }, 84 attribute when { atomDateConstruct }, 85 ( element at:by { atomPersonConstruct}?, 86 & element at:comment {atomTextConstruct}?, 87 & extensionElement* ) 88 } 90 The at:deleted-entry element MUST contain a ref attribute whose value 91 specifies the value of the atom:id of the entry that has been 92 removed. 94 The at:deleted-entry element MUST contain a when attribute whose 95 value is an [RFC3339] "date-time" specifying the instant the entry 96 was removed from the feed. An uppercase "T" character MUST be used 97 to separate date and time, and an uppercase "Z" character MUST be 98 present in the absence of a numeric time zone offset 100 The at:deleted-entry element MAY contain one at:by element used to 101 identify the entity that removed the entry from the feed. The at:by 102 element is an Atom Person Construct as defined by Section 3.2 of 103 [RFC4287]. 105 The at:deleted-entry element MAY contain one at:comment element whose 106 value provides additional, language-sensitive information about the 107 deletion operation. The atom:comment element is an Atom Text 108 Construct as defined by Section 3.1 of [RFC4287]. 110 An Atom feed MAY contain any number of at:deleted-entry elements, but 111 MUST NOT contain more than one with the same combination of ref and 112 when attribute values. 114 116 ... 117 118 122 123 126 127 John Doe 128 jdoe@example.org 129 130 Removed comment spam 131 132 ... 133 135 An Atom feed MAY contain atom:entry elements and at:deleted-entry 136 elements sharing the same atom:id value. Atom processors SHOULD 137 ignore any at:deleted-entry elements sharing an atom:id value with an 138 atom:entry whose atom:updated element specifies a date and time more 139 recent than the at:deleted-entry element's when value. 141 Elements and attributes from other XML vocabularies MAY be used 142 within an at:deleted-entry element following the same model defined 143 by Section 6 of [RFC4287]. Processors encountering such markup MUST 144 NOT stop processing or signal an error. It might be the case that 145 the Processor is able to process the foreign markup correctly and 146 does so. When unknown markup is encountered as a child of at: 147 deleted-entry, Processors MAY bypass the markup and any textual 148 content and MUST NOT change their behavior as a result of the 149 markup's presence. 151 4. Security Considerations 153 As specified in [RFC4287], Atom processors should be aware of the 154 potential for spoofing attacks where an attacker publishes atom:entry 155 or atom:deleted-entry elements using the same atom:id values as 156 entries from other Atom feeds. An attacker may attempt to trick an 157 application into believing that a given entry has either been removed 158 from or added to a feed. To mitigate this issue, Atom processors are 159 advised to ignore atom:deleted-entry elements referencing entries 160 that have not previously appeared within the containing Feed document 161 and should take steps to verify the origin of the Atom feed before 162 considering the entries to be removed. 164 5. IANA Considerations 166 No IANA actions are required by this document. 168 6. Acknowledgements 170 The author gratefully acknowledges the feedback from the members of 171 the Atom Publishing Format and Protocol working group during the 172 development of this specification. 174 7. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 180 Internet: Timestamps", RFC 3339, July 2002. 182 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 183 Syndication Format", RFC 4287, December 2005. 185 [W3C.REC-xml-names-19990114] 186 Layman, A., Hollander, D., and T. Bray, "Namespaces in 187 XML", World Wide Web Consortium FirstEdition REC-xml- 188 names-19990114, January 1999, 189 . 191 Author's Address 193 James M Snell 195 Phone: 196 Email: jasnell@gmail.com 197 URI: http://snellspace.com 199 Full Copyright Statement 201 Copyright (C) The IETF Trust (2008). 203 This document is subject to the rights, licenses and restrictions 204 contained in BCP 78, and except as set forth therein, the authors 205 retain all their rights. 207 This document and the information contained herein are provided on an 208 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 209 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 210 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 211 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 212 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 215 Intellectual Property 217 The IETF takes no position regarding the validity or scope of any 218 Intellectual Property Rights or other rights that might be claimed to 219 pertain to the implementation or use of the technology described in 220 this document or the extent to which any license under such rights 221 might or might not be available; nor does it represent that it has 222 made any independent effort to identify any such rights. Information 223 on the procedures with respect to rights in RFC documents can be 224 found in BCP 78 and BCP 79. 226 Copies of IPR disclosures made to the IETF Secretariat and any 227 assurances of licenses to be made available, or the result of an 228 attempt made to obtain a general license or permission for the use of 229 such proprietary rights by implementers or users of this 230 specification can be obtained from the IETF on-line IPR repository at 231 http://www.ietf.org/ipr. 233 The IETF invites any interested party to bring to its attention any 234 copyrights, patents or patent applications, or other proprietary 235 rights that may cover technology that may be required to implement 236 this standard. Please address the information to the IETF at 237 ietf-ipr@ietf.org. 239 Acknowledgment 241 Funding for the RFC Editor function is provided by the IETF 242 Administrative Support Activity (IASA).