Documented optional pubsub transport for RAP data.
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.
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.
-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.
-| Attribute | -Definition | -Inclusion | -
|---|---|---|
| ns | -The primary namespace of the application type. | -REQUIRED | -
| num | -The resource's priority for this application type. |
- REQUIRED | -
The following business rules apply to resource application presence provided by the client:
-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.
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").
The <rap/> element SHOULD be empty.
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.
-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.
+| Attribute | +Definition | +Inclusion | +
|---|---|---|
| ns | +The primary namespace of the application type. | +REQUIRED | +
| num | +The resource's priority for this application type. |
+ REQUIRED | +
An example follows.
+The following business rules apply to the generation of resource application priority by the client:
+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.
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").
The <rap/> element SHOULD be empty.
As explained in the following sections, there are two possible transports for RAP data: standard XMPP presence and the XMPP publish-subscribe extension.
+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.
+For the three resources ("desktop", "pda", and "mobile") mentioned above, the presence stanzas received by a contact would be as follows.
+Alternatively, RAP data MAY be provided via the XMPP &xep0060; publish-subscribe extension, specifically the &xep0163; profile thereof.
+For the three resources ("desktop", "pda", and "mobile") mentioned above, the pubsub notifications received by a contact would be as follows.
+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.
To flag the primary resource related to a specific application type, the server shall add a <primary/> child to the relevant RAP element. Here is an example:
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;.
Neither client publishing of resource application priority nor server flagging of the primary resource introduces any known security vulnerabilities or compromises of user privacy.
+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.
+Server flagging of the primary resource is not know to introduce any vulnerabilities or compromises of user privacy.
This document requires no interaction with &IANA;.