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.