Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. While the XMPP &xep0060; extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented. Instead, many "extended presence" formats are currently sent using the &PRESENCE; stanza type; unfortunately, 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. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines a simplified subset of pubsub that can be followed by instant messaging client and server developers to more easily deploy personal eventing services across the Jabber/XMPP network. We label this subset "Personal Eventing via Pubsub" or PEP. 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.

This section provides a friendly, non-normative introduction to the workings of personal eventing via pubsub (PEP).

There are two sides to personal eventing: what the user does to generate events and what the contact does to receive events. As shown in the following examples, both are simplified in PEP as compared to generic pubsub.

Imagine that you are a Shakespearean character named Juliet and that you want to generate the following kinds of events that may be of interest to other people:

1. Information about what music you're listening to, which anyone may see even if they are not allowed to know your online/offline presence (i.e., a pubsub access model of "presence")
2. Information about your geographical location, which only contacts in your "Friends" roster group may see (i.e., a pubsub access model of "roster" with a group of "Friends")

We assume that there are three other users who have the following relationship to you:

1. benvolio@montague.net, who has no subscription to your presence
2. nurse@capulet.com, who has a bidirectional subscription to your presence and who is in your "Servants" roster group
3. romeo@montague.net, who has a bidirectional subscription to your presence and who is in your "Friends" roster group

We also assume that your server (montague.net) supports PEP and that your client discovered that support when you logged in.

Now you start playing a song on your music playing software. Your client captures that "event" and publishes it to your server:

Note the following about your publish request:

1. It is sent with no 'to' address (see Every Account a Pubsub Service).
2. It specifies a node of "http://jabber.org/protocol/tune" (see One Node per Namespace).
3. It includes the desired node configuration, which here is a presence access model (see Fire and Forget).

If all goes well (see Publishing Events), everyone who is interested in what you are listening to will receive notification of the event:

But how do Romeo and the Nurse tell your server that they are interested in knowing what you're listening to? In generic pubsub they need to explicitly subscribe to your "http://jabber.org/protocol/tune" node. That is still necessary for open access model nodes in PEP if another user does not have a subscription to your presence, such as benvolio@montague.net in our scenario. In PEP, they only need to advertise that they are interested by including some special flags (see Filtered Notifications) in the &xep0115; information they include in their presence broadcasts (see Use Presence).

Your server knows to send tune information to Romeo not directly because his client advertises an 'ext' value of "sendmetunes" (the 'ext' values have no semantic meaning in XEP-0115) but because the disco#info response from the "http://www.chatopus.com/ec#sendmetunes" node advertises a feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in the protocol that precedes the suffix:

Naturally your server doesn't need to send out a disco#info request every time, since it will quickly create a large cache of such extensions!

So that's the general idea. We'll demonstrate it again with an example of geolocation...

First your client generates a geolocation event:

Then your server sends event notifications, this time addressing the event only to Romeo, since the Nurse is not in your Friends roster group:

And your server knows to send the geolocation notification to Romeo because (1) he is in your Friends group and (2) his client advertised interest in "http://jabber.org/protocol/geolocation" events.

When a user creates an account (or has an account provisioned) at a Jabber/XMPP server that supports PEP, the server associates a virtual pubsub service with the account. 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 (&BAREJID;). This assumption also simplifies publishing and subscribing.

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:

• Each messaging and presence account simply is a virtual publish-subscribe service.
• The default access model is "presence".
• A contact's subscription to an account owner's personal eventing data is normally handled via the existence of an XMPP presence subscription.
• Services take account of subscriber presence in the generation of notifications. This works only if the subscription state is "both" (see RFC 3921).

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, 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.

A client should be able to publish an item without having to worry about whether the node exists; if the node does not exist, the server simply creates the node automatically and applies the specified configuration.

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:

For PEP purposes, this is equivalent to the following pubsub subscription exchange:

Note: Automated pubsub subscriptions MUST be based on the JID contained in the 'from' address of the presence subscription request, which for IM contacts will be a bare JID (&BAREJID;).

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 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: Including, say, the 'http://jabber.org/protocol/geoloc' namespace indicates that the client understands the geolocation namespace, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation.

• http://jabber.org/protocol/geoloc+notify
• http://jabber.org/protocol/tune+notify

This set of namespaces would then be advertised as a XEP-0115 "ext" value, such as the following:

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 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).

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, with the result that it will not need to send these service discovery requests):

Note: The disco#info result from the node#ver includes only base protocol support, since user-configured notification preferences are to be specified in entity capability extensions. Therefore the server also needs to query the relevant extensions:

Note: As explained in XEP-0115, these requests would not all be sent to the same client and resource, but rather would be sent to random entities that advertise the same entity capabilities information.

The server shall also query the node#ver and node#ext combinations for other contacts (not shown here), which for <romeo@montague.net> indicate an interest in "http://jabber.org/protocol/geoloc+notify" and "http://jabber.org/protocol/tune+notify" but not "http://jabber.org/protocol/activity+notify".

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 presence-access "http://jabber.org/protocol/tune" node, her server will send notifications to <nurse@capulet.com/chamber> and <romeo@montague.net/orchard> (full JIDs).

• 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>.

Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &xep0030; information request to the server:

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 XEP-0060 features):

A contact MAY send service discovery requests to the account owner's bare JID (&BAREJID;). If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in XEP-0060.

Note: When returning disco#info results, 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.

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:

1. A presence subscription state changes (e.g., when a subscription request is approved).
2. A roster item is modified (e.g., when the item is moved to a new roster group).

If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY 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 XEP-0060).

A PEP node with an access model of "whitelist" and no entities on the whitelist effectively results in a node that enables private data storage, e.g. as defined in &xep0049;. A separate document will specify private data storage via PEP in more detail.

The ®ISTRAR; includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;); as a result of this document, the Registrar includes a type of "pep" to that category.

The registry submission is as follows:

The XMPP Registrar maintains a registry of service discovery features (see &DISCOFEATURES;), which includes a number of features that may be returned by pubsub services. The following registry submission has been provided to the XMPP Registrar for that purpose.