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).