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.