idnits 2.17.1
draft-snell-atompub-feed-thread-11.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 511.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 488.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 495.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 501.
** 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 exact meaning of the all-uppercase expression 'MAY NOT' is not
defined in RFC 2119. If it is intended as a requirements expression, it
should be rewritten using one of the combinations defined in RFC 2119;
otherwise it should not be all-uppercase.
== The expression 'MAY NOT', while looking like RFC 2119 requirements text,
is not defined in RFC 2119, and should not be used. Consider using 'MUST
NOT' instead (if that is what you mean).
Found 'MAY NOT' in this paragraph:
Lastly, implementors need to be aware that while the Atom
specification [RFC4287] explicitly allows the link element to contain
arbitrary extensions, the specification does not require that
implementations support such extensions. Specifically, relating to the
use of extensions, Atom does not define any level of mandatory
conformance on the part of feed consumers beyond a requirement that
implementations ignore any extension the implementation does not
understand. As a result, some implementations MAY NOT be capable of
fully utilizing the extensions defined by this or any specification.
-- 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 (May 23, 2006) is 6547 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)
-- Obsolete informational reference (is this intentional?): RFC 2822
(Obsoleted by RFC 5322)
Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Snell
3 Internet-Draft May 23, 2006
4 Expires: November 24, 2006
6 Atom Threading Extensions
7 draft-snell-atompub-feed-thread-11.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 November 24, 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:total' Element . . . . . . . . . . . . . . . . . . . 8
50 6. Considerations for using thr:count, thr:updated and
51 thr:total . . . . . . . . . . . . . . . . . . . . . . . . . . 8
52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
54 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
55 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
56 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
59 Intellectual Property and Copyright Statements . . . . . . . . . . 13
61 1. Introduction
63 This document defines an extension for expressing threaded
64 discussions within the Atom Syndication Format [RFC4287].
66 2. 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 BCP 14, [RFC2119], as
71 scoped to those conformance targets.
73 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
74 elements and attributes described in this specification is:
75 http://purl.org/syndication/thread/1.0
77 In this document, the namespace prefix "thr:" is used for the above
78 Namespace URI. Note that the choice of namespace prefix is arbitrary
79 and not semantically significant.
81 This specification uses a shorthand form of terms from the XML
82 Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information
83 Item" is omitted when naming Element and Attribute Information Items.
84 Therefore, when this specification uses the term "element," it is
85 referring to an Element Information Item in Infoset terms. Likewise,
86 when this specification uses the term "attribute," it is referring to
87 an Attribute Information Item.
89 This specification allows the use of IRIs [RFC3987]. Every URI
90 [RFC3986] is also an IRI, so a URI may be used wherever an IRI is
91 named. When an IRI that is not also a URI is given for
92 dereferencing, it MUST be mapped to a URI using the steps in Section
93 3.1 of [RFC3987]. When an IRI is serving as an identifier, it MUST
94 NOT be so mapped.
96 Some sections of this specification are illustrated with a non-
97 normative RELAX NG Compact schema [RELAXNG]. In those sections this
98 specification uses the atomCommonAttributes, atomMediaType and
99 atomURI patterns defined in [RFC4287].
101 However, the text of this specification provides the sole definition
102 of conformance.
104 3. The 'in-reply-to' extension element
106 The "in-reply-to" element is used to indicate that an entry is a
107 response to another resource. The element MUST contain a "ref"
108 attribute identifying the resource that is being responded to.
110 The element is not unlike the references and in-reply-to email
111 message headers defined by [RFC2822]. However, unlike the
112 in-reply-to header, the "in-reply-to" element is required to identify
113 the unique identifier of only a single parent resource. If the entry
114 is a response to multiple resources, additional "in-reply-to"
115 elements MAY be used. There is no direct equivalent to the
116 references header, which lists the unique identifiers of each
117 preceding message in a thread.
119 in-reply-to =
120 element thr:in-reply-to {
121 atomCommonAttributes,
122 ref,
123 href?,
124 source?,
125 type?,
126 ( undefinedContent )
127 }
129 ref = attribute ref { atomURI }
130 href = attribute href { atomURI }
131 type = attribute type { atomMediaType }
132 source = attribute source { atomURI }
134 The "ref" attribute specifies the persistent, universally unique
135 identifier of the resource being responded to. The value MUST
136 conform to the same construction and comparison rules as the value of
137 the atom:id element as defined in section 4.2.6 of [RFC4287]. Though
138 the IRI might use a dereferenceable scheme, processors MUST NOT
139 assume it can be dereferenced.
141 If the resource being responded to does not have a persistent,
142 universally unique identifier, an IRI used to retrieve a
143 representation of the resource SHOULD be used so long as that IRI can
144 also be used as a valid atom:id value and so long as the "href"
145 attribute is also specified.
147 The "source" attribute MAY be used to specify the IRI [RFC3987] of an
148 Atom Feed or Entry Document containing an atom:entry with an atom:id
149 value equal to the value of the "ref" attribute. The IRI specified,
150 once appropriately mapped to a corresponding URI, MUST be
151 dereferenceable.
153 The "href" attribute specifies an IRI that may be used to retrieve a
154 representation of the resource being responded to. The IRI
155 specified, once appropriately mapped to a corresponding URI, MUST be
156 dereferenceable.
158 The "type" attribute MAY be used to provide a hint to the client
159 about the media type [RFC4288] of the resource identified by the
160 "href" attribute. The "type" attribute is only meaningful if a
161 corresponding "href" attribute is also provided.
163 This specification assigns no significance to the order in which
164 multiple "in-reply-to" elements appear within an entry.
166 An example entry with a response,
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
177 My original entry
178 2006-03-01T12:12:12Z
179
182 This is my original entry
183
184
185 tag:example.org,2005:1,1
186 A response to the original
187 2006-03-01T12:12:12Z
188
189
193 This is a response to the original entry
194
195
197 To allow Atom processors that are not familiar with the in-reply-to
198 extension to know that a relationship exists between the entry and
199 the resource being responded to, publishers are advised to consider
200 including a "related" link referencing a representation of the
201 resource identified by the in-reply-to element. While such links are
202 unlikely to be processed as a reference to a predecessor in a
203 threaded conversation, they are helpful in at least establishing a
204 semantically meaningful relationship between the linked resources.
206 For example,
208
210 http://www.example.org/myfeed
211 My Example Feed
212 2005-07-28T12:00:00Z
213
214 James
215
216 tag:example.org,2005:1,1
217 A response to the original
218 2006-03-01T12:12:12Z
219
220
225
229 This is a response to the original entry
230
231
233 4. The 'replies' link relation
235 An Atom link element with a rel attribute value of "replies" may be
236 used to reference a resource where responses to an entry may be
237 found. If the type attribute of the atom:link is omitted, it's value
238 is assumed to be "application/atom+xml".
240 A "replies" link appearing as a child of the Atom feed or source
241 element indicates that the referenced resource likely contains
242 responses to any of that feeds entries. A "replies" link appearing
243 as a child of an Atom entry element indicates that the linked
244 resource likely contains responses specific to that entry.
246 An atom:link element using the "replies" rel attribute value MAY
247 contain a "thr:count" attribute whose value is an unsigned, non-
248 negative integer, conforming to the canonical representation of the
249 XML Schema nonNegativeInteger data type [W3C.REC-xmlschema-2-
250 20041028], that provides a hint to clients as to the total number of
251 replies contained by the linked resource. The value is advisory and
252 may not accurately reflect the actual number of replies.
254 The link MAY also contain a "thr:updated" attribute, whose value is a
255 [RFC3339] date-time stamp conforming to the same construction rules
256 as the Atom Date Construct defined in [RFC4287], and is used to
257 provide a hint to clients as to the date and time of the most
258 recently updated reply contained by the linked resource. The value
259 is advisory and may not accurately reflect the actual date and time
260 of the most recent reply.
262 For example,
264
266 http://www.example.org/myfeed
267 My Example Feed
268 2005-07-28T12:00:00Z
269
270 James
271
272 tag:entries.com,2005:1
273 My original entry
274 2006-03-01T12:12:12Z
275
276
280 This is my original entry
281
282
284 While Atom feed, entry and source elements MAY each contain any
285 number of atom:link elements using the "replies" link relation, this
286 specification assigns no significance to the presence or order of
287 such links. Multiple replies links appearing within an atom:entry
288 may reference alternative representations of the same set of
289 responses, or may reference entirely distinct resources containing
290 distinct sets of responses. Processors MUST NOT assume that multiple
291 replies links are referencing different representations of the same
292 resource and MUST process each replies link independently of any
293 others.
295 5. The 'thr:total' Element
297 The "thr:total" element is used to indicate the total number of
298 unique responses to an entry known to the publisher. Its content
299 MUST be an unsigned non-negative integer value conforming to the
300 canonical representation of the XML Schema nonNegativeInteger data
301 type [W3C.REC-xmlschema-2-20041028].
303 total = element thr:total { xsd:nonNegativeInteger }
305 Atom entries MAY contain a "thr:total" element, but MUST NOT contain
306 more than one.
308 There is no implied relationship between the value of the "thr:total"
309 element of an Atom entry and any individual or aggregate values of
310 the "thr:count" attributes of its Atom link elements having a
311 "replies" relation.
313 6. Considerations for using thr:count, thr:updated and thr:total
315 The thr:count, thr:updated and thr:total extensions provide
316 additional metadata about the thread of discussion associated with an
317 entry. The values are intended to make it easier for feed consumers
318 to display basic contextual information about the thread without
319 requiring those consumers to dereference, parse and analyze the
320 linked resource. That said, there are a number of considerations
321 implementors need to be aware of.
323 First, these extensions MUST NOT be assumed to provide completely
324 accurate information about the thread of discussion. That is, for
325 instance, the actual total number of responses contained by a linked
326 resource MAY differ than the number specified in the thr:count
327 attribute. Feed publishers SHOULD make an effort to ensure that the
328 values are accurate. The non-authoritative nature of "external
329 reference metadata", like the replies link attributes, is discussed
330 in detail in section 3.3 of the W3C document "Tag Finding 12:
331 Authoritative Metadata" [TAG12].
333 Second, the values of the these extensions are volatile and may
334 change at a faster rate than the containing entry. Frequent updates
335 to these values, or to any part of the Atom document, could have a
336 detrimental impact on the cacheability of the document using the
337 attributes, leading to an increase in overall bandwidth consumption.
339 Feed publishers SHOULD consider a change to the values of the thr:
340 count, thr:updated and thr:replies extensions to be an
341 "insignificant" update in terms of [RFC4287], meaning that the value
342 of the containing feed, entry or source element's atom:updated
343 element SHOULD NOT be affected by a change to the values of these
344 extensions.
346 Lastly, implementors need to be aware that while the Atom
347 specification [RFC4287] explicitly allows the link element to contain
348 arbitrary extensions, the specification does not require that
349 implementations support such extensions. Specifically, relating to
350 the use of extensions, Atom does not define any level of mandatory
351 conformance on the part of feed consumers beyond a requirement that
352 implementations ignore any extension the implementation does not
353 understand. As a result, some implementations MAY NOT be capable of
354 fully utilizing the extensions defined by this or any specification.
356 7. Security Considerations
358 As this specification defines an extension to the Atom Syndication
359 Format, it is subject to the same security considerations as defined
360 in [RFC4287].
362 Feeds using the mechanisms described here could be crafted in such a
363 way as to cause a consumer to initiate excessive (or even an unending
364 sequence of) network requests, causing denial of service (either to
365 the consumer, the target server, and/or intervening networks).
366 Consumers can mitigate this risk by requiring user intervention after
367 a certain number of requests, or by limiting requests either
368 according to a hard limit, or with heuristics.
370 The mechanisms described here can be used to construct threaded
371 conversations spanning resources distributed across multiple domains.
372 For example, an individual posting an entry to one weblog hosted on
373 one Internet domain could mark that entry as a response to an entry
374 from a different weblog hosted on a different domain. Implementors
375 should not that such distributed responses could be leveraged by an
376 attacker to attach inappropriate or unwanted content to a discussion.
377 Such attacks can be prevented or mitigated by allowing users to
378 explicitly configure the sources from which responses may be
379 retrieved, or by applying heuristics to determine the legitimacy of a
380 given response source.
382 Implementors should also note the potential for abuse that exists
383 when malicious content publishers edit or change previously published
384 content. In closed, centralized comment systems, after-the-fact
385 editing of comments is typically not an issue as such changes are
386 easily prevented, detected or tracked. With the form of distributed
387 comments enabled through the use of the thr:in-reply-to extension,
388 however, such changes become more difficult to detect, raising the
389 possibility of serious attribution and repudiation concerns. One
390 possible approach to mitigating these concerns is through the use of
391 XML Digital signatures as specified in Section 5.1 of [RFC4287],
392 however, the presence of a valid XML Digital Signature within an
393 entry does not, by itself, provide a reliable defense against
394 repudiation issues.
396 8. IANA Considerations
398 This specification defines one new Atom link relation type to be
399 registered in the IANA Registry of Link Relation as defined by
400 [RFC4287].
402 Attribute Value: replies
403 Description: (see section 4)
404 Expected display characteristics: (see section 4)
405 Security considerations: (see section 5)
407 9. References
409 9.1. Normative References
411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
412 Requirement Levels", BCP 14, RFC 2119, March 1997.
414 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
415 Timestamps", RFC 3339, July 2002.
417 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
418 Resource Identifier (URI): Generic Syntax", STD 66,
419 RFC 3986, January 2005.
421 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
422 Identifiers (IRIs)", RFC 3987, January 2005.
424 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
425 Format", RFC 4287, December 2005.
427 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
428 Registration Procedures", BCP 13, RFC 4288, December 2005.
430 [W3C.REC-xml-infoset-20040204]
431 Tobin, R. and J. Cowan, "XML Information Set (Second
432 Edition)", W3C REC REC-xml-infoset-20040204,
433 February 2004.
435 [W3C.REC-xml-names-19990114]
436 Hollander, D., Bray, T., and A. Layman, "Namespaces in
437 XML", W3C REC REC-xml-names-19990114, January 1999.
439 [W3C.REC-xmlschema-2-20041028]
440 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
441 Second Edition", W3C REC REC-xmlschema-2-20041028,
442 October 2004.
444 9.2. Informative References
446 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001,
447 .
450 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
451 April 2001.
453 [TAG12] Fielding, R. and I. Jacobs, "Tag Finding 12: Authoritative
454 Metadata",
455 .
457 Appendix A. Acknowledgements
459 The author gratefully acknowledges the feedback from Antone Roundy,
460 Aristotle Pagaltzis, Byrne Reese, David Powell, Eric Scheid, James
461 Holderness, John Panzer, Lisa Dusseault, M. David Peterson, Sam Ruby,
462 Sylvain Hellegouarch, and the remaining members of the Atom
463 Publishing Format and Protocol working group during the development
464 of this specification. Any fault or weakness in the definition of
465 this extension is solely the blame of the author.
467 Some portions of text in this document have been adapted from
468 [RFC4287] in order to maintain a stylistic and technical alignment
469 with that specification.
471 Author's Address
473 James M Snell
475 Phone:
476 Email: jasnell@gmail.com
477 URI: http://www.snellspace.com
479 Intellectual Property Statement
481 The IETF takes no position regarding the validity or scope of any
482 Intellectual Property Rights or other rights that might be claimed to
483 pertain to the implementation or use of the technology described in
484 this document or the extent to which any license under such rights
485 might or might not be available; nor does it represent that it has
486 made any independent effort to identify any such rights. Information
487 on the procedures with respect to rights in RFC documents can be
488 found in BCP 78 and BCP 79.
490 Copies of IPR disclosures made to the IETF Secretariat and any
491 assurances of licenses to be made available, or the result of an
492 attempt made to obtain a general license or permission for the use of
493 such proprietary rights by implementers or users of this
494 specification can be obtained from the IETF on-line IPR repository at
495 http://www.ietf.org/ipr.
497 The IETF invites any interested party to bring to its attention any
498 copyrights, patents or patent applications, or other proprietary
499 rights that may cover technology that may be required to implement
500 this standard. Please address the information to the IETF at
501 ietf-ipr@ietf.org.
503 Disclaimer of Validity
505 This document and the information contained herein are provided on an
506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
508 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
509 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
510 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
513 Copyright Statement
515 Copyright (C) The Internet Society (2006). This document is subject
516 to the rights, licenses and restrictions contained in BCP 78, and
517 except as set forth therein, the authors retain all their rights.
519 Acknowledgment
521 Funding for the RFC Editor function is currently provided by the
522 Internet Society.