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 Protocol" or PEP.

Note: Any use cases not described herein are described in XEP-0060. Also, this document does not show error flows related to the generic 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 document merely defines a "subset" or "profile" of XMPP publish-subscribe.

This section provides a friendly introduction to personal eventing via pubsub (PEP).

Imagine that you are a Shakespearean character named Juliet and that you want to generate events about what music you're listening to, which anyone may see as long as they are authorized to see your online/offline presence (i.e., a pubsub access model of "presence").

We assume that you have three contacts with the following relationship to you:

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

We also assume that your server (capulet.lit) 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).

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

Because PEP services must send notifications to the account owner, you too receive the notification at each of your resources (here "balcony" and "chamber").

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 typically need to explicitly subscribe to your "http://jabber.org/protocol/tune" node. That may still be necessary for open access model nodes in PEP if another user does not send you presence, such as benvolio@montague.lit in our scenario. But PEP services support two special features:

1. "auto-subscribe" -- because they are subscribed to your presence, they automatically receive your events (see Use Presence).
2. "filtered-notification" -- they can include some special flags in their &xep0115; information to specify which event types (payloads) they want to receive (see Filtered Notifications).

Your server knows to send tune information to Romeo because when the server unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with XEP-0115, it discovers that Romeo's client advertises a service discovery feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in receiving notifications of the node whose NodeID precedes the suffix (see XEP-0060 § 9.2). The server can verify this support if needed by sending a service discovery request to Romeo's full JID, where the response would be as follows:

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

So that's the general idea.

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.

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 automatically created because the contact has an XMPP presence subscription (the "auto-subscribe" feature).
• Services take account of subscriber presence in the generation of notifications. This works only if the subscription state is "both" (see RFC 3921).
• A service automatically sends notifications to all of the account owner's connected resources (subject to notification filtering).

These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).

Note: It is strongly NOT RECOMMENDED to use directed presence with Entity Capabilities data that differs from the data included in broadcast presence for the purpose of establishing implicit PEP subscriptions to another entity, because the directed presence information will be overwritten by any subsequent presence broadcast.

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. Because the PEP service supports the "filtered-notifications" feature, it 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 PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of XEP-0060. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has the right to subscribe to any of the account owner's PEP nodes (if the access model is the default of "presence") and to retrieve items from such PEP nodes.

A PEP service MUST support the "filtered-notifications" feature defined in Section 9.2 of XEP-0060. This implies that when an automatic subscriber can specify which event payloads it wants to receive by including appropriate feature bundles in the XEP-0115 information it broadcasts.

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 its own bare JID:

If the account owner's server supports PEP and the account is provisioned for PEP, the server MUST return an identity of "pubsub/pep" on behalf of the account (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#items 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).

An earlier version of this document specified that there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.

A specification that defines a given payload format for use in PEP MUST specify whether there shall be only one node per namespace, or whether multiple NodeIDs for the same namespace are allowable.

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: