<abstract>This document defines an XMPP protocol extension to indicate the presence priority of XMPP resources for applications other than standard XMPP messaging.</abstract>
<remark><p>Added section on RAP-based routing of messages sent to bare JIDs; removed RAP request protocol; changed app attribute to ns attribute; removed the application types registry since it is unnecessary if the ns attribute specifies the XML namespace of the data most closely associated with the application type; updated namespaces to conform to XMPP Registrar processes.</p></remark>
<p>Within the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;), presence indicates availability for communication. Specifically, in systems that bundle presence and instant messaging (see &rfc3921;), the <priority/> child of the XMPP &PRESENCE; stanza indicates availability for communications qualified by the "jabber:client" namespace, especially instant messaging. However, a wide variety of entities might provide XMPP presence, including entities that are not primarily focused on IM (e.g., phones) or even entities that do not support XMPP messaging at all.</p>
<p>If the contact chooses the resource with which it initiates a voice chat based on the standard XMPP <priority/> element, the resulting behavior could be misleading (i.e., initiating the voice chat with the "desktop" resource rather than the "mobile" resource).</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. This document defines such a mechanism via an optional XMPP presence extension.</p>
<p>As extensions to that core use case, this document also defines:</p>
<ul>
<li>A way for an XMPP server to mark 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.</li>
<li>A way for an XMPP server to use application priority data for more intelligent routing of specially-labelled XMPP &MESSAGE; stanzas directed to a user's bare JID &LOCALBARE;.</li>
<p>Application priority is encapsulated by a <rap/> element qualified by the 'http://www.xmpp.org/extensions/xep-0168.html#ns' namespace &NSNOTE;. The attributes of the <rap/> element are as follows.</p>
<tablecaption='RAP Attributes'>
<tr>
<th>Attribute</th>
<th>Definition</th>
<th>Inclusion</th>
</tr>
<tr>
<td>ns</td>
<td>The primary namespace of the application type.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>num</td>
<td>The resource's priority for this application type. <note>This protocol uses a 'num' attribute rather than a 'priority' attribute to reduce confusion with standard XMPP presence.)</note></td>
<p>The following business rules apply to the generation of resource application priority by the client:</p>
<olstart='1'>
<li><p>A client SHOULD include a <rap/> 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 <rap/> 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 <rap/> element SHOULD be empty.</p></li>
</ol>
<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>
<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>
<examplecaption='Contact receives presence from user'><