XEP-0402: Bookmarks 2 (This Time it's Serious)

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction

The original Bookmarks specification (Bookmark Storage (XEP-0048) [1]) used the widely available Private XML Storage (Private XML Storage (XEP-0049) [2]), but stored all bookmarks in a single element. When the specification was moved to the Standards Track and Draft, it was also updated to use the user's Pubsub service (Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223) [3]), but kept this single element containing all bookmarks inside a single Pubsub item.

Most implementations have kept to the original, Private XML Storage based solution, and while some newer implementations have used Pubsub, these are limited in capability by the use of a single item.

This specification resolves both issues by providing a new Bookmarks specification to migrate to, and takes the opportunity to update the XML namespace in use as well. The URL storage is dropped, since it is rarely used. Storage of URL bookmarks is therefore out of scope.

2. Outline of use

Clients store each bookmarked chatroom as a Pubsub item within the 'urn:xmpp:bookmarks:0' node. Each item SHALL have, as item id, the Room JID of the chatroom (eg, coven@chat.shakespeare.lit).

The payload of the item SHALL be a conference element qualified by the 'urn:xmpp:bookmarks:0' namespace, with the following syntax:

Note: The datatypes are as defined in XML Schema Part 2 [5].

Example 1. An example of the conference element

<conference xmlns='urn:xmpp:bookmarks:0'
            name='Council of Oberon'
            autojoin='true'>
    <nick>Puck</nick>
</conference>

This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.

Note that a bookmark item MUST contain only one conference room.

Note also that a conference element has no truly mandatory attributes or child elements, though a name SHOULD be given. Thus the following is legal:

Example 2. Minimalist conference element

<conference xmlns='urn:xmpp:bookmarks:0'/>

3. Examples

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

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

<iq from='juliet@capulet.lit/balcony' type='set' id='pip1'>
    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
        <publish node='urn:xmpp:bookmarks:0'>
            <item id='theplay@conference.shakespeare.lit'>
                <conference name='The Play&apos;s the Thing'
                            autojoin='true'>
                    <nick>JC</nick>
                </conference>
            </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'/>
        

<iq from='juliet@capulet.lit/balcony' type='set' id='remove-bookmark1'>
    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
        <retract node='urn:xmpp:bookmarks:0'>
            <item id='theplay@conference.shakespeare.lit'/>
        </retract>
    </pubsub>
</iq>
        

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

4. Bookmark Notifications

When a client is sent an event from the Pubsub service for the 'urn:xmpp:bookmarks:0' node, it MUST check the 'autojoin' attribute if present, and join the room immediately if the attribute is both present and true.

5. Implementation Notes

6. Determining Support

This specification relies fully on a number of others. Most particularly, support for this protocol is available if Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223) [3] is supported.

7. Acknowledgements

The authors would like to note that much of the syntax description was copied exactly from Bookmark Storage (XEP-0048) [1] by Rachel Blackman, Peter Millard, and Peter Saint-Andre. Much of the remainder of this specification is based closely on their work.

8. Security Considerations

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

The client needs to make sure that the server actually supports the "http://jabber.org/protocol/pubsub#publish-options" feature, before relying on it. If it's not supported, the client should configure the 'urn:xmpp:bookmarks:0' node first (see xep-0060), before adding any bookmarks.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0402
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.2.0
Last Updated: 2018-03-28
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: bookmarks2
Registry: <http://xmpp.org/registrar/bookmarks2.html>
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

There exists a special venue for discussion related to the technology described in this document: the <standards@xmpp.org> mailing list.

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