This JEP specifies a set of XMPP extensions that provide support for "extended presence" information.
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.
Status: Experimental
Type: Standards Track
Number: 0119
Version: 0.6
Last Updated: 2005-03-28
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0060, JEP-0073, JEP-0080, JEP-0084, JEP-0107, JEP-0108, JEP-0112
Supersedes: None
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/Extended Presence Protocol Suite (JEP-0119)>
Email: stpeter@jabber.org
JID: stpeter@jabber.org
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.
A number of network services enable the exchange of information about an entity's availability for communications over the network. This information is usually called "presence". Examples include a person's availability to talk over a traditional or mobile telephony network, chat over an instant messaging (IM) network, or participate in a video conference. In this core sense, presence is a boolean, "on/off" indicator of network availability.
Over time, this core notion of presence has been extended to include other information about the entity that either (1) changes quickly or (2) affects the entity's interest in or ability to engage in communications. Examples of such "extended presence" include a person's proximity to or interaction with a user agent (e.g., "away" or "do not disturb"), activity (e.g., "driving"), ambient environment (e.g., "noisy"), and mood (e.g., "grumpy"). Related information includes data about the person's available devices (e.g., "phone" or "IM"), current contact modes or address, and date/time ranges for availability. Because extended presence information can change throughout the day, it is distinct from more stable information about the individual (such as is captured in a vCard or other long-lived metadata).
This document describes a unified approach to the provision and communication of extended presence information using the Extensible Messaging and Presence Protocol (XMPP), in the form of a "protocol suite" that incorporates by reference a number of existing XMPP extensions.
XMPP began life as a dedicated instant messaging and presence protocol within the Jabber community. The needs of this community were not advanced (simple IM and presence), and the presence model designed by that community mainly takes account of basic presence only (i.e., on/off availability on an IM network). Within this model (and using the terminology of RFC 2778 [1]), the only watchers are those in the principal's contact list (in XMPP called a "roster"). In addition, authorization to receive basic presence broadcasts is handled by the principal through a combination of roster management and basic presence subscriptions as defined in XMPP IM [2]. The presence service is tied to the principal's session with a server, and the server's internal session manager handles both presence and instant messaging functionality (although IM and presence can be separated in system configuration or "on the fly" via negative presence priorities).
This basic presence model was not designed for the more advanced world of extended presence, wherein there are many granular extended presence nodes, each with its own set of publishers and subscribers. However, there is a more advanced protocol that is specially designed to fully implement the publish-subscribe design pattern on top of XMPP, specified in JEP-0060: Publish-Subscribe [3]. The publish-subscribe protocol can be used to create a presence service that provides full control over each type of extended presence data.
In particular, the provision and communication of extended presence information follows the classic publish-subscribe design pattern: an individual publishes information such as geographical location data, and the data is broadcasted to all subscribers who are authorized to receive that data. (Alternatively, the data can be published on behalf of the individual, such as by a mobile telephony service that has knowledge of the individual's geographical location and authorization to act as a publisher of that data.) In general, the relationship between the publisher and subscriber is mediated by a service that receives publication requests, broadcasts data to subscribers, and enables the individual to manage lists of entities that are authorized to publish or subscribe to the data.
The following diagram provides a schematic representation of such a system.
Mobile XMPP
Telephony Principal Session
Service | Manager
|__________ ________|_________ _______|
| | | | | | | |
|1| |2| |3| |4| |5| |6|
+-------------------------+
| |
| Extended Presence |
| Service |
| |
+-------------------------+
|1| |2| |3| |4| |5| |6|
|___| |_| | _______|_
| | || | |
Sub Sub Sub Sub Sub
In this example, there are six different extended presence nodes (these might be, for example, geographical location, icon/avatar, activity, mood, network availability, etc.). The principal is authorized to publish to all six, a Mobile Telephony Service is also authorized to publish to Node 1 (e.g., geolocation), and an XMPP Session Manager is also authorized to publish to Node 6 (e.g., network availability). There are five subscribers: Subscriber 1 is authorized to receive data from Node 1 and Node 2, Subscriber 2 is authorized to Node 2 and Node 3, Subscriber 3 is authorized to receive data from Node 4 and Node 6, and Subscribers 4 and 5 are authorized to receive data from Node 6 only.
It is clear that this model enables a highly flexible presence service with regard to the granularity of extended presence information that an individual can publish, the management of authorized publishers, and the management of authorized subscribers. The generic publish-subscribe pattern is the future of extended presence services in XMPP.
This document follows the same approach as Basic IM Protocol Suite [4]. By design, the Basic IM Protocol Ssuite does not include more advanced functionality related to "extended presence"; the present document fills the need for a protocol suite that addresses such functionality.
A protocol is deemed worthy of inclusion in this protocol suite if:
We define the Extended Presence Protocol Suite as follows:
Table 1: Required and Recommended Specifications
| Specification | Requirement Level |
|---|---|
| JEP-0073: Basic IM Protocol Suite | REQUIRED (prerequisite) |
| JEP-0060: Publish-Subscribe | REQUIRED (prerequisite) |
| User Geolocation [6] | REQUIRED |
| User Physical Location [7] | REQUIRED |
| User Activity [8] | REQUIRED |
| User Mood [9] | REQUIRED |
| User Avatar [10] | REQUIRED |
In order to expedite the discovery of all the extended presence pubsub nodes offered by a user, it is RECOMMENDED to use a combination of publish-subscribe nodes and well-known Service Discovery [11] nodes as described below (the latter using the service discovery publishing functionality described in the Publishing Available Items section of JEP-0030). The suggested protocol flow to be followed by the user in publishing these items, and by the contact in retrieving these items, is shown below.
First, the user creates a pubsub node for his extended presence.
Example 1. User creates extended presence pubsub node
<iq type='set'
from='romeo@montague.net'
to='pubsub.shakespeare.lit'
id='create1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='romeo-extended-presence-node'/>
</pubsub>
</iq>
Example 2. Pubsub service acknowledges node creation
<iq type='result'
to='romeo@montague.net'
from='pubsub.shakespeare.lit'
id='create1'/>
Having created a pubsub node for his extended presence information, the user now publishes this pubsub node to the service discovery node "http://jabber.org/protocol/extended-presence" at his bare JID (using the service discovery publishing protocol) so that other entities can determine the location of his extended presence information when he is offline.
Example 3. User publishes pubsub node location as a disco item
<iq id='disco-set-1'
type='set'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/extended-presence'>
<item action='update'
jid='pubsub.shakespeare.lit'
node='romeo-extended-presence-node'
name='Extended Presence'/>
</query>
</iq>
Example 4. User's server acknowledges disco node publication
<iq from='romeo@montague.net/home'
id='disco-set-1'
to='romeo@montague.net/home'
type='result'/>
Now the user creates a specific extended presence node, such as a geolocation node.
Example 5. User creates pubsub node for geolocation information
<iq type='set'
to='pubsub.shakespeare.lit'
id='create2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='romeo-geolocation-information'/>
</pubsub>
</iq>
Example 6. Pubsub service acknowledges node creation
<iq type='result'
to='romeo@montague.net'
from='pubsub.shakespeare.lit'
id='create2'/>
Next, the user publishes his geolocation information pubsub node to the node "http://jabber.org/protocol/geoloc" at his bare JID (using the service discovery publishing protocol) so that it may be discovered even when he is offline.
Example 7. User publishes this node as a disco item
<iq id='disco-set-2'
type='set'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/geoloc'>
<item action='update'
jid='pubsub.shakespeare.lit'
name='Geographic Location'
node='romeo-geolocation-information'/>
</query>
</iq>
Example 8. User's server acknowledges disco node publication
<iq from='romeo@montague.net/home'
id='disco-set-2'
to='romeo@montague.net/home'
type='result'/>
The user also publishes the geolocation pubsub node as an item under the extended presence pubsub node. The pubsub ItemID MUST be the namespace of the relevant presence extension protocol (in this case, 'http://jabber.org/protocol/geoloc').
Example 9. User publishes geoloc node as extended presence item
<iq type='set'
to='pubsub.shakespeare.lit'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='romeo-extended-presence-node'>
<item id='http://jabber.org/protocol/geoloc'>
<item xmlns='http://jabber.org/protocol/disco#items'
action='update'
jid='pubsub.shakespeare.lit'
name='Geographic Location'
node='romeo-geolocation-information'/>
</item>
</publish>
</pubsub>
</iq>
Example 10. Pubsub service acknowledges item publication
<iq from='pubsub.shakespeare.lit'
id='publish1'
to='romeo@montague.net/home' type='result'/>
At this point, a contact who is interested only in the user's geolocation information can send a disco#items request to the node "http://jabber.org/protocol/geoloc" at the user's bare JID:
Example 11. Contact requests geoloc node as disco item
<iq from='nurse@capulet.com/pda'
id='disco-get-1'
to='romeo@montague.net'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/geoloc'/>
</iq>
Example 12. Server informs contact of published geoloc node
<iq from='romeo@montague.net'
id='disco-get-1'
to='nurse@capulet.com/pda'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/geoloc'>
<item jid='pubsub.shakespeare.lit'
name='Geographic Location'
node='romeo-geolocation-information'/>
</query>
</iq>
The contact can then subscribe to that pubsub node.
On the other hand, a contact who is interested in all of the user's extended presence information can send a disco#items request to the node "http://jabber.org/protocol/extended-presence" at the user's bare jid:
Example 13. Contact requests extended presence nodes as disco items
<iq from='juliet@capulet.com/balcony'
id='disco-get-2'
to='romeo@montague.net'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/extended-presence'/>
</iq>
Example 14. Server informs contact of published extended presence nodes
<iq from='romeo@montague.net'
id='disco-get-2'
to='juliet@capulet.com/balcony'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/extended-presence'>
<item jid='pubsub.shakespeare.lit'
name='Geolographic Location'
node='romeo-geolocation-information'/>
<item jid='pubsub.shakespeare.lit'
name='Mood Information'
node='romeo-mood-information'/>
<item jid='pubsub.shakespeare.lit'
name='Activity Information'
node='romeo-activity'/>
<item jid='pubsub.shakespeare.lit'
name='Avatar Information'
node='romeo-avatar'/>
</query>
</iq>
This document introduces no new security considerations above and beyond those defined in the documents on which it depends.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [12].
The Jabber Registrar [13] shall include 'http://jabber.org/protocol/extended-presence' in its registry of well-known Service Discovery nodes.
There is no schema associated with the 'http://jabber.org/protocol/extended-presence' namespace, since it is used only for service discovery.
1. RFC 2778: A Model for Presence and Instant Messaging <http://www.ietf.org/rfc/rfc2778.txt>.
2. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
3. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
4. JEP-0073: Basic IM Protocol Suite <http://www.jabber.org/jeps/jep-0073.html>.
5. JEP-0001: Jabber Enhancement Proposals <http://www.jabber.org/jeps/jep-0001.html>.
6. JEP-0080: User Geolocation <http://www.jabber.org/jeps/jep-0080.html>.
7. JEP-0112: User Physical Location <http://www.jabber.org/jeps/jep-0112.html>.
8. JEP-0108: User Activity <http://www.jabber.org/jeps/jep-0108.html>.
9. JEP-0107: User Mood <http://www.jabber.org/jeps/jep-0107.html>.
10. JEP-0084: User Avatar <http://www.jabber.org/jeps/jep-0084.html>.
11. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
12. 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/>.
13. 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/>.
END