idnits 2.17.1 draft-snell-atompub-notification-01.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 294. -- Found old boilerplate from RFC 3978, Section 5.5 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 540. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 556), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 316. ** 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 14 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. 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 (January 31, 2005) is 7026 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 503, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 507, 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-05 Summary: 7 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 January 31, 2005 3 Expires: August 1, 2005 5 The Atom Notification Protocol 6 draft-snell-atompub-notification-01 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 August 1, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 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. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 58 Intellectual Property and Copyright Statements . . . . . . . . 7 60 1. Introduction 62 The Atom Notification Protocol is an application-level protocol for 63 posting notification of new or updated content using HTTP and the 64 Atom Syndication Format. 66 1.1 Notational Conventions 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [1]. 72 1.2 Terminology 74 Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this 75 case, the fragment is a single 'entry' element and all its child 76 elements. Each Atom Entry describes a single Web resource, providing 77 metadata and optionally a textual representation of that resource. 79 Atom Head: atom:head elements are used within the Atom Syndication 80 Format as children of both the atom:feed and atom:entry elements to 81 provide information descriptive of the feed. 83 NotificationURI: A HTTP URI that is used to receive notifications 84 about new or updated Atom entries. 86 2. The Atom Notification Protocol Model 88 The Atom Notification Protocol has been designed to complement the 89 Atom Publishing Protocol by providing the means of sending 90 notifications when Atom-based content is modified in some way. 92 The Atom Notification Protocol works by POSTing atom:entry or 93 atom:head elements to a NotificationURI using HTTP POST. 95 As is the case with the Atom Publishing Protocol, this document does 96 not seek to specify the form of the URIs that are used. This 97 document does, however, specify the formats of the entities posted to 98 those URIs. 100 3. Functional Specification 102 3.1 NotificationURI 104 The NotificationURI is used to POST notifications. A notification 105 consists of a single atom:entry or atom:head element. The 106 notification is essentially a one-way operation that implies no 107 operational semantics or action on the part of the receiver. 109 3.1.1 Locating the NotificationURI 111 Because of the broad variety of cases in which the Atom Notification 112 Protocol may be used and the lack of any single operational semantic 113 for notifications beyond basic delivery, no single location mechanism 114 for NotificationURI's will be defined. This means that it is up to 115 specific application profiles to determine the best way to make the 116 NotificationURI known within the context of that application. 118 3.1.2 Request 120 The request contains a filled-in atom:entry or atom:head element. 122 A notification request containing an atom:entry is intended to notify 123 the receiving endpoint that a specific entry has been created or 124 updated. 126 A notification request containing an atom:head is intended to notify 127 the receiving endpoint that a specific feed described by the 128 atom:head has been created or updated. 130 atom:entry's POSTed to a NotificationURI SHOULD contain a atom:head 131 element that identifies the feed to which the entry belongs. 133 atom:head elements POSTed to a NotificationURI MUST have a version 134 attribute that identifies the Atom Syndication Format version used. 135 The version attribute is identical to the version attribute defined 136 for the atom:feed element in the Atom Syndication Format. 138 139 141 Example Feed 142 143 2003-12-13T18:30:02Z 144 145 John Doe 146 147 149 POST is the only method that SHOULD be supported by the 150 NotificationURI. Clients MUST NOT submit requests using any other 151 method to the NotificationURI. If a client submits a request using 152 any other method than POST, The NotificationURI SHOULD respond with a 153 405 Method Not Allowed response. 155 3.1.3 Response 157 The response to a notification POST MUST be an empty message. That 158 is, the message MUST NOT contain any content beyond the HTTP headers. 159 Clients MUST ignore any content that a NotificationURI implementation 160 happens to include. 162 3.1.3.1 2xx Response Codes 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 All other 2xx HTTP status codes SHOULD be treated as if they were 202 169 responses. 171 3.1.3.2 3xx Response Codes 173 A response code of 301 indicates that the NotificationURI has 174 permanently changed locations and that the client MUST NOT make any 175 further attempts to send notifications to this location. A new 176 location SHOULD be provided using the Location HTTP header field. 178 A response code of 302 indicates that the NotificationURI has 179 temporarily changed locations and that the client SHOULD reissue 180 their notification to the new location specified in the Location HTTP 181 header field but that future notifications should continue to be sent 182 to this location. 184 NotificationURI's SHOULD NOT return 300, 303, 304, 306 or 307 185 response codes. If a NotificationURI's does return any of these 186 codes, they MUST be ignored. 188 3.1.3.3 4xx Response Codes 190 All 4xx response codes are to be interpretted as they are defined in 191 the HTTP specification. 416 and 417 SHOULD NOT be issued by the 192 NotificationURI and MUST be ignored if they are. 194 3.1.3.4 5xx Response Codes 196 All 5xx response codes are to be interpretted as they are defined in 197 the HTTP specification. 199 4. Security Considerations 201 The decision of whether or not to secure the Atom Notification 202 Protocol will be made on a case-by-case decision. Some notification 203 endpoints may be restricted to known authenticated users while others 204 will be open for anyone who wishes to post notifications. If a given 205 NotificationURI is restricted, the same authentication mechanism(s) 206 used by the Atom Publishing Protocol SHOULD be used. 208 One particular challenge that implementors of NotificationURI 209 endpoints will need to be aware of is the potential for denial of 210 service attacks and notification spamming. This document shall not 211 deal with potential solutions to such attacks. 213 5. IANA Considerations 215 This document has no actions for IANA. 217 6 References 219 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 220 Levels", BCP 14, RFC 2119, March 1997. 222 [2] Gregorio, J., Ed. and R. Sayre, Ed., "The Atom Publishing 223 Protocol", draft-ietf-atompub-protocol-02 (work in progress), 224 September 2004. 226 [3] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication 227 Format", draft-ietf-atompub-format-05 (work in progress), 228 January 2005. 230 Author's Address 232 James M Snell 234 EMail: james@snellspace.com 235 URI: http://www.snellspace.com 237 Intellectual Property Statement 239 The IETF takes no position regarding the validity or scope of any 240 Intellectual Property Rights or other rights that might be claimed to 241 pertain to the implementation or use of the technology described in 242 this document or the extent to which any license under such rights 243 might or might not be available; nor does it represent that it has 244 made any independent effort to identify any such rights. Information 245 on the procedures with respect to rights in RFC documents can be 246 found in BCP 78 and BCP 79. 248 Copies of IPR disclosures made to the IETF Secretariat and any 249 assurances of licenses to be made available, or the result of an 250 attempt made to obtain a general license or permission for the use of 251 such proprietary rights by implementers or users of this 252 specification can be obtained from the IETF on-line IPR repository at 253 http://www.ietf.org/ipr. 255 The IETF invites any interested party to bring to its attention any 256 copyrights, patents or patent applications, or other proprietary 257 rights that may cover technology that may be required to implement 258 this standard. Please address the information to the IETF at 259 ietf-ipr@ietf.org. 261 Disclaimer of Validity 263 This document and the information contained herein are provided on an 264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 266 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 267 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 268 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 271 Copyright Statement 273 Copyright (C) The Internet Society (2005). This document is subject 274 to the rights, licenses and restrictions contained in BCP 78, and 275 except as set forth therein, the authors retain all their rights. 277 Acknowledgment 279 Funding for the RFC Editor function is currently provided by the 280 Internet Society. 282 Network Working Group J. Snell 284 Expires: August 1, 2005 286 The Atom Notification Protocol 287 draft-snell-atompub-notification-01 289 Status of this Memo 291 By submitting this Internet-Draft, I certify that any applicable 292 patent or other IPR claims of which I am aware have been disclosed, 293 and any of which I become aware will be disclosed, in accordance with 294 RFC 3668. 296 Internet-Drafts are working documents of the Internet Engineering 297 Task Force (IETF), its areas, and its working groups. Note that 298 other groups may also distribute working documents as 299 Internet-Drafts. 301 Internet-Drafts are draft documents valid for a maximum of six months 302 and may be updated, replaced, or obsoleted by other documents at any 303 time. It is inappropriate to use Internet-Drafts as reference 304 material or to cite them other than as "work in progress." 306 The list of current Internet-Drafts can be accessed at 307 http://www.ietf.org/ietf/1id-abstracts.txt. 309 The list of Internet-Draft Shadow Directories can be accessed at 310 http://www.ietf.org/shadow.html. 312 This Internet-Draft will expire on August 1, 2005. 314 Copyright Notice 316 Copyright (C) The Internet Society (2005). All Rights Reserved. 318 Abstract 320 This memo presents a protocol for posting notifications of new or 321 updated content using a combination of the Atom Syndication Format 322 and HTTP POSTs. 324 Table of Contents 326 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 327 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 328 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 329 2. The Atom Notification Protocol Model . . . . . . . . . . . . . 3 330 3. Functional Specification . . . . . . . . . . . . . . . . . . . 3 331 3.1 NotificationURI . . . . . . . . . . . . . . . . . . . . . 3 332 3.1.1 Locating the NotificationURI . . . . . . . . . . . . . 4 333 3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 4 334 3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5 335 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 336 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 337 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 338 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 339 Intellectual Property and Copyright Statements . . . . . . . . 7 341 1. Introduction 343 The Atom Notification Protocol is an application-level protocol for 344 posting notification of new or updated content using HTTP and the 345 Atom Syndication Format. 347 1.1 Notational Conventions 349 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 350 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 351 document are to be interpreted as described in [1]. 353 1.2 Terminology 355 Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this 356 case, the fragment is a single 'entry' element and all its child 357 elements. Each Atom Entry describes a single Web resource, providing 358 metadata and optionally a textual representation of that resource. 360 Atom Head: atom:head elements are used within the Atom Syndication 361 Format as children of both the atom:feed and atom:entry elements to 362 provide information descriptive of the feed. 364 NotificationURI: A HTTP URI that is used to receive notifications 365 about new or updated Atom entries. 367 2. The Atom Notification Protocol Model 369 The Atom Notification Protocol has been designed to complement the 370 Atom Publishing Protocol by providing the means of sending 371 notifications when Atom-based content is modified in some way. 373 The Atom Notification Protocol works by POSTing atom:entry or 374 atom:head elements to a NotificationURI using HTTP POST. 376 As is the case with the Atom Publishing Protocol, this document does 377 not seek to specify the form of the URIs that are used. This 378 document does, however, specify the formats of the entities posted to 379 those URIs. 381 3. Functional Specification 383 3.1 NotificationURI 385 The NotificationURI is used to POST notifications. A notification 386 consists of a single atom:entry or atom:head element. The 387 notification is essentially a one-way operation that implies no 388 operational semantics or action on the part of the receiver. 390 3.1.1 Locating the NotificationURI 392 Because of the broad variety of cases in which the Atom Notification 393 Protocol may be used and the lack of any single operational semantic 394 for notifications beyond basic delivery, no single location mechanism 395 for NotificationURI's will be defined. This means that it is up to 396 specific application profiles to determine the best way to make the 397 NotificationURI known within the context of that application. 399 3.1.2 Request 401 The request contains a filled-in atom:entry or atom:head element. 403 A notification request containing an atom:entry is intended to notify 404 the receiving endpoint that a specific entry has been created or 405 updated. 407 A notification request containing an atom:head is intended to notify 408 the receiving endpoint that a specific feed described by the 409 atom:head has been created or updated. 411 atom:entry's POSTed to a NotificationURI SHOULD contain a atom:head 412 element that identifies the feed to which the entry belongs. 414 atom:head elements POSTed to a NotificationURI MUST have a version 415 attribute that identifies the Atom Syndication Format version used. 416 The version attribute is identical to the version attribute defined 417 for the atom:feed element in the Atom Syndication Format. 419 420 422 Example Feed 423 424 2003-12-13T18:30:02Z 425 426 John Doe 427 428 430 POST is the only method that SHOULD be supported by the 431 NotificationURI. Clients MUST NOT submit requests using any other 432 method to the NotificationURI. If a client submits a request using 433 any other method than POST, The NotificationURI SHOULD respond with a 434 405 Method Not Allowed response. 436 3.1.3 Response 438 The response to a notification POST MUST be an empty message. That 439 is, the message MUST NOT contain any content beyond the HTTP headers. 440 Clients MUST ignore any content that a NotificationURI implementation 441 happens to include. 443 3.1.3.1 2xx Response Codes 445 A response code of 202 indicates that the notification was 446 successfully received and accepted. The body of the message SHOULD 447 be empty. 449 All other 2xx HTTP status codes SHOULD be treated as if they were 202 450 responses. 452 3.1.3.2 3xx Response Codes 454 A response code of 301 indicates that the NotificationURI has 455 permanently changed locations and that the client MUST NOT make any 456 further attempts to send notifications to this location. A new 457 location SHOULD be provided using the Location HTTP header field. 459 A response code of 302 indicates that the NotificationURI has 460 temporarily changed locations and that the client SHOULD reissue 461 their notification to the new location specified in the Location HTTP 462 header field but that future notifications should continue to be sent 463 to this location. 465 NotificationURI's SHOULD NOT return 300, 303, 304, 306 or 307 466 response codes. If a NotificationURI's does return any of these 467 codes, they MUST be ignored. 469 3.1.3.3 4xx Response Codes 471 All 4xx response codes are to be interpretted as they are defined in 472 the HTTP specification. 416 and 417 SHOULD NOT be issued by the 473 NotificationURI and MUST be ignored if they are. 475 3.1.3.4 5xx Response Codes 477 All 5xx response codes are to be interpretted as they are defined in 478 the HTTP specification. 480 4. Security Considerations 482 The decision of whether or not to secure the Atom Notification 483 Protocol will be made on a case-by-case decision. Some notification 484 endpoints may be restricted to known authenticated users while others 485 will be open for anyone who wishes to post notifications. If a given 486 NotificationURI is restricted, the same authentication mechanism(s) 487 used by the Atom Publishing Protocol SHOULD be used. 489 One particular challenge that implementors of NotificationURI 490 endpoints will need to be aware of is the potential for denial of 491 service attacks and notification spamming. This document shall not 492 deal with potential solutions to such attacks. 494 5. IANA Considerations 496 This document has no actions for IANA. 498 6 References 500 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 501 Levels", BCP 14, RFC 2119, March 1997. 503 [2] Gregorio, J., Ed. and R. Sayre, Ed., "The Atom Publishing 504 Protocol", draft-ietf-atompub-protocol-02 (work in progress), 505 September 2004. 507 [3] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication 508 Format", draft-ietf-atompub-format-05 (work in progress), 509 January 2005. 511 Author's Address 513 James M Snell 515 EMail: james@snellspace.com 516 URI: http://www.snellspace.com 518 Intellectual Property Statement 520 The IETF takes no position regarding the validity or scope of any 521 Intellectual Property Rights or other rights that might be claimed to 522 pertain to the implementation or use of the technology described in 523 this document or the extent to which any license under such rights 524 might or might not be available; nor does it represent that it has 525 made any independent effort to identify any such rights. Information 526 on the procedures with respect to rights in RFC documents can be 527 found in BCP 78 and BCP 79. 529 Copies of IPR disclosures made to the IETF Secretariat and any 530 assurances of licenses to be made available, or the result of an 531 attempt made to obtain a general license or permission for the use of 532 such proprietary rights by implementers or users of this 533 specification can be obtained from the IETF on-line IPR repository at 534 http://www.ietf.org/ipr. 536 The IETF invites any interested party to bring to its attention any 537 copyrights, patents or patent applications, or other proprietary 538 rights that may cover technology that may be required to implement 539 this standard. Please address the information to the IETF at 540 ietf-ipr@ietf.org. 542 Disclaimer of Validity 544 This document and the information contained herein are provided on an 545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 547 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 548 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 549 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Copyright Statement 554 Copyright (C) The Internet Society (2005). This document is subject 555 to the rights, licenses and restrictions contained in BCP 78, and 556 except as set forth therein, the authors retain all their rights. 558 Acknowledgment 560 Funding for the RFC Editor function is currently provided by the 561 Internet Society.