idnits 2.17.1 draft-snell-atompub-feed-thread-10.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 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 343. ** 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 (May 12, 2006) is 6558 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 May 12, 2006 4 Expires: November 13, 2006 6 Atom Threading Extensions 7 draft-snell-atompub-feed-thread-10.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 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 . . . . . . . . . . . . . . . . . . . 7 50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 51 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 53 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 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. Note that the choice of namespace prefix is arbitrary 76 and not semantically significant. 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]. In those sections this 88 specification uses the atomCommonAttributes, atomMediaType and 89 atomURI patterns defined in [RFC4287]. 91 However, the text of this specification provides the sole definition 92 of conformance. 94 3. The 'in-reply-to' extension element 96 The "in-reply-to" element is used to indicate that an entry is a 97 response to another resource and MUST contain either or both the 98 "ref" and "href" attributes. 100 in-reply-to = 101 element thr:in-reply-to { 102 atomCommonAttributes, 103 ( ref, source? 104 | href, type? 105 | ref, source?, href, type? ) 106 } 108 ref = attribute ref { atomURI } 109 href = attribute href { atomURI } 110 type = attribute type { atomMediaType } 111 source = attribute source { atomURI } 113 The "ref" attribute specifies the universally unique identifier of 114 the resource being responded to. The value MUST conform to the same 115 construction and comparison rules as the value of the atom:id 116 element. The "source" attribute MAY be used to specify the IRI 117 [RFC3987] of an Atom Feed or Entry Document containing an atom:entry 118 with an atom:id value equal to the "ref" attribute. 120 The "href" attribute specifies the 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 entries MAY contain any number of "in-reply-to" extension 126 elements. 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 An Atom link element with a rel attribute value of "replies" may be 195 used to reference a resource where responses to an entry may be 196 found. If the type attribute of the atom:link is omitted, it's value 197 is assumed to be "application/atom+xml". 199 Atom feed, entry and source elements MAY contain any number of 200 replies links. 202 A "replies" link appearing as a child of the Atom feed or source 203 element indicates that the linked resource may contain responses to 204 any of that feeds entries. A "replies" link appearing as a child of 205 an Atom entry element indicates that the linked resource may contain 206 responses specific to that entry. 208 Atom links using the "replies" rel attribute value MAY contain a 209 "thr:count" attribute whose value is a non-negative integer 210 indicating the total number of replies contained by the linked 211 resource. The value is strictly advisory and may not accurately 212 reflect the actual number of replies. 214 Reply links MAY also contain a "thr:when" attribute whose value is a 215 [RFC3339] date-time stamp conforming to the same construction rules 216 as the Atom Date Construct defined in [RFC4287], and is used to 217 indicate the date and time of the most recent reply contained by the 218 linked resource. The value is strictly advisory and may not 219 accurately reflect the actual date and time of the most recent reply. 221 For example, 223 225 http://www.example.org/myfeed 226 My Example Feed 227 2005-07-28T12:00:00Z 228 229 James 230 231 tag:entries.com,2005:1 232 My original entry 233 2006-03-01T12:12:12Z 234 235 239 This is my original entry 240 241 243 The use of "replies" link relations specifying any media type other 244 than "application/atom+xml" is undefined. Software written to 245 conform to this version of the specification will not be guaranteed 246 to process such links correctly. 248 5. Security Considerations 250 As this specification defines an extension to the Atom Syndication 251 Format, it is subject to the same security considerations as defined 252 in [RFC4287]. 254 Feeds using the mechanisms described here could be crafted in such a 255 way as to cause a consumer to initiate excessive (or even an unending 256 sequence of) network requests, causing denial of service (either to 257 the consumer, the target server, and/or intervening networks). 258 Consumers can mitigate this risk by requiring user intervention after 259 a certain number of requests, or by limiting requests either 260 according to a hard limit, or with heuristics. 262 6. IANA Considerations 264 This specification defines one new Atom link relation type to be 265 registered in the IANA Registry of Link Relation as defined by 266 [RFC4287]. 267 Attribute Value: replies 268 Description: (see section 4) 269 Expected display characteristics: (see section 4) 270 Security considerations: (see section 5) 272 7. References 274 7.1. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 280 Timestamps", RFC 3339, July 2002. 282 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 283 Identifiers (IRIs)", RFC 3987, January 2005. 285 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 286 Format", RFC 4287, December 2005. 288 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 289 Registration Procedures", BCP 13, RFC 4288, December 2005. 291 [W3C.REC-xml-infoset-20040204] 292 Tobin, R. and J. Cowan, "XML Information Set (Second 293 Edition)", W3C REC REC-xml-infoset-20040204, 294 February 2004. 296 [W3C.REC-xml-names-19990114] 297 Hollander, D., Bray, T., and A. Layman, "Namespaces in 298 XML", W3C REC REC-xml-names-19990114, January 1999. 300 7.2. Informative References 302 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, 303 . 306 Appendix A. Acknowledgements 308 The author gratefully acknowledges the feedback from James 309 Holderness, Byrne Reese, Aristotle Pagaltzis, and the remaining 310 members of the Atom Publishing Format and Protocol working group 311 during the development of this specification. 313 Author's Address 315 James M Snell 317 Phone: 318 Email: jasnell@gmail.com 319 URI: http://www.snellspace.com 321 Intellectual Property Statement 323 The IETF takes no position regarding the validity or scope of any 324 Intellectual Property Rights or other rights that might be claimed to 325 pertain to the implementation or use of the technology described in 326 this document or the extent to which any license under such rights 327 might or might not be available; nor does it represent that it has 328 made any independent effort to identify any such rights. Information 329 on the procedures with respect to rights in RFC documents can be 330 found in BCP 78 and BCP 79. 332 Copies of IPR disclosures made to the IETF Secretariat and any 333 assurances of licenses to be made available, or the result of an 334 attempt made to obtain a general license or permission for the use of 335 such proprietary rights by implementers or users of this 336 specification can be obtained from the IETF on-line IPR repository at 337 http://www.ietf.org/ipr. 339 The IETF invites any interested party to bring to its attention any 340 copyrights, patents or patent applications, or other proprietary 341 rights that may cover technology that may be required to implement 342 this standard. Please address the information to the IETF at 343 ietf-ipr@ietf.org. 345 Disclaimer of Validity 347 This document and the information contained herein are provided on an 348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 350 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 351 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 352 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 355 Copyright Statement 357 Copyright (C) The Internet Society (2006). This document is subject 358 to the rights, licenses and restrictions contained in BCP 78, and 359 except as set forth therein, the authors retain all their rights. 361 Acknowledgment 363 Funding for the RFC Editor function is currently provided by the 364 Internet Society.