idnits 2.17.1
draft-snell-atompub-feed-thread-08.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 375.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 352.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 359.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 365.
** 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 11, 2006) is 6590 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 11, 2006
4 Expires: October 13, 2006
6 Atom Threading Extensions
7 draft-snell-atompub-feed-thread-08.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 13, 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. Security Considerations . . . . . . . . . . . . . . . . . . . 8
50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
51 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
52 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
53 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
54 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
56 Intellectual Property and Copyright Statements . . . . . . . . . . 11
58 1. Introduction
60 This document defines an extension for expressing threaded
61 discussions within the Atom Syndication Format [RFC4287].
63 2. Notational Conventions
65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
67 document are to be interpreted as described in BCP 14, [RFC2119], as
68 scoped to those conformance targets.
70 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
71 elements and attributes described in this specification is:
72 http://purl.org/syndication/thread/1.0
74 In this document, the namespace prefix "thr:" is used for the above
75 Namespace URI.
77 This specification uses a shorthand form of terms from the XML
78 Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information
79 Item" is omitted when naming Element and Attribute Information Items.
80 Therefore, when this specification uses the term "element," it is
81 referring to an Element Information Item in Infoset terms. Likewise,
82 when this specification uses the term "attribute," it is referring to
83 an Attribute Information Item.
85 Some sections of this specification are illustrated with a non-
86 normative RELAX NG Compact schema [RELAXNG]. However, the text of
87 this specification provides the definition of conformance.
89 This specification uses the atomCommonAttributes, atomURI, and
90 atomMediaType constructs as defined in [RFC4287].
92 3. The 'in-reply-to' extension element
94 The "in-reply-to" extension element is used to indicate that a feed
95 entry is a response to another resource. The element MUST contain
96 either or both the "ref" and "href" attributes.
98 in-reply-to =
99 element thr:in-reply-to {
100 atomCommonAttributes,
101 ( ref, source?
102 | href, type?
103 | ref, source?, href, type? )
104 }
106 ref = attribute ref { atomURI }
107 href = attribute href { atomURI }
108 type = attribute type { atomMediaType }
109 source = attribute source { atomURI }
111 The "ref" attribute specifies the universally unique identifier of
112 the resource being responded to. The value of the attribute MUST
113 conform to the same construction and comparison rules as the atom:id
114 element. The "source" attribute MAY be used to specify the IRI
115 [RFC3987] of an Atom Feed or Entry Document within which an atom:
116 entry with an atom:id value equal to the value of the "ref" attribute
117 may be found.
119 The "href" attribute specifies an IRI that may be used to retrieve a
120 representation of the resource being responded to. The "type"
121 attribute MAY be used to identify the media type [RFC4288] of the
122 resource identified by the "href" attribute.
124 Atom feed, entry and source elements MAY each contain any number of
125 "in-reply-to" extension elements but SHOULD NOT contain more than one
126 having the same "ref" value.
128 An example entry with a response,
130
132 http://www.example.org/myfeed
133 My Example Feed
134 2005-07-28T12:00:00Z
135
136 James
137
138 tag:example.org,2005:1
139 My original entry
140 2006-03-01T12:12:12Z
141
144 This is my original entry
145
146
147 tag:example.org,2005:1,1
148 A response to the original
149 2006-03-01T12:12:12Z
150
151
155 This is a response to the original entry
156
157
159 To allow Atom clients that are not familiar with the in-reply-to
160 extension to know that a relationship exists between the entry and
161 the resource being responded to, publishers are advised to consider
162 including a "related" link referencing a representation of the
163 resource identified by the in-reply-to element.
165 For example
167
169 http://www.example.org/myfeed
170 My Example Feed
171 2005-07-28T12:00:00Z
172
173 James
174
175 tag:example.org,2005:1,1
176 A response to the original
177 2006-03-01T12:12:12Z
178
179
184
188 This is a response to the original entry
189
190
192 4. The 'replies' link relation
194 While responses to an atom:entry may appear within the same feed
195 document as the resource being responded to, it is common practice to
196 separate responses into a separate feed document or other resource.
197 In such cases, it is helpful for an atom:feed or atom:entry to
198 indicate the location where responses may be found. An atom:link
199 element with the "rel" attribute value "replies" is used for this
200 purpose. If the type attribute of the atom:link is omitted, it's
201 value is assumed to be "application/atom+xml".
203 Atom feed, entry and source elements MAY each contain any number of
204 "replies" atom:link elements but SHOULD NOT contain more than one
205 having the same "type" and "href" attribute values.
207 A "replies" link appearing as a child of the Atom feed or source
208 element indicates that the referenced resource may contain responses
209 to any of the feeds entries. A "replies" link appearing as a child
210 of an Atom entry element indicates that the referenced resource may
211 contain responses specific to that entry.
213 Atom links using the "replies" rel attribute value MAY contain a
214 "thr:count" attribute whose value is a non-negative integer
215 indicating the total number of replies contained by the linked
216 resource. The value is strictly advisory and may not accurately
217 reflect the actual number of replies.
219 Reply links MAY also contain a "thr:when" attribute whose value is a
220 [RFC3339] date-time stamp conforming to the same construction rules
221 as the Atom Date Construct defined in [RFC4287], and is used to
222 indicate the date and time of the most recent reply contained by the
223 linked resource. The value is strictly advisory and may not
224 accurately reflect the actual date and time of the most recent reply.
226 For example, replies contained in a separate Atom feed
228
230 http://www.example.org/myfeed
231 My Example Feed
232 2005-07-28T12:00:00Z
233
234 James
235
236 tag:entries.com,2005:1
237 My original entry
238 2006-03-01T12:12:12Z
239
240
245 This is my original entry
246
247
249 The presence of a "replies" link is merely a hint as to where
250 responses to entries may be found and does not guarantee that the
251 referenced resource contains any responses to any entries within the
252 containing feed.
254 The behavior of "replies" link relations specifying any media type
255 other than "application/atom+xml" is undefined. Software written to
256 conform to this version of the specification will not be guaranteed
257 to process such links correctly.
259 Implementors should note that while the Atom Syndication Format does
260 not forbid the inclusion of namespaced extension attributes on the
261 Atom link element, neither does it explicitly allow for such
262 extensions. As a result, the thr:count and thr:when attributes fall
263 under what [RFC4287] defines as "unknown foreign markup".
265 5. Security Considerations
267 As this specification defines an extension to the Atom Syndication
268 Format, it is subject to the same security considerations as defined
269 in [RFC4287].
271 Feeds using the mechanisms described here could be crafted in such a
272 way as to cause a consumer to initiate excessive (or even an unending
273 sequence of) network requests, causing denial of service (either to
274 the consumer, the target server, and/or intervening networks).
275 Consumers can mitigate this risk by requiring user intervention after
276 a certain number of requests, or by limiting requests either
277 according to a hard limit, or with heuristics.
279 Consumers should be mindful of resource limits when storing feed
280 documents; to reiterate, they are not required to always store or
281 reconstruct the feed when conforming to this specification; they only
282 need inform the user when the reconstructed feed is not complete.
284 6. IANA Considerations
286 This specification defines one new Atom link relation type to be
287 registered in the IANA Registry of Link Relation as defined by
288 [RFC4287].
289 Attribute Value: replies
290 Description: (see section 4)
291 Expected display characteristics: None
292 Security considerations: (see section 5)
294 7. References
296 7.1. Normative References
298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
299 Requirement Levels", BCP 14, RFC 2119, March 1997.
301 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
302 Timestamps", RFC 3339, July 2002.
304 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
305 Identifiers (IRIs)", RFC 3987, January 2005.
307 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
308 Format", RFC 4287, December 2005.
310 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
311 Registration Procedures", BCP 13, RFC 4288, December 2005.
313 [W3C.REC-xml-infoset-20040204]
314 Tobin, R. and J. Cowan, "XML Information Set (Second
315 Edition)", W3C REC REC-xml-infoset-20040204,
316 February 2004.
318 [W3C.REC-xml-names-19990114]
319 Hollander, D., Bray, T., and A. Layman, "Namespaces in
320 XML", W3C REC REC-xml-names-19990114, January 1999.
322 7.2. Informative References
324 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001,
325 .
328 Appendix A. Acknowledgements
330 The author gratefully acknowledges the feedback from James
331 Holderness, Byrne Reese, Aristotle Pagaltzis, and the remaining
332 members of the Atom Publishing Format and Protocol working group
333 during the development of this specification.
335 Author's Address
337 James M Snell
339 Phone:
340 Email: jasnell@gmail.com
341 URI: http://www.snellspace.com
343 Intellectual Property Statement
345 The IETF takes no position regarding the validity or scope of any
346 Intellectual Property Rights or other rights that might be claimed to
347 pertain to the implementation or use of the technology described in
348 this document or the extent to which any license under such rights
349 might or might not be available; nor does it represent that it has
350 made any independent effort to identify any such rights. Information
351 on the procedures with respect to rights in RFC documents can be
352 found in BCP 78 and BCP 79.
354 Copies of IPR disclosures made to the IETF Secretariat and any
355 assurances of licenses to be made available, or the result of an
356 attempt made to obtain a general license or permission for the use of
357 such proprietary rights by implementers or users of this
358 specification can be obtained from the IETF on-line IPR repository at
359 http://www.ietf.org/ipr.
361 The IETF invites any interested party to bring to its attention any
362 copyrights, patents or patent applications, or other proprietary
363 rights that may cover technology that may be required to implement
364 this standard. Please address the information to the IETF at
365 ietf-ipr@ietf.org.
367 Disclaimer of Validity
369 This document and the information contained herein are provided on an
370 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
371 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
372 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
373 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
374 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
375 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
377 Copyright Statement
379 Copyright (C) The Internet Society (2006). This document is subject
380 to the rights, licenses and restrictions contained in BCP 78, and
381 except as set forth therein, the authors retain all their rights.
383 Acknowledgment
385 Funding for the RFC Editor function is currently provided by the
386 Internet Society.