idnits 2.17.1 draft-snell-atompub-tombstones-02.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 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 218. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 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). -- 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 (February 20, 2006) is 6641 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: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft February 20, 2006 4 Expires: August 24, 2006 6 Atom Syndication Format Tombstones 7 draft-snell-atompub-tombstones-02.txt 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 August 24, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This specification defines mechanisms by which Atom Feed publishers 41 may explicitly indicate that specific Atom Entries have been removed 42 from an Atom feed. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 48 3. The 'deleted-entry' element . . . . . . . . . . . . . . . . . . 3 49 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 50 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 51 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 52 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 Intellectual Property and Copyright Statements . . . . . . . . . . 7 56 1. Introduction 58 This specification defines mechanisms in the form of Atom Format 59 [RFC4287] extensions that Atom Feed publishers can use to explicitly 60 indicate that specific Atom Entries have been removed from a feed for 61 any reason. 63 2. Notational Conventions 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in BCP 14, [RFC2119] 69 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 70 to uniquely identify XML element names. It uses the following 71 namespace prefix for the indicated namespace URI; 73 {Ed. Note: this namespace MUST be changed to a proper IETF namespace 74 scheme prior to publication} 76 "at": "http://purl.org/atompub/tombstones/1.0" 78 3. The 'deleted-entry' element 80 The 'deleted-entry' element MAY appear as a child of atom:feed to 81 represent an Atom Entry that has been removed from the feed. 83 deletedEntry = element at:deleted-entry { 84 atomCommonAttributes, 85 ( & atomID, 86 & when { atomDateConstruct }, 87 & by?, 88 & comment?, 89 & undefinedContent ) 90 } 92 when = element at:when { atomDateConstruct } 93 by = element at:by { atomPersonConstruct } 94 comment = element at:comment { atomTextConstruct } 96 The 'deleted-entry' element MUST contain one 'atom:id' element whose 97 value specifies the atom:id of the deleted entry. 99 The 'deleted-entry' element MUST contain one 'when' element whose 100 value is an [RFC3339] "date-time" specifying the instant the entry 101 was deleted. An uppercase "T" character MUST be used to separate 102 date and time, and an uppercase "Z" character MUST be present in the 103 absence of a numeric time zone offset 105 The 'deleted-entry' element MAY contain one 'by' element used to 106 identify the entity that removed the entry from the feed. 108 The 'deleted-entry' element MAY contain one 'comment' element whose 109 value provides additional information about the deletion operation. 110 The 'comment' element is Language-Sensitive as specified by 111 [RFC4287]. 113 Atom Feed Documents MAY contain any number of 'deleted-entry' 114 elements. 116 117 ... 118 119 tag:example.org,2005:/entries/1 120 2005-11-29T12:12:12Z 121 122 John Doe 123 jdoe@example.org 124 125 Removed comment spam 126 127 128 tag:example.org,2005:/entries/2 129 2005-11-29T12:11:12Z 130 131 John Doe 132 jdoe@example.org 133 134 Removed comment spam 135 136 ... 137 139 An Atom feed MAY contain atom:entry elements and 'deleted-entry' 140 elements sharing the same atom:id value. Atom processors MUST ignore 141 any 'deleted-entry' elements sharing an atom:id value with an atom: 142 entry whose 'updated' element specifies a date and time more recent 143 than the 'deleted-entry' element's 'when' value. 145 4. Security Considerations 147 As specified in [RFC4287], Atom processors should be aware of the 148 potential for spoofing attacks where an attacked publishes atom:entry 149 elements with the same atom:id value of entries from other Atom 150 feeds. The same potential exists with the mechanisms defined here in 151 that an attacker may attempt to spoof an application into believing 152 that a given entry has been removed from a feed. To mitigate this 153 issue, Atom processors are advised to ignore 'deleted-entry' elements 154 referencing entries that have not previously appeared within the 155 containing Feed document and should take steps to verify the origin 156 of the Atom feed before considering the entries to be removed. 158 5. IANA Considerations 160 There are no IANA considerations introduced by this specification. 162 6. Acknowledgements 164 The author gratefully acknowledges the feedback from the members of 165 the Atom Publishing Format and Protocol working group during the 166 development of this specification. 168 7. References 170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 171 Requirement Levels", BCP 14, RFC 2119, March 1997. 173 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 174 Timestamps", RFC 3339, July 2002. 176 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 177 Format", RFC 4287, December 2005. 179 [W3C.REC-xml-infoset-20040204] 180 Tobin, R. and J. Cowan, "XML Information Set (Second 181 Edition)", W3C REC REC-xml-infoset-20040204, 182 February 2004. 184 [W3C.REC-xml-names-19990114] 185 Hollander, D., Bray, T., and A. Layman, "Namespaces in 186 XML", W3C REC REC-xml-names-19990114, January 1999. 188 Author's Address 190 James M Snell 192 Phone: 193 Email: jasnell@gmail.com 194 URI: http://snellspace.com 196 Intellectual Property Statement 198 The IETF takes no position regarding the validity or scope of any 199 Intellectual Property Rights or other rights that might be claimed to 200 pertain to the implementation or use of the technology described in 201 this document or the extent to which any license under such rights 202 might or might not be available; nor does it represent that it has 203 made any independent effort to identify any such rights. Information 204 on the procedures with respect to rights in RFC documents can be 205 found in BCP 78 and BCP 79. 207 Copies of IPR disclosures made to the IETF Secretariat and any 208 assurances of licenses to be made available, or the result of an 209 attempt made to obtain a general license or permission for the use of 210 such proprietary rights by implementers or users of this 211 specification can be obtained from the IETF on-line IPR repository at 212 http://www.ietf.org/ipr. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary 216 rights that may cover technology that may be required to implement 217 this standard. Please address the information to the IETF at 218 ietf-ipr@ietf.org. 220 Disclaimer of Validity 222 This document and the information contained herein are provided on an 223 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 224 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 225 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 226 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 227 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 228 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 230 Copyright Statement 232 Copyright (C) The Internet Society (2006). This document is subject 233 to the rights, licenses and restrictions contained in BCP 78, and 234 except as set forth therein, the authors retain all their rights. 236 Acknowledgment 238 Funding for the RFC Editor function is currently provided by the 239 Internet Society.