This document specifies XMPP semantics for using the publish-subscribe protocol to broadcast state change events associated with a user or account.
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.12
Last Updated: 2006-08-01
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030, JEP-0060, JEP-0115
Supersedes: None
Superseded By: None
Short Name: pep
Wiki Page: <http://wiki.jabber.org/index.php/Personal Eventing via Pubsub (JEP-0163)>
Email:
stpeter@jabber.org
JID:
stpeter@jabber.org
Email:
kevin@kismith.co.uk
JID:
kevdadrum@jabber.ex.ac.uk
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 following 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".
The XMPP Publish-Subscribe [1] extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in User Geolocation [2], User Mood [3], User Activity [4], and User Tune [5]. [6] However, the full, generic pubsub protocol is often thought of as complicated and therefore has not been widely implemented in clients. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to XMPP IM [7]), this document defines simplified protocol semantics that can be followed by instant messaging client and server developers, hopefully resulting in the deployment of personal eventing services across the Jabber/XMPP network.
Personal eventing via pubsub ("PEP") is based on five principles:
These principles are described more fully below.
When a user creates an account (or has an account provisioned) at a Jabber/XMPP server, that account should have associated with it a virtual pubsub service. This greatly simplifies the task of discovering the account owner's personal pubsub nodes, since the root pubsub node simply is the account owner's bare JID (<node@domain.tld>). This assumption also simplifies publishing and subscribing.
There is no need for multiple publishers to a personal eventing service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.
To further simplify matters, we recommend that there be only one publish-subscribe node associated with any given payload type (XML namespace) for the owner-publisher. For example, there should be one pubsub node for location events, one node for tune events, one node for mood events, and so on. This simplifies node creation, discovery, publishing, and subscribing.
Most pubsub configuration options and metadata are not needed for personal eventing. Instead, servers should offer smart defaults to simplify node creation and management.
Although generic publish-subscribe service do not necessarily have access to presence information about subscribers, personal eventing services are integrated with presence in the following ways:
These uses of presence simplify the task of developing compliant clients (cf. Protocol Design Guidelines [9]).
This document illustrates PEP through a series of examples that use the following scenario:
An owner-publisher juliet@capulet.com who publishes the following information:
Three users who have the following relationship to Juliet:
The examples shown in the following sections walk through the protocol flows for node creation, discovery, publishing, and subscribing.
Naturally, before an account owner attempts to create nodes, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a Service Discovery [11] information request to the server:
<iq from='juliet@capulet.com/balcony' to='capulet.com' id='disco1' type='get'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
If a server supports PEP, it MUST return an identity of "pubsub/pep" (as well as a list of the namespaces and other features it supports, including all supported JEP-0060 features):
<iq from='capulet.com' to='juliet@capulet.com/balcony' id='disco1' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='pubsub' type='pep'/> ... </query> </iq>
In order to create a node, an account owner MUST follow the node creation protocol specified in JEP-0060. [12]
For example, Juliet would send the following stanzas in order to create the nodes mentioned above:
<iq from='juliet@capulet.com/balcony' type='set' id='create-open'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <create node='http://jabber.org/protocol/tune'/> <configure> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/pubsub#node_config</value> </field> <field var='pubsub#access_model'> <option><value>open</value></option> </field> </x> </configure> </pubsub> </iq>
<iq from='juliet@capulet.com/balcony' type='set' id='create-presence'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <create node='http://jabber.org/protocol/activity'/> <configure> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/pubsub#node_config</value> </field> <field var='pubsub#access_model'> <option><value>presence</value></option> </field> </x> </configure> </pubsub> </iq>
<iq from='juliet@capulet.com/balcony' type='set' id='create-roster'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <create node='http://jabber.org/protocol/geoloc'/> <configure> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/pubsub#node_config</value> </field> <field var='pubsub#access_model'> <option><value>roster</value></option> </field> <field var='pubsub#roster_groups_allowed'> <option><value>friends</value></option> </field> </x> </configure> </pubsub> </iq>
<iq from='juliet@capulet.com/balcony' type='set' id='create-whitelist'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <create node='storage:bookmarks'/> <configure> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/pubsub#node_config</value> </field> <field var='pubsub#access_model'> <option><value>whitelist</value></option> </field> </x> </configure> </pubsub> </iq>
A contact MAY send service discovery requests to the account owner's bare JID (<node@domain.tld>). Although this is not necessary in order to subscribe to the account owner's personal eventing data (as explained in the following section), it is shown here to further illustrate the role of access models.
First, benvolio@montague.net sends a disco#info request to juliet@capulet.com:
<iq from='benvolio@montague.net/home' to='juliet@capulet.com' id='disco1' type='get'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
If Juliet's server supports PEP (thereby making juliet@capulet.com a virtual pubsub service), it MUST return an identity of "pubsub/pep":
<iq from='juliet@capulet.com' to='benvolio@montague.net/home' id='disco1' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='pubsub' type='pep'/> ... </query> </iq>
Second, benvolio@montague.net sends a disco#items request to juliet@capulet.com:
<iq from='benvolio@montague.net/home' to='juliet@capulet.com' id='disco2' type='get'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq>
The account owner's server MUST check the access model for each of the account owner's PEP nodes and MUST return as service discovery items only those nodes to which the contact is allowed to subscribe or from which the contact is allowed to retrieve items.
Therefore, in this case, the server would return only the "http://jabber.org/protocol/tune" node (since it has an open access model and the contact does not have a presence subscription to the account owner's presence):
<iq from='juliet@capulet.com' to='benvolio@montague.net/home' id='disco2' type='result'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='juliet@capulet.com' node='http://jabber.org/protocol/tune'/> </query> </iq>
Next, nurse@capulet.com sends a disco#items request to juliet@capulet.com:
<iq from='nurse@capulet.com/chamber' to='juliet@capulet.com' id='disco3' type='get'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq>
However, in this case, the server would return the "http://jabber.org/protocol/tune" node (open access model) and the "http://jabber.org/protocol/activity" node (presence access model):
<iq from='juliet@capulet.com' to='nurse@capulet.com/chamber' id='disco3' type='result'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='juliet@capulet.com' node='http://jabber.org/protocol/tune'/> <item jid='juliet@capulet.com' node='http://jabber.org/protocol/activity'/> </query> </iq>
Finally, romeo@montague.net sends a disco#items request to juliet@capulet.com:
<iq from='romeo@montague.net/orchard' to='juliet@capulet.com' id='disco4' type='get'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq>
In this case, the server would return the "http://jabber.org/protocol/tune" node (open access model) and the "http://jabber.org/protocol/activity" node (presence access model) and the "http://jabber.org/protocol/geoloc" node (roster access model):
<iq from='juliet@capulet.com' to='romeo@montague.net/orchard' id='disco4' type='result'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='juliet@capulet.com' node='http://jabber.org/protocol/tune'/> <item jid='juliet@capulet.com' node='http://jabber.org/protocol/activity'/> <item jid='juliet@capulet.com' node='http://jabber.org/protocol/geoloc'/> </query> </iq>
If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in JEP-0060. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:
<iq type='set' from='benvolio@montague.net/home' to='juliet@capulet.com' id='sub1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <subscribe node='http://jabber.org/protocol/tune' jid='romeo@montague.net'/> </pubsub> </iq>
However, when a contact is affiliated with the account owner through a presence subscription, PEP greatly simplifies the subscription process. Indeed, such a contact automatically receives notifications from all nodes of interest simply by being subscribed to the account owner's presence. This is done by associating the presence subscription with a pubsub subscription to the account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all". As a result, a contact with a presence subscription to the account owner will receive all items published to all of the account owner's nodes with access models of "open" and "presence".
Consider, then, the following presence subscription exchange:
<presence from='nurse@capulet.com' to='juliet@capulet.com' type='subscribe'/> <presence from='juliet@capulet.com' to='nurse@capulet.com' type='subscribed'/>
This is equivalent to the following pubsub subscription exchange:
<iq type='set' from='nurse@capulet.com/chamber' to='juliet@capulet.com id='collsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <subscribe jid='nurse@capulet.com'/> <options> <x xmlns='jabber:x:data'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/pubsub#subscribe_options</value> </field> <field var='pubsub#subscription_type'> <value>items</value> </field> <field var='pubsub#subscription_depth'> <value>all</value> </field> </x> </options> </pubsub> </iq> <iq type='result' from='juliet@capulet.com' to='nurse@capulet.com/chamber' id='collsub'/>
Therefore, because both nurse@capulet.com and romeo@montague.net have presence subscriptions to juliet@capulet.com, they will receive all notifications generated by the "http://jabber.org/protocol/tune" and "http://jabber.org/protocol/activity" nodes.
In addition, because romeo@montague.net is in the "Friends" group in Juliet's roster, he will receive the foregoing notifications as well as notifications generated by the "http://jabber.org/protocol/geoloc" node.
Consider what happens when the account owner publishes an item to a node:
<iq from='juliet@capulet.com/balcony' 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>Gerald Finzi</artist> <title>Introduction (Allegro vigoroso)</title> <source>Music for "Love's Labors Lost" (Suite for small orchestra)</source> <track>1</track> <length>255</length> </tune> </item> </publish> </pubsub> </iq>
Now the account owner's server generates notifications and sends them to all subscribers (in this case, all three entities):
<message from='juliet@capulet.com' to='benvolio@montague.net' 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>Gerald Finzi</artist> <title>Introduction (Allegro vigoroso)</title> <source>Music for "Love's Labors Lost" (Suite for small orchestra)</source> <track>1</track> <length>255</length> </tune> </item> </items> </event> </message> <message from='juliet@capulet.com' to='nurse@capulet.com/chamber' 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>Gerald Finzi</artist> <title>Introduction (Allegro vigoroso)</title> <source>Music for "Love's Labors Lost" (Suite for small orchestra)</source> <track>1</track> <length>255</length> </tune> </item> </items> </event> <addresses xmlns='http://jabber.org/protocol/address'> <address type='replyto' jid='juliet@capulet.com/balcony'/> </addresses> </message> <message from='juliet@capulet.com' to='romeo@montague.net/home' 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>Gerald Finzi</artist> <title>Introduction (Allegro vigoroso)</title> <source>Music for "Love's Labors Lost" (Suite for small orchestra)</source> <track>1</track> <length>255</length> </tune> </item> </items> </event> <addresses xmlns='http://jabber.org/protocol/address'> <address type='replyto' jid='juliet@capulet.com/balcony'/> </addresses> </message>
The server MUST set the 'from' address on the notification to the bare JID (<node@domain.tld>) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to entities that have presence subscription to the account owner, the server SHOULD include an Extended Stanza Addressing [13] "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables 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). However, a server MUST NOT include the "replyto" address when sending notifications to entities that do not have presence subscriptions to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.
For further rules regarding notifications, see the Contact Notification Filtering and Generating Notifications sections of this document.
A contact with a presence subscription to the account owner may not want to receive notifications from all nodes with an access model of "open" or "presence" (or "roster"). A contact MAY signal its preferences to the account owner's server by including Entity Capabilities [14] information that specifies the namespaces for which the contact wishes to receive notifications.
In order to make this possible, all possible payload namespaces can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the payload format. Thus if Romeo wants to receive notifications for activity data and geolocation data but not tune data, his client would advertise support for the following namespaces in the disco#info results it sends:
This set of namespaces would then be advertised as a JEP-0115 "ext" value, such as the following:
<presence from='romeo@montague.net/orchard'> <c xmlns='http://jabber.org/protocol/caps' node='http://www.chatopus.com/' ver='2.1' ext='foobar pres+'/> </presence>
Note: In JEP-0115, the "ext" values are opaque strings with no semantic meaning.
It is the responsibility of the account owner's server to cache JEP-0115 information (including "ext" values and their associated namespaces). When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the supported and desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Developer consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact.
Some examples may help to illustrate the concept. Here we show presence generated by two of the contacts listed above (benvolio@montague.net does have any presence subscriptions to or from juliet@capulet.com and therefore is not involved in these protocol flows).
<presence from='nurse@capulet.com/chamber'> <c xmlns='http://jabber.org/protocol/caps' node='http://exodus.jabberstudio.org/caps' ver='0.9' ext='asdf fdsa bar baz'/> </presence> <presence from='romeo@montague.net/orchard'> <c xmlns='http://jabber.org/protocol/caps' node='http://www.chatopus.com/' ver='2.1' ext='foobar pres+'/> </presence>
We assume that Juliet's server doesn't know anything about these capabilities, so it sends service discovery information requests to each of the clients on Juliet's behalf (realistically, the capulet.com server will quickly build up a cache of client capabilities so will not need to send these services discovery requests):
<iq from='juliet@capulet.com' to='nurse@capulet.com/chamber' type='get' id='disco123'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq> <iq from='nurse@capulet.com/chamber' to='juliet@capulet.com' type='result' id='disco123'> <query xmlns='http://jabber.org/protocol/disco#info'> <feature var='http://jabber.org/protocol/tune'/> <feature var='http://jabber.org/protocol/tune+notify'/> <feature var='http://jabber.org/protocol/activity'/> <feature var='http://jabber.org/protocol/activity+notify'/> <feature var='http://jabber.org/protocol/geoloc'/> <feature var='http://jabber.org/protocol/geoloc+notify'/> </query> </iq>
<iq from='juliet@capulet.com' to='romeo@montague.net/orchard' type='get' id='disco234'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq> <iq from='romeo@montague.net/orchard' to='juliet@capulet.com' type='result' id='disco234'> <query xmlns='http://jabber.org/protocol/disco#info'> <feature var='http://jabber.org/protocol/tune'/> <feature var='http://jabber.org/protocol/activity'/> <feature var='http://jabber.org/protocol/geoloc'/> <feature var='http://jabber.org/protocol/geoloc+notify'/> </query> </iq>
Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information:
If Juliet publishes a tune item to the open-access "http://jabber.org/protocol/tune" node, her server will send notifications to <benvolio@montague.net> (bare JID) and to <nurse@capulet.com/chamber> (full JID) but not to <romeo@montague.net/orchard>.
If Juliet publishes an activity item to the presence-access "http://jabber.org/protocol/activity" node, her server will send notifications only to <nurse@capulet.com/chamber>.
If Juliet publishes a geolocation item to the roster-access "http://jabber.org/protocol/geolco" node, her server will send notifications only to <romeo@montague.net/orchard>.
If a subscriber subscribed using a full JID (<node@domain.tld/resource>), domain identifier (<domain.tld>), or domain plus resource (<domain.tld/resource>), a PEP service MUST send one notification only, addressed to the subscribed JID.
If a subscriber subscribed using a bare JID (<node@domain.tld>) and a PEP service has presence information about the subscriber, the service MUST send one notification to the full JID (<node@domain.tld/resource>) of each of the subscriber's available resources that have specified non-negative presence priority. [15]
If a subscriber subscribed using a bare JID (<node@domain.tld>) and a PEP service does not have presence information about the subscriber, it MUST send at most one notification, addressed to the bare JID (<node@domain.tld>) of the subscriber.
When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all subscribers (where the number of notifications is determined by the foregoing rules).
When a PEP service successfully processes a new subscription, it MUST generate a notification containing the last published item for that node and send it to the subscribing JID (where the number of notifications is determined by the foregoing rules).
When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.
As an exception to the foregoing MUST rules, a PEP service MAY choose not to send notifications to a subscriber if the subscribed JID is a bare JID (<node@domain.tld>) and the service does not have presence information about the subscriber. [16]
As an exception to the foregoing MUST rules, a PEP service MAY choose not to send notifications to a particular resource for a subscriber if it knows via Entity Capabilities that the resource does not support PEP or does not support the payload namespace associated with a particular node.
As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using privacy lists as specified in XMPP IM.
As described in the Generating Notifications section of this document, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber. [17]
<presence from='romeo@montague.net/orchard'/>
<presence from='romeo@montague.net/orchard' to='juliet@capulet.com'/>
<message from='juliet@capulet.com' to='romeo@montague.net/orchard' 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>Gerald Finzi</artist> <title>Introduction (Allegro vigoroso)</title> <source>Music for "Love's Labors Lost" (Suite for small orchestra)</source> <track>1</track> <length>255</length> </tune> </item> </items> </event> <x xmlns='jabber:x:delay' stamp='20031213T23:58:37'/> </message>
A PEP service MUST support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and items retrieval use cases specified in JEP-0060, and MAY support other use cases according to implementation decisions or deployment policies.
A PEP service MUST support the "owner" and "subscriber" affiliations but SHOULD NOT support other affiliations.
The default access model for a PEP service SHOULD be "presence" for IM servers and SHOULD be "open" for non-IM servers; a PEP service associated with an IM server SHOULD also support the "roster" access model; a PEP service MAY also support the "authorize" and "whitelist" access models.
A PEP service SHOULD use the following "smart defaults" for every node:
A PEP service MUST treat the owner-publisher's bare JID (<node@domain.tld>) as a collection node (i.e., as the root collection node for the account's virtual pubsub service), but SHOULD NOT support any other collection nodes.
A PEP service SHOULD NOT support instant nodes, since the "one node per namespace" rule makes instant nodes unnecessary.
In order to ensure appropriate access to information published at nodes of type "presence" and "roster"", a PEP service MUST re-calculate access controls when:
If the modification results in a loss of access, the service MUST cancel the entity's subscription and SHOULD send a message to the (former) subscriber informing it of the cancellation. For information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of JEP-0060.
A PEP 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) [18].
The Jabber Registrar includes a category of "pubsub" in its registry of Service Discovery identities (see <http://www.jabber.org/registrar/disco-features.html>); as a result of this JEP, the Registrar shall add a type of "pep" to that category.
The registry submission is as follows:
<category> <name>pubsub</name> <type> <name>pep</name> <desc> A personal eventing service that supports the publish-subscribe subset defined in JEP-0163. </desc> <doc>JEP-0163</doc> </type> </category>
Because the Personal Eventing Protocol is all and only a subset of Publish-Subscribe, the schemas defined in JEP-0060 apply to PEP as well.
The authors wish to thank the participants in the XMPP Interoperability Testing Event held July 24 and 25, 2006, who provided valuable feedback that resulted in radical simplification of the protocol.
1. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
2. JEP-0080: User Geolocation <http://www.jabber.org/jeps/jep-0080.html>.
3. JEP-0107: User Mood <http://www.jabber.org/jeps/jep-0107.html>.
4. JEP-0108: User Activity <http://www.jabber.org/jeps/jep-0108.html>.
5. JEP-0118: User Tune <http://www.jabber.org/jeps/jep-0118.html>.
6. Currently, many "extended presence" formats are sent using the <presence/> stanza type; however, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable.
7. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
8. JEP-0115: Entity Capabilities <http://www.jabber.org/jeps/jep-0115.html>.
9. JEP-0134: Protocol Design Guidelines <http://www.jabber.org/jeps/jep-0134.html>.
10. JEP-0049: Private XML Storage <http://www.jabber.org/jeps/jep-0049.html>.
11. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
12. The authors considered simpler node creation semantics, for example behavior in which a service automatically creates a given node when an account owner attempts to publish to it. Although this has the virtue of being similar to, say, room creation in JEP-0045, it seriously complicates the task of determining the node access model (so much so that the publish semantics would in the end closely resemble the existing node creation semantics).
13. JEP-0033: Extended Stanza Addressing <http://www.jabber.org/jeps/jep-0033.html>.
14. JEP-0115: Entity Capabilities <http://www.jabber.org/jeps/jep-0115.html>.
15. If the only presence information received by the service is from resources that have specified negative priorities, the service MUST NOT send any notifications.
16. If the only presence information received by the service is from resources that have specified negative priorities, the service MUST NOT send any notifications.
17. That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in XMPP IM.
18. 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/>.
Simplified the subscription process using XMPP presence and entity capabilities.
(psa)Clarified rules regarding number of notifications and when to generate notifications; corrected several errors in the text and examples.
(psa)Updated to reflect version 1.8 of JEP-0060.
(psa)Updated to reflect use of data forms in JEP-0060.
(psa)Clarified terminology and defaults.
(psa)Specified that notifications are to be sent from bare JID, not full JID.
(psa)Updated to reflect pubsub changes; clarified business rules for generation of notifications and cancellation of subscriptions.
(psa)Modified roster groups example to use jabber:x:data; added note about advertising client support for PEP.
(psa)Specified rules for generation of notifications, including use of presence in determining address of intended recipient for notifications and sending of last published item on receipt of presence information; changed name to Personal Eventing Protocol; specified service discovery identity of pubsub/pep; removed section on service types; added Kevin Smith as co-author.
(psa/ks)Specified that a service may enforce additional privacy and security policies; specified that an account owner must always be allowed to subscribe and to retrieve items; specified that an implementation should enforce access modifications resulting from roster state changes.
(psa)Updated to reflect proposed JEP-0060 modifications.
(psa)Initial JEP version.
(psa)Added more details and examples.
(psa)First draft.
(psa)END