idnits 2.17.1 draft-snell-atompub-notification-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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 292), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (December 14, 2004) is 7072 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) == Unused Reference: '2' is defined on line 239, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 243, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-atompub-protocol-02 == Outdated reference: A later version (-11) exists of draft-ietf-atompub-format-03 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Snell 2 Internet-Draft December 14, 2004 3 Expires: June 14, 2005 5 The Atom Notification Protocol 6 draft-snell-atompub-notification-00 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on June 14, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This memo presents a protocol for posting notifications of new or 40 updated content using a combination of the Atom Syndication Format 41 and HTTP POSTs. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 47 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. The Atom Notification Protocol Model . . . . . . . . . . . . . 3 49 3. Functional Specification . . . . . . . . . . . . . . . . . . . 3 50 3.1 NotificationURI . . . . . . . . . . . . . . . . . . . . . 3 51 3.1.1 Locating the NotificationURI . . . . . . . . . . . . . 4 52 3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Atom Syntax Extensions . . . . . . . . . . . . . . . . . . . . 5 55 4.1 "atom:notification" Element . . . . . . . . . . . . . . . 5 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 60 Intellectual Property and Copyright Statements . . . . . . . . 8 62 1. Introduction 64 The Atom Notification Protocol is an application-level protocol for 65 posting notification of new or updated content using HTTP and the 66 Atom Syndication Format. 68 1.1 Notational Conventions 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [1]. 74 1.2 Terminology 76 Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this 77 case, the fragment is a single 'entry' element and all its child 78 elements. Each Atom Entry describes a single Web resource, providing 79 metadata and optionally a textual representation of that resource. 81 Atom Feed: In the context of an Atom Notification, an Atom Feed is a 82 minimal "atom:feed" element containing an "atom:head" element and no 83 "atom:entry" elements. 85 NotificationURI: A URI that is used to receive notifications about 86 new or updated Atom entries. 88 2. The Atom Notification Protocol Model 90 The Atom Notification Protocol has been designed to complement the 91 Atom Publishing Protocol by providing the means of sending 92 notifications when Atom-based content is created or updated. 94 The Atom Notification Protocol works by POSTing Atom Entries or Atom 95 Feeds to a NotificationURI using HTTP POST. 97 As is the case with the Atom Publishing Protocol, this document does 98 not seek to specify the form of the URIs that are used. This 99 document does, however, specify the formats of the entities posted to 100 those URIs. 102 3. Functional Specification 104 3.1 NotificationURI 106 The NotificationURI is used to POST notifications. A notification 107 consists of a single Atom Entry or Atom Feed. The notification is 108 essentially a one-way operation that implies no semantics or action 109 on the part of the receiver. 111 3.1.1 Locating the NotificationURI 113 The NotificationURI can be discovered in one of two ways. 115 First, with an link element with a @rel of 'service.notification' in 116 the "head" element of an HTML document. 118 123 Second, using a "atom:notification" element as described in section 124 4.1. 126 3.1.2 Request 128 The request contains a filled-in Atom Entry or Atom Feed. 130 A notification request containing an Atom Entry is intended to notify 131 the receiving endpoint that a specific entry has been created or 132 updated. 134 A notification request containing an Atom Feed is intended to notify 135 the receiving endpoint that a specific feed has been created or 136 updated. 138 Atom Entries POSTed to a NotificationURI MAY contain a "atom:head" 139 element that identifies the feed to which the entry belongs. 141 Atom Feeds POSTed to a NotificationURI MUST NOT contain any 142 "atom:entry" elements and SHOULD consist of only a minimal 143 "atom:head" element using as few optional elements as possible. 145 146 148 149 Example Feed 150 151 2003-12-13T18:30:02Z 152 153 John Doe 154 155 156 158 3.1.3 Response 160 The possible HTTP status codes from a POST are 202, 400 or 500. 162 3.1.3.1 Response Code 202 164 A response code of 202 indicates that the notification was 165 successfully received and accepted. The body of the message SHOULD 166 be empty. 168 3.1.3.2 Response Code 400 170 A response code of 400 indicates that the server believes the data 171 sent constitutes an invalid request. For example, the data received 172 may not be a well-formed Atom entry or feed. The server SHOULD 173 include an entity containing an explanation of the error situation 174 and whether it is a temporary or permanent condition. 176 3.1.3.3 Response Code 500 178 A response code of 500 indicates that the server detected an internal 179 error while processing the notification request. The server SHOULD 180 include an entity containing an explanation of the error situation, 181 and whether it is a temporary or permanent condition. 183 4. Atom Syntax Extensions 185 4.1 "atom:notification" Element 187 The "atom:notification" element is a Service construct that conveys 188 the URI used to receive notifications related to an entry or feed. 189 No more than one "atom:notification" element may be added to the 190 "atom:head" or "atom:entry" elements. The "atom:notification" 191 element uses the same namespace URI as the Atom core elements. 193 194 196 197 Example Feed 198 199 2003-12-13T18:30:02Z 200 201 John Doe 202 203 204 205 206 Atom-Powered Robots Run Amok 207 208 vemmi://example.org/2003/32397 209 2003-12-13T18:30:02Z 210 211 212 214 5. Security Considerations 216 The decision of whether or not to secure the Atom Notification 217 Protocol will be made on a case-by-case decision. Some notification 218 endpoints may be restricted to known authenticated users while others 219 will be open for anyone who wishes to post notifications. If a given 220 NotificationURI is restricted, the same authentication mechanisms 221 used by the Atom Publishing Protocol SHOULD be used. Because of 222 this, the Notification Protocol is open to the same threats as the 223 Publication Protocol. 225 One particular challenge that implementors of NotificationURI 226 endpoints will need to be aware of is the potential for denial of 227 service attacks and notification spamming. This document shall not 228 deal with potential solutions to such attacks. 230 6. IANA Considerations 232 This document has no actions for IANA. 234 7 References 236 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 237 Levels", BCP 14, RFC 2119, March 1997. 239 [2] Gregorio, J., Ed. and R. Sayre, Ed., "The Atom Publishing 240 Protocol", draft-ietf-atompub-protocol-02 (work in progress), 241 September 2004. 243 [3] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication 244 Format", draft-ietf-atompub-format-03 (work in progress), 245 October 2004. 247 Author's Address 249 James M Snell 251 EMail: james@snellspace.com 252 URI: http://www.snellspace.com 254 Intellectual Property Statement 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org. 278 Disclaimer of Validity 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Copyright Statement 290 Copyright (C) The Internet Society (2004). This document is subject 291 to the rights, licenses and restrictions contained in BCP 78, and 292 except as set forth therein, the authors retain all their rights. 294 Acknowledgment 296 Funding for the RFC Editor function is currently provided by the 297 Internet Society.