git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1138 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-08-10 17:17:22 +00:00
parent ff896107e1
commit 12bd6f5a15
1 changed files with 5 additions and 5 deletions

View File

@ -27,10 +27,10 @@
&stpeter;
&ksmith;
<revision>
<version>1.1pre5</version>
<date>in progress, last updated 2007-07-17</date>
<version>1.1pre6</version>
<date>in progress, last updated 2007-08-10</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; updated to reflect changes to entity capabilities.</p></remark>
<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; updated to reflect changes to entity capabilities and pubsub.</p></remark>
</revision>
<revision>
<version>1.0</version>
@ -261,7 +261,7 @@
</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.lit in our scenario.</note> But PEP services support two special features:</p>
<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 typically need to explicitly subscribe to your "http://jabber.org/protocol/tune" node. <note>That may still be necessary for open access model nodes in PEP if another user does not send you presence, such as benvolio@montague.lit in our scenario.</note> But PEP services support two special features:</p>
<ol>
<li>"auto-subscribe" -- because they are subscribed to your presence, they automatically receive your events (see <link url='#approach-presence'>Use Presence</link>).</li>
<li>"filtered-notification" -- they can include some special flags in their &xep0115; information to specify which event types (payloads) they want to receive (see <link url='#approach-filter'>Filtered Notifications</link>).</li>
@ -360,7 +360,7 @@
<section1 topic='Receiving Event Notifications' anchor='notify'>
<p>An entity shall receive event notifications if:</p>
<ol start='1'>
<li>The node has an open access model and the entity has explicitly discovered and subscribed to the node as explained in <cite>XEP-0060</cite>.</li>
<li>The node has an open access model and the entity has explicitly or implicitly subscribed to the node as explained in <cite>XEP-0060</cite>.</li>
<li>The entity shares presence with the account owner (see <link url='#notify-presence'>Presence Sharing</link>), is authorized to receive events from the node in accordance with the node access model (see <cite>XEP-0060</cite>), and advertises an interest in the payload type (see <link url='#notify-filter'>Notification Filtering</link>).</li>
<li>The entity is the account owner itself, in which case the PEP service shall send notifications to all of the account owner's available resources (subject to <link url='#notify-filter'>notification filtering</link>).</li>
</ol>