Atom Threading Extensions
RFC 4685
Document | Type |
RFC - Proposed Standard
(September 2006; No errata)
Was draft-snell-atompub-feed-thread (individual in gen area)
|
|
---|---|---|---|
Author | James Snell | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4685 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lisa Dusseault | ||
Send notices to | (None) |
Network Working Group J. Snell Request for Comments: 4685 September 2006 Category: Standards Track Atom Threading Extensions Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. Table of Contents 1. Introduction ....................................................1 2. Notational Conventions ..........................................2 3. The 'in-reply-to' Extension Element .............................2 4. The 'replies' Link Relation .....................................5 5. The 'total' Extension Element ...................................6 6. Considerations for Using thr:count, thr:updated, and total ......7 7. Security Considerations .........................................8 8. IANA Considerations .............................................9 9. References ......................................................9 9.1. Normative References .......................................9 9.2. Informative References ....................................10 Appendix A. Acknowledgements .....................................11 1. Introduction This document defines an extension for expressing threaded discussions within the Atom Syndication Format [RFC4287]. Snell Standards Track [Page 1] RFC 4685 Feed Thread September 2006 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets. The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML elements and attributes described in this specification is: http://purl.org/syndication/thread/1.0 In this document, the namespace prefix "thr:" is used for the above Namespace URI. Note that the choice of namespace prefix is arbitrary and not semantically significant. This specification uses a shorthand form of terms from the XML Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information Item" is omitted when naming Element and Attribute Information Items. Therefore, when this specification uses the term "element," it is referring to an Element Information Item in Infoset terms. Likewise, when this specification uses the term "attribute," it is referring to an Attribute Information Item. This specification allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. When an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of [RFC3987]. When an IRI is serving as an identifier, it MUST NOT be so mapped. Some sections of this specification are illustrated with a non- normative RELAX NG Compact schema [RELAXNG]. In those sections, this specification uses the atomCommonAttributes, atomMediaType, and atomURI patterns, defined in [RFC4287]. However, the text of this specification provides the sole definition of conformance. 3. The 'in-reply-to' Extension Element The "in-reply-to" element is used to indicate that an entry is a response to another resource. The element MUST contain a "ref" attribute identifying the resource that is being responded to. The element is not unlike the references and in-reply-to email message headers, defined by [RFC2822]. However, unlike the in- reply-to header, the "in-reply-to" element is required to identify the unique identifier of only a single parent resource. If the entry Snell Standards Track [Page 2] RFC 4685 Feed Thread September 2006 is a response to multiple resources, additional "in-reply-to" elements MAY be used. There is no direct equivalent to the references header, which lists the unique identifiers of each preceding message in a thread. in-reply-to = element thr:in-reply-to { atomCommonAttributes, ref, href?, source?, type?, ( undefinedContent ) } ref = attribute ref { atomURI } href = attribute href { atomURI } type = attribute type { atomMediaType } source = attribute source { atomURI }Show full document text