mirror of https://github.com/moparisthebest/xeps
1.10pre6
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1162 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
99a6d7932a
commit
2869c521c0
162
xep-0060.xml
162
xep-0060.xml
|
|
@ -49,10 +49,19 @@
|
|||
&ralphm;
|
||||
|
||||
<revision>
|
||||
<version>1.10pre5</version>
|
||||
<date>in progress, last updated 2007-08-14</date>
|
||||
<version>1.10pre6</version>
|
||||
<date>in progress, last updated 2007-08-16</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>In accordance with XMPP Council consensus, moved the auto-create, auto-subscribe, filtered-notifications, and last-published features from XEP-0163 to this specification and defined them more precisely; added publish-options functionality; clarified optional auto-subscribe to open access nodes via presence receipt; added developer-friendly How It Works section; split several long sections into smaller sub-sections.</p></remark>
|
||||
<remark>
|
||||
<ul>
|
||||
<li>In accordance with XMPP Council consensus, moved the auto-create, auto-subscribe, filtered-notifications, and last-published features from XEP-0163 to this specification</li>
|
||||
<li>Clarified implications of auto-subscribe feature for handling of account owners, stable presence subscribers, and transient presence sharers</li>
|
||||
<li>Updated filtered-notifications text and examples to track changes to XEP-0115</li>
|
||||
<li>Added publish-options functionality</li>
|
||||
<li>Added developer-friendly How It Works section</li>
|
||||
<li>Split several long sections into smaller sub-sections.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
|
|
@ -4880,41 +4889,22 @@ And by opposing end them?
|
|||
<section1 topic='IM Account Integration' anchor='presence'>
|
||||
<p>Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see <cite>RFC 3921</cite>), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID (&BAREJID;) of the account, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section.</p>
|
||||
<section2 topic='Auto-Subscribe' anchor='auto-subscribe'>
|
||||
<p>When a contact is affiliated with the account owner through an XMPP presence subscription, the "auto-subscribe" feature greatly simplifies the subscription process. This is done by associating the presence subscription with a pubsub subscription to the account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all".</p>
|
||||
<p>Consider the following presence subscription exchange:</p>
|
||||
<example caption='Presence subscription handshake'><![CDATA[
|
||||
<presence from='nurse@capulet.lit' to='juliet@capulet.lit' type='subscribe'/>
|
||||
|
||||
<presence from='juliet@capulet.lit' to='nurse@capulet.lit' type='subscribed'/>
|
||||
]]></example>
|
||||
<p>With the auto-subscribe feature enabled, this presence subscription exchange is equivalent to the following pubsub subscription exchange:</p>
|
||||
<example caption='Entity subscribes to a collection node'><![CDATA[
|
||||
<iq type='set'
|
||||
from='nurse@capulet.lit/chamber'
|
||||
to='juliet@capulet.lit
|
||||
id='collsub'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<subscribe jid='nurse@capulet.lit'/>
|
||||
<options>
|
||||
<x xmlns='jabber:x:data'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#subscribe_options</value>
|
||||
</field>
|
||||
<field var='pubsub#subscription_type'>
|
||||
<value>items</value>
|
||||
</field>
|
||||
<field var='pubsub#subscription_depth'>
|
||||
<value>all</value>
|
||||
</field>
|
||||
</x>
|
||||
</options>
|
||||
</pubsub>
|
||||
</iq>
|
||||
|
||||
<iq type='result' from='juliet@capulet.lit' to='nurse@capulet.lit/chamber' id='collsub'/>
|
||||
]]></example>
|
||||
<p>When an IM contact has a subscription to the account owner's presence, the automated pubsub subscription MUST be based on the JID contained in the 'from' address of the presence subscription request, which for an IM contact will be a bare JID (&BAREJID;).</p>
|
||||
<p>If the node has an open access model, the pubsub service SHOULD also consider an entity to be (temporarily) subscribed to the node if the entity sends presence to the IM account owner in the absence of a presence subscription. In this case, the subscription SHOULD be based on the 'from' address of the presence stanza, which will typically be a full JID (&FULLJID;).</p>
|
||||
<p>When a contact is affiliated with the account owner through sharing of XMPP presence, the "auto-subscribe" feature greatly simplifies the subscription process. In particular, support for the "auto-subscribe" has the following implications:</p>
|
||||
<section3 topic='Account Owner' anchor='auto-subscribe-owner'>
|
||||
<p>Because the account owner itself is implicitly subscribed to its own XMPP presence (e.g., each XMPP resource receives presence information from all of the account owner's resources), a service MUST consider the account owner to have a pubsub subscription to the account owner's root collection node with a subscription_type of "items" and a subscription_depth of "all". This is true for all access models.</p>
|
||||
</section3>
|
||||
<section3 topic='Presence Subscriber' anchor='auto-subscribe-contact'>
|
||||
<p>If an entity (i.e., an IM contact) has an XMPP presence subscription to the account owner's bare JID (&BAREJID;), a service MUST consider the contact to have a pubsub subscription to the account owner's root collection node with a subscription_type of "items" and a subscription_depth of "all" if:</p>
|
||||
<ol>
|
||||
<li>The node has an access model of "open".</li>
|
||||
<li>The node has an access model of "presence".</li>
|
||||
<li>The node has an access model of "roster" and the contact is in the specified roster group.</li>
|
||||
</ol>
|
||||
<p>Note: When an IM contact has a subscription to the account owner's presence, the automated pubsub subscription MUST be based on the JID contained in the 'from' address of the presence subscription request, which for an IM contact will be a bare JID (&BAREJID;).</p>
|
||||
</section3>
|
||||
<section3 topic='Presence Sharer' anchor='auto-subscribe-directed'>
|
||||
<p>If the node has an open access model, the pubsub service SHOULD also consider an entity to be (temporarily) subscribed to the node if the entity sends presence to the account owner in the absence of a presence subscription. In this case, the subscription SHOULD be based on the 'from' address of the presence stanza, which will be a full JID (&FULLJID;). When the service receives unavailable presence from the full JID, it MUST consider cancel the (temporary) subscription.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Filtered Notifications' anchor='filtered-notifications'>
|
||||
<p>A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including <cite>XEP-0115</cite> information that specifies the namespaces for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send only those payload types that the subscriber wishes to receive.</p>
|
||||
|
|
@ -4923,113 +4913,77 @@ And by opposing end them?
|
|||
<li>http://jabber.org/protocol/geoloc+notify</li>
|
||||
<li>http://jabber.org/protocol/tune+notify</li>
|
||||
</ul>
|
||||
<p>This set of namespaces would then be advertised as a <cite>XEP-0115</cite> "ext" value, such as the following:</p>
|
||||
<p>This set of namespaces would then be advertised by including the namespace in the identity+features hash encapsulated via the 'ver' attribute as described in <cite>XEP-0115</cite>.</p>
|
||||
<example caption='Contact 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'/>
|
||||
node='http://www.chatopus.com/#2.2'
|
||||
ver='AFBT0mPr29zQE5aGtCJp97CIS6E='/>
|
||||
</presence>
|
||||
]]></example>
|
||||
<p>Note: In <cite>XEP-0115</cite>, the "ext" values are opaque strings with no semantic meaning.</p>
|
||||
<p>It is the responsibility of the account owner's server to cache <cite>XEP-0115</cite> information (including "ext" values and their associated namespaces). When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.</p>
|
||||
<p>It is the responsibility of the account owner's server to cache <cite>XEP-0115</cite> information. When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "namespace+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.</p>
|
||||
<p>Some examples may help to illustrate the concept of notification filtering. Here we show presence generated by two of the contacts listed above (benvolio@montague.lit does not have any presence subscriptions to or from juliet@capulet.lit and therefore is not involved in these protocol flows).</p>
|
||||
<example caption='Presence with caps'><![CDATA[
|
||||
<presence from='nurse@capulet.lit/chamber'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
node='http://exodus.jabberstudio.org/caps'
|
||||
ver='0.9'
|
||||
ext='foo bar baz'/>
|
||||
node='http://exodus.jabberstudio.org/#0.9.1'
|
||||
ver='wXj6c5xhT9frdqhvTSjkdejUUP8='/>
|
||||
</presence>
|
||||
|
||||
<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'/>
|
||||
node='http://www.chatopus.com/#2.2'
|
||||
ver='1FDrLLbYMpzvcI95jgSHABSWDRY='/>
|
||||
</presence>
|
||||
]]></example>
|
||||
<p>We assume that Juliet's server doesn't know anything about these capabilities, so it sends service discovery information requests to each of the clients on Juliet's behalf (realistically, the capulet.lit server will quickly build up a cache of client capabilities, with the result that it will not need to send these service discovery requests):</p>
|
||||
<example caption='Account server queries node#ver'><![CDATA[
|
||||
<example caption='Account server queries contact'><![CDATA[
|
||||
<iq from='juliet@capulet.lit'
|
||||
to='nurse@capulet.lit/chamber'
|
||||
type='get'
|
||||
id='disco123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#0.9'/>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
|
||||
<iq from='nurse@capulet.lit/chamber'
|
||||
to='juliet@capulet.lit'
|
||||
type='result'
|
||||
id='disco123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#0.9'/>
|
||||
<feature var='http://jabber.org/protocol/tune'/>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<identity category='client' type='pc'/>
|
||||
<feature var='http://jabber.org/protocol/activity'/>
|
||||
<feature var='http://jabber.org/protocol/activity+notify'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Note: The disco#info result from the node#ver includes only base protocol support, since user-configured notification preferences are to be specified in entity capability extensions. Therefore the server also needs to query the relevant extensions:</p>
|
||||
<example caption='Account server queries node#ext combinations'><![CDATA[
|
||||
<iq from='juliet@capulet.lit'
|
||||
to='nurse@capulet.lit/chamber'
|
||||
type='get'
|
||||
id='ext123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#foo'/>
|
||||
</iq>
|
||||
|
||||
<iq from='nurse@capulet.lit/chamber'
|
||||
to='juliet@capulet.lit'
|
||||
type='result'
|
||||
id='ext123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#foo'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc+notify'/>
|
||||
<feature var='http://jabber.org/protocol/muc'/>
|
||||
<feature var='http://jabber.org/protocol/tune'/>
|
||||
<feature var='http://jabber.org/protocol/tune+notify'/>
|
||||
</query>
|
||||
</iq>
|
||||
|
||||
]]></example>
|
||||
<p>The server shall also query the identity+features for <romeo@montague.lit>:</p>
|
||||
<example caption='Account server queries contact'><![CDATA[
|
||||
<iq from='juliet@capulet.lit'
|
||||
to='nurse@capulet.lit/chamber'
|
||||
to='romeo@montague.lit/orchard
|
||||
type='get'
|
||||
id='ext234'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#bar'/>
|
||||
id='disco234'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
|
||||
<iq from='nurse@capulet.lit/chamber'
|
||||
<iq from='romeo@montague.lit/orchard'
|
||||
to='juliet@capulet.lit'
|
||||
type='result'
|
||||
id='ext234'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#bar'/>
|
||||
<feature var='http://jabber.org/protocol/activity+notify'/>
|
||||
</query>
|
||||
</iq>
|
||||
|
||||
<iq from='juliet@capulet.lit'
|
||||
to='nurse@capulet.lit/chamber'
|
||||
type='get'
|
||||
id='ext123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#baz'/>
|
||||
</iq>
|
||||
|
||||
<iq from='nurse@capulet.lit/chamber'
|
||||
to='juliet@capulet.lit'
|
||||
type='result'
|
||||
id='ext123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#baz'/>
|
||||
id='disco234'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<identity category='client' type='pda'/>
|
||||
<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>Note: As explained in <cite>XEP-0115</cite>, these requests would not all be sent to the same client and resource, but rather would be sent to random entities that advertise the same entity capabilities information.</p>
|
||||
<p>The server shall also query the node#ver and node#ext combinations for other contacts (not shown here), which for <romeo@montague.lit> indicate an interest in "http://jabber.org/protocol/geoloc+notify" and "http://jabber.org/protocol/tune+notify" but not "http://jabber.org/protocol/activity+notify".</p>
|
||||
<p>(As noted in <cite>XEP-0115</cite>, the server MUST check the hash provided in the 'ver' attribute against the generation method to ensure that no poisoning has occurred.)</p>
|
||||
<p>Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information:</p>
|
||||
<ul>
|
||||
<li><p>If Juliet publishes a tune item to the presence-access "http://jabber.org/protocol/tune" node, her server will send notifications to <nurse@capulet.lit/chamber> and <romeo@montague.lit/orchard> (full JIDs).</p></li>
|
||||
|
|
|
|||
Loading…
Reference in New Issue