idnits 2.17.1
draft-snell-atompub-feed-thread-09.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 14.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 443.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 420.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 427.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 433.
** 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.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
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 (April 2006) is 6584 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)
** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)
Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 2006
4 Expires: October 3, 2006
6 Atom Threading Extensions
7 draft-snell-atompub-feed-thread-09.txt
9 Status of this Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on October 3, 2006.
34 Copyright Notice
36 Copyright (C) The Internet Society (2006).
38 Abstract
40 This memo presents a mechanism that allows feeds publishers to
41 express threaded discussions within the Atom Syndication Format.
43 Table of Contents
45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
46 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
47 3. The 'in-reply-to' extension element . . . . . . . . . . . . . 3
48 4. The 'replies' link relation . . . . . . . . . . . . . . . . . 6
49 5. The 'thr:replies' Element . . . . . . . . . . . . . . . . . . 7
50 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
52 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
53 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
54 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
55 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
57 Intellectual Property and Copyright Statements . . . . . . . . . . 13
59 1. Introduction
61 This document defines an extension for expressing threaded
62 discussions within the Atom Syndication Format [RFC4287].
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], as
69 scoped to those conformance targets.
71 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
72 elements and attributes described in this specification is:
73 http://purl.org/syndication/thread/1.0
75 In this document, the namespace prefix "thr:" is used for the above
76 Namespace URI.
78 This specification uses a shorthand form of terms from the XML
79 Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information
80 Item" is omitted when naming Element and Attribute Information Items.
81 Therefore, when this specification uses the term "element," it is
82 referring to an Element Information Item in Infoset terms. Likewise,
83 when this specification uses the term "attribute," it is referring to
84 an Attribute Information Item.
86 Some sections of this specification are illustrated with a non-
87 normative RELAX NG Compact schema [RELAXNG]. However, the text of
88 this specification provides the definition of conformance.
90 This specification uses the atomCommonAttributes, atomURI, and
91 atomMediaType constructs as defined in [RFC4287].
93 3. The 'in-reply-to' extension element
95 The "in-reply-to" extension element is used to indicate that a feed
96 entry is a response to another resource. The element MUST contain
97 either or both the "ref" and "href" attributes.
99 in-reply-to =
100 element thr:in-reply-to {
101 atomCommonAttributes,
102 ( ref, source?
103 | href, type?
104 | ref, source?, href, type? )
105 }
107 ref = attribute ref { atomURI }
108 href = attribute href { atomURI }
109 type = attribute type { atomMediaType }
110 source = attribute source { atomURI }
112 The "ref" attribute specifies the universally unique identifier of
113 the resource being responded to. The value of the attribute MUST
114 conform to the same construction and comparison rules as the atom:id
115 element. The "source" attribute MAY be used to specify the IRI
116 [RFC3987] of an Atom Feed or Entry Document within which an atom:
117 entry with an atom:id value equal to the value of the "ref" attribute
118 may be found.
120 The "href" attribute specifies an IRI that may be used to retrieve a
121 representation of the resource being responded to. The "type"
122 attribute MAY be used to identify the media type [RFC4288] of the
123 resource identified by the "href" attribute.
125 Atom feed, entry and source elements MAY each contain any number of
126 "in-reply-to" extension elements but SHOULD NOT contain more than one
127 having the same "ref" value.
129 An example entry with a response,
131
133 http://www.example.org/myfeed
134 My Example Feed
135 2005-07-28T12:00:00Z
136
137 James
138
139 tag:example.org,2005:1
140 My original entry
141 2006-03-01T12:12:12Z
142
145 This is my original entry
146
147
148 tag:example.org,2005:1,1
149 A response to the original
150 2006-03-01T12:12:12Z
151
152
156 This is a response to the original entry
157
158
160 To allow Atom clients that are not familiar with the in-reply-to
161 extension to know that a relationship exists between the entry and
162 the resource being responded to, publishers are advised to consider
163 including a "related" link referencing a representation of the
164 resource identified by the in-reply-to element.
166 For example
168
170 http://www.example.org/myfeed
171 My Example Feed
172 2005-07-28T12:00:00Z
173
174 James
175
176 tag:example.org,2005:1,1
177 A response to the original
178 2006-03-01T12:12:12Z
179
180
185
189 This is a response to the original entry
190
191
193 4. The 'replies' link relation
195 While responses to an atom:entry may appear within the same feed
196 document as the resource being responded to, it is common practice to
197 separate responses into a separate feed document or other resource.
198 In such cases, it is helpful for an atom:feed or atom:entry to
199 indicate the location where responses may be found. An atom:link
200 element with the "rel" attribute value "replies" is used for this
201 purpose. If the type attribute of the atom:link is omitted, it's
202 value is assumed to be "application/atom+xml".
204 Atom feed, entry and source elements MAY each contain any number of
205 "replies" atom:link elements but SHOULD NOT contain more than one
206 having the same "type" and "href" attribute values.
208 A "replies" link appearing as a child of the Atom feed or source
209 element indicates that the referenced resource may contain responses
210 to any of the feeds entries. A "replies" link appearing as a child
211 of an Atom entry element indicates that the referenced resource may
212 contain responses specific to that entry.
214 For example, replies contained in a separate Atom feed
216
218 http://www.example.org/myfeed
219 My Example Feed
220 2005-07-28T12:00:00Z
221
222 James
223
224 tag:entries.com,2005:1
225 My original entry
226 2006-03-01T12:12:12Z
227
228
231 This is my original entry
232
233
235 The presence of a "replies" link is merely a hint as to where
236 responses to entries may be found and does not guarantee that the
237 referenced resource contains any responses to any entries within the
238 containing feed.
240 The behavior of "replies" link relations specifying any media type
241 other than "application/atom+xml" is undefined. Software written to
242 conform to this version of the specification will not be guaranteed
243 to process such links correctly.
245 5. The 'thr:replies' Element
247 In some cases, a feed publisher may wish to provide additional
248 metadata about a linked Web resource containing replies beyond what
249 the atom:link element allows. For instance, the feed publisher may
250 wish to identify the total number of known replies and the date and
251 time of the most recent reply, etc. The "thr:replies" element
252 provides a container for this metadata.
254 thrReplies = element thr:replies {
255 atomCommonAttributes,
256 attribute ref { atomUri },
257 attribute label { text }?,
258 attribute count { nonNegativeInteger }?,
259 attribute updated { date-time }?
260 ( extensionElement* )
262 }
264 The "thr:replies" element MUST contain a "ref" attribute whose value
265 is the universaly unique identifier of a Web resource that contains
266 replies to the containing entry. For instance, if a "replies" link
267 relation is used to point to an Atom Feed Document, the "ref"
268 attribute of the corresponding thr:replies element is the value of
269 that Atom Feed Document's atom:id. The value of the attribute MUST
270 conform to the same construction and comparison rules as the atom:id
271 element.
273 Atom entry elements MAY contain zero or more "thr:replies" elements
274 so long as each contains a different ref attribute value.
276 The "thr:replies" element MAY contain a "thr:label" attribute
277 specifying a Language-Sensitive human-readable label.
279 The "thr:replies" element SHOULD contain a "count" attribute whose
280 value is a non-negative integer indicating the total number of
281 replies contained by the identified resource. The value is strictly
282 advisory and may not accurately reflect the actual number of replies.
284 The "thr:replies" element MAY contain an "updated" attribute whose
285 value is a [RFC3339] date-time stamp conforming to the same
286 construction rules as the Atom Date Construct defined in [RFC4287],
287 and is used to indicate the date and time of the most recent reply
288 contained by the identified resource. The value is strictly advisory
289 and may not accurately reflect the actual date and time of the most
290 recent reply.
292 The "thr:replies" element MAY contain any number of namespaced
293 extension elements. For instance, an extension to the thr:replies
294 element may be used to identify the URI of an Atom Publishing
295 Protocol collection to which replies can be posted. Such extensions
296 MUST be handled as "Foreign Markup" as defined by [RFC4287].
298 For example,
300
302 tag:example.org,2006
303 Entries and Comments
304 ...
305
306 tag:example.org,2006:1
307 My Post
308 2006-05-01T08:08:08Z
309
311
314
317 ...
318
319
320 tag:example.org,2006:2
321 My Second Post
322 2006-05-01T09:09:09Z
323
325
328
329 ...
330
331
333 Here, the entry identified by the atom:id value
334 "tag:example.og,2006:1" has two replies in the resource identified by
335 the IRI "tag:example.org,2006:comments" and one reply included
336 directly within the Atom Feed Document.
338 6. Security Considerations
340 As this specification defines an extension to the Atom Syndication
341 Format, it is subject to the same security considerations as defined
342 in [RFC4287].
344 Feeds using the mechanisms described here could be crafted in such a
345 way as to cause a consumer to initiate excessive (or even an unending
346 sequence of) network requests, causing denial of service (either to
347 the consumer, the target server, and/or intervening networks).
348 Consumers can mitigate this risk by requiring user intervention after
349 a certain number of requests, or by limiting requests either
350 according to a hard limit, or with heuristics.
352 7. IANA Considerations
354 This specification defines one new Atom link relation type to be
355 registered in the IANA Registry of Link Relation as defined by
356 [RFC4287].
357 Attribute Value: replies
358 Description: (see section 4)
359 Expected display characteristics: (see section 4)
360 Security considerations: (see section 5)
362 8. References
364 8.1. Normative References
366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
367 Requirement Levels", BCP 14, RFC 2119, March 1997.
369 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
370 Timestamps", RFC 3339, July 2002.
372 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
373 Identifiers (IRIs)", RFC 3987, January 2005.
375 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
376 Format", RFC 4287, December 2005.
378 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
379 Registration Procedures", BCP 13, RFC 4288, December 2005.
381 [W3C.REC-xml-infoset-20040204]
382 Tobin, R. and J. Cowan, "XML Information Set (Second
383 Edition)", W3C REC REC-xml-infoset-20040204,
384 February 2004.
386 [W3C.REC-xml-names-19990114]
387 Hollander, D., Bray, T., and A. Layman, "Namespaces in
388 XML", W3C REC REC-xml-names-19990114, January 1999.
390 8.2. Informative References
392 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, .
396 Appendix A. Acknowledgements
398 The author gratefully acknowledges the feedback from James
399 Holderness, Byrne Reese, Aristotle Pagaltzis, and the remaining
400 members of the Atom Publishing Format and Protocol working group
401 during the development of this specification.
403 Author's Address
405 James M Snell
407 Phone:
408 Email: jasnell@gmail.com
409 URI: http://www.snellspace.com
411 Intellectual Property Statement
413 The IETF takes no position regarding the validity or scope of any
414 Intellectual Property Rights or other rights that might be claimed to
415 pertain to the implementation or use of the technology described in
416 this document or the extent to which any license under such rights
417 might or might not be available; nor does it represent that it has
418 made any independent effort to identify any such rights. Information
419 on the procedures with respect to rights in RFC documents can be
420 found in BCP 78 and BCP 79.
422 Copies of IPR disclosures made to the IETF Secretariat and any
423 assurances of licenses to be made available, or the result of an
424 attempt made to obtain a general license or permission for the use of
425 such proprietary rights by implementers or users of this
426 specification can be obtained from the IETF on-line IPR repository at
427 http://www.ietf.org/ipr.
429 The IETF invites any interested party to bring to its attention any
430 copyrights, patents or patent applications, or other proprietary
431 rights that may cover technology that may be required to implement
432 this standard. Please address the information to the IETF at
433 ietf-ipr@ietf.org.
435 Disclaimer of Validity
437 This document and the information contained herein are provided on an
438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
440 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
441 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
442 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
445 Copyright Statement
447 Copyright (C) The Internet Society (2006). This document is subject
448 to the rights, licenses and restrictions contained in BCP 78, and
449 except as set forth therein, the authors retain all their rights.
451 Acknowledgment
453 Funding for the RFC Editor function is currently provided by the
454 Internet Society.