XEP-0119: Extended Presence Protocol Suite

WARNING: This document has been retracted by the author(s). Implementation of the protocol described herein is not recommended. Developers desiring similar functionality are advised to implement the protocol that supersedes this one (if any).

Table of Contents

1. Introduction

Note: This document has been retracted since its functionality is handled by Personal Eventing Protocol [1].

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 quite often (e.g., several times in the course of a typical IM session), it is distinct from more stable information about the individual (such as is captured in a vCard or other user profile).

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.

2. Background

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 [2]), 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 [3]. 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. While some existing IM clients publish extended presence information as XML extensions to the XMPP <presence/> stanza, that model does not scale well, does not respect the bandwidth restrictions of many clients on the network, and does not provide for more granular control over information access (anyone who receives presence will also receive geolocation data and the like). 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 XEP-0060: Publish-Subscribe [4]. The publish-subscribe protocol can be used to create a service that provides full control over each type of extended presence data, sending that data only to those specifically authorized to receive it and those who have an active interest in each extension. In particular, for extended presence related to IM users, we specify the use of the personal eventing subset of XEP-0060, as defined in XEP-0163.

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. This model makes it possible to deploy highly flexible extended presence services within the context of XMPP.

The following diagram provides a schematic representation of such a service.

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, 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.

3. Requirements

This document follows the same approach as Basic IM Protocol Suite [5]. By design, the Basic IM Protocol Suite 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:

• It addresses "extended presence" data that is defined in other presence services or protocols (e.g., Wireless Village or SIMPLE), or that is felt to be needed within the Jabber/XMPP community.
• It has achieved a status of at least Draft within the XMPP Standards Foundation's standards process (as defined in XMPP Extension Protocols [6]).

4. Extended Presence Protocol Suite

We define the Extended Presence Protocol Suite as follows:

* Note: The User Avatar specification (XEP-0084) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.

5. Node Discovery

Discovery of extended presence pubsub nodes is expedited through the use of Personal Eventing via Pubsub (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:

• Activity: http://jabber.org/protocol/activity
• Avatar: http://jabber.org/protocol/avatar#metadata
• Geolocation: http://jabber.org/protocol/geoloc
• Mood: http://jabber.org/protocol/mood
• Physical Location: http://jabber.org/protocol/physloc

These nodes SHOULD have an access model of either "presence" or "roster".

6. Security Considerations

This document introduces no new security considerations above and beyond those defined in the documents on which it depends. Because publicly exposing some forms of extended presence information (e.g., geolocation information) may lead to unnecessary risks, care should be taken in setting the access model for the relevant pubsub nodes (minimally, an access model of "presence" to take advantage of the bidirectional authorization scheme inherent in XMPP presence subscriptions).

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [12].

8. XMPP Registrar Considerations

This document requires no interaction with the XMPP Registrar [13].

Appendices

Appendix A: Document Information

Series: XEP
Number: 0119
Publisher: XMPP Standards Foundation
Status: Retracted
Type: Standards Track
Version: 0.8
Last Updated: 2006-08-08
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0060, XEP-0073, XEP-0080, XEP-0084, XEP-0107, XEP-0108, XEP-0112, XEP-0163
Supersedes: None
Superseded By: XEP-0163
Short Name: N/A
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards 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 document 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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END