Replaced hardcoded NodeIDs (one node per namespace) with server-side namespace matching; specified semantic layering of data format, wrapper, and NodeID; defined registry for NodeIDs; more fully specified use of PEP for private data storage.
The XMPP &xep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &xep0080; or &xep0107;.
-
The XMPP &xep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;.
Note: This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension.
Personal eventing via pubsub ("PEP") is based on the following principles:
+Personal eventing via pubsub ("PEP") is based on six principles:
These principles are described more fully below.
There is no need for multiple publishers to a PEP 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.
There is only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there is one pubsub node for geolocation events, one node for tune events, and one node for mood events). This simplifies node creation, discovery, publishing, and subscribing.
+Although generic publish-subscribe services do not necessarily have access to presence information about subscribers, PEP services are integrated with presence in the following ways:
These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).
By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &xep0115; information in the presence notifications it sends to the account owner. The PEP service then sends only those notifications that match the contact's expressed notification preferences, based on the "pubsub#type" of the nodes that match -- where the payload type is the wrapper namespace (if any) or, in the absence of a wrapper, the data format namespace (as described below under Semantic Layering).
+By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &xep0115; information in the presence notifications it sends to the account owner, and the PEP service sends only those notifications that match the contact's expressed notification preferences.
Most pubsub configuration options and metadata are not needed for personal eventing. Instead, PEP services offer smart defaults to simplify node creation and management. The only required configuration options are the access model and the pubsub type (payload namespace).
-There are several layers of meaning in personal eventing:
Thus there is a one to many relationship between data formats and wrappers, and a one to many relationship between wrappers and NodeIDs. The examples below show the function of semantic layering in PEP.
+Most pubsub configuration options and metadata are not needed for personal eventing. Instead, PEP services offer smart defaults to simplify node creation and management.
An owner-publisher juliet@capulet.com who publishes the following information:
When an account owner attempts to publish an item to a PEP node and that node does not already exist, the PEP service MUST automatically create the node with default configuration.
For example, Juliet would send the following stanzas in order to create the nodes mentioned above:
-In the foregoing examples, we assume the following semantic layering:
-A contact MAY send service discovery requests to the account owner's bare JID (&BAREJID;). 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:
+If Juliet's server supports PEP (thereby making juliet@capulet.com a virtual pubsub service), it MUST return an identity of "pubsub/pep":
+Second, benvolio@montague.net sends a disco#items request to juliet@capulet.com:
+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 without first subscribing.
+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):
+Next, nurse@capulet.com sends a disco#items request to juliet@capulet.com:
+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):
+Finally, romeo@montague.net sends a disco#items request to juliet@capulet.com:
+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):
+If an entity is not subscribed to the account owner's presence, it MUST discover and then subscribe to a node using the protocol defined in XEP-0060. However, when a contact and account owner are subscribed to each other's presence, PEP greatly simplifies the subscription process. 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".
+If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in XEP-0060. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:
+However, when a contact is affiliated with the account owner through a presence subscription, PEP greatly simplifies the subscription process. 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".
Consider the following presence subscription exchange:
A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including XEP-0115 information that specifies the namespaces for which the contact wishes to receive notifications (if any).
-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 tune data and geolocation data but not blog data, his client would advertise support for the following namespaces in the disco#info results it sends:
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 XEP-0115 "ext" value, such as the following:
@@ -501,7 +568,7 @@ ]]>Note: In XEP-0115, the "ext" values are opaque strings with no semantic meaning.
-It is the responsibility of the account owner's server to cache XEP-0115 information (including "ext" values and their associated namespaces). When a PEP-enabled server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the 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. Community 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 and the contact has a presence subscription to the account owner.
+It is the responsibility of the account owner's server to cache XEP-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 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. Community 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 and the contact has a presence subscription to the account owner.
Some examples may help to illustrate the concept of notification filtering. 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).
Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information:
If Juliet publishes a blog item to the open-access "blog1" node (pubsub type "http://weblog.example.org/schema" 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 a tune item to the presence-access "mytunes" node (pubsub type "http://jabber.org/protocol/tune"), her server will send notifications only to <nurse@capulet.com/chamber>.
If Juliet publishes a geolocation item to the roster-access "mylocation" node (pubsub type "http://jabber.org/protocol/geoloc"), her server will send notifications only to <romeo@montague.net/orchard>.
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/geoloc" node, her server will send notifications only to <romeo@montague.net/orchard>.
As noted, PEP services can be used to implement so-called "private data storage", similar in functionality to the dedicated protocol described in &xep0049; (which is often used for storing client preferences, user bookmarks, and the like). In essence, a private node is a pubsub node whose access model is "whitelist", where there are no entities in the whitelist (the account owner is automatically granted access to the node and therefore receives all node events and can retrieve items from the node at will). This results in the following functionality:
-As noted, PEP services may be used to implement private data storage, such as defined in &xep0049;. A future version of this document will specify this usage in more detail.
A PEP service MUST:
A PEP service MAY support other use cases, affiliations, access models, and features, but such support is OPTIONAL.
A service SHOULD support all NodeIDs that are registered with the XMPP Registrar as described in the PEP Nodes section of this document. This support shall include enforcement of the NodeID within the context of a given account, the payload type (whether wrapper or data format namespace), and any other configuration defaults as specified in the registry (this enables clients to perform seamless publish-and-create in one step).
-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:
The XMPP Registrar shall create a registry of PEP nodes.
- ®PROCESS; -
- the NodeID for the PEP node
- a natural-language description of the PEP node
- the specification in which the PEP node is specified
-
- default_value
-
-
- ]]>
- Note: The "pubsub_configuration_field_name" and "default_value" strings are as registered for the "pubsub#node_config" FORM_TYPE by XEP-0060.
-The registrant may register more than one PEP node at a time, each contained in a separate <node/> element.
-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. Thanks also to Ralph Meijer and Ian Paterson for helpful discussions related to payload types and NodeID registration.
+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.