XEP-0173: Pubsub Subscription Storage

WARNING: Consideration of this document has been Deferred by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended.

Table of Contents

1. Introduction

Publish-Subscribe [1] allows Jabber entities to subscribe to various kinds of information, but provides no way of remembering which nodes a user has subscribed to. Other protocols (e.g. User Geolocation [2], User Avatar [3]) allow information about a certain entity to be published to a Pubsub node. These protocols use Service Discovery [4] to allow other entities to find the pubsub node used by a certain entity, but provide no way of performing the opposite mapping, from pubsub node to information source. This document attempts to fill that void, using Private XML Storage [5] for storing information about subscriptions.

2. Requirements

This protocol enables Jabber clients to do the following:

• Remember which pubsub nodes the entity has subscribed to, and what kind of information is available at each node
• Update the mappings when subscriptions are added or removed
• Correlate incoming pubsub events to subscriptions

3. Protocol

The <subscriptions/> element qualified by the 'storage:pubsubs' namespace is the root element used in the jabber:iq:private transactions. It has zero or more <subscription/> child elements, each of which MUST possess the following attributes:

• jid -- The JID of the pubsub service used
• node -- The pubsub node at which the data is available
• subscription -- The current subscription state, one of "none", "pending", "unconfigured" and "subscribed"

Additionally, the <subscription/> element MAY possess these attributes:

• resource -- The resource that is subscribed to this pubsub node. If the 'resource' attribute is absent, the bare JID is subscribed.
• user -- The JID of the owner of this particular piece of data
• targetns -- The namespace of the data in question

4. Use Cases

<iq type='get' id='retrieve1'>
  <query xmlns='jabber:iq:private'>
    <subscriptions xmlns='storage:pubsubs'/>
  </query>
</iq>

<iq type='result' id='retrieve1'>
  <query xmlns='jabber:iq:private'>
    <subscriptions xmlns='storage:pubsubs'>
      <subscription user='juliet@capulet.com'
		    jid='pubsub.capulet.com'
		    node='juliet/geoloc'
		    targetns='http://jabber.org/protocol/geoloc'
		    subscription='subscribed'/>
    </subscriptions>
  </query>
</iq>

<iq type='set' id='update1'>
  <query xmlns='jabber:iq:private'>
    <subscriptions xmlns='storage:pubsubs'>
      <subscription user='juliet@capulet.com'
		    jid='pubsub.capulet.com'
		    node='juliet/geoloc'
		    targetns='http://jabber.org/protocol/geoloc'
		    subscription='subscribed'/>
      <subscription user='romeo@montague.net'
		    jid='pubsub.montague.net'
		    node='5017cdc9f4a3d1450445c9096064e459'
		    targetns='http://jabber.org/protocol/tune'
		    subscription='subscribed'/>
    </subscriptions>
  </query>
</iq>

<iq type='result' id='update1'/>

<message
    from='pubsub.montague.net'
    to='mercutio@shakespeare.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='5017cdc9f4a3d1450445c9096064e459'>
      <item id='current'>
        <tune xmlns='http://jabber.org/protocol/tune'>
          <artist>Yes</artist>
          <title>Heart of the Sunrise</title>
          <source>Yessongs</source>
          <track>3</track>
          <length>686</length>
        </tune>
      </item>
    </items>
  </event>
</message>

5. Security Considerations

Pubsub events offer an opportunity to spoof sender addresses e.g. through 'replyto' data (as specified by the Extended Stanza Addressing [7] protocol). This protocol attempts to close that hole. It does so by the following rules and assumptions:

• A client MUST add mappings (i.e. associations between a publisher's JID and a pubsub node) only from trustworthy sources, i.e. published disco items (see Service Discovery [8]). This relies on disco information not being cracked or falsified.
• A client MUST retrieve mappings only from trustworthy sources, i.e. private XML storage. This assumes that no-one but the user is able to change such information.

6. IANA Considerations

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

7. XMPP Registrar Considerations

No namespaces or parameters need to be registered with the XMPP Registrar [10] as a result of this document.

8. XML Schema

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

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

  <xs:element name='subscriptions'>
    <xs:complexType>
      <xs:sequence>
	<xs:element ref='subscription' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='subscription'>
    <xs:complexType>
      <xs:attribute name='jid' type='xs:string' use='required'/>
      <xs:attribute name='node' type='xs:string' use='required'/>
      <xs:attribute name='subscription' use='required'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='none'/>
            <xs:enumeration value='pending'/>
            <xs:enumeration value='subscribed'/>
            <xs:enumeration value='unconfigured'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name='resource' type='xs:string' use='optional'/>
      <xs:attribute name='user' type='xs:string' use='optional'/>
      <xs:attribute name='targetns' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

</xs:schema>
  

Appendices

Appendix A: Document Information

Series: XEP
Number: 0173
Publisher: XMPP Standards Foundation
Status: Deferred
Type: Historical
Version: 0.1
Last Updated: 2006-02-09
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0049, XEP-0060
Supersedes: None
Superseded By: None
Short Name: pubsubs
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