moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

1.1pre4

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@909 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-06-04 19:07:05 +00:00
parent a7201a7a7b
commit de277fadf6
1 changed files with 7 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
xep-0163.xml
View File

@ -27,8 +27,8 @@
&stpeter;
&ksmith;
<revision>
<version>1.1pre3</version>
<date>in progress, last updated 2007-05-30</date>
<version>1.1pre4</version>
<date>in progress, last updated 2007-06-04</date>
<initials>psa</initials>
<remark><p>In accordance with XMPP Council consensus (1) explicitly defined auto-create, auto-subscribe, filtered-notifications, and last-published features, (2) moved them to XEP-0060, and (3) added appropriate references to XEP-0060 throughout; also added friendly but non-normative How It Works section and removed references to private data storage.</p></remark>
</revision>
@ -145,19 +145,14 @@
<section1 topic='Introduction' anchor='intro'>
<section2 topic='Motivation' anchor='motivation'>
<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>
<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.</p>
<p class='em'>Note: Any use cases not described herein are described in <cite>XEP-0060</cite>. Also, this document does not show error flows related to the generic 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. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.</p>
</section2>
<section2 topic='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>
<ol start='1'>
<li>Information 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")</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>
<p>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").</p>
<p>We assume that you have three contacts with the following relationship to you:</p>
<ol start='1'>
<li>benvolio@montague.lit, who has no subscription to your presence</li>
<li>nurse@capulet.lit, who has a bidirectional subscription to your presence and who is in your "Servants" roster group</li>
@ -254,45 +249,7 @@
</iq>
]]></example>
<p>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!</p>
<p>So that's the general idea. We'll demonstrate it again with an example of geolocation...</p>
<p>First your client generates a geolocation event:</p>
<example caption='Publishing another event'><![CDATA[
<iq from='juliet@capulet.lit/balcony' type='set' id='pub2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/geoloc'>
<item>
<geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
<country>Italy</country>
<lat>45.44</lat>
<locality>Venice</locality>
<lon>12.33</lon>
</geoloc>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<p>Then your server sends event notifications, this time addressing the event only to Romeo, since the Nurse is not in your Friends roster group:</p>
<example caption='Interested parties receive event notifications'><![CDATA[
<message from='juliet@capulet.lit'
to='romeo@montague.lit/orchard'
type='headline'
id='locfoo1'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/geoloc'>
<item>
<geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
<country>Italy</country>
<lat>45.44</lat>
<locality>Venice</locality>
<lon>12.33</lon>
</geoloc>
</item>
</items>
</event>
</message>
]]></example>
<p>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.</p>
<p>So that's the general idea.</p>
</section2>
</section1>