XEP-0048: Bookmarks

NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

Table of Contents

1. Introduction

For ease-of-use in a Jabber client, it is desirable to have a way to store shortcuts to various services and resources (such as conference rooms and web pages) as "bookmarks" that can be displayed in the user's client. Several Jabber clients have already agreed on and implemented a method to provide this service; that informal agreement is documented and expanded upon in this document. In particular, we introduce the <storage/> element (qualified by the 'storage:bookmarks' namespace) as a container for this sort of this data. While bookmarks data can be stored using any XML storage mechanism, this document recommends one method that is specific to XMPP.

2. Data Format

A storage element qualified by the 'storage:bookmarks' namespace may contain a collection of child elements, each representing a bookmark to be displayed in a client. At present, only two sub-elements are defined: <conference/> for bookmarking of Multi-User Chat [1] rooms and <url/> for bookmarking of web pages.

All child elements allow a 'name' attribute, which is the friendly name by which they will be displayed in the client. If an element lacks a 'name' attribute, the client SHOULD generate an appropriate substitution based on the other available data.

    <storage xmlns='storage:bookmarks'>
      <conference name='Council of Oberon' 
                  autojoin='true'
                  jid='council@conference.underhill.org'>
        <nick>Puck</nick>
      </conference>
    </storage>
    

    <storage xmlns='storage:bookmarks'>
      <url name='Complete Works of Shakespeare'
           url='http://the-tech.mit.edu/Shakespeare/'/>
    </storage>
    

3. Storage

It is RECOMMENDED to use Publish-Subscribe [4] for data storage, specifically through the use of personal data nodes hosted at the user's virtual publish-subscribe service as described in Best Practices for Persistent Storage of Private Data via Publish-Subscribe [5] and illustrated in the following sections.

Note: In the past, Private XML Storage [6] was the recommended method (see the archived version of this specification at <http://www.xmpp.org/extensions/attic/xep-0048-1.0.html>). In addition, other methods could be used, such as HTTP or WebDAV.

<iq from='juliet@capulet.lit/balcony' type='set' id='pip1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='storage:bookmarks'>
      <item id='current'>
        <storage xmlns='storage:bookmarks'>
          <conference name='The Play&apos;s the Thing' 
                      autojoin='true'
                      jid='theplay@conference.shakespeare.lit'>
            <nick>JC</nick>
          </conference>
        </storage>
      </item>
    </publish>
    <publish-options>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#publish-options</value>
        </field>
        <field var='pubsub#persist_items'>
          <value>true</value>
        </field>
        <field var='pubsub#access_model'>
          <value>whitelist</value>
        </field>
      </x>
    </publish-options>
  </pubsub>
</iq>
    

<iq to='juliet@capulet.lit/balcony' type='result' id='pip1'/>
    

<message from='juliet@capulet.lit'
         to='juliet@capulet.lit/balcony'
         type='headline'
         id='rnfoo1'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='storage:bookmarks'>
      <item id='current'>
        <storage xmlns='storage:bookmarks'>
          <conference name='The Play&apos;s the Thing' 
                      autojoin='true'
                      jid='theplay@conference.shakespeare.lit'>
            <nick>JC</nick>
          </conference>
        </storage>
      </item>
    </items>
  </event>
</message>

<message from='juliet@capulet.lit'
         to='juliet@capulet.lit/chamber'
         type='headline'
         id='rnfoo2'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='storage:bookmarks'>
      <item id='current'>
        <storage xmlns='storage:bookmarks'>
          <conference name='The Play&apos;s the Thing' 
                      autojoin='true'
                      jid='theplay@conference.shakespeare.lit'>
            <nick>JC</nick>
          </conference>
        </storage>
      </item>
    </items>
  </event>
</message>
    

<iq from='juliet@capulet.lit/randomID' type='get' id='retrieve1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='storage:bookmarks'/>
  </pubsub>
</iq>
    

<iq type='result'
    to='juliet@capulet.lit/randomID'
    id='retrieve1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='storage:bookmarks'>
      <item id='current'>
        <storage xmlns='storage:bookmarks'>
          <conference name='The Play&apos;s the Thing' 
                      autojoin='true'
                      jid='theplay@conference.shakespeare.lit'>
            <nick>JC</nick>
          </conference>
        </storage>
      </item>
    </items>
  </pubsub>
</iq>
    

4. Security Considerations

Security considerations related to object persistent via publish-subscribe are described in XEP-0060 and XEP-0223.

Use of the <password/> child of the <conference/> element is NOT RECOMMENDED, since the password could be discovered by a third party, e.g. an eavesdropper (if channel encryption is not used) or a server administrator. However, the element MAY be used in suitably secure environments (e.g., where it is known that communications will not be sent over unencrypted channels and the server administrators are trusted). Clients SHOULD NOT default to storing passwords and MUST enable users to disable any password storage.

5. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].

6. XMPP Registrar Considerations

No action by the XMPP Registrar [8] is required, since the 'storage:bookmarks' namespace is already included in the protocol namespaces registry (see <http://xmpp.org/registrar/namespaces.html>).

7. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='storage:bookmarks'
    xmlns='storage:bookmarks'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0048: http://www.xmpp.org/extensions/xep-0048.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='storage'>
    <xs:complexType>
      <xs:choice>
        <xs:element ref='conference'/>
        <xs:element ref='url'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='conference'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='nick' type='xs:string' minOccurs='0'/>
        <xs:element name='password' type='xs:string' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='autojoin' type='xs:boolean' use='optional' default='false'/>
      <xs:attribute name='jid' type='xs:string' use='required'/>
      <xs:attribute name='name' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='url'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='name' type='xs:string' use='required'/>
          <xs:attribute name='url' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
  

8. Author Note

Peter Millard, a co-author of this specification from version 0.1 through version 1.0, died on April 26, 2006.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0048
Publisher: XMPP Standards Foundation
Status: Draft
Type: Standards Track
Version: 1.1
Last Updated: 2007-11-07
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0060, XEP-0223
Supersedes: None
Superseded By: None
Short Name: bookmarks
Schema: <http://www.xmpp.org/schemas/bookmarks.xsd>
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END