RPID: Rich Presence Extensions to the Presence Inf

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.

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
   <presence> root element, zero or more <tuple> elements carrying
   presence information including a Uniform Resource Identifier (URI)
   for communication, zero or more <note> elements, and zero or more
   extension elements from other name spaces.  Each tuple defines a
   basic status of either "open" or "closed".

   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 <note> 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
   <tuple> element, defined in PIDF; devices and persons are represented
   by the <device> and <person> XML elements, respectively, defined in
   the data model [16].  However, neither PIDF nor the data model
   defines presence attributes beyond the <basic> 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 <tuple>
   element and the <device> and <person> 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

   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 <tuple>, <device>, or
   <person>, respectively.  Below, we summarize the RPID elements.  The
   next sections will then provide more detailed descriptions.

   activities:  The <activities> 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 <device>
      element, indicating that this device contributes to the service
      described by the tuple.

   mood:  The <mood> status element indicates the mood of the person.

   place-is:  The <place-is> 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 <place-type> status elements reports the type of
      place the person is located in, such as ’classroom’ or ’home’.

   privacy:  The <privacy> 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 <service-class> element describes whether the
      service is delivered electronically, is a postal or delivery
      service, or describes in-person communications.

   sphere:  The <sphere> element characterizes the overall current role
      of the presentity.

   status-icon:  The <status-icon> element depicts the current status of
      the person or service.

   time-offset:  The <time-offset> status element quantifies the time
      zone the person is in, expressed as the number of minutes away
      from UTC.

   user-input:  The <user-input> 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 <note> element.  The
   usage of these elements within the <person>, <tuple>, and <device>
   elements is shown in columns 4 through 6.  An ’x’ in the respective

   column indicates that the RPID element MAY appear as a child of that
   element.

 +-----------------+------------+------+----------+---------+----------+
 | Element         | From/until | Note | <person> | <tuple> | <device> |
 |                 | ?          | ?    |          |         |          |
 +-----------------+------------+------+----------+---------+----------+
 | <activities>    |      x     |   x  |     x    |         |          |
 | <class>         |            |      |     x    |    x    |     x    |
 | <deviceID>      |            |      |          |    x    |          |
 | <mood>          |      x     |   x  |     x    |         |          |
 | <place-is>      |      x     |   x  |     x    |         |          |
 | <place-type>    |      x     |   x  |     x    |         |          |
 | <privacy>       |      x     |   x  |     x    |    x    |          |
 | <relationship>  |            |   x  |          |    x    |          |
 | <service-class> |            |   x  |          |    x    |          |
 | <sphere>        |      x     |      |     x    |         |          |
 | <status-icon>   |      x     |      |     x    |    x    |          |
 | <time-offset>   |      x     |      |     x    |         |          |
 | <user-input>    |            |      |     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.

   Enumerations can be extended by elements from other namespaces, as
   described in Section 6.  The <activities>, <mood>, and <place-type>
   elements can also take <other> 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 <activities> 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 <activities> 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 <other>
   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 <appointment>, <breakfast>, <dinner>, <holiday>,
   <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation>
   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

      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 <place-type> 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 <activities> 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.

   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 <activities> element MAY be qualified with the ’from’ and ’until’
   attributes as described in Section 3.1.

   Example:

     <activities>
       <note>Enjoying the morning paper</note>
       <vacation/>
       <breakfast/>
       <other>reading</other>
     </activities>

3.3.  Class Element

   The <class> 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 <class> element MUST NOT be qualified with the ’from’ and ’until’
   attributes as described in Section 3.1.

3.4.  Device Identifier

   The <deviceID> element in the <tuple> 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 <deviceID> elements.  There is no significance in the
   order of these elements.

   The <deviceID> element MUST NOT be qualified with the ’from’ and
   ’until’ attributes as described in Section 3.1.

3.5.  Mood Element

   The <mood> 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 <mood>
   element (e.g., <happy/>); one such child element is REQUIRED.  The
   user MAY also specify a natural-language description of, or reason
   for, the mood in the <note> child of the <mood> 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 <other> element,
   or IANA-registered values from other namespaces (Section 7).

   The <mood> element MAY be qualified with the ’from’ and ’until’
   attributes as described in Section 3.1.

   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

   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:

     <mood>
       <note>I’m ready for the bar BOF!</note>
       <sleepy/>
       <thirsty/>
     </mood>

3.6.  Place-is Element

   The <place-is> 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.

   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 <place-is> element contains other elements, e.g.,

     <place-is>
       <audio>
         <noisy />
       </audio>
       <video>
         <dark />
       </video>
     </place-is>

   The <place-is> element MAY be qualified with the ’from’ and ’until’
   attributes as described in Section 3.1.

3.7.  Place-type Element

   The <place-type> 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.

   The <place-type> element is a choice of elements, as in

     <place-type>
          <pt:street/>
     </place-type>

   The <place-type> element MAY be qualified with the ’from’ and ’until’
   attributes as described in Section 3.1.

3.8.  Privacy Element

   The <privacy> 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 <privacy> 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 <privacy> element MAY be qualified with the ’from’ and ’until’
   attributes as described in Section 3.1.

   Example:

     <privacy>
       <text/>
       <audio/>
     </privacy>

3.9.  Relationship Element

   The <relationship> element extends <tuple> 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 <contact> element
   refers to the entity, such as the assistant, that has a relationship
   to the presentity, not the presentity itself.

   Like tuples without a <relationship&