idnits 2.17.1
draft-snell-atompub-feed-thread-07.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 333.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323.
** 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 :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
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 (March 2006) is 6611 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)
No issues found here.
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 March 2006
4 Expires: September 2, 2006
6 Atom Threading Extensions
7 draft-snell-atompub-feed-thread-07.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 September 2, 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 . . . . . . . . . . . . . . . . . 5
49 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
51 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
52 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
54 Intellectual Property and Copyright Statements . . . . . . . . . . 10
56 1. Introduction
58 This document specifies extension for expressing threaded discussions
59 within the Atom Syndication Format ([RFC4287]).
61 2. Notational Conventions
63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
65 document are to be interpreted as described in BCP 14, [RFC2119], as
66 scoped to those conformance targets.
68 This specification uses XML Namespaces [W3C.REC-xml-names-19990114]
69 to uniquely identify XML element names. It uses the following
70 namespace prefix for the indicated namespace URI;
71 "thr": "http://purl.org/syndication/thread/1.0"
73 This specification uses terms from the XML Infoset [W3C.REC-xml-
74 infoset-20040204]. However, this specification uses a shorthand; the
75 phrase "Information Item" is omitted when naming Element Information
76 Items. Therefore, when this specification uses the term "element,"
77 it is referring to an Element Information Item in Infoset terms.
79 3. The 'in-reply-to' extension element
81 The 'in-reply-to' extension element is used to indicate that a feed
82 entry is a response to another resource. The element MUST contain
83 either or both the 'ref' and 'href' attributes.
85 in-reply-to = element thr:in-reply-to {
86 atomCommonAttributes,
87 attribute ref { atomURI }?,
88 attribute href { atomURI }?,
89 attribute type { atomMediaType }?,
90 attribute source { atomURI }?
91 }
93 The 'ref' attribute specifies the universally unique identifier of
94 the resource being responded to. The value of the attribute MUST
95 conform to the same construction and comparison rules as the atom:id
96 element. The 'href' attribute specifies an IRI that may be used to
97 retrieve a representation of the resource being responded to.
99 The "in-reply-to" element MAY contain a "type" attribute whose value
100 identifies the media type of the resource identified by the href
101 attribute.
103 The "in-reply-to" element MAY contain a "source" attribute whose
104 value specifies the IRI of an Atom Feed Document within which an
105 atom:entry representing the resource being responded to MAY be found.
107 Atom feed, entry and source elements MAY each contain any number of
108 'in-reply-to' extension elements but SHOULD NOT contain more than one
109 having the same 'ref' and 'href' attribute values.
111 For example
113
115 http://www.example.org/myfeed
116 My Example Feed
117 2005-07-28T12:00:00Z
118
119 James
120
121 tag:example.org,2005:1
122 My original entry
123 2006-03-01T12:12:12Z
124
127 This is my original entry
128
129
130 tag:example.org,2005:1,1
131 A response to the original
132 2006-03-01T12:12:12Z
133
134
138 This is a response to the original entry
139
140
142 To allow Atom clients that are not familiar with the in-reply-to
143 extension to know that a relationship exists between the entry and
144 the resource being responded to, publishers are advised to consider
145 including a "related" link referencing a representation of the
146 resource identified by the in-reply-to element.
148 For example
150
152 http://www.example.org/myfeed
153 My Example Feed
154 2005-07-28T12:00:00Z
155
156 James
157
158 tag:example.org,2005:1,1
159 A response to the original
160 2006-03-01T12:12:12Z
161
162
167
171 This is a response to the original entry
172
173
175 4. The 'replies' link relation
177 While responses to an atom:entry MAY appear within the same feed
178 document as the resource being responded to, it is common practice to
179 separate responses into a separate feed documents or other resource.
180 In such cases, it is helpful for an atom:feed or atom:entry to
181 indicate the location where responses may be found. An atom:link
182 element with the 'rel' attribute value 'replies' is used for this
183 purpose. If the type attribute of the atom:link is omitted, it's
184 value is assumed to be "application/atom+xml".
186 Atom feed, entry and source elements MAY each contain any number of
187 'replies' atom:link elements but SHOULD NOT contain more than one
188 having the same 'type' and 'href' attribute values.
190 A 'replies' link appearing as a child of the Atom feed or source
191 element indicates that the referenced resource MAY contain responses
192 to any of the feeds entries. A 'replies' link appearing as a child
193 of an Atom entry element indicates that the referenced resource MAY
194 contain responses specific to that entry.
196 Atom links using the "replies" rel attribute value MAY contain a
197 "thr:count" attribute whose value is a non-negative integer
198 indicating the total number of replies contained by the linked
199 resource. The value is strictly advisory and may not accurately
200 reflect the actual number of replies.
202 Reply links MAY also contain a "thr:when" attribute whose value is a
203 [RFC3339] date-time stamp conforming to the same construction rules
204 as the Atom Date Construct defined in [RFC4287], and is used to
205 indicate the date and time of the most recent reply contained by the
206 linked resource. The value is strictly advisory and may not
207 accurately reflect the actual date and time of the most recent reply.
209 For example, replies contained in a separate Atom feed
211
213 http://www.example.org/myfeed
214 My Example Feed
215 2005-07-28T12:00:00Z
216
217 James
218
219 tag:entries.com,2005:1
220 My original entry
221 2006-03-01T12:12:12Z
222
223
228 This is my original entry
229
230
232 The presence of a 'replies' link is merely a hint as to where
233 responses to entries MAY be found and does not guarantee that the
234 referenced resource contains any responses to any entries within the
235 containing feed.
237 The behavior of 'replies' link relations specifying any media type
238 other than "application/atom+xml" is undefined. Software written to
239 conform to this version of the specification will not be guaranteed
240 to process such links correctly.
242 Implementors should note that while the Atom Syndication Format does
243 not forbid the inclusion of namespaced extension attributes on the
244 Atom link element, neither does is explicitly allow for such
245 extensions. The result of this is that the thr:count and thr:when
246 attributes fall outside of the guidelines for Atom extensions as
247 defined in Section 6 of [RFC4287] and may not be supported by all
248 Atom implementations.
250 5. Security Considerations
252 As this specification defines an extension to the Atom Syndication
253 Format, it is subject to the same security considerations as defined
254 in [RFC4287] and does not introduce any new or specific
255 considerations.
257 6. IANA Considerations
259 This specification defines one new Atom link relation type to be
260 registered in the IANA Registry of Link Relation as defined by
261 [RFC4287].
262 Attribute Value: replies
263 Description: (see section 4)
264 Expected display characteristics: (see section 4)
265 Security considerations: (see section 6)
267 7. References
269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
270 Requirement Levels", BCP 14, RFC 2119, March 1997.
272 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
273 Timestamps", RFC 3339, July 2002.
275 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
276 Format", RFC 4287, December 2005.
278 [W3C.REC-xml-infoset-20040204]
279 Tobin, R. and J. Cowan, "XML Information Set (Second
280 Edition)", W3C REC REC-xml-infoset-20040204,
281 February 2004.
283 [W3C.REC-xml-names-19990114]
284 Hollander, D., Bray, T., and A. Layman, "Namespaces in
285 XML", W3C REC REC-xml-names-19990114, January 1999.
287 Appendix A. Acknowledgements
288 The author gratefully acknowledges the feedback from James
289 Holderness, Byrne Reese, Aristotle Pagaltzis, and the remaining
290 members of the Atom Publishing Format and Protocol working group
291 during the development of this specification.
293 Author's Address
295 James M Snell
297 Phone:
298 Email: jasnell@gmail.com
299 URI: http://www.snellspace.com
301 Intellectual Property Statement
303 The IETF takes no position regarding the validity or scope of any
304 Intellectual Property Rights or other rights that might be claimed to
305 pertain to the implementation or use of the technology described in
306 this document or the extent to which any license under such rights
307 might or might not be available; nor does it represent that it has
308 made any independent effort to identify any such rights. Information
309 on the procedures with respect to rights in RFC documents can be
310 found in BCP 78 and BCP 79.
312 Copies of IPR disclosures made to the IETF Secretariat and any
313 assurances of licenses to be made available, or the result of an
314 attempt made to obtain a general license or permission for the use of
315 such proprietary rights by implementers or users of this
316 specification can be obtained from the IETF on-line IPR repository at
317 http://www.ietf.org/ipr.
319 The IETF invites any interested party to bring to its attention any
320 copyrights, patents or patent applications, or other proprietary
321 rights that may cover technology that may be required to implement
322 this standard. Please address the information to the IETF at
323 ietf-ipr@ietf.org.
325 Disclaimer of Validity
327 This document and the information contained herein are provided on an
328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
335 Copyright Statement
337 Copyright (C) The Internet Society (2006). This document is subject
338 to the rights, licenses and restrictions contained in BCP 78, and
339 except as set forth therein, the authors retain all their rights.
341 Acknowledgment
343 Funding for the RFC Editor function is currently provided by the
344 Internet Society.