RPID -- Rich Presence Information Data Format
From: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-00.txt
Ref: draft-ietf-simple-rpid-00.txt
------------------------------------------------------------------------
Internet Engineering Task Force
Internet Draft H. Schulzrinne (ed.)
Columbia U.
draft-ietf-simple-rpid-00.txt
July 31, 2003
Expires: January 2004
RPID -- Rich Presence Information Data Format
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The Rich Presence Information Data Format (RPID) adds elements to the
Presence Information Data Format (PIDF) that provide additional
information about the presentity and its contacts. This information
can be translated into call routing behavior or be delivered to
watchers, for example. The information is designed so that much of it
can be derived automatically, e.g., from calendar files or user
activity.
H. Schulzrinne (ed.) [Page 1]
Internet Draft RPID July 31, 2003
1 Introduction
The PIDF definition [1] describes a basic presence information data
format for exchanging presence information in CPIM-compliant systems.
It consists of a root element, zero or more
elements carrying presence information, zero or more elements
and zero or more extension elements from other name spaces. Each
tuple defines a basic status of either "open" or "closed".
This document provides additional status information for presentities
and defines a Rich Presence Information Data Format for Presence
(RPID) to convey this information.
This extension has three main goals:
1. Provide rich presence indication that is at least as
powerful as common commercial presence systems. Such
feature-parity simplifies transition to CPIM-compliant
systems, both in terms of user acceptance and protocol
conversion.
2. Maintain backwards-compatibility with PIDF, so that PIDF-
only watchers and gateways can continue to function
properly, naturally without access to the functionality
described here.
We make no assumptions how the information in the RPID is generated.
Experience has shown that users are not always diligent about
updating their presence status. Thus, we want to make it as easy as
possible to derive RPID information from other information sources,
such as calendars, the status of communication devices such as
telephones, typing activity and physical presence detectors as
commonly found in energy-management systems.
The information in a presence document can be generated by a single
entity or can be composed from information published by multiple
entities.
Many of the elements correspond to data commonly found in personal
calendars. Thus, we attempted to align some of the extensions with
the usage found in calendar formats such as iCal [10] and xCal [11],
as noted below.
Note that PIDF documents and this extension can be used in two
different contexts, namely by the presentity to publish its presence
status and by the presence server to notify some set of watchers. The
presence server MAY compose, translate or filter the published
presence state before delivering customized presence information to
H. Schulzrinne (ed.) [Page 2]
Internet Draft RPID July 31, 2003
the watcher. For example, it may merge presence information from
multiple PUAs, remove whole elements, translate values in elements or
remove information from elements. Mechanisms that filter calls and
other communications to the presentity can subscribe to this presence
information just like a regular watcher and in turn generate
automated rules, such as scripts [12], that govern the actual
communications behavior of the presentity.
The flow diagram below illustrates this process.
presentity
|
--> publish
|
--> PA (filter)
--> notification 1 to A, B, C
--> notification 2 to D, E
--> notification 3 to F
--> notification 4 to script gen.
2 RPID Features
Below, we summarize and motivate the major additional features that
RPID adds to PIDF.
The PIDF definition does not clearly describe what a
represents. We add an element (Section 6.3) that allows a
presentity to label tuples in ways that make sense to the presentity,
e.g., to group similar tuples by name. The element
describes whether a tuple is a device, a set of devices with a common
address ("service"), a human face-to-face contact or a presentity.
While the PIDF definition describes which means of communications are
available for a presentity, it does not describe the activity that
the presentity is currently engaged in. The (Section 6.2)
element adds this information.
The (Section 6.5) element indicates when the device was last
used or simply whether it has been idle.
To help the watcher gauge the appropriateness of different types of
communications, we indicate the type of place the user is currently
in, via the element (Section 6.6) and hint at the privacy
available via .
H. Schulzrinne (ed.) [Page 3]
Internet Draft RPID July 31, 2003
PIDF defines a element indicating the date and time of
the status change of a tuple. RPID adds a validity period for
, and values, as a hint how long the
current status is likely to be valid.
An important sub-case is that a presentity is interruptible only
under unusual circumstances, after mediation by some, typically
human, authority such as a secretary or supervisor. We allow the
presentity to convey that certain contact addresses actually belong
to a different person, presumably one that can either interrupt the
presentity or otherwise assist. The (Section 6.8)
element allows to indicate that a particular tuple refers to a
different principal or presentity.
Note that this document does not defined a new content type. Rather,
it inherits the content type from [1], namely application/cpim-
pidf+xml
3 Scope
This extension does not replace media negotiation mechanisms defined
for SIP (e.g. SDP [2]), therefore media negotiation (e.g., choice of
voice and video codecs) MUST be performed according to [3]. This
extension is only aimed to give the watchers hints about the
presentity's preferences, willingness and capabilities to communicate
before watchers initiate SIP-based communication with the presentity.
4 Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [4]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are
used in the same meaning as defined therein. The key words MUST,
MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL
in this document are to be interpreted as described in BCP XX, RFC
2119 [5].
5 The Meaning of "open" and "closed"
PIDF describes the basic status values of "open" or "closed" only as
"have meanings of general availability for other communications
means". We define "closed" in our context as meaning that
communication to the contact address will in all likelihood not
succeed, is undesired or will not reach the intended party. (For
example, a presentity may include a hotel phone number as a contact.
After check-out, the phone number will still ring, but reach the
chambermaid or the next guest. Thus, it would be declared "closed".)
For "pres" contacts, "closed" means that no presence status
H. Schulzrinne (ed.) [Page 4]
Internet Draft RPID July 31, 2003
information is available.
The interpretation of "closed" was chosen since there is no
other status value to indicate that a communications
address is not reachable. Omitting the element
does not work since it would confuse watchers that have not
previously seen an "open" status for the same contact
address.
6 RPID Elements
6.1 Introduction
Below, we describe the RPID elements in detail. , , , , extend the PIDF
element, while and extend the PIDF
element.
In general, it is highly unlikely that a presentity will publish or
announce all of these elements at the same time. Rather, these
elements were chosen to give the presentity maximum flexibility in
deriving this information from existing sources, such as calendaring
tools, device activity sensors or location trackers, as well as to
manually configure this information.
The namespace URIs for these elements defined by this specification
are URNs [6], using the namespace identifier 'ietf' defined by [7]
and extended by [8]:
urn:ietf:params:xml:ns:pidf:rpid-status
urn:ietf:params:xml:ns:pidf:rpid-tuple
6.2 Activity Element
The indication describes what the presentity is currently
doing. This can be quite helpful to the watcher in judging how
appropriate a communication attempt is and which means of
communications is most likely to succeed and not annoy the
presentity. The activity indications correspond roughly to the
category field in calendar entries, such as Section 4.8.1.2 of RFC
2445 [9].
Use of an enumerated, but extensible, set of activity
H. Schulzrinne (ed.) [Page 5]
Internet Draft RPID July 31, 2003
categories simplifies automated generation and processing
of presence information. The categories can be readily
selected from a drop-down list by the user or translated
from the corresponding activity field in calendars.
Recipients of this information can render at least a subset
as icons, automatically translate them into different
languages or convert them to sound "jingles" and speech, or
use them to generate call processing rules.
An activity indication consists of one or more values drawn from the
list below, any other token string or IANA-registered values (Section
10). Communities of interest such as a profession or an organization
may define additional activity labels for their internal use.
On-the-phone: The presentity is talking on the telephone. This
activity is included since it can often be derived
automatically.
Away: The presentity is physically away from the device
location. This activity was included since it can often be
derived automatically from security systems, energy
management systems or entry badge systems.
Appointment: The presentity has a calendar appointment.
Holiday: This is a scheduled national or local holiday. This
information can typically be derived automatically from
calendars.
Meal: The presentity is scheduled for a meal. This activity
category can often be generated automatically from a
calendar.
Meeting: This activity category can often be generated
automatically from a calendar.
Steering: The presentity is controlling a vehicle, ship or
plane.
In-transit: The presentity is riding in a vehicle, such as a
car, but not steering. Alternatively, the presentity MAY
offer more specific information.
Travel: The presentity is on a business or personal trip, but
not necessarily in-transit. This category can often be
generated automatically from a calendar.
Vacation: This activity category can often be generated
H. Schulzrinne (ed.) [Page 6]
Internet Draft RPID July 31, 2003
automatically from a calendar.
Sleeping: This activity category can often be generated
automatically from a calendar, local time information or
biometric data.
Busy: User is busy, without further details. This activity
category would typically be indicated manually.
Permanent-absence: Presentity will not return for the
foreseeable future, e.g., because it is no longer working
for the company.
The activity element MAY be qualified with the 'from' and value and
the time until which is element is expected to be valid.
6.3 Class
The 'class' attribute describes the class of the tuple. Multiple
tuples can have the same class name within a presence document. The
naming of classes is left to the presentity. The presentity can use
this information to group similar tuples or to convey information
that the presence agent can use for filtering.
The class description is similar in spirit to the 'class'
attribute of XML elements, used to support Cascading Style
Sheets.
6.4 Contact-Type Element
The element describes the type of the tuple. A tuple
can represent a communication facility ("device"), a face-to-face
communication tuple ("in-person"), a set of devices offering a common
service ("service"), or a whole presentity ("presentity"). Additional
types can be registered with IANA.
URI schema are insufficient to distinguish the different
types of tuples. For example, a SIP URI can designate a
single device, a presentity or a subgroup of devices.
6.5 Idle Element
The records the absolute time and date the communication
device was last used. This provides an indication as to how likely a
user is to answer the device. A device that has not been used in a
while may still be OPEN, but a watcher may choose to first contact a
H. Schulzrinne (ed.) [Page 7]
Internet Draft RPID July 31, 2003
device that is both OPEN and not marked as idle.
The element can be empty if the presentity wants to indicate
that the device has not been used for a while, but does not want to
reveal the precise duration:
The SHOULD be included in the presence document if the idle
time exceeds a user-setable threshold, with a RECOMMENDED default
value of 10 minutes. Configuration MUST include the option to omit
the timestamp.
6.6 Type of Place Element
The element describes the type of place the presentity is
currently at. This offers the watcher an indication what kind of
communication is likely to be appropriate. We define an initial set
of values below:
home: The presentity is in a private or residential setting, not
necessarily the personal residence of the presentity, e.g.,
including hotel or a friend's home.
office: The presentity is in a business setting, such as an
office.
public: The presentity is in a public area such as a shopping
mall, street, park, public building, train station, airport
or in public conveyance such as a bus, train, plane or
ship. Alternatively, the more detailed indications below
may be provided.
street: Walking in a street.
public-transport: Any form of public transport, including
aircraft, bus, train or ship.
aircraft: The presentity is in a plane, helicopter or balloon.
ship: Water vessel, boat.
bus: Public bus.
train: The presentity is traveling in a train.
H. Schulzrinne (ed.) [Page 8]
Internet Draft RPID July 31, 2003
airport: Airport, heliport or similar location.
station: Bus or train station.
mall: Shopping mall or shopping area.
outdoors: General outdoors area, such as a park or city streets.
This list can be augmented by free-text values or additional IANA-
registered values (Section 10).
The placetype element MAY be qualified with the 'from' and value and
the time until which is element is expected to be valid. The relative
to the publication of the presence information.
The placetype element can be used by logic executing on the
watcher or by a composer to filter, sort and label tuples.
For example, a composer may have rules that limit the
publication of "home" tuples to a subset of the watchers.
6.7 Privacy Element
The element indicates whether third parties may be able to
hear or view parts of the communication.
public: Others may be able to see or hear the communications.
private: Inappropriate individuals are not likely to see or hear
the communications.
quiet: The presentity is in a place such as a library,
restaurant, place-of-worship, or theater that discourages
noise, conversation and other distractions.
This indication is not limited to voice communications. For example,
a presentity might label her privacy as "quiet" when giving a talk,
since it would be inappropriate if an instant message popped up on
the laptop screen that is being projected for the audience.
The placetype element can be used by logic executing on the
watcher or by a composer to filter, sort and label tuples.
For example, a composer may have rules that limit the
publication of tuples labeled as "quiet" to a select subset
of the watchers.
The activity element MAY be qualified with the 'from' and value and
H. Schulzrinne (ed.) [Page 9]
Internet Draft RPID July 31, 2003
the time until which is element is expected to be valid. The relative
to the publication of the presence information.
6.8 Relationship Element
The element designates the type of relationship an
alternate contact has with the presentity. This element is provided
only if the tuple refers to somebody other than the presentity.
Relationship values include "family", "associate" (e.g., for a
colleague), "assistant", "supervisor". Other free-text values and
additional IANA-registered values (Section 10) can be used as well.
The element for tuples labeled with a relationship can
contain either a communication URI such as "im", "sip"/"sips",
"h323", "tel" or "mailto", or a presence URI, such as "pres" or
"sip".
7 Examples
7.1 Presentity with Activity
I'm in a boring meetingassistantpresentityopensip:secretary@example.comassistantMy secretarysipserviceopenmeeting
office
H. Schulzrinne (ed.) [Page 10]
Internet Draft RPID July 31, 2003
quiet2003-01-27T10:43:00Zsip:someone@example.com2001-10-27T16:49:29Zphonedeviceopenquietim:someone@mobilecarrier.net2001-10-27T16:49:29Zmaildeviceopenmailto:someone@example.com
8 XML Schema Definitions
H. Schulzrinne (ed.) [Page 11]
Internet Draft RPID July 31, 2003
Describes RPID tuple extensions for PIDF.
H. Schulzrinne (ed.) [Page 12]
Internet Draft RPID July 31, 2003
Describes RPID status extensions for PIDF.
H. Schulzrinne (ed.) [Page 13]
Internet Draft RPID July 31, 2003
9 Security Considerations
The security considerations in [1] apply, as well as [9]. Compared to
PIDF, this presence document format reveals additional information
that can be highly sensitive. Beyond traditional security measures to
protect confidentiality and integrity, systems should offer a means
to selectively reveal information to particular watchers and to
inspect the information that is being published, particularly if it
is generated automatically from other sources, such as calendars or
sensors.
Like any information retrieved by reference, the information provided
in the , and elements may refer to data types
that expose the watcher to security risks.
10 IANA Considerations
This document calls for IANA to:
o register two new XML namespace URNs per [8];
o establish registry for activity categories (Section 6.2),
place types (Section 6.6), and relationships (Section 6.8).
Note that this document does not need a new content type. It inherits
the content type from [1], namely application/cpim-pidf+xml
10.1 URN Sub-Namespace Registration for
URI: urn:ietf:params:xml:ns:rpid-status
Description: This is the XML namespace for XML elements defined
H. Schulzrinne (ed.) [Page 14]
Internet Draft RPID July 31, 2003
by RFCXXXX to describe rich presence information extensions
for the status element in the PIDF presence document format
in the
application/cpim-pidf+xml
content type.
Registrant Contact: IETF, SIMPLE working group,
,
Henning Schulzrinne,
XML:
BEGIN
RPID -- Rich Presence Information Data Format
for Presence