Atom Link Relation: Discuss
draft-saintandre-atomlink-discuss-01

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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 November 30, 2008.

Copyright Notice

Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This specification defines a link relation that enables an Atom document to point to a venue for multi-party discussion of the document or its primary topic.

Table of Contents

1.  Introduction
2.  Notational Conventions
3.  The 'discuss' Link Relation
4.  Example
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Copying Conditions
§  Author's Address

1.  Introduction

Atom [ATOM] (Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.) is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. Such metadata can include links to other resources, which are primarily defined by Uniform Resource Indentifiers [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) or Internationalized Resource Indentifiers [IRI] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.). A link can be secondarily defined as partaking in a specific kind of relationship to the document. This specification defines a new link relation, "discuss", which can be used to point to Internet resources where a person can actively engage in a multi-party discussion or conversation about the document itself or the primary topic covered by the document.

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 [TERMS] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This specification allows the use of Internationalized Resource Identifiers [IRI] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.). Every Uniform Resource Identifier [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) 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 [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.). When an IRI is serving as an identifier, it MUST NOT be so mapped.

3.  The 'discuss' Link Relation

An Atom link element with a rel attribute value of "discuss" is used to reference an Internet resource where multi-party discussion of the feed, entry, or source can occur. In the terminology of this specification, such a resource is called a "venue". Such venues might include, but are not limited to, the following:

• Electronic mail discussion lists
• NetNews discussion boards (see [NNTP] (Feather, C., “Network News Transfer Protocol (NNTP),” October 2006.))
• Internet Relay Chat channels (see [IRC] (Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.))
• Web-based forums accessible via the Hypertext Transport Protocol (see [HTTP] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.))
• Multi-user chat rooms based on the Extensible Messaging and Presence Protocol (see [MUC] (Saint-Andre, P., “Multi-User Chat,” April 2007.) and [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.))
• Multi-user chat rooms based on the Message Session Relay Protocol (see [MSRP] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.))
• Voice or video conference rooms based on the Session Initiation Protocol (see [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.))

The use of the "discuss" relation enables a person who receives an Atom feed or entry to discover a venue where the person can engage in a conversation about the feed or entry with interested others. This use case is not currently addressed by any existing Atom link relation, which to date address use cases such as reading background material (the "related" relation) or following other people's comments (the "replies" relation) rather than actively engaging in a conversation or discussion about the feed or entry.

It is expected that a link relation of type "discuss" would be presented to a human user in such a way that the user would understand that following the link would result in joining an active discussion venue rather than accessing a static resource.

If the rel attribute has a value of "discuss" but the type attribute of the atom:link is omitted, no type value shall be assumed.

Although Atom feed, entry, and source elements MAY each contain any number of atom:link elements using the "discuss" link relation, this specification assigns no significance to the presence or order of such links. Multiple discuss links appearing within an atom:entry may reference alternative representations of the same venue or may reference entirely distinct venues containing distinct conversations. Processors MUST NOT assume that multiple discuss links make reference to different representations of the same venue and MUST process each discuss link independently of any others.

4.  Example

The following example shows an Atom entry that contains numerous links related to the ejabberd XMPP server project. The resources identified by the links are as follows:

• An XMPP publish-subscribe node (see [PUBSUB] (Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe,” March 2008.)) where a user can subscribe to real-time updates to the feed (see [ATOMSUB] (Saint-Andre, P., Hildebrand, J., and B. Wyman, “Atomsub: Transporting Atom Notifications over the Publish-Subscribe Extension to the Extensible Messaging and Presence Protocol (XMPP),” May 2008.)).
• An XMPP publish-subscribe node (see [PUBSUB] (Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe,” March 2008.)) where a user can subscribe to real-time updates to the feed of comments on the entry (see [THREADING] (Snell, J., “Atom Threading Extensions,” September 2006.) and [ATOMSUB] (Saint-Andre, P., Hildebrand, J., and B. Wyman, “Atomsub: Transporting Atom Notifications over the Publish-Subscribe Extension to the Extensible Messaging and Presence Protocol (XMPP),” May 2008.)).
• An XMPP chatroom.
• An email discussion list.
• A NetNews discussion board.
• A web forum.
• Two web pages containing background information.

<entry xmlns='http://www.w3.org/2005/Atom'>
  <source>
    <title>Example.org Admin Feed</title>
    <link href='http://example.org/'/>
    <link rel='self'
          type='application/atom+xml'
          href='http://example.org/atom.xml'/>
    <id>tag:example.org,2008:home</id>
    <updated>2008-05-27T17:30:03Z</updated>
    <author>
      <name>Example.org Admin Team</name>
    </author>
  </source>
  <title>Service Upgrade</title>
  <summary>We have upgraded to ejabberd 2.0</summary>
  <link rel='alternate'
        type='text/html'
        href='http://example.org/2008/05/27/atom03'/>
  <link rel='alternate'
        href='xmpp:pubsub.example.com?;node=admin-feed'
        label='Real-time admin feed'/>
  <link rel='replies'
        href='xmpp:pubsub.example.com?;node=admin-comments'
        label='Real-time comments on the admin feed'/>
  <link rel='discuss'
        href='xmpp:ejabberd@conference.jabber.ru?join'
        label='Real-time chatroom about ejabberd'/>
  <link rel='discuss'
        href='mailto:ejabberd@jabber.ru'
        label='Email discussion list about ejabberd'/>
  <link rel='discuss'
        href='news://news.gmane.org/gmane.network.jabber.ejabberd'
        label='Newsgroup about ejabberd'/>
  <link rel='discuss'
        href='http://www.ejabberd.im/forum'
        label='Web forum about ejabberd'/>
  <link rel='related'
        href='http://ejabberd.im/'
        label='Project homepage for ejabberd'/>
  <link rel='related'
        href='http://en.wikipedia.org/wiki/Ejabberd'
        label='Wikipedia page about ejabberd'/>
  <id>tag:example.org,2008:entry-32397</id>
  <published>2008-05-27T17:30:03Z</published>
  <updated>2008-05-27T17:30:03Z</updated>
</entry>

Notice that without the "discuss" relation it would be difficult to differentiate among some of these links and that the "discuss" links can be differentiated via the URI schemes. In particular:

• The entry contains three links to XMPP entities, which can be differentiated by the relation ("alternate" vs. "replies" vs. "discuss").
• The entry contains four "discuss" links, which can be differentiated via the URI scheme ("xmpp" vs. "mailto" vs. "nntp" vs. "http").
• The entry contains three links to HTTP resources, which can be differentiated via the relation type ("discuss" vs. "related").

5.  Security Considerations

This document introduces few additional security considerations beyond those associated with the use and resolution of URIs/IRIs in general.

However, depending on the technology used and the local service policy at a particular installation, a venue for multi-party discussion may expose personally-identifying information about the participants (e.g., IP addresses), may be public in the sense that anyone can join the venue, and may archive the conversations that occur in the venue either privately or publicly (e.g., on the World Wide Web). An Atom user agent or the appropriate helper application should warn a human user about the possibility of information exposure and public archiving.

6.  IANA Considerations

This specification defines one new Atom link relation type, which shall be registered in the IANA Registry of Atom Link Relations, as defined by [ATOM] (Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.).

Attribute value:

discuss

Description:

(see Section 3 (The 'discuss' Link Relation))

Expected display characteristics:

(see Section 3 (The 'discuss' Link Relation))

Security considerations:

(see Section 5 (Security Considerations))

7.  References

7.1. Normative References

7.2. Informative References

Appendix A.  Acknowledgements

The author wishes to thank Frank Ellerman, Sylvain Hellegouarch, Aristotle Pagaltzis, Brian Smith, and James Snell for their feedback.

Appendix B.  Copying Conditions

Regarding this entire document or any portion of it, the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.

Author's Address