Atom Threading Extensions
RFC 4685

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 12

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 }