mirror of https://github.com/moparisthebest/xeps
1.1pre4
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@909 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
a7201a7a7b
commit
de277fadf6
57
xep-0163.xml
57
xep-0163.xml
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue