Network Working Group H. Schulzrinne
Request for Comments: 4480 Columbia U.
Category: Standards Track V. Gurbani
Lucent
P. Kyzivat
J. Rosenberg
Cisco
July 2006
RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Presence Information Data Format (PIDF) defines a basic format
for representing presence information for a presentity. This format
defines a textual note, an indication of availability (open or
closed) and a Uniform Resource Identifier (URI) for communication.
The Rich Presence Information Data format (RPID) described here is an
extension that adds optional elements to the Presence Information
Data Format (PIDF). These extensions provide additional information
about the presentity and its contacts. The information is designed
so that much of it can be derived automatically, e.g., from calendar
files or user activity.
This extension includes information about what the person is doing, a
grouping identifier for a tuple, when a service or device was last
used, the type of place a person is in, what media communications
might remain private, the relationship of a service tuple to another
presentity, the person's mood, the time zone it is located in, the
type of service it offers, an icon reflecting the presentity's
status, and the overall role of the presentity.
These extensions include presence information for persons, services
(tuples), and devices.
Schulzrinne, et al. Standards Track [Page 1]
RFC 4480 RIPD July 2006
Table of Contents
1. Introduction ....................................................2
2. Terminology and Conventions .....................................4
3. RPID Elements ...................................................4
3.1. Overview ...................................................4
3.2. Activities Element .........................................7
3.3. Class Element .............................................10
3.4. Device Identifier .........................................10
3.5. Mood Element ..............................................10
3.6. Place-is Element ..........................................12
3.7. Place-type Element ........................................13
3.8. Privacy Element ...........................................14
3.9. Relationship Element ......................................15
3.10. Service Class ............................................15
3.11. Sphere Element ...........................................16
3.12. Status-Icon Element ......................................16
3.13. Time Offset ..............................................17
3.14. User-Input Element .......................................17
4. Example ........................................................18
5. XML Schema Definitions .........................................20
5.1. urn:ietf:params:xml:ns:pidf:rpid ..........................20
6. Extending RPID .................................................30
7. IANA Considerations ............................................31
7.1. URN Sub-Namespace Registration for ........................31
'urn:ietf:params:xml:ns:pidf:rpid'
7.2. Schema Registration for Schema ............................32
'urn:ietf:params:xml:ns:pidf:status:rpid'
8. Internationalization Considerations ............................32
9. Security Considerations ........................................32
10. References ....................................................33
10.1. Normative References .....................................33
10.2. Informative References ...................................34
Appendix A. Acknowledgements .....................................35
1. Introduction
The Presence Information Data Format (PIDF) definition [8] describes
a basic presence information data format, encoded as an Extensible
Markup Language (XML) [9] (SCHEMA-1 [10]) (SCHEMA-2 [11]), for
exchanging presence information in systems compliant with the common
model for presence and instant messaging [5]. It consists of a
root element, zero or more elements carrying
presence information including a Uniform Resource Identifier (URI)
for communication, 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".
Schulzrinne, et al. Standards Track [Page 2]
RFC 4480 RIPD July 2006
However, it is frequently useful to convey additional information
about a user that needs to be interpreted by an automata, and is
therefore not appropriate to be placed in the element of the
PIDF document, which is typically intended for the human observer.
Therefore, this specification defines extensions to the PIDF document
format for conveying richer presence information. Generally, the
extensions have been chosen to provide features common in existing
presence systems at the time of writing, in addition to elements that
could readily be derived automatically from existing sources of
presence, such as calendaring systems or communication devices, or
sources describing the user's current physical environment.
The presence data model [16] defines the concepts of service, device,
and person as the data elements that are used to model the state of a
presentity. (The term "presentity" is defined in RFC 2778 [5] and
abbreviates presence entity. A presentity provides presence
information to a presence service.) Services are encoded using the
element, defined in PIDF; devices and persons are represented
by the and XML elements, respectively, defined in
the data model [16]. However, neither PIDF nor the data model
defines presence attributes beyond the status element.
This specification defines additional presence attributes to describe
person, service, and device data elements, summarized as "Rich
Presence Information Data format for presence" (RPID). These
attributes are specified by XML elements that extend the PIDF
element and the and elements defined in the data
model.
This extension has two main goals:
1. Provide rich presence information that is at least as powerful as
common commercial presence systems. Such feature-parity
simplifies transition to systems complying with the Common
Profile for Instant Messaging (CPIM) [14], both in terms of user
acceptance and protocol conversion.
2. Maintain backward-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 as to how the information in the RPID elements
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 personal calendars, the status of
communication devices such as telephones, typing activity, and
Schulzrinne, et al. Standards Track [Page 3]
RFC 4480 RIPD July 2006
physical presence detectors as commonly found in energy-management
systems.
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 [13].
The information in a presence document can be generated by a single
entity or can be composed from information published by multiple
entities.
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
the watcher. For example, it may merge presence information from
multiple presence user agents, 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 [15], that
govern the actual communications behavior of the presentity. Details
are described in the data model document.
Since RPID is a PIDF XML document, it also uses the content type
application/pidf+xml.
2. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP model
document [5]. 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, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC 2119 [1].
3. RPID Elements
3.1. Overview
Some of the RPID elements describe services, some devices, and some
the person. As such, they either extend , , or
, respectively. Below, we summarize the RPID elements. The
next sections will then provide more detailed descriptions.
Schulzrinne, et al. Standards Track [Page 4]
RFC 4480 RIPD July 2006
activities: The status element enumerates what the
person is doing.
class: An identifier that groups similar person elements, devices,
or services.
deviceID: A device identifier in a tuple references a
element, indicating that this device contributes to the service
described by the tuple.
mood: The status element indicates the mood of the person.
place-is: The status element reports on the properties of
the place the presentity is currently at, such as the levels of
light and noise.
place-type: The status elements reports the type of
place the person is located in, such as 'classroom' or 'home'.
privacy: The element distinguishes whether the
communication service is likely to be observable by other parties.
relationship: When a service is likely to reach a user besides the
person associated with the presentity, the relationship indicates
how that user relates to the person.
service-class: The element describes whether the
service is delivered electronically, is a postal or delivery
service, or describes in-person communications.
sphere: The element characterizes the overall current role
of the presentity.
status-icon: The element depicts the current status of
the person or service.
time-offset: The status element quantifies the time
zone the person is in, expressed as the number of minutes away
from UTC.
user-input: The element records the user-input or usage
state of the service or device, based on human user input.
The 'From/until?' column in Table 1 indicates by an 'x' that the
element can take 'from' and 'until' attributes. An 'x' in the
'Note?' column marks elements that can include a element. The
usage of these elements within the , , and
elements is shown in columns 4 through 6. An 'x' in the respective
Schulzrinne, et al. Standards Track [Page 5]
RFC 4480 RIPD July 2006
column indicates that the RPID element MAY appear as a child of that
element.
+-----------------+------------+------+----------+---------+----------+
| Element | From/until | Note | | | |
| | ? | ? | | | |
+-----------------+------------+------+----------+---------+----------+
| | x | x | x | | |
| | | | x | x | x |
| | | | | x | |
| | x | x | x | | |
| | x | x | x | | |
| | x | x | x | | |
| | x | x | x | x | |
| | | x | | x | |
| | | x | | x | |
| | x | | x | | |
| | x | | x | x | |
| | x | | x | | |
| | | | x | x | x |
+-----------------+------------+------+----------+---------+----------+
Table 1
In general, it is 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. In either case, there is no guarantee
that the information is accurate, as users forget to update calendars
or may not always adjust the presence information manually.
The namespace URIs for these elements defined by this specification
are URNs [2], using the namespace identifier 'ietf' defined by [4]
and extended by [6]:
urn:ietf:params:xml:ns:pidf:rpid
The elements marked with the value 'x' in column 2 of Table 1 MAY be
qualified with the 'from' and 'until' attributes to describe the
absolute time when the element assumed this value and the absolute
time until which this element is expected to be valid. Note that
there can be multiple elements of the same type, whose time ranges
SHOULD NOT overlap.
Elements MAY contain an 'id' attribute that allows to uniquely
reference the element.
Schulzrinne, et al. Standards Track [Page 6]
RFC 4480 RIPD July 2006
Enumerations can be extended by elements from other namespaces, as
described in Section 6. The , , and
elements can also take elements containing text, for custom
free-text values specific to an application.
All elements described in this document are optional within PIDF
documents.
3.2. Activities Element
The element describes what the person is currently
doing, expressed as an enumeration of activity-describing elements.
A person can be engaged in multiple activities at the same time,
e.g., traveling and having a meal. The element 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 person. The activity indications
correspond roughly to the category field in calendar entries, such as
Section 4.8.1.2 of RFC 2445 [13].
An activities enumeration consists of one or more elements using
elements drawn from the list below, a string enclosed in the
element, or IANA-registered values from other namespaces (Section 7).
If a person publishes an activity of "permanent-absence", it is
likely that all services will report a status of CLOSED. In general,
services MAY advertise either service status for any activity value.
Activities such as , , , ,
, , , , , or
can often be derived from calendar information.
appointment: The person has a calendar appointment, without
specifying exactly of what type. This activity is indicated if
more detailed information is not available or the person chooses
not to reveal more information.
away: The person is physically away from all interactive
communication devices. This activity element was included since
it can often be derived automatically from security systems,
energy management systems, or entry badge systems. Although this
activity would typically be associated with a status of CLOSED
across all services, a person may declare himself or herself away
Schulzrinne, et al. Standards Track [Page 7]
RFC 4480 RIPD July 2006
to discourage communication, but indicate that he or she still can
be reached if needed. However, communication attempts might reach
an answering service, for example.
breakfast: The person is eating the first meal of the day, usually
eaten in the morning.
busy: The person is busy, without further details. Although this
activity would typically be associated with a status of CLOSED
across all services, a person may declare himself or herself busy
to discourage communication, but indicate that he or she still can
be reached if needed.
dinner: The person is having his or her main meal of the day, eaten
in the evening or at midday.
holiday: This is a scheduled national or local holiday.
in-transit: The person is riding in a vehicle, such as a car, but
not steering. The element provides more specific
information about the type of conveyance the person is using.
looking-for-work: The presentity is looking for (paid) work.
lunch: The person is eating his or her midday meal.
meal: The person is scheduled for a meal, without specifying whether
it is breakfast, lunch, or dinner, or some other meal.
meeting: The person is in an assembly or gathering of people, as for
a business, social, or religious purpose. A meeting is a sub-
class of an appointment.
on-the-phone: The person is talking on the telephone. This activity
is included since it can often be derived automatically.
other: The person is engaged in an activity with no defined
representation as an element. The enclosed string
describes the activity in plain text.
performance: A performance is a sub-class of an appointment and
includes musical, theatrical, and cinematic performances as well
as lectures. It is distinguished from a meeting by the fact that
the person may either be lecturing or be in the audience, with a
potentially large number of other people, making interruptions
particularly noticeable.
Schulzrinne, et al. Standards Track [Page 8]
RFC 4480 RIPD July 2006
permanent-absence: The person will not return for the foreseeable
future, e.g., because it is no longer working for the company.
This activity is associated with a status of CLOSED across all
services.
playing: The person is occupying himself or herself in amusement,
sport, or other recreation.
presentation: The person is giving a presentation, lecture, or
participating in a formal round-table discussion.
shopping: The person is visiting stores in search of goods or
services.
sleeping: This activity category can often be generated
automatically from a calendar, local time information, or
biometric data.
spectator: The person is observing an event, such as a sports event.
steering: The person is controlling a vehicle, watercraft, or plane.
travel: The person is on a business or personal trip, but not
necessarily in-transit.
tv: The person is watching television.
unknown: The activity of the person is unknown. This element is
generally not used together with other activities.
vacation: A period of time devoted to pleasure, rest, or relaxation.
working: The presentity is engaged in, typically paid, labor, as
part of a profession or job.
worship: The presentity is participating in religious rites.
The element MAY be qualified with the 'from' and 'until'
attributes as described in Section 3.1.
Example:
Enjoying the morning paper
reading
Schulzrinne, et al. Standards Track [Page 9]
RFC 4480 RIPD July 2006
3.3. Class Element
The element describes the class of the service, device, or
person. Multiple elements can have the same class name within a
presence document, but each person, service, or device can only have
one class label. The naming of classes is left to the presentity.
The presentity can use this information to group similar services,
devices, or person elements or to convey information that the
presence agent can use for filtering or authorization. This
information is not generally presented to the watcher user interface.
The element MUST NOT be qualified with the 'from' and 'until'
attributes as described in Section 3.1.
3.4. Device Identifier
The element in the element references the device
that provides a particular service. The element is defined
syntactically in the data model [16] schema. One service can be
provided by multiple devices, so that each service tuple may contain
zero or more elements. There is no significance in the
order of these elements.
The element MUST NOT be qualified with the 'from' and
'until' attributes as described in Section 3.1.
3.5. Mood Element
The element describes the mood of the presentity. The mood
values are enumerated chosen by the presentity. The mood itself is
provided as the element name of a defined child element of the
element (e.g., child of the element, which is
OPTIONAL. (This definition follows the Jabber Extension JEP-107.)
It is RECOMMENDED that an implementation support the mood values
proposed in Jabber Extension JEP-0107, which in turn are a superset
of the Wireless Village [18] mood values and the values enumerated in
the Affective Knowledge Representation that has been defined by
Lisetti [17]:
A mood enumeration consists of one or more elements using elements
drawn from the list below, a string enclosed in the element,
or IANA-registered values from other namespaces (Section 7).
The element MAY be qualified with the 'from' and 'until'
attributes as described in Section 3.1.
Schulzrinne, et al. Standards Track [Page 10]
RFC 4480 RIPD July 2006
o afraid
o amazed
o angry
o annoyed
o anxious
o ashamed
o bored
o brave
o calm
o cold
o confused
o contented
o cranky
o curious
o depressed
o disappointed
o disgusted
o distracted
o embarrassed
o excited
o flirtatious
o frustrated
o grumpy
o guilty
o happy
o hot
o humbled
o humiliated
o hungry
o hurt
o impressed
o in_awe
o in_love
o indignant
o interested
o invincible
o jealous
o lonely
o mean
o moody
o nervous
o neutral
o offended
o other
o playful
o proud
o relieved
o remorseful
Schulzrinne, et al. Standards Track [Page 11]
RFC 4480 RIPD July 2006
o restless
o sad
o sarcastic
o serious
o shocked
o shy
o sick
o sleepy
o stressed
o surprised
o thirsty
o unknown
o worried
Example:
I'm ready for the bar BOF!
3.6. Place-is Element
The element describes properties of the place the person
is currently at. This offers the watcher an indication of what kind
of communication is likely to be successful. Each major media type
has its own set of attributes. Omitting the element indicates that
the property is unknown.
For audio, we define the following attributes:
noisy: The person is in a place with a level of background noise
that makes audio communications difficult.
ok: The environmental conditions are suitable for audio
communications.
quiet: The person is in a place such as a library, restaurant, place
of worship, or theater that discourages noise, conversation, and
other distractions.
unknown: The place attributes for audio are unknown.
For video, we define the following attributes:
toobright: The person is in a bright place, sufficient for good
rendering on video.
Schulzrinne, et al. Standards Track [Page 12]
RFC 4480 RIPD July 2006
ok: The environmental conditions are suitable for video.
dark: The person is in a dark place, and thus the camera may not be
able to capture a good image.
unknown: The place attributes for video are unknown.
For text (real-time text and instant messaging), we define
uncomfortable: Typing or other text entry is uncomfortable.
inappropriate: Typing or other text entry is inappropriate, e.g.,
since the user is in a vehicle or house of worship.
ok: The environmental conditions are suitable for text-based
communications.
unknown: The place attributes for text are unknown.
This list can be augmented by free-text values in a note or
additional IANA-registered values (Section 7).
The element contains other elements, e.g.,
The element MAY be qualified with the 'from' and 'until'
attributes as described in Section 3.1.
3.7. Place-type Element
The element describes the type of place the person is
currently at. This offers the watcher an indication of what kind of
communication is likely to be appropriate. The initial set of values
is contained in RFC 4589 [12].
This list can be augmented by free-text values or additional IANA-
registered values as described in RFC 4589.
Schulzrinne, et al. Standards Track [Page 13]
RFC 4480 RIPD July 2006
The element is a choice of elements, as in
The element MAY be qualified with the 'from' and 'until'
attributes as described in Section 3.1.
3.8. Privacy Element
The element indicates which types of communication third
parties in the vicinity of the presentity are unlikely to be able to
intercept accidentally or intentionally. This does not in any way
describe the privacy properties of the electronic communication
channel, e.g., properties of the encryption algorithm or the network
protocol used.
audio: Inappropriate individuals are not likely to overhear audio
communications.
text: Inappropriate individuals are not likely to see text
communications.
unknown: This information is unknown.
video: Inappropriate individuals are not likely to see video
communications.
The 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 "private" to a select subset of the watchers.
The element MAY be qualified with the 'from' and 'until'
attributes as described in Section 3.1.
Example:
Schulzrinne, et al. Standards Track [Page 14]
RFC 4480 RIPD July 2006
3.9. Relationship Element
The element extends and 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", "friend",
"associate" (e.g., for a colleague), "assistant", "supervisor",
"self", and "unknown". The default is "self".
If a relationship is indicated, the URI in the element
refers to the entity, such as the assistant, that has a relationship
to the presentity, not the presentity itself.
Like tuples without a qualifier, 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".
Example:
3.10. Service Class
The element extends and designates the type
of service offered.
electronic: Delivery of information by electronic means, i.e.,
without delivering physical objects. Examples include telephone,
fax, email, instant messaging, and SMS.
postal: Delivery by the postal service, e.g., as a letter, parcel,
or postcard. Delivery could be to a post office box or central
mailroom rather than the presentity's office location, for
example.
courier: Delivery by messenger, overnight delivery, or courier.
Courier-delivered messages are usually delivered to a receptionist
rather than, say, a mailroom or receiving department.
freight: Delivery by freight carrier, typically of larger objects
that are not sent by postal mail or courier. The recipient is
often the shipping department or a loading dock.
in-person: Describes the coordinates for visits in person, as by a
visitor, i.e., usually somebody's office or residence.
Schulzrinne, et al. Standards Track [Page 15]
RFC 4480 RIPD July 2006
unknown: The type of service is unknown.
Electronic service is implied if omitted. The service types
'postal', 'courier', 'freight', and 'in-person' MUST NOT be used
unless the contact URI is empty. Additional data elements defined
elsewhere describe the physical service delivery address for the in-
person, postal, or delivery services. Such addresses might be
specified in geospatial coordinates, civic addresses, or some
specialized address format, e.g., for interstellar addresses or a
company-specific delivery system.
Example:
element designates the current state and role that the
person plays. For example, it might describe whether the person is
in a work mode, at home, or participating in activities related to
some other organization such as the IETF or a church. This document
does not define names for these spheres except for two common ones,
"work" and "home", as well as "unknown".
Spheres allow the person to easily turn on or off certain rules that
depend on what groups of people should be made aware of the person's
status. For example, if the person is a Boy Scout leader, he might
set the sphere to "scouting" and then have a rule set that allows
other scout masters in his troop to see his presence status. As soon
as he switches his status to "work", "home", or some other sphere,
the fellow scouts would lose access.
The element MAY be qualified with the 'from' and 'until'
attributes as described in Section 3.1.
Example:
3.12. Status-Icon Element
The element includes a URI pointing to an image (icon)
representing the current status of the person or service. The
watcher MAY use this information to represent the status in a
graphical user interface. Presentities SHOULD provide images of
Schulzrinne, et al. Standards Track [Page 16]
RFC 4480 RIPD July 2006
sizes and aspect ratios that are appropriate for rendering as an
icon. Support for JPEG, PNG, and GIF formats is RECOMMENDED.
Watchers resolving the URI MUST validate whether the local copy of
the icon is current when receiving a notification, using the standard
cache control mechanism in the URI-identified retrieval protocol.
Example:
http://www.example.com/playing.gif
3.13. Time Offset
The element describes the number of minutes of offset
from UTC at the person's current location. A positive number
indicates that the local time-of-day is ahead (i.e., east of)
Universal Time, while a negative number indicates that the local
time-of-day is behind (i.e., west of) Universal Time. Transitions
into and out of daylight savings time may temporarily cause a
difference between the true offset from UTC and the time offset
element.
An optional attribute, description, can be used to describe the
offset, e.g., by labeling the time zone. This description is meant
for human consumption.
Publishers on mobile devices SHOULD NOT publish this information
unless they know the time offset information to reflect the current
location. (For example, many laptop users do not update their time
zone when traveling.) Publishers SHOULD update the information
whenever they discover that their UTC offset has changed.
Example:
-300
3.14. User-Input Element
The element records the user-input or usage state of the
service or device, based on human user input, e.g., keyboard,
pointing device, or voice. If contained in a element, it
summarizes any user input activity across all services and devices
operated by the presentity. The mechanism for such aggregation is
beyond the scope of this document, but generally reflects the most
recent user input across all devices and services. The element can
assume one of two values, namely, 'active' or 'idle', with an
optional 'last-input' attribute that records when the last user input
Schulzrinne, et al. Standards Track [Page 17]
RFC 4480 RIPD July 2006
was received. An optional 'idle-threshold' element records how long
the presentity will wait before reporting the service or device to be
idle, measured in seconds.
(A two-state model was chosen since it would otherwise be necessary
to send repeated last-input updates during continuous activity.)
A service that wants to indicate user input activity sends a 'active' indication when the user has provided user input
within a configurable interval of time, the idle-threshold. If the
user ceases to provide input and the idle-threshold has elapsed, the
tuple is marked with a 'idle' indication instead,
optionally including the time of last activity in the 'last-input'
attribute. An example is below:
idle
Depending on device or service capabilities, user input may be
detected only for a particular application, i.e., when the
application has user focus or when a user has sent a message or
placed a call, or can be based on user input across all applications
running on one end system.
The element may be used by a watcher, typically in
combination with other data, to estimate how likely a user is to
answer when contacting the service. A tuple that has not been used
in a while may still be OPEN, but a watcher may choose to first
contact a URI in a tuple that is both OPEN and has been used more
recently.
The attribute can be omitted 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, as in the following:
idle
Configuration MUST include the option to omit the 'last-input'
attribute.
4. Example
The example below describes the presentity
'pres:someone@example.com', which has a SIP contact,
'sip:someone@example.com', representing a service. It also has a
device contact, as an email box. The presentity is in a meeting, in
a public office setting. The 'until' information indicates that he
will be there until 5:30 pm local time. The presentity also has an
Schulzrinne, et al. Standards Track [Page 18]
RFC 4480 RIPD July 2006
assistant, sip:secretary@example.com, who happens to be available for
communications.
open
urn:device:0003ba4811e3
im:someone@mobile.example.net
Don't Disturb Please!
Ne derangez pas, s'il vous plait
2005-10-27T16:49:29Z
open
mailto:secretary@example.com
open
urn:x-mac:0003ba4811e3
email
http://example.com/mail.png
mailto:someone@example.com
I'll be in Tokyo next week
idle
urn:device:0003ba4811e3
Schulzrinne, et al. Standards Track [Page 19]
RFC 4480 RIPD July 2006
PC
Far away
calendar
brooding
bowling league
http://example.com/play.gif
-240
Scoring 120
2005-05-30T16:09:44+05:00
5. XML Schema Definitions
The RPID schema is shown below. Due to limitations in composing
schemas, not all XML documents that validate against the schema below
are semantically valid RPID documents. In particular, the schema
allows each element to appear anyhere in PIDF or data-model elements;
Table 1 restricts where these elements can appear for semantically
valid RPID documents. Elements that do not have from/until
parameters MUST NOT appear more than once in each , ,
or .
5.1. urn:ietf:params:xml:ns:pidf:rpid
Describes what the person is currently doing, expressed as
an enumeration of activity-describing elements. A person
can be engaged in multiple activities at the same time,
e.g., traveling and having a meal.
Describes the class of the service, device or person.
Schulzrinne, et al. Standards Track [Page 22]
RFC 4480 RIPD July 2006
Describes the mood of the presentity.
Schulzrinne, et al. Standards Track [Page 26]
RFC 4480 RIPD July 2006
Describes the type of place the person is currently at.
Indicates which type of communication third parties in the
vicinity of the presentity are unlikely to be able to
intercept accidentally or intentionally.
Schulzrinne, et al. Standards Track [Page 27]
RFC 4480 RIPD July 2006
Designates the type of relationship an alternate contact
has with the presentity.
Designates the type of service offered.
Schulzrinne, et al. Standards Track [Page 28]
RFC 4480 RIPD July 2006
Designates the current state and role that the person plays.
A URI pointing to an image (icon) representing the current
status of the person or service.
Describes the number of minutes of offset from UTC at the
user's current location.
Schulzrinne, et al. Standards Track [Page 29]
RFC 4480 RIPD July 2006
Records the user-input or usage state of the service or
device.
6. Extending RPID
Any developer can introduce their own element names, avoiding
conflict by choosing an appropriate namespace URI. To add new
standardized elements to the enumerations , ,
, and , the extension process
described in PIDF [9] is followed, i.e., such extensions would use
namespace designators such as urn:ietf:params:xml:ns:pidf:ext, where
'ext' is the name of the extension. Any new values for the element are assigned according to [12] and are given a
namespace designator at their time of registration.
Schulzrinne, et al. Standards Track [Page 30]
RFC 4480 RIPD July 2006
To avoid the unnecessary proliferation of XML namespaces containing a
single element, groups of element registrations for each of these
enumerations, such as , SHOULD be bundled into a single
namespace rather than assigning a new namespace to each new element.
7. IANA Considerations
7.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid'
URI: urn:ietf:params:xml:ns:pidf:rpid
Description: This is the XML namespace for XML elements defined by
RFC 4480 to describe rich presence information extensions for the
status element in the PIDF presence document format in the
application/pidf+xml content type.
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
Henning Schulzrinne, hgs@cs.columbia.edu
XML:
BEGIN
RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)
Namespace for rich presence extension
urn:ietf:params:xml:ns:pidf:rpid
See
RFC&4480;.