mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
cleanup per XEP-0060
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1080 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
e2dc80863b
commit
ee1bf89d42
96
xep-0163.xml
96
xep-0163.xml
@ -27,10 +27,10 @@
|
||||
&stpeter;
|
||||
&ksmith;
|
||||
<revision>
|
||||
<version>1.1pre4</version>
|
||||
<date>in progress, last updated 2007-06-04</date>
|
||||
<version>1.1pre5</version>
|
||||
<date>in progress, last updated 2007-07-17</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>
|
||||
<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>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.0</version>
|
||||
@ -220,35 +220,77 @@
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Because PEP services must send notifications to the account owner, you too receive the notification at each of your resources (here "balcony" and "chamber").</p>
|
||||
<example caption='Publisher receives event notification'><![CDATA[
|
||||
<message from='juliet@capulet.lit'
|
||||
to='juliet@capulet.lit/balcony'
|
||||
type='headline'
|
||||
id='tunefoo3'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='http://jabber.org/protocol/tune'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
<length>255</length>
|
||||
<source>Music for "Love's Labors Lost" (Suite for small orchestra)</source>
|
||||
<title>Introduction (Allegro vigoroso)</title>
|
||||
<track>1</track>
|
||||
</tune>
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
|
||||
<message from='juliet@capulet.lit'
|
||||
to='juliet@capulet.lit/chamber'
|
||||
type='headline'
|
||||
id='tunefoo4'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='http://jabber.org/protocol/tune'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
<length>255</length>
|
||||
<source>Music for "Love's Labors Lost" (Suite for small orchestra)</source>
|
||||
<title>Introduction (Allegro vigoroso)</title>
|
||||
<track>1</track>
|
||||
</tune>
|
||||
</item>
|
||||
</items>
|
||||
</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>
|
||||
<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 events they want to receive (see <link url='#approach-filter'>Filtered Notifications</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>
|
||||
</ol>
|
||||
<example caption='Romeo sends presence with caps'><![CDATA[
|
||||
<presence from='romeo@montague.lit/orchard'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
node='http://www.chatopus.com/ec'
|
||||
ver='2.1'
|
||||
ext='sendmeloc sendmetunes'/>
|
||||
ver='054H4A7280JuT6+IroVYxgCAjZo='/>
|
||||
</presence>
|
||||
]]></example>
|
||||
<p>Your server knows to send tune information to Romeo not because his client advertises an 'ext' value of "sendmetunes" (the 'ext' values have no semantic meaning in <cite>XEP-0115</cite>) but because the disco#info response from the "http://www.chatopus.com/ec#sendmetunes" node advertises a feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in receiving notifications related to the protocol that precedes the suffix:</p>
|
||||
<p>Your server knows to send tune information to Romeo because when the server unpacks the value of the 'ver' attribute ("054H4A7280JuT6+IroVYxgCAjZo=") in accordance with <cite>XEP-0115</cite>, it discovers that Romeo's client advertises a service discovery feature of "http://jabber.org/protocol/tune+notify", where the "+notify" suffix indicates interest in receiving notifications related to the protocol that precedes the suffix. The server can verify this support if needed by sending a service discovery request to Romeo's full JID, where the response would be as follows:</p>
|
||||
<example caption='Disco#info result from extension'><![CDATA[
|
||||
<iq from='romeo@montague.lit/orchard'
|
||||
to='juliet@capulet.lit'
|
||||
type='result'
|
||||
id='disco123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://www.chatopus.com/ec#sendmetunes'/>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<feature var='http://jabber.org/protocol/disco#info'/>
|
||||
<feature var='http://jabber.org/protocol/disco#items'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc+notify'/>
|
||||
<feature var='http://jabber.org/protocol/tune'/>
|
||||
<feature var='http://jabber.org/protocol/tune+notify'/>
|
||||
</query>
|
||||
</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>Naturally your server doesn't need to send out a disco#info request every time, since it will quickly create a large cache of 'ver' values.</p>
|
||||
<p>So that's the general idea.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
@ -280,6 +322,7 @@
|
||||
<li>The default access model is "presence".</li>
|
||||
<li>A contact's subscription to an account owner's personal eventing data is automatically created because the contact has an XMPP presence subscription (the "auto-subscribe" feature).</li>
|
||||
<li>Services take account of subscriber presence in the generation of notifications. <note>This works only if the subscription state is "both" (see <cite>RFC 3921</cite>).</note></li>
|
||||
<li>A service automatically sends notifications to all of the account owner's connected resources.</li>
|
||||
</ul>
|
||||
<p>These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).</p>
|
||||
</section2>
|
||||
@ -310,34 +353,8 @@
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the node does not already exist, the PEP service MUST create the node. This "auto-create" feature MUST be supported by a PEP service, but support for the feature is OPTIONAL on the part of a generic pubsub service. (Naturally, the account owner's client MAY follow the node creation use case specified in <cite>XEP-0060</cite> before attempting to publish an item.)</p>
|
||||
<example caption='Publishing an event'><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony' type='set' id='pub1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='http://jabber.org/protocol/tune'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
<length>255</length>
|
||||
<source>Music for "Love's Labors Lost" (Suite for small orchestra)</source>
|
||||
<title>Introduction (Allegro vigoroso)</title>
|
||||
<track>1</track>
|
||||
</tune>
|
||||
</item>
|
||||
</publish>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#node_config</value>
|
||||
</field>
|
||||
<field var='pubsub#access_model'>
|
||||
<value>presence</value>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the node does not already exist, the PEP service MUST create the node. This "auto-create" feature (defined in <cite>XEP-0060</cite>) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in <cite>XEP-0060</cite> before attempting to publish an item.)</p>
|
||||
<p>A PEP service SHOULD also support the "publish-options" feature defined in <cite>XEP-0060</cite>.</p>
|
||||
<p>If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the <link url='#notify'>Receiving Event Notifications</link> section of this document, as well as to any of the account owner's available resources.</p>
|
||||
</section1>
|
||||
|
||||
@ -346,6 +363,7 @@
|
||||
<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 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>
|
||||
<section2 topic='Automatic Subscriptions' anchor='notify-autosubscribe'>
|
||||
<p>A PEP service MUST support the "auto-subscribe" feature defined in Section 10.1 of <cite>XEP-0060</cite>. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has a pubsub subscription account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all".</p>
|
||||
@ -377,7 +395,7 @@
|
||||
</ol>
|
||||
</section3>
|
||||
<section3 topic='Sending the Last Published Item' anchor='notify-last'>
|
||||
<p>As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in <cite>XMPP IM</cite>.)</p>
|
||||
<p>As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber, including the account owner itself. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in <cite>XMPP IM</cite>.)</p>
|
||||
<example caption='Subscriber sends presence from newly-available resource'><![CDATA[
|
||||
<presence from='romeo@montague.lit/orchard'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
|
||||
Loading…
Reference in New Issue
Block a user