This document specifies a simple profile of the publish-subscribe protocol for use in personal publishing and similar applications.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Standards Track
Number: 0163
Version: 0.3
Last Updated: 2006-01-30
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0060
Supersedes: None
Superseded By: None
Short Name: spps
Wiki Page: <http://wiki.jabber.org/index.php/Simplified Personal Publish-Subscribe (JEP-0163)>
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software 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 JEP 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.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The XMPP Publish-Subscribe [1] extension is commonly thought of as complicated. This is unfortunate, since it would be good to use it for simple personal publishing tasks, such as those described in Extended Presence Protocol Suite [2]. To make publish-subscribe functionality more accessible, this document defines best practices that can be followed by client and server developers, hopefully resulting in the deployment of simplified personal publish-subscribe ("SPPS") services across the Jabber/XMPP network.
Note Well: This document describes all and only a subset of the full publish-subscribe protocol; any new features needed by SPPS shall be defined in JEP-0060, not in this document. Until the provisional changes to JEP-0060 are approved by the Jabber Council, readers of this document are referred to the version-in-progress located at <http://www.jabber.org/jeps/tmp/jep-0060-1.8.html>.
Simplified personal publish-subscribe is based on four principles:
These principles are described more fully below.
When a user creates an account (or has an account provisioned) at an XMPP server, that account should have associated with it a virtual pubsub service. This greatly simplifies the task of discovering the personal pubsub nodes associated with the account owner, since the root pubsub node simply is the account owner's bare JID (<node@domain.tld>). It also simplifies publishing and subscribing.
Most pubsub configuration options and metadata are not needed for simplified personal publishing. Instead, servers should offer smart defaults to simplify node creation and management.
There is no need for multiple publishers to a personal pubsub service, since by definition the service is personal. The owner and publisher for every node is the bare JID of the associated account owner.
To further simplify matters, we assume that there is only one publish-subscribe node associated with any given payload type (XML namespace) for the publisher/owner. For example, there is one pubsub node for User Geolocation [3], one node for User Tune [4], one node for User Mood [5], and so on. This simplifies both publishing and subscribing.
In order to discover whether a server or other entity supports simplified personal publish-subscribe, an entity MUST use Service Discovery [6].
Example 1. Entity queries a server regarding protocol support
<iq from='juliet@capulet.com/balcony'
to='capulet.com'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
If a server supports SPPS, it MUST return a feature of "http://jabber.org/protocol/pubsub#spps" and MUST specify its default access model as described in JEP-0060.
Example 2. Server communicates protocol support
<iq from='capulet.com'
to='juliet@capulet.com/balcony'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='pubsub' type='service'/>
<feature var='http://jabber.org/protocol/pubsub'/>
<feature var='http://jabber.org/protocol/pubsub#spps'/>
<feature var='http://jabber.org/protocol/pubsub#default_access_model_presence'/>
...
</query>
</iq>
First, the account owner creates the node.
Example 3. Account owner creates node
<iq type='set' id='create1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='http://jabber.org/protocol/mood'/>
<configure/>
</pubsub>
</iq>
There are several things to note about this node creation request:
Now the server acknowledges success.
Example 4. Server returns result
<iq type='result' id='create1'/>
The value of the 'access' attribute SHOULD be "open", "presence", or "roster" for SPPS nodes (i.e., the value SHOULD NOT be "authorize" or "whitelist" since maintenance of such nodes requires interaction on the part of the node owner). The default access model for SPPS nodes MUST be "presence" for IM servers but MAY be something other than "presence" for other SPPS service types (e.g., non-IM servers).
If the account owner desires an open access model for a node, it MUST specify that in the creation request:
Example 5. Account owner creates open access node
<iq type='set' id='create-open-1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='http://jabber.org/protocol/tune' access='open'/>
<configure/>
</pubsub>
</iq>
If the account owner desires a roster access model for a node, it MUST specify that in the creation request:
Example 6. Account owner creates roster access node
<iq type='set' id='create-open-1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='http://jabber.org/protocol/geoloc' access='roster'>
<group>Friends</group>
</create>
<configure/>
</pubsub>
</iq>
Next, the account owner publishes an item to the node.
Example 7. Account owner publishes item
<iq type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/tune'>
<item>
<tune xmlns='http://jabber.org/protocol/tune'>
<artist>Ralph Vaughan Williams</artist>
<title>Concerto in F for Bass Tuba</title>
<source>Golden Brass: The Collector's Edition</source>
</tune>
</item>
</publish>
</pubsub>
</iq>
Again, the server acknowledges success.
Example 8. Server returns result
<iq type='result' id='pub1'/>
The notification (with payload) is then delivered to all subscribers:
Example 9. Server generates notifications
<message to='stpeter@jabber.org' from='pgmillard@jabber.org/work' type='headline' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/tune'>
<item>
<tune xmlns='http://jabber.org/protocol/tune'>
<artist>Ralph Vaughan Williams</artist>
<title>Concerto in F for Bass Tuba</title>
<source>Golden Brass: The Collector's Edition</source>
</tune>
</item>
</items>
</event>
</message>
.
.
.
Because it may be desirable to specify which resource has published an item, the server MUST set the 'from' address on the notification to the full JID (<node@domain.tld/resource>) of the publishing resource (in the previous example, "pgmillard@jabber.org/work"). This will enable the subscriber's client to differentiate between information received from each of an account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). Naturally, if there is only one active resource for the account owner, the subscriber's client can safely ignore the resource.
Node discovery is made easy since there is only one node per namespace. The potential subscriber may send a service discovery items request to the bare JID to discover all active pubsub nodes.
Example 10. Subscriber queries bare JID
<iq type='set' id='disco1' from='stpeter@jabber.org/roundabout' to='pgmillard@jabber.org'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
Subject to access restrictions as described in JEP-0030, the account owner's server would then return all pubsub nodes:
Example 11. Servers returns list of pubsub nodes
<iq type='result' id='disco1' to='stpeter@jabber.org/roundabout' from='pgmillard@jabber.org'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='pgmillard@jabber.org' node='http://jabber.org/protocol/mood'/>
<item jid='pgmillard@jabber.org' node='http://jabber.org/protocol/tune'/>
<item jid='pgmillard@jabber.org' node='http://jabber.org/protocol/geolocation'/>
</query>
</iq>
Alternatively, the potential subscriber may send a disco#info request to the specific node of interest:
Example 12. Subscriber queries specific node
<iq type='set' id='disco2' from='stpeter@jabber.org/roundabout' to='pgmillard@jabber.org'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/tune'/>
</iq>
The account owner's server would then return information about the node (if it exists) or an <item-not-found/> error if the node does not exist:
Example 13. Servers returns node info
<iq type='result' id='disco2' to='stpeter@jabber.org/roundabout' from='pgmillard@jabber.org'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/tune'>
<identity category='pubsub' type='leaf'/>
<feature var='http://jabber.org/protocol/pubsub'/>
</query>
</iq>
In order to subscribe, a contact sends a subscription request to the account owner's bare JID (not full JID) and specifies the desired node:
Example 14. Contact subscribes to a node
<iq type='set'
from='stpeter@jabber.org/roundabout'
to='pgmillard@jabber.org'
id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='http://jabber.org/protocol/tune' jid='stpeter@jabber.org'/>
</pubsub>
</iq>
The following scenarios are possible:
The only exception foreseen to the SHOULD requirements in the foregoing scenarios is the enforcement of local privacy and security policies as specified more fully in the Security Considerations section of this document. (In addition, a service MUST always allow the account owner to subscribe and to retrieve items.)
If the server disallows the subscription for whatever reason (including enforcement of local security policies), it MUST return a <forbidden/> error:
Example 15. Server disallows subscription
<iq type='result'
from='pgmillard@jabber.org'
to='stpeter@jabber.org/roundabout'
id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='http://jabber.org/protocol/tune' jid='stpeter@jabber.org'/>
</pubsub>
<error code='403' type='cancel'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If the server allows the subscription, it MUST return an IQ-result:
Example 16. Server allows subscription
<iq type='result'
from='pgmillard@jabber.org'
to='stpeter@jabber.org/roundabout'
id='sub1'/>
As noted, a service MUST always allow the account owner to subscribe and to retrieve items.
The default access model for an SPPS service SHOULD be "presence" (it MUST be "presence" for an SPPS service associated with an IM server but MAY be something other than "presence" for other kinds of SPPS services).
An SPPS service SHOULD NOT support affiliations other than Owner and Subscriber.
An SPPS service SHOULD use the following "smart defaults" for every node:
An SPPS service MAY allow the bare JID (<node@domain.tld>) to be a collection node, but SHOULD NOT support any other collection nodes.
An SPPS service SHOULD NOT support instant nodes, since the "one node per namespace" rule makes instant nodes unnecessary.
It is envisioned that most SPPS services will be associated with instant messaging and presence servers that conform to RFC 3921 [7]. However, it is also possible for an SPPS service to be associated with a "mere" XMPP server that conforms only to RFC 3920 [8] or with a non-server implementation such as a Multi-User Chat [9] service.
When the SPPS service is associated with an IM server, the default access model MUST be "presence".
When the SPPS service is associated with a non-IM server, the default access model SHOULD be "open" but MAY be "whitelist" (how and by whom the whitelist is maintained are outside the scope of this document); the default access model MUST NOT be "presence" or "roster" since those concepts do not apply to non-IM servers and SHOULD NOT be "authorize".
When the SPPS service is associated with a multi-user chat service, the default access model SHOULD be "roster" (where the roster is the room roster of occupants in the room) but MAY be "whitelist" (where the whitelist is the list of members in a members-only room); the default access model MUST NOT be "presence" since that concept does not apply to multi-user chat services and SHOULD NOT be "authorize" or "open".
In order to ensure coherency for nodes of type "presence" and "roster", a service SHOULD recalculate access controls whenever a roster item is modified (e.g., when a subscription request is approved or whhen the item is moved to a new roster group). If the modification results in a loss of access, a service MUST cancel the entity's subscription and MAY send a message to the (former) subscriber informing the entity of the cancellation.
An SPPS service MAY enforce additional privacy and security policies when determining whether an entity is allowed to subscribe to a node or retrieve items from a node; however, any such policies shall be considered specific to an implementation or deployment and are out of scope for this document.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [10].
The Jabber Registrar [11] shall include 'http://jabber.org/protocol/pubsub#spps' in its registry of protocol namespaces.
Not needed (see JEP-0060).
Thanks to Kevin Smith of the Psi project for his helpful comments.
1. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
2. JEP-0119: Extended Presence Protocol Suite <http://www.jabber.org/jeps/jep-0119.html>.
3. JEP-0080: User Geolocation <http://www.jabber.org/jeps/jep-0080.html>.
4. JEP-0118: User Tune <http://www.jabber.org/jeps/jep-0118.html>.
5. JEP-0107: User Mood <http://www.jabber.org/jeps/jep-0107.html>.
6. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
7. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
8. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
9. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
10. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
11. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END