<abstract>This document specifies semantics for using the XMPP publish-subscribe protocol to handle generic XMPP events (including presence, one-to-one messaging, and groupchat).</abstract>
&LEGALNOTICE;
<number>0207</number>
<status>Active</status>
<type>Humorous</type>
<sig>Standards JIG</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.0</version>
<date>2007-04-01</date>
<initials>psa</initials>
<remark><p>April Fools!</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0163; (PEP) introduced the concept of "eventing" into the Extensible Messaging and Presence Protocol (see &xmppcore;). But PEP merely scratched the surface of eventing technologies based on the XMPP &xep0060; extension. This document extends the eventing concept to its ultimate conclusion: the ability to communicate all XMPP semantics via pubsub.</p>
</section1>
<section1topic='Concepts and Approach'anchor='approach'>
<p>Jabber technologies as invented by Jeremie Miller started out as a relatively lightweight XML messaging transport, but they have become unnecessarily -- even ridiculously -- bloated over the years. Formalization of the core Jabber protocols as the Extensible Messaging and Presence Protocol (XMPP) within the IETF seemed like a good idea at the time, but the extensible nature of the core protocols has tempted the developer community to extend XMPP six ways from Sunday. The result has been a plethora of different conceptual models for various extensions, such as &xep0045; for multi-user communication and &xep0050; for structured entity-to-entity request/response semantics. These different models are inelegant and unnecessary. Indeed, even the inclusion of three different basic packet types (presence, message, and IQ) in the core protocol is overkill.</p>
<p>We can do better. In fact, we can reduce all the communication types and styles that are currently defined within the XMPP ecosystem to one model: publish-subscribe as specified in <cite>XEP-0060</cite>.</p>
<p>Consider:</p>
<ul>
<li>It has often been observed that presence (see &xmppim;) is a form of publish-subscribe. <note>See, for instance, <<linkurl='http://mail.jabber.org/pipermail/xmppwg/2003-February/000636.html'>http://mail.jabber.org/pipermail/xmppwg/2003-February/000636.html</link>>.</note></li>
<li>The primitive XMPP "roster" can be easily implemented using the pubsub permissions model.</li>
<li>Multi-user chat too is a kind of publish-subscribe, since a single "publish" to the room results in multiple notifications to the room occupants, who are really subscribers to an information node.</li>
<li>Even one-to-one messaging is just another example of publish-subscribe (in fact it is a special case of multi-user chat).</li>
</ul>
<p>The remainder of this document will prove beyond a doubt that the older, multiple approaches are obsolete, and that there is indeed one model that serves all our needs: pubsub.</p>
</section1>
<section1topic='Presence'anchor='presence'>
<p>Presence simply is pubsub, since it follows the classic "observer" pattern: multiple subscribers receive notifications whenever the publisher (typically an end user) generates an event related to network availability. Currently in XMPP this is done with the &PRESENCE; stanza, which serves as a kind of pubsub primitive (though only for availability information). For example, Juliet may log into the capulet.lit server and send presence:</p>
<examplecaption='Presence Update'><![CDATA[
<presencefrom='juliet@capulet.lit/balcony'>
<status>Moping</status>
</presence>
]]></example>
<p>The capulet.lit server will then send notifications to all of the users who have subscribed to Juliet's presence:</p>
<p>It is true that in this case the packets are significantly larger in the pubsub realization than in the old-fashioned presence realization. This is the price of elegance. Implementations SHOULD use native Transport Layer Security compression (see &rfc4346;) or &xep0138; at the application layer to conserve bandwidth.</p>
</section1>
<section1topic='Rosters and Presence Subscriptions'anchor='roster'>
<p>The original Jabber technologies included a kind of Buddy List ™ (called the "roster"). But the roster is simply a list of the entities that are subscribed to a user's presence. Occam's Razor would indicate that it is foolish to implement two concepts (presence subscription and roster) when one will solve the problem at hand. In XMPP Eventing via Pubsub, there is no need for a specialized "roster" since the same information is represented in the list of entities who are subscribed to the user's "presence" node in pubsub/PEP.</p>
<p>Using XMPP Eventing via Pubsub also cleans up the syntax for presence subscription management, which currently uses four specialized values of the &PRESENCE; element's 'type' attribute: "subscribe", "subscribed", "unsubscribe", and "unsubscribed".</p>
<p>Thus for example a presence subscription request is currently made by sending the following presence stanza:</p>
label='Allow this JID to subscribe to this pubsub node?'>
<value>false</value>
</field>
</x>
</message>
]]></example>
<p>In order to approve the request, the owner shall submit the form and set the "pubsub#allow" field to a value of "1" or "true"; for tracking purposes the message MUST reflect the 'id' attribute originally provided.</p>
<p>Simple. Elegant. And no need for a roster! The pubsub approach is bit more verbose, but then again clients and servers should implement and deploy stream compression if they are really worred about bandwidth usage.</p>
</section1>
<section1topic='Multi-User Chat'anchor='muc'>
<p>The existing groupchat protocol for XMPP overloads the &PRESENCE; stanza for temporary "subscriptions" to a virtual room and uses the &MESSAGE; stanza (with a special type of "groupchat") to communicate information to multiple room occupants. Sound familiar? It's just another form of pubsub!</p>
<p>In groupchat, a user joins a room by sending presence to "room@service/nick":</p>
<p>It's really rather silly that XMPP includes two different models for messaging, one for groupchat and the other for one-to-one messages. Pubsub solves that problem by using one model for everything. In order to exchange messages, one of the parties simply creates a pubsub node with a whitelist model and adds the other person as a publisher (it may also be necessary to add the other party to the whitelist):</p>
<examplecaption='Creating a One-to-One Messaging Node'><