Atom Comment Metadata Extensions (Draft)
atomcommentmeta-00

Status of this Memo

This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 9, 2010.

Abstract

This document presents an extension to the Atom Threading Extensions which allows entries that represent replies to include some metadata about what is being replied to.

Requirements Language

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 RFC 2119 (, “RFC 2119,” .) [RFC2119].

Table of Contents

1.  Introduction
2.  Notational Conventions
3.  Extensions to thr:in-reply-to
4.  Authoritative Metadata
5.  Security Considerations
6.  IANA Considerations
7.  Normative References
Appendix A.  Acknowledgements
Appendix B.  Examples
    B.1.  Parent Entry Example
    B.2.  Child Entry Example
§  Author's Address

1.  Introduction

[RFC4685] (Snell, J., “Atom Threading Extensions,” September 2006.) describes an extension to the Atom Syndication Format (, “The Atom Syndication Format,” .) [RFC4287] that allows publishers to express that a particular entry is in reply to another entry. However, the mechanism provided by this extension does not provide sufficient metadata to describe the parent resource to a human user.

While consumers can in theory fetch the original feed and locate the entry, this requires an additional fetch for each comment that is too expensive for many consumer use-cases. This specification follows the principles of the atom:source element from the Atom specification to provide additional, non-authoritative metadata as a hint to such consumers.

2.  Notational Conventions

In this document, the the XML namespace prefix "atom:" is used for the namespace URI http://www.w3.org/2005/Atom, and the XML namespace prefix "thr:" is used for the namespace URI http://purl.org/syndication/thread/1.0. This 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.

This specification uses "the Atom specification" to refer to [RFC4287] (, “The Atom Syndication Format,” .), and "the threading extensions specification" to refer to [RFC4685] (Snell, J., “Atom Threading Extensions,” September 2006.).

Where this specification describes the heirarchy of replies, it uses the term "the parent element" to refer to the target of an "in reply to" relationship as described in the threading extensions specification, and "the child element" to refer to the source of that relationship.

3.  Extensions to thr:in-reply-to

The extensions described by this specification are in the form of child elements of the thr:in-reply-to element as defined by the threading extensions specification.

Publishers MAY include the atom:title, atom:summary, atom:content, atom:published, atom:updated, atom:author and atom:link elements as children of thr:in-reply-to. When used in this way, these elements have equivalent meaning and content model as the same elements appearing as children of the parent entry. If a publisher includes any of these elements, the publisher SHOULD ensure that they have the same values as those in the parent entry as far as possible with the information available.

Publishers MUST NOT include an atom:link element of relationship "alternate" that has href and type attributes identical to those on the thr:in-reply-to element, as those attributes on in-reply-to imply such a link. If there is more than one "alternate" hyperlink, and if one of the hyperlinks is of type text/html, the text/html hyperlink SHOULD be represented via attributes on the thr:in-reply-to element.

Note also that in particular atom:id MUST NOT be included as a child of thr:in-reply-to. The "ref" attribute of thr:in-reply-to has equivalent meaning.

Consumers MUST NOT assume that the absense of an element as a child of thr:in-reply-to implies the absense of that element in the parent entry.

4.  Authoritative Metadata

In most cases, the additional metadata included using this extension are non-authoritative, and are provided only as a hint to consumers so that they may, when appropriate, avoid dereferencing the source feed of the parent entry.

However, there are three occasions where a consumer MAY consider the parent entry metadata to be authoritative:

• When the parent entry appears within the same feed as the child entry.
• When the child entry is appears within a feed that is known to be referenced by a "replies" hyperlink in the source entry.
• When the consumer has external information about the authoritative nature of the metadata. For example, a particular consumer might have recieved some form of guarantee that the comment feeds provided by a particular publisher will always contain up-to-date metadata about parent resources in other feeds provided by that same publisher.

Publishers MUST ensure that in the above situations any parent entry metadata is suitably accurate for use in place of the equivalent on the parent entry, or omit any elements which they are unable to produce accurately.

5.  Security Considerations

As this specification defines an extension to the Atom Syndication Format, it is subject to the same security considerations defined in [RFC4287] (, “The Atom Syndication Format,” .).

The additional elements defined in this specification contain non-authoritative metadata except as described in Section 4 (Authoritative Metadata) and must therefore not be presented to the end-user as authoritative.

[TODO: Write some more here.]

6.  IANA Considerations

None.

7. Normative References

Appendix A.  Acknowledgements

...

Appendix B.  Examples

This appendix is non-normative. Where these examples include fragments of XML documents, assume the namespace declarations xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0" are in scope.

B.1.  Parent Entry Example

An example top-level entry

<entry>
   <id>tag:blogpad.example.com,2008:entry01</id>
   <title>Pictures of my Cat</title>
   <published>2008-11-02T15:29:00Z</published>
   <updated>2008-11-02T15:29:00Z</updated>
   <link rel="alternate" type="text/html"
         href="/geraldine/entries/1" />
   <link rel="replies" type="application/atom+xml"
         href="/geraldine/entries/1/comments.atom" />
   <content type="html">
       (content elided)
   </content>
   <author>
      <name>Geraldine</name>
      <uri>http://blogpad.example.com/geraldine/</uri>
   </author>
</entry>

This example shows a typical Atom entry with a "replies" hyperlink as described in the threading extensions specification.

B.2.  Child Entry Example

An example "comment" entry

<entry>
   <id>tag:blogpad.example.com,2008:comment01</id>
   <title>Re: Pictures of my Cat</title>
   <published>2008-11-02T15:34:02Z</published>
   <link rel="alternate" type="text/html"
         href="/geraldine/entres/1#comment1" />
   <content type="text">
       So cute!
   </content>
   <author>
      <name>Tim</name>
      <uri>http://blogpad.example.com/tim/</uri>
   </author>
   <thr:in-reply-to ref="tag:blogpad.example.com,2008:entry01"
                    type="text/html" href="/geraldine/entries/1">
      <title>Pictures of my Cat</title>
      <published>2008-11-02T15:29:00Z</published>
      <updated>2008-11-02T15:29:00Z</updated>
   </thr:in-reply-to>
</entry>

This example shows an Atom entry that represents a text-based comment on the entry shown in Appendix B.1 (Parent Entry Example). In this case, the comment entry includes the title, publication and last-updated dates of the parent entry.

Author's Address