<abstract>This document specifies XMPP semantics for using the publish-subscribe protocol to broadcast state change events associated with an instant messaging and presence account.</abstract>
<remark><p>Defined atomic publish+configure action for use on first publish; added friendly but non-normative How It Works section to introduction; tightened up definition of normative sections; explicitly defined auto-create and publish-and-configure features.</p></remark>
<remark><p>Per a vote of the Jabber Council, advanced status to Draft.</p></remark>
</revision>
<revision>
<version>0.15</version>
<date>2006-08-30</date>
<initials>psa</initials>
<remark><p>Added the deliver_notifications and send_last_published_item configuration options to the recommended defaults.</p></remark>
</revision>
<revision>
<version>0.14</version>
<date>2006-08-02</date>
<initials>psa</initials>
<remark><p>Changed various recommended defaults from SHOULD to MUST; corrected several errors in the text and examples.</p></remark>
</revision>
<revision>
<version>0.13</version>
<date>2006-08-01</date>
<initials>psa</initials>
<remark><p>Recommended node creation with default configuration on initial publish; corrected several errors and clarified several points in the text.</p></remark>
</revision>
<revision>
<version>0.12</version>
<date>2006-08-01</date>
<initials>psa</initials>
<remark><p>Simplified the subscription process using XMPP presence and entity capabilities.</p></remark>
</revision>
<revision>
<version>0.11</version>
<date>2006-07-20</date>
<initials>psa</initials>
<remark><p>Clarified rules regarding number of notifications and when to generate notifications; corrected several errors in the text and examples.</p></remark>
<remark><p>Clarified terminology and defaults.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2006-04-10</date>
<initials>psa</initials>
<remark><p>Specified that notifications are to be sent from bare JID, not full JID.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2006-04-10</date>
<initials>psa</initials>
<remark><p>Updated to reflect pubsub changes; clarified business rules for generation of notifications and cancellation of subscriptions.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2006-03-09</date>
<initials>psa</initials>
<remark><p>Modified roster groups example to use jabber:x:data; added note about advertising client support for PEP.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2006-02-02</date>
<initials>psa/ks</initials>
<remark><p>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.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2006-01-30</date>
<initials>psa</initials>
<remark><p>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.</p></remark>
<p>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.
<note>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.</note>
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.
<note>This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in <cite>XEP-0060</cite>. The reader is referred to <cite>XEP-0060</cite> for all relevant protocol details related to the XMPP publish-subscribe extension.</note></p>
</section2>
<section2topic='How It Works'anchor='howitworks'>
<p>This section provides a friendly, non-normative introduction to the workings of personal eventing via pubsub (PEP).</p>
<p>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.</p>
<p>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:</p>
<olstart='1'>
<li>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")</li>
<li>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")</li>
</ol>
<p>We assume that there are three other users who have the following relationship to you:</p>
<olstart='1'>
<li>benvolio@montague.net, who has no subscription to your presence</li>
<li>nurse@capulet.com, who has a bidirectional subscription to your presence and who is in your "Servants" roster group</li>
<li>romeo@montague.net, who has a bidirectional subscription to your presence and who is in your "Friends" roster group</li>
</ol>
<p>We also assume that your server (montague.net) supports PEP and that your client discovered that support when you logged in.</p>
<p>Now you start playing a song on your music playing software. Your client captures that "event" and publishes it to your server:</p>
<p>Note the following about your publish request:</p>
<olstart='1'>
<li>It is sent with no 'to' address (see <linkurl='#approach-everyjid'>Every Account a Pubsub Service</link>).</li>
<li>It specifies a node of "http://jabber.org/protocol/tune" (see <linkurl='#approach-onenode'>One Node per Namespace</link>).</li>
<li>It includes the desired node configuration, which here is a presence access model (see <linkurl='#approach-fire'>Fire and Forget</link>).</li>
</ol>
<p>If all goes well (see <linkurl='#publish'>Publishing Events</link>), everyone who is interested in what you are listening to will receive notification of the event:</p>
<source>Music for "Love's Labors Lost" (Suite for small orchestra)</source>
<track>1</track>
<length>255</length>
</tune>
</item>
</items>
</event>
</message>
]]></example>
<p>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. <note>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.</note> In PEP, they only need to advertise that they are interested by including some special flags (see <linkurl='#approach-filter'>Filtered Notifications</link>) in the &xep0115; information they include in their presence broadcasts (see <linkurl='#approach-presence'>Use Presence</link>).</p>
<examplecaption='Romeo sends presence with caps'><![CDATA[
<presencefrom='romeo@montague.net/orchard'>
<cxmlns='http://jabber.org/protocol/caps'
node='http://www.chatopus.com/ec'
ver='2.1'
ext='sendmeloc sendmetunes'/>
</presence>
]]></example>
<p>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 <cite>XEP-0115</cite>) 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:</p>
<examplecaption='Disco#info result from extension'><