moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 12:12:22 -05:00
Code Issues Releases Wiki Activity

0.6

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1398 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-11-19 23:30:15 +00:00
parent ac137a388a
commit 8256ad0862
1 changed files with 119 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
xep-0168.xml
View File

@ -24,6 +24,12 @@
<shortname>TO BE ASSIGNED</shortname> <shortname>TO BE ASSIGNED</shortname>
&stpeter; &stpeter;
&hildjj; &hildjj;
<revision>
<version>0.6</version>
<date>2007-11-19</date>
<initials>psa</initials>
<remark><p>Documented optional pubsub transport for RAP data.</p></remark>
</revision>
<revision> <revision>
<version>0.5</version> <version>0.5</version>
<date>2007-11-15</date> <date>2007-11-15</date>
@ -120,7 +126,8 @@
<p>What is needed is a way for the user's clients to indicate that the application priority for the three resources is different from the standard XMPP priority. Such information can also be used by an XMPP server to route XMPP &MESSAGE; stanzas directed to a user's bare JID (&BAREJID;). This document defines such a mechanism via an optional XMPP presence extension.</p> <p>What is needed is a way for the user's clients to indicate that the application priority for the three resources is different from the standard XMPP priority. Such information can also be used by an XMPP server to route XMPP &MESSAGE; stanzas directed to a user's bare JID (&BAREJID;). This document defines such a mechanism via an optional XMPP presence extension.</p>
<p>In addition, this document also defines a way for an XMPP server to flag which resource it considers to be primary for any given application type, if it has information -- such as communication preferences -- that can help it determine the primary resource.</p> <p>In addition, this document also defines a way for an XMPP server to flag which resource it considers to be primary for any given application type, if it has information -- such as communication preferences -- that can help it determine the primary resource.</p>
</section1> </section1>
<section1 topic='Application Priority' anchor='primary'> <section1 topic='Application Priority' anchor='rap'>
<section2 topic='Format' anchor='rap-format'>
<p>Application priority is encapsulated by a &lt;rap/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0168.html#ns' namespace &NSNOTE;. The attributes of the &lt;rap/&gt; element are as follows.</p> <p>Application priority is encapsulated by a &lt;rap/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0168.html#ns' namespace &NSNOTE;. The attributes of the &lt;rap/&gt; element are as follows.</p>
<table caption='RAP Attributes'> <table caption='RAP Attributes'>
<tr> <tr>
@ -139,41 +146,113 @@
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
</table> </table>
<p>The following business rules apply to resource application presence provided by the client:</p> <p>An example follows.</p>
<example caption='Data format'><![CDATA[
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns'
num='5'/>
]]></example>
</section2>
<section2 topic='Generation' anchor='rap-gen'>
<p>The following business rules apply to the generation of resource application priority by the client:</p>
<ol start='1'> <ol start='1'>
<li><p>A client SHOULD include a &lt;rap/&gt; element for each application type for which it wishes to advertise a priority, but SHOULD NOT do so if the priority for that application is the same as the resource's standard XMPP priority.</p></li> <li><p>A client SHOULD include a &lt;rap/&gt; element for each application type for which it wishes to advertise a priority, but SHOULD NOT do so if the priority for that application is the same as the resource's standard XMPP priority.</p></li>
<li><p>A client MUST NOT generate a &lt;rap/&gt; element that has a 'ns' attribute whose value is "jabber:client" or that has no 'ns' attribute (since the default 'ns' is "jabber:client").</p></li> <li><p>A client MUST NOT generate a &lt;rap/&gt; element that has a 'ns' attribute whose value is "jabber:client" or that has no 'ns' attribute (since the default 'ns' is "jabber:client").</p></li>
<li><p>The &lt;rap/&gt; element SHOULD be empty.</p></li> <li><p>The &lt;rap/&gt; element SHOULD be empty.</p></li>
</ol> </ol>
<p>Consider the three resources ("desktop", "pda", and "mobile") mentioned above. The presence stanzas received by a contact for those three resources would be as follows.</p> <p>As explained in the following sections, there are two possible transports for RAP data: standard XMPP presence and the XMPP publish-subscribe extension.</p>
</section2>
<section2 topic='Presence Transport' anchor='rap-presence'>
<p>RAP data MAY be included as extended content within a standard XMPP presence stanza. This is consistent with the rule that presence stanzas must be related to the network availability or communication preferences of the entity that provides presence information.</p>
<p>For the three resources ("desktop", "pda", and "mobile") mentioned above, the presence stanzas received by a contact would be as follows.</p>
<example caption='Contact receives presence from user'><![CDATA[ <example caption='Contact receives presence from user'><![CDATA[
<presence from='juliet@capulet.com/desktop' to='romeo@montague.net/home'> <presence from='juliet@capulet.lit/desktop' to='romeo@montague.lit/home'>
<priority>10</priority> <priority>10</priority>
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns' <rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns' ns='http://www.xmpp.org/extensions/xep-0167#ns'
num='5'/> num='5'/>
</presence> </presence>
<presence from='juliet@capulet.com/pda' to='romeo@montague.net/home'> <presence from='juliet@capulet.lit/pda' to='romeo@montague.lit/home'>
<priority>5</priority> <priority>5</priority>
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns' <rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns' ns='http://www.xmpp.org/extensions/xep-0167#ns'
num='-1'/> num='-1'/>
</presence> </presence>
<presence from='juliet@capulet.com/mobile' to='romeo@montague.net/home'> <presence from='juliet@capulet.lit/mobile' to='romeo@montague.lit/home'>
<priority>-1</priority> <priority>-1</priority>
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns' <rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns' ns='http://www.xmpp.org/extensions/xep-0167#ns'
num='10'/> num='10'/>
</presence> </presence>
]]></example> ]]></example>
</section2>
<section2 topic='Pubsub Transport' anchor='rap-pubsub'>
<p>Alternatively, RAP data MAY be provided via the XMPP &xep0060; publish-subscribe extension, specifically the &xep0163; profile thereof.</p>
<p>For the three resources ("desktop", "pda", and "mobile") mentioned above, the pubsub notifications received by a contact would be as follows.</p>
<example caption='Contact receives pubsub notifications from user'><![CDATA[
<message from='juliet@capulet.lit'
to='romeo@montague.lit/orchard'
type='headline'
id='rap1'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://www.xmpp.org/extensions/xep-0168.html#ns'>
<item>
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns'
num='5'/>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='juliet@capulet.lit/desktop'/>
</addresses>
</message>
<message from='juliet@capulet.lit'
to='romeo@montague.lit/orchard'
type='headline'
id='rap2'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://www.xmpp.org/extensions/xep-0168.html#ns'>
<item>
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns'
num='-1'/>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='juliet@capulet.lit/pda'/>
</addresses>
</message>
<message from='juliet@capulet.lit'
to='romeo@montague.lit/orchard'
type='headline'
id='rap3'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://www.xmpp.org/extensions/xep-0168.html#ns'>
<item>
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns'
num='10'/>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='juliet@capulet.lit/mobile'/>
</addresses>
</message>
]]></example>
</section2>
</section1> </section1>
<section1 topic='Flagging the Primary Resource' anchor='flag'> <section1 topic='Flagging the Primary Resource' anchor='flag'>
<p>The user's server may have special information that enables it to flag a resource as primary for a given application type. For instance, the server may include a communication policy service that enables the user to define (outside the context of any presence priorities) that she would prefer to be called at her desktop computer only between the hours of 9:00 AM and 5:00 PM local time, prefer to be called on her mobile phone at all other times, and so on.</p> <p>The user's server may have special information that enables it to flag a resource as primary for a given application type. For instance, the server may include a communication policy service that enables the user to define (outside the context of any presence priorities) that she would prefer to be called at her desktop computer only between the hours of 9:00 AM and 5:00 PM local time, prefer to be called on her mobile phone at all other times, and so on.</p>
<p>To flag the primary resource related to a specific application type, the server shall add a &lt;primary/&gt; child to the relevant RAP element. Here is an example:</p> <p>To flag the primary resource related to a specific application type, the server shall add a &lt;primary/&gt; child to the relevant RAP element. Here is an example:</p>
<example caption='Primary resource flag'><![CDATA[ <example caption='Primary resource flag'><![CDATA[
<presence from='juliet@capulet.com/mobile'> <presence from='juliet@capulet.lit/mobile'>
<priority>-1</priority> <priority>-1</priority>
<rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns' <rap xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns'
ns='http://www.xmpp.org/extensions/xep-0167#ns' ns='http://www.xmpp.org/extensions/xep-0167#ns'
@ -197,8 +276,8 @@
<p>For example, consider a &xep0155; request sent from one user (Romeo) to another (Juliet), where the users do not share presence. Romeo wants the request to be delivered to the highest-priority resource for the "http://www.xmpp.org/extensions/xep-0167#ns" application type.</p> <p>For example, consider a &xep0155; request sent from one user (Romeo) to another (Juliet), where the users do not share presence. Romeo wants the request to be delivered to the highest-priority resource for the "http://www.xmpp.org/extensions/xep-0167#ns" application type.</p>
<example caption="User requests session"><![CDATA[ <example caption="User requests session"><![CDATA[
<message type='headline' <message type='headline'
from='romeo@montague.net/orchard' from='romeo@montague.lit/orchard'
to='juliet@capulet.com'> to='juliet@capulet.lit'>
<route xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns-raproute' <route xmlns='http://www.xmpp.org/extensions/xep-0168.html#ns-raproute'
ns='http://www.xmpp.org/extensions/xep-0167#ns'/> ns='http://www.xmpp.org/extensions/xep-0167#ns'/>
<thread>ffd7076498744578d10edabfe7f4a866</thread> <thread>ffd7076498744578d10edabfe7f4a866</thread>
@ -222,8 +301,8 @@
<p>In order to discover whether a server or other entity supports this protocol, an entity MUST use &xep0030; or the dynamic profile of service discovery defined in &xep0115;.</p> <p>In order to discover whether a server or other entity supports this protocol, an entity MUST use &xep0030; or the dynamic profile of service discovery defined in &xep0115;.</p>
<example caption='Entity queries a server regarding protocol support'><![CDATA[ <example caption='Entity queries a server regarding protocol support'><![CDATA[
<iq type='get' <iq type='get'
from='juliet@capulet.com/balcony' from='juliet@capulet.lit/balcony'
to='capulet.com' to='capulet.lit'
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
@ -235,8 +314,8 @@
</ul> </ul>
<example caption='Server communicates protocol support for RAP'><![CDATA[ <example caption='Server communicates protocol support for RAP'><![CDATA[
<iq type='result' <iq type='result'
from='capulet.com' from='capulet.lit'
to='juliet@capulet.com/balcony' to='juliet@capulet.lit/balcony'
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'> <query xmlns='http://jabber.org/protocol/disco#info'>
... ...
@ -248,7 +327,8 @@
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>Neither client publishing of resource application priority nor server flagging of the primary resource introduces any known security vulnerabilities or compromises of user privacy.</p> <p>When the pubsub transport is used, client publishing of resource application priority may result in a presence leak if the node access model is "open". Care should be taken in properly configuring the pubsub node so that unauthorized entities are not able to retrieve information about the user's available resources.</p>
<p>Server flagging of the primary resource is not know to introduce any vulnerabilities or compromises of user privacy.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>