moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

removed restriction on not sending to resources with negative priority 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2181 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-09-03 17:34:12 +00:00
parent 0705cd6bd7
commit de05dedab5
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xep-0163.xml
View File

@ -6,7 +6,7 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Personal Eventing via Pubsub</title>
<title>Personal Eventing Protocol</title>
<abstract>This specification defines semantics for using the XMPP publish-subscribe protocol to broadcast state change events associated with an instant messaging and presence account. This profile of pubsub therefore enables a standard XMPP user account to function as a virtual pubsub service, easing the discovery of syndicated data and event notifications associated with such an account.</abstract>
&LEGALNOTICE;
<number>0163</number>
@ -145,7 +145,7 @@
<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.</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 Protocol" 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'>
@ -383,14 +383,14 @@
<section3 topic='Number of Notifications' anchor='notify-num'>
<ol start='1'>
<li><p>If an entity subscribed using a full JID &FULLJID; or a bare domain identifier &DOMAINBARE;, a PEP service MUST send one notification only, addressed to the subscribed JID.</p></li>
<li><p>If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and <cite>XEP-0115</cite> data that indicates interest in the relevant data format.)</p></li>
<li><p>If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have specified non-negative presence priority and included <cite>XEP-0115</cite> information that indicates an interest in the data format.</p></li>
<li><p>If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with <cite>XEP-0115</cite> data that indicates interest in the relevant data format.)</p></li>
<li><p>If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have included <cite>XEP-0115</cite> information indicating an interest in the data format.</p></li>
</ol>
</section3>
<section3 topic='When to Generate Notifications' anchor='notify-when'>
<ol start='1'>
<li><p>When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).</p></li>
<li><p>When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority and including <cite>XEP-0115</cite> information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.</p></li>
<li><p>When a PEP service receives initial presence information from a subscriber's resource including <cite>XEP-0115</cite> information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.</p></li>
<li><p>As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using communications blocking as specified in &xep0016; or &xep0191;.</p></li>
</ol>
</section3>
@ -534,7 +534,7 @@
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>Because Personal Eventing via Pubsub simply reuses the protocol specified in <cite>XEP-0060</cite>, a separate schema is not needed.</p>
<p>Because PEP simply reuses the protocol specified in <cite>XEP-0060</cite>, a separate schema is not needed.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>