This document defines an XMPP presence extension to indicate the priority of XMPP resources for applications other than messaging.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Type: Standards Track
Last Updated: 2005-12-15
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030
Superseded By: None
Short Name: rap
Wiki Page: <http://wiki.jabber.org/index.php/Resource Application Priority (RAP) (JEP-0168)>
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Within the Extensible Messaging and Presence Protocol (XMPP; see RFC 3920 ), presence indicates availability for communication -- specifically, communication via XMPP messaging (usually in the form of "instant messaging" or IM as described in RFC 3921 ). 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.
Consider a scenario in which a contact wants to initiate a voice chat with a user who has the following three XMPP resources:
|Resource||Messaging Priority||Voice Chat Priority|
If the contact chooses the resource with which it initiates a voice chat based on the user's default XMPP presence priority (i.e., priority for XMPP messaging), the resulting behavior could be misleading (i.e., initiating the voice chat with the "desktop" resource rather than the "mobile" resource).
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 messaging priority. 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 determine the primary resource.
In order to discover whether a server or other entity supports this protocol, an entity MUST use Service Discovery .
<iq firstname.lastname@example.org/balcony' to='capulet.com' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
If the queried entity supports resource application presence, it MUST return a feature of "http://jabber.org/protocol/rap":
<iq from='capulet.com' email@example.com/balcony' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'> ... <feature var='http://jabber.org/protocol/rap'/> ... </query> </iq>
If the queried entity supports resource application presence as well as RAP requests (see the Requesting RAP Data Via IQ section of this document), it MUST return features of "http://jabber.org/protocol/rap" and "http://jabber.org/protocol/raprequest":
<iq from='capulet.com' firstname.lastname@example.org/balcony' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'> ... <feature var='http://jabber.org/protocol/rap'/> <feature var='http://jabber.org/protocol/raprequest'/> ... </query> </iq>
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:
<presence email@example.com/desktop' firstname.lastname@example.org/home'> <priority>10</priority> <rap xmlns='http://jabber.org/protocol/rap' app='jingle-audio' num='5'/> </presence> <presence email@example.com/pda' firstname.lastname@example.org/home'> <priority>5</priority> <rap xmlns='http://jabber.org/protocol/rap' app='jingle-audio' num='-1'/> </presence> <presence email@example.com/mobile' firstname.lastname@example.org/home'> <priority>-1</priority> <rap xmlns='http://jabber.org/protocol/rap' app='jingle-audio' num='10'/> </presence>
(Note: This protocol uses a 'num' attribute rather than a 'priority' attribute to reduce confusion with XMPP presence and also to save some bytes.)
The following business rules apply to resource application presence provided by the client:
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" resource only between the hours of 9:00 AM and 5:00 PM local time, prefer to be called on her mobile at all other times, and so on.
The XML for representing the primary resource related to a specific application type is extremely simple: the server may add a <primary/> child to the relevant RAP element. Here is an example:
<presence email@example.com/mobile'> <priority>-1</priority> <rap xmlns='http://jabber.org/protocol/rap' app='jingle-audio' num='10'> <primary/> </rap> </presence>
The following business rules apply to resource flagging by the server:
In the interest of saving bandwidth, a server MAY choose to strip all RAP data out of presence stanzas and instead provide RAP data only on request via IQ interactions. A likely scenario is as follows:
An example protocol flow for the last two steps is as follows:
<iq firstname.lastname@example.org/home' email@example.com'> <raprequest xmlns='http://jabber.org/protocol/raprequest'/> </iq>
<iq firstname.lastname@example.org/home' email@example.com'> <raprequest xmlns='http://jabber.org/protocol/raprequest'> <presence firstname.lastname@example.org/desktop' xmlns='jabber:client'> <priority>10</priority> <rap xmlns='http://jabber.org/protocol/rap' app='jingle-audio' num='5'/> </presence> <presence email@example.com/pda' xmlns='jabber:client'> <priority>5</priority> <rap xmlns='http://jabber.org/protocol/rap' app='jingle-audio' num='-1'/> </presence> <presence firstname.lastname@example.org/mobile' xmlns='jabber:client'> <priority>-1</priority> <rap xmlns='http://jabber.org/protocol/rap' app='jingle-audio' num='10'/> </presence> </raprequest> </iq>
See the Security Considerations section of this document for an important proviso regarding access to RAP data.
Neither client publishing of resource application priority nor server flagging of the primary resource introduces any known security vulnerabilities or compromises of user privacy.
If a server supports RAP requests, it MUST carefully control access to RAP data in order to guard against presence leaks and directory harvest attacks. Specifically, if the requesting entity is not authorized (e.g., a contact with a presence subscription of "both" or "from" as described in RFC 3921) or is not explicitly trusted (e.g., a server in a trusted network), the server MUST return a <forbidden/> error in response to RAP requests.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) .
The Jabber Registrar  shall include the following namespaces in its registry of protocol namespaces:
The Jabber Registrar shall maintain a registry of application types. Although strictly speaking this should not be necessary, it is desirable to maintain a list of "short names" for various application types rather than using long XML namespaces, especially in presence broadcasts. For example, a short name of "jingle-audio" is only 12 characters long, whereas the full XML namespace "http://jabber.org/protocol/jingle/sessions/audio" is 48 characters long. The difference can be quite significant when many presence stanzas are sent.
In order to submit new values to this registry, the registrant must define an XML fragment of the following form and either include it in the relevant Jabber Enhancement Proposal or send it to the email address <email@example.com>:
<app> <name>the value of the 'app' attribute</name> <ns>the full namespace associated with the relevant protocol</ns> <desc>a natural-language description of the application type</desc> <doc>the document in which this application type is specified</doc> </app>
<app> <name>im</name> <ns>jabber:client</ns> <desc>Standard XMPP messaging</desc> <doc>RFC 3921</doc> </app> <app> <name>jingle-audio</name> <ns>http://jabber.org/protocol/jingle/sessions/audio</ns> <desc>Jingle audio sessions</desc> <doc>JEP-0167</doc> </app>
<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='http://jabber.org/protocol/rap' xmlns='http://jabber.org/protocol/rap' elementFormDefault='qualified'> <xs:element name='rap'> <xs:complexType> <xs:sequence> <xs:element name='primary' type='empty' minOccurs='0'/> </xs:sequence> <xs:attribute name='app' type='xs:nmtoken' default='message'/> <xs:attribute name='num' type='xs:byte'/> </xs:complexType> </xs:element> <xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType> </xs:schema>
4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
5. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.