idnits 2.17.1
draft-snell-atompub-feed-thread-12.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 510.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 487.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 494.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 500.
** 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 25, 2006) is 6540 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 25, 2006
4 Expires: November 26, 2006
6 Atom Threading Extensions
7 draft-snell-atompub-feed-thread-12.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 26, 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 'total' extension element . . . . . . . . . . . . . . . . 8
50 6. Considerations for using thr:count, thr:updated and total . . 8
51 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
52 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
53 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
54 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
55 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
56 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
58 Intellectual Property and Copyright Statements . . . . . . . . . . 13
60 1. Introduction
62 This document defines an extension for expressing threaded
63 discussions within the Atom Syndication Format [RFC4287].
65 2. Notational Conventions
67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
69 document are to be interpreted as described in BCP 14, [RFC2119], as
70 scoped to those conformance targets.
72 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
73 elements and attributes described in this specification is:
74 http://purl.org/syndication/thread/1.0
76 In this document, the namespace prefix "thr:" is used for the above
77 Namespace URI. Note that the choice of namespace prefix is arbitrary
78 and not semantically significant.
80 This specification uses a shorthand form of terms from the XML
81 Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information
82 Item" is omitted when naming Element and Attribute Information Items.
83 Therefore, when this specification uses the term "element," it is
84 referring to an Element Information Item in Infoset terms. Likewise,
85 when this specification uses the term "attribute," it is referring to
86 an Attribute Information Item.
88 This specification allows the use of IRIs [RFC3987]. Every URI
89 [RFC3986] is also an IRI, so a URI may be used wherever an IRI is
90 named. When an IRI that is not also a URI is given for
91 dereferencing, it MUST be mapped to a URI using the steps in Section
92 3.1 of [RFC3987]. When an IRI is serving as an identifier, it MUST
93 NOT be so mapped.
95 Some sections of this specification are illustrated with a non-
96 normative RELAX NG Compact schema [RELAXNG]. In those sections this
97 specification uses the atomCommonAttributes, atomMediaType and
98 atomURI patterns defined in [RFC4287].
100 However, the text of this specification provides the sole definition
101 of conformance.
103 3. The 'in-reply-to' extension element
105 The "in-reply-to" element is used to indicate that an entry is a
106 response to another resource. The element MUST contain a "ref"
107 attribute identifying the resource that is being responded to.
109 The element is not unlike the references and in-reply-to email
110 message headers defined by [RFC2822]. However, unlike the
111 in-reply-to header, the "in-reply-to" element is required to identify
112 the unique identifier of only a single parent resource. If the entry
113 is a response to multiple resources, additional "in-reply-to"
114 elements MAY be used. There is no direct equivalent to the
115 references header, which lists the unique identifiers of each
116 preceding message in a thread.
118 in-reply-to =
119 element thr:in-reply-to {
120 atomCommonAttributes,
121 ref,
122 href?,
123 source?,
124 type?,
125 ( undefinedContent )
126 }
128 ref = attribute ref { atomURI }
129 href = attribute href { atomURI }
130 type = attribute type { atomMediaType }
131 source = attribute source { atomURI }
133 The "ref" attribute specifies the persistent, universally unique
134 identifier of the resource being responded to. The value MUST
135 conform to the same construction and comparison rules as the value of
136 the atom:id element as defined in section 4.2.6 of [RFC4287]. Though
137 the IRI might use a dereferenceable scheme, processors MUST NOT
138 assume it can be dereferenced.
140 If the resource being responded to does not have a persistent,
141 universally unique identifier, the publisher MUST assign an
142 identifier that satisfies all the considerations in section 4.2.6 of
143 [RFC4287] for use as the value of the "ref" attribute. In that case,
144 if a representation of the resource can be retrieved from an IRI that
145 can be used as a valid atom:id value, then this IRI SHOULD be used as
146 the value of both the "ref" and "href" attributes.
148 The "source" attribute MAY be used to specify the IRI [RFC3987] of an
149 Atom Feed or Entry Document containing an atom:entry with an atom:id
150 value equal to the value of the "ref" attribute. The IRI specified,
151 once appropriately mapped to a corresponding URI, MUST be
152 dereferenceable.
154 The "href" attribute specifies an IRI that may be used to retrieve a
155 representation of the resource being responded to. The IRI
156 specified, once appropriately mapped to a corresponding URI, MUST be
157 dereferenceable.
159 The "type" attribute MAY be used to provide a hint to the client
160 about the media type [RFC4288] of the resource identified by the
161 "href" attribute. The "type" attribute is only meaningful if a
162 corresponding "href" attribute is also provided.
164 This specification assigns no significance to the order in which
165 multiple "in-reply-to" elements appear within an entry.
167 An example entry with a response,
169
171 http://www.example.org/myfeed
172 My Example Feed
173 2005-07-28T12:00:00Z
174
175 James
176
177 tag:example.org,2005:1
178 My original entry
179 2006-03-01T12:12:12Z
180
183 This is my original entry
184
185
186 tag:example.org,2005:1,1
187 A response to the original
188 2006-03-01T12:12:12Z
189
190
194 This is a response to the original entry
195
196
198 To allow Atom processors that are not familiar with the in-reply-to
199 extension to know that a relationship exists between the entry and
200 the resource being responded to, publishers are advised to consider
201 including a "related" link referencing a representation of the
202 resource identified by the in-reply-to element. While such links are
203 unlikely to be processed as a reference to a predecessor in a
204 threaded conversation, they are helpful in at least establishing a
205 semantically meaningful relationship between the linked resources.
207 For example,
209
211 http://www.example.org/myfeed
212 My Example Feed
213 2005-07-28T12:00:00Z
214
215 James
216
217 tag:example.org,2005:1,1
218 A response to the original
219 2006-03-01T12:12:12Z
220
221
226
230 This is a response to the original entry
231
232
234 4. The 'replies' link relation
236 An Atom link element with a rel attribute value of "replies" may be
237 used to reference a resource where responses to an entry may be
238 found. If the type attribute of the atom:link is omitted, its value
239 is assumed to be "application/atom+xml".
241 A "replies" link appearing as a child of the Atom feed or source
242 element indicates that the referenced resource likely contains
243 responses to any of that feed's entries. A "replies" link appearing
244 as a child of an Atom entry element indicates that the linked
245 resource likely contains responses specific to that entry.
247 An atom:link element using the "replies" rel attribute value MAY
248 contain a "thr:count" attribute whose value is an unsigned, non-
249 negative integer, conforming to the canonical representation of the
250 XML Schema nonNegativeInteger data type [W3C.REC-xmlschema-2-
251 20041028], that provides a hint to clients as to the total number of
252 replies contained by the linked resource. The value is advisory and
253 may not accurately reflect the actual number of replies.
255 The link MAY also contain a "thr:updated" attribute, whose value is a
256 [RFC3339] date-time stamp conforming to the same construction rules
257 as the Atom Date Construct defined in [RFC4287], and is used to
258 provide a hint to clients as to the date and time of the most
259 recently updated reply contained by the linked resource. The value
260 is advisory and may not accurately reflect the actual date and time
261 of the most recent reply.
263 For example,
265
267 http://www.example.org/myfeed
268 My Example Feed
269 2005-07-28T12:00:00Z
270
271 James
272
273 tag:entries.com,2005:1
274 My original entry
275 2006-03-01T12:12:12Z
276
277
281 This is my original entry
282
283
285 While Atom feed, entry and source elements MAY each contain any
286 number of atom:link elements using the "replies" link relation, this
287 specification assigns no significance to the presence or order of
288 such links. Multiple replies links appearing within an atom:entry
289 may reference alternative representations of the same set of
290 responses, or may reference entirely distinct resources containing
291 distinct sets of responses. Processors MUST NOT assume that multiple
292 replies links are referencing different representations of the same
293 resource and MUST process each replies link independently of any
294 others.
296 5. The 'total' extension element
298 The "total" element is used to indicate the total number of unique
299 responses to an entry known to the publisher. Its content MUST be an
300 unsigned non-negative integer value conforming to the canonical
301 representation of the XML Schema nonNegativeInteger data type
302 [W3C.REC-xmlschema-2-20041028].
304 total = element thr:total { xsd:nonNegativeInteger }
306 Atom entries MAY contain a "total" element, but MUST NOT contain more
307 than one.
309 There is no implied relationship between the value of the "total"
310 element of an Atom entry and any individual or aggregate values of
311 the "thr:count" attributes of its Atom link elements having a
312 "replies" relation.
314 6. Considerations for using thr:count, thr:updated and total
316 The thr:count, thr:updated and total extensions provide additional
317 metadata about the thread of discussion associated with an entry.
318 The values are intended to make it easier for feed consumers to
319 display basic contextual information about the thread without
320 requiring those consumers to dereference, parse and analyze linked
321 resources. That said, there are a number of considerations
322 implementors need to be aware of.
324 First, these extensions MUST NOT be assumed to provide completely
325 accurate information about the thread of discussion. That is, for
326 instance, the actual total number of responses contained by a linked
327 resource MAY differ from the number specified in the thr:count
328 attribute. Feed publishers SHOULD make an effort to ensure that the
329 values are accurate. The non-authoritative nature of "external
330 reference metadata", like the replies link attributes, is discussed
331 in detail in section 3.3 of the W3C document "Tag Finding 12:
332 Authoritative Metadata" [TAG12].
334 Second, the values of the these extensions are volatile and may
335 change at a faster rate than the containing entry. Frequent updates
336 to these values, or to any part of the Atom document, could have a
337 detrimental impact on the cacheability of the document using the
338 attributes, leading to an increase in overall bandwidth consumption.
340 Feed publishers SHOULD consider a change to the values of the thr:
341 count, thr:updated and total extensions to be an "insignificant"
342 update in terms of [RFC4287], meaning that the value of the
343 containing feed, entry or source element's atom:updated element
344 SHOULD NOT be affected by a change to the values of these 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 note that such distributed responses can 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. XML
390 Digital Signatures as specified in Section 5.1 of [RFC4287] present
391 one possible avenue for mitigating such concerns, although the
392 presence of a valid XML Digital Signature within an entry is not, by
393 itself, a reliable defense against repudiation issues.
395 8. IANA Considerations
397 This specification defines one new Atom link relation type to be
398 registered in the IANA Registry of Link Relation as defined by
399 [RFC4287].
401 Attribute Value: replies
402 Description: (see section 4)
403 Expected display characteristics: (see section 4)
404 Security considerations: (see section 5)
406 9. References
408 9.1. Normative References
410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
411 Requirement Levels", BCP 14, RFC 2119, March 1997.
413 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
414 Timestamps", RFC 3339, July 2002.
416 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
417 Resource Identifier (URI): Generic Syntax", STD 66,
418 RFC 3986, January 2005.
420 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
421 Identifiers (IRIs)", RFC 3987, January 2005.
423 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
424 Format", RFC 4287, December 2005.
426 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
427 Registration Procedures", BCP 13, RFC 4288, December 2005.
429 [W3C.REC-xml-infoset-20040204]
430 Tobin, R. and J. Cowan, "XML Information Set (Second
431 Edition)", W3C REC REC-xml-infoset-20040204,
432 February 2004.
434 [W3C.REC-xml-names-19990114]
435 Hollander, D., Bray, T., and A. Layman, "Namespaces in
436 XML", W3C REC REC-xml-names-19990114, January 1999.
438 [W3C.REC-xmlschema-2-20041028]
439 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
440 Second Edition", W3C REC REC-xmlschema-2-20041028,
441 October 2004.
443 9.2. Informative References
445 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001,
446 .
449 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
450 April 2001.
452 [TAG12] Fielding, R. and I. Jacobs, "Tag Finding 12: Authoritative
453 Metadata",
454 .
456 Appendix A. Acknowledgements
458 The author gratefully acknowledges the feedback from Antone Roundy,
459 Aristotle Pagaltzis, Byrne Reese, David Powell, Eric Scheid, James
460 Holderness, John Panzer, Lisa Dusseault, M. David Peterson, Sam Ruby,
461 Sylvain Hellegouarch, and the remaining members of the Atom
462 Publishing Format and Protocol working group during the development
463 of this specification. Any fault or weakness in the definition of
464 this extension is solely the blame of the author.
466 Some portions of text in this document have been adapted from
467 [RFC4287] in order to maintain a stylistic and technical alignment
468 with that specification.
470 Author's Address
472 James M Snell
474 Phone:
475 Email: jasnell@gmail.com
476 URI: http://www.snellspace.com
478 Intellectual Property Statement
480 The IETF takes no position regarding the validity or scope of any
481 Intellectual Property Rights or other rights that might be claimed to
482 pertain to the implementation or use of the technology described in
483 this document or the extent to which any license under such rights
484 might or might not be available; nor does it represent that it has
485 made any independent effort to identify any such rights. Information
486 on the procedures with respect to rights in RFC documents can be
487 found in BCP 78 and BCP 79.
489 Copies of IPR disclosures made to the IETF Secretariat and any
490 assurances of licenses to be made available, or the result of an
491 attempt made to obtain a general license or permission for the use of
492 such proprietary rights by implementers or users of this
493 specification can be obtained from the IETF on-line IPR repository at
494 http://www.ietf.org/ipr.
496 The IETF invites any interested party to bring to its attention any
497 copyrights, patents or patent applications, or other proprietary
498 rights that may cover technology that may be required to implement
499 this standard. Please address the information to the IETF at
500 ietf-ipr@ietf.org.
502 Disclaimer of Validity
504 This document and the information contained herein are provided on an
505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
512 Copyright Statement
514 Copyright (C) The Internet Society (2006). This document is subject
515 to the rights, licenses and restrictions contained in BCP 78, and
516 except as set forth therein, the authors retain all their rights.
518 Acknowledgment
520 Funding for the RFC Editor function is currently provided by the
521 Internet Society.