XEP-0036: Pub-Sub Subscriptions

WARNING: This document has been retracted by the author(s). Implementation of the protocol described herein is not recommended. Developers desiring similar functionality are advised to implement the protocol that supersedes this one (if any).

Table of Contents

1. Introduction

The Jabber community needs a cohesive standard for publish-subscribe functionality. Certainly there is interest in developing such a standard, as witness the number of proposals written on this topic (Jabber Event Notification Service [1], Publish/Subscribe [2], XEP-0028). Unfortunately, past discussion of this issue has been clouded by confusion over requirements and even terminology. This XEP seeks to clarify the situation somewhat and to provide a protocol for the subscribe half of publish-subscribe functionality within Jabber.

2. Narrative

Traditional pub-sub consists of event notification. This makes it possible for entities to publish data and for other interested entities to receive notification when the data is published. The following are some likely applications of pub-sub functionality within Jabber:

• Auction and trading systems
• Online catalogs
• Document workflow systems
• Network management systems
• NNTP over Jabber
• Groupchat

In such systems, a subscriber would request to receive notifications about data the subscriber is interested in. We define a "topic" as an object that defines the relationship between a publisher and its subscribers. Specifically, a topic contains three essential collections of information:

1. A description of the information that will be provided
2. A list of subscribers to items that fit the description
3. One or more items that fit the description

We define an "item" as an instance of data published by the publisher that fits the description associated with a topic. Each item MAY possess a unique identifier that enables the data to be tracked. (NOTE: This XEP does not address the durability of items, i.e., data storage.)

A topic is addressed by means of a unique "topic ID". A topic ID is simply a string with no required semantic meaning. While a topic ID may have semantic meaning (e.g., '/instruments/guitars/electric' or 'rec.music.dylan'), such meaning is not necessary and a topic ID may be any random string (e.g., 'a1gh83jfn342092'). The only requirement is that a topic ID be unique within the context of a specific pub-sub domain (e.g., pubsub.jabber.org).

3. Protocol Details

Example 1. Protocol

<iq type="set" from="pgm@jabber.org" to="pubsub.jabber.org" id="1">
    <query xmlns="jabber:iq:pubsub">
        <subscribe>
            <topic id="12345"/>
            <topic id="/presence/dizzyd@jabber.org"/>
        </subscribe>
    </query>
</iq>

<iq type="set" from="pgm@jabber.org" to="pubsub.jabber.org" id="1">
    <query xmlns="jabber:iq:pubsub">
        <unsubscribe>
            <topic id="12345"/>
        </unsubscribe>
    </query>
</iq>

<iq type="set" to="pubsub.jabber.org" id="1">
    <query xmlns="jabber:iq:pubsub">
        <publish>
            <topic id="12345">
                <item>some kind of cdata goes here</item>
            </topic>
        </publish>
    </query>
</iq>

<iq type="set" to="pubsub.jabber.org" id="1">
    <query xmlns="jabber:iq:pubsub">
        <createtopic>
            <topic id="new_topic">
                <profile>
                    <!-- is this even remotely close?? -->
                    <publisher>pgm@jabber.org</publisher>
                    <publisher>dizzyd@jabber.org</publisher>
                </profile>
            </topic>
            <topic id="another_topic>
                <profile>
                    <publisher/>
                </profile>
            </topic>
        </createtopic>
    </query>
</iq>

<iq type="set" to="pubsub.jabber.org" id="1">
    <query xmlns="jabber:iq:pubsub">
        <removetopic>
            <topic id="12345"/>
        </removetopic>
    </query>
</iq>
  

4. Author Note

Peter Millard, co-author of this specification, died on April 26, 2006.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0036
Publisher: XMPP Standards Foundation
Status: Retracted
Type: Standards Track
Version: 0.2
Last Updated: 2003-04-22
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: None
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 3920) and XMPP IM (RFC 3921) 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