Skip to main content

RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
draft-ietf-simple-rpid-10

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4480.
Authors Paul Kyzivat , Vijay K. Gurbani , Henning Schulzrinne , Jonathan Rosenberg
Last updated 2020-01-21 (Latest revision 2005-12-21)
Replaces draft-ietf-simple-rpids
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4480 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ted Hardie
Send notices to (None)
draft-ietf-simple-rpid-10
SIMPLE                                                    H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: June 23, 2006                                        V. Gurbani
                                                                  Lucent
                                                              P. Kyzivat
                                                            J. Rosenberg
                                                                   Cisco
                                                       December 20, 2005

 RPID: Rich Presence Extensions to the Presence Information Data Format
                                 (PIDF)
                       draft-ietf-simple-rpid-10

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 23, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Presence Information Data Format (PIDF) defines a basic format
   for representing presence information for a presentity.  That format
   defines a textual note, an indication of availability (open or

Schulzrinne, et al.       Expires June 23, 2006                 [Page 1]
Internet-Draft                    RPID                     December 2005

   closed) and a Universal 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.       Expires June 23, 2006                 [Page 2]
Internet-Draft                    RPID                     December 2005

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Terminology and Conventions  . . . . . . . . . . . . . . . .   5
   3.   RPID Elements  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2  Activities Element . . . . . . . . . . . . . . . . . . . .   8
     3.3  Class Element  . . . . . . . . . . . . . . . . . . . . . .  10
     3.4  Device Identifier  . . . . . . . . . . . . . . . . . . . .  10
     3.5  Mood Element . . . . . . . . . . . . . . . . . . . . . . .  11
     3.6  Place-is Element . . . . . . . . . . . . . . . . . . . . .  13
     3.7  Place-type Element . . . . . . . . . . . . . . . . . . . .  14
     3.8  Privacy Element  . . . . . . . . . . . . . . . . . . . . .  16
     3.9  Relationship Element . . . . . . . . . . . . . . . . . . .  17
     3.10   Service Class  . . . . . . . . . . . . . . . . . . . . .  18
     3.11   Sphere Element . . . . . . . . . . . . . . . . . . . . .  18
     3.12   Status-Icon Element  . . . . . . . . . . . . . . . . . .  19
     3.13   Time Offset  . . . . . . . . . . . . . . . . . . . . . .  19
     3.14   User-Input Element . . . . . . . . . . . . . . . . . . .  20
   4.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   5.   XML Schema Definitions . . . . . . . . . . . . . . . . . . .  23
     5.1  urn:ietf:params:xml:ns:pidf:rpid . . . . . . . . . . . . .  23
   6.   Extending RPID . . . . . . . . . . . . . . . . . . . . . . .  34
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  34
     7.1  URN Sub-Namespace Registration for
          'urn:ietf:params:xml:ns:pidf:rpid' . . . . . . . . . . . .  34
     7.2  Schema Registration for Schema
          urn:ietf:params:xml:ns:pidf:status:rpid' . . . . . . . . .  35
   8.   Internationalization Considerations  . . . . . . . . . . . .  35
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  36
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  36
     10.1   Normative References . . . . . . . . . . . . . . . . . .  36
     10.2   Informative References . . . . . . . . . . . . . . . . .  37
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  38
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  38
        Intellectual Property and Copyright Statements . . . . . . .  40

Schulzrinne, et al.       Expires June 23, 2006                 [Page 3]
Internet-Draft                    RPID                     December 2005

1.  Introduction

   The Presence Information Data Format (PIDF) definition [9] describes
   a basic presence information data format, encoded as an Extensible
   Markup Language (XML) document, for exchanging presence information
   in systems compliant with the common model for presence and instant
   messaging [6].  It consists of a <presence> root element, zero or
   more <tuple> elements carrying presence information including a
   Universal 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.  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 [14] 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 [6] and
   abbreviates presence entity.  A presentity provides presence
   information to a presence service.  It is typically a uniquely-
   identified person.)  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 the data
   model [14].  However, neither PIDF nor the data model define 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 which 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

Schulzrinne, et al.       Expires June 23, 2006                 [Page 4]
Internet-Draft                    RPID                     December 2005

       Profile for Instant Messaging (CPIM) [12], 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 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 [11].

   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 [13], 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 [6].  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

Schulzrinne, et al.       Expires June 23, 2006                 [Page 5]
Internet-Draft                    RPID                     December 2005

   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.
   device-id: 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 elements 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 a '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.

Schulzrinne, et al.       Expires June 23, 2006                 [Page 6]
Internet-Draft                    RPID                     December 2005

   +------------+----------+----------+----------+----------+----------+
   | Element    | From/unt |   Note?  | <person> |  <tuple> | <device> |
   |            |    il?   |          |          |          |          |
   +------------+----------+----------+----------+----------+----------+
   | <activitie |     x    |     x    |     x    |          |          |
   | s>         |          |          |          |          |          |
   | <class>    |          |          |     x    |     x    |     x    |
   | <device-id |          |          |          |     x    |          |
   | >          |          |          |          |          |          |
   | <mood>     |     x    |     x    |     x    |          |          |
   | <place-is> |     x    |     x    |     x    |          |          |
   | <place-typ |     x    |     x    |     x    |          |          |
   | e>         |          |          |          |          |          |
   | <privacy>  |     x    |     x    |     x    |     x    |          |
   | <relations |          |     x    |          |     x    |          |
   | hip>       |          |          |          |          |          |
   | <service-c |          |     x    |          |     x    |          |
   | lass>      |          |          |          |          |          |
   | <sphere>   |     x    |          |     x    |          |          |
   | <status-ic |     x    |          |     x    |     x    |          |
   | on>        |          |          |          |          |          |
   | <time-offs |     x    |          |     x    |          |          |
   | et>        |          |          |          |          |          |
   | <user-inpu |          |          |     x    |     x    |     x    |
   | t>         |          |          |          |          |          |
   +------------+----------+----------+----------+----------+----------+

                                  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 [5]
   and extended by [7]:

      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 is element is expected to be valid.  Note that there

Schulzrinne, et al.       Expires June 23, 2006                 [Page 7]
Internet-Draft                    RPID                     December 2005

   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 [11].

   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.  While this
      activity would typically be associated with a status of CLOSED
      across all services, a person may declare itself away to

Schulzrinne, et al.       Expires June 23, 2006                 [Page 8]
Internet-Draft                    RPID                     December 2005

      discourage communication, but indicate that it 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.  While this
      activity would typically be associated with a status of CLOSED
      across all services, a person may declare itself busy to
      discourage communication, but indicate that it 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.

Schulzrinne, et al.       Expires June 23, 2006                 [Page 9]
Internet-Draft                    RPID                     December 2005

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

Schulzrinne, et al.       Expires June 23, 2006                [Page 10]
Internet-Draft                    RPID                     December 2005

   syntactically in the data model [14] 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.  They 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 <text> 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 [16] mood values and the values enumerated in the
   Affective Knowledge Representation that has been defined by Lisetti
   [15]:

   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 <activities> element MAY be qualified with the 'from' and 'until'
   attributes as described in Section 3.1.
      afraid
      amazed
      angry
      annoyed
      anxious
      ashamed
      bored
      brave
      calm
      cold
      confused
      contented
      cranky
      curious
      depressed
      disappointed
      disgusted

Schulzrinne, et al.       Expires June 23, 2006                [Page 11]
Internet-Draft                    RPID                     December 2005

      distracted
      embarrassed
      excited
      flirtatious
      frustrated
      grumpy
      guilty
      happy
      hot
      humbled
      humiliated
      hungry
      hurt
      impressed
      in_awe
      in_love
      indignant
      interested
      invincible
      jealous
      lonely
      mean
      moody
      nervous
      neutral
      offended
      other
      playful
      proud
      relieved
      remorseful
      restless
      sad
      sarcastic
      serious
      shocked
      shy
      sick
      sleepy
      stressed
      surprised
      thirsty
      unknown
      worried

   Example:

Schulzrinne, et al.       Expires June 23, 2006                [Page 12]
Internet-Draft                    RPID                     December 2005

     <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 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
      be able to capture a good image.
   unknown: The place attributes for video are unknown.

   For text, we define the following attributes:

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

Schulzrinne, et al.       Expires June 23, 2006                [Page 13]
Internet-Draft                    RPID                     December 2005

   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 what kind of
   communication is likely to be appropriate.  We define an initial set
   of values below:

   aircraft: The person is traveling in a plane, helicopter or balloon.
   airport: The person is located in an airport, heliport or similar
      location.
   arena: The person is in an enclosed area used for sports events.
   automobile: The person is in a self-propelled passenger vehicle.
   bank: The person is in a business establishment in which money is
      kept for saving or commercial purposes or is invested, supplied
      for loans, or exchanged.
   bar: The person is in a bar or saloon.
   bus: The person is traveling in a public or charter bus.
   bus-station: The person is in a terminal that serves bus passengers;
      bus depot or bus terminal.
   cafe: The person is in a cafe or coffeeshop.
   classroom: The person is in an academic classroom or lecture hall.
   club: The person is in a dance club or discotheque.
   construction: The person is on a construction site.
   convention-center: The person is in a convention center.
   cycle: The person is riding a bicycle, motorcycle or similar vehicle.
   government-building: The person is in a government building, such as
      those used by the legislative, executive, or judicial branches of
      governments, including court houses, police stations and military
      installations.

Schulzrinne, et al.       Expires June 23, 2006                [Page 14]
Internet-Draft                    RPID                     December 2005

   hospital: The person is in a hospital, hospice, medical clinic,
      mental institution, or doctor's office.
   hotel: The person is in a hotel, motel, inn or other lodging
      establishment.
   industrial: The person is in an industrial setting, such as a
      manufacturing floor or power plant.
   library: The person is in a library or other public place which
      literary and artistic materials, such as books, periodicals,
      newspapers, pamphlets, prints, records, and tapes, are kept for
      reading, reference, or lending.
   office: The person is in a business setting, such as an office.
   outdoors: The person is in a general outdoor area, such as a park or
      city streets.
   other: The person is in a place without a <place-type>
      representation.  The enclosed string describes the type of place.
   parking: The person is in a parking lot or parking garage.
   place-of-worship: A building where congregations gather for religious
      observances, such as a church, chapel, meetinghouse, mosque,
      shrine, synagogue, or temple.
   prison: The person is in a prison, penitentiary, jail, brig, or
      criminal mental institution.
   public: The person 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.  This general
      description encompasses the more precise descriptors "street",
      "public-transport", "aircraft", "ship", "bus", "train", "airport",
      "mall" and "outdoors".
   public-transport: The person is using any form of public transport,
      including aircraft, bus, train or ship.
   residence: The person is in a private or residential setting, not
      necessarily the personal residence of the person, e.g., a friend's
      home.
   restaurant: The person is in a restaurant or other public dining
      establishment.
   school: The person is in a school or university, but not necessarily
      in a classroom or library.
   shopping-area: The person is frequenting a shopping mall or shopping
      area, i.e., a large, often enclosed shopping complex containing
      various stores, businesses, and restaurants usually accessible by
      common passageways.
   stadium: The person is in a large, usually open structure for sports
      events, including a racetrack.
   store: The person is located in a place where merchandise is offered
      for sale; a shop.

Schulzrinne, et al.       Expires June 23, 2006                [Page 15]
Internet-Draft                    RPID                     December 2005

   street: The person is walking in a street.
   theater: The person is in a theater, lecture hall, auditorium,
      circus, class room, movie theater or similar facility designed for
      presentations, talks, plays, movies, music performances and other
      events involving an audience.
   train: The person is traveling in a train, monorail, maglev, cable
      car or similar conveyance.
   train-station: The person is in a terminal where trains load or
      unload passengers or goods; railway station, railroad station,
      railroad terminal, train depot.
   truck: The person is in a truck, used primarily to carry goods rather
      than people.
   underway: The person is in a land, water, or air craft which is under
      way (in motion).
   unknown: The type of place is unknown.
   warehouse: The person is in a place in which goods or merchandise are
      stored; a storehouse or self-storage facility.
   water: The person is on water, such as an ocean, lake, river, canal
      or other waterway.
   watercraft: The person is traveling in a boat or ship.

   This list can be augmented by free-text values or additional IANA-
   registered values (Section 7).

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

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

Schulzrinne, et al.       Expires June 23, 2006                [Page 16]
Internet-Draft                    RPID                     December 2005

   audio: Audio communication is likely only to be heard by the intended
      recipient.
   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 as "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> qualifier, the <contact> 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:

     <relationship>

Schulzrinne, et al.       Expires June 23, 2006                [Page 17]
Internet-Draft                    RPID                     December 2005

       <friend/>
     </relationship>

3.10  Service Class

   The <service-class> element extends <tuple> 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 mail
      room 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.
   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:

     <service-class><postal/></service-class>

3.11  Sphere Element

   The <sphere> element designates the current state and role that the
   person plays.  For example, it might describe whether the person is
   in a work mode or at home or participating in activities related to
   some other organization such as the IETF or a church.  This document

Schulzrinne, et al.       Expires June 23, 2006                [Page 18]
Internet-Draft                    RPID                     December 2005

   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" or "home" or some other sphere,
   the fellow scouts would lose access.

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

   Example:

     <sphere>
       <home/>
     </sphere>

3.12  Status-Icon Element

   The <status-icon> 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
   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:

     <status-icon>http://www.example.com/playing.gif</status-icon>

3.13  Time Offset

   The <time-offset> 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)

Schulzrinne, et al.       Expires June 23, 2006                [Page 19]
Internet-Draft                    RPID                     December 2005

   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:

     <time-offset description="America/New_York">-300
     </time-offset>

3.14  User-Input Element

   The <user-input> 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 <person> element, it
   summarize 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 has been
   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 <user-
   input> '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 <user-input> 'idle' indication instead,
   optionally including the time of last activity in the 'last-input'

Schulzrinne, et al.       Expires June 23, 2006                [Page 20]
Internet-Draft                    RPID                     December 2005

   attribute.  An example is below:

     <user-input idle-threshold="600"
       last-input="2004-10-21T13:20:00.000-05:00">idle</user-input>

   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 <user-input> 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 <user-input> 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:

     <user-input>idle</user-input>

   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
   assistant, sip:secretary@example.com, who happens to be available for
   communications.

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
     xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
       xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd
     urn:ietf:params:xml:ns:pidf:data-model data-model.xsd
     urn:ietf:params:xml:ns:pidf:rpid rpid.xsd"

Schulzrinne, et al.       Expires June 23, 2006                [Page 21]
Internet-Draft                    RPID                     December 2005

     entity="pres:someone@example.com">

     <tuple id="bs35r9">
       <status>
         <basic>open</basic>
       </status>
       <dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
       <rpid:relationship><rpid:self/></rpid:relationship>
       <rpid:service-class><rpid:electronic/></rpid:service-class>
       <contact priority="0.8">im:someone@mobile.example.net</contact>
       <note xml:lang="en">Don't Disturb Please!</note>
       <note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
       <timestamp>2005-10-27T16:49:29Z</timestamp>
     </tuple>

     <tuple id="ty4658">
       <status>
         <basic>open</basic>
       </status>
       <rpid:relationship><rpid:assistant/></rpid:relationship>
       <contact priority="1.0">mailto:secretary@example.com</contact>
     </tuple>

     <tuple id="eg92n8">
       <status>
         <basic>open</basic>
       </status>
       <dm:deviceID>urn:x-mac:0003ba4811e3</dm:deviceID>
       <rpid:class>email</rpid:class>
       <rpid:service-class><rpid:electronic/></rpid:service-class>
       <rpid:status-icon>http://example.com/mail.png</rpid:status-icon>
       <contact priority="1.0">mailto:someone@example.com</contact>
     </tuple>

     <note>I'll be in Tokyo next week</note>

     <dm:device id="pc147">
       <rpid:user-input idle-threshold="600"
         last-input="2004-10-21T13:20:00-05:00">idle</rpid:user-input>
       <dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
       <dm:note>PC</dm:note>
     </dm:device>

     <dm:person id="p1">
       <rpid:activities from="2005-05-30T12:00:00+05:00"
          until="2005-05-30T17:00:00+05:00">
          <rpid:note>Far away</rpid:note>
          <rpid:away/>

Schulzrinne, et al.       Expires June 23, 2006                [Page 22]
Internet-Draft                    RPID                     December 2005

       </rpid:activities>
       <rpid:class>calendar</rpid:class>
       <rpid:mood>
         <rpid:angry/>
         <rpid:other>brooding</rpid:other>
       </rpid:mood>
       <rpid:place-is>
          <rpid:audio>
             <rpid:noisy/>
          </rpid:audio>
       </rpid:place-is>
       <rpid:place-type><rpid:residence/></rpid:place-type>
       <rpid:privacy><rpid:unknown/></rpid:privacy>
       <rpid:sphere>bowling league</rpid:sphere>
       <rpid:status-icon>http://example.com/play.gif</rpid:status-icon>
       <rpid:time-offset>-240</rpid:time-offset>
       <dm:note>Scoring 120</dm:note>
       <dm:timestamp>2005-05-30T16:09:44+05:00</dm:timestamp>
     </dm:person>
   </presence>

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 <person>, <tuple>
   or <device>.

5.1  urn:ietf:params:xml:ns:pidf:rpid

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:rpid"
      xmlns="urn:ietf:params:xml:ns:pidf:rpid"
      xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

Schulzrinne, et al.       Expires June 23, 2006                [Page 23]
Internet-Draft                    RPID                     December 2005

     <xs:include schemaLocation="common-schema.xsd"/>

     <xs:simpleType name="activeIdle">
       <xs:restriction base="xs:string">
         <xs:enumeration value="active"/>
         <xs:enumeration value="idle"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:element name="activities">
       <xs:annotation>
         <xs:documentation>
           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.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:sequence>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <xs:choice>
             <xs:element name="unknown" type="empty" minOccurs="0"/>
             <xs:sequence maxOccurs="unbounded">
               <xs:choice>
                 <xs:element name="appointment"
                   type="empty" />
                 <xs:element name="away"
                   type="empty" />
                 <xs:element name="breakfast"
                   type="empty" />
                 <xs:element name="busy"
                   type="empty" />
                 <xs:element name="dinner"
                   type="empty" />
                 <xs:element name="holiday"
                   type="empty" />
                 <xs:element name="in-transit"
                   type="empty" />
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />
                 <xs:element name="meeting"
                   type="empty" />
                 <xs:element name="on-the-phone"
                   type="empty" />
                 <xs:element name="performance"

Schulzrinne, et al.       Expires June 23, 2006                [Page 24]
Internet-Draft                    RPID                     December 2005

                   type="empty" />
                 <xs:element name="permanent-absence"
                   type="empty" />
                 <xs:element name="playing"
                   type="empty" />
                 <xs:element name="presentation"
                   type="empty" />
                 <xs:element name="shopping"
                   type="empty" />
                 <xs:element name="sleeping"
                   type="empty" />
                 <xs:element name="spectator"
                   type="empty" />
                 <xs:element name="steering"
                   type="empty" />
                 <xs:element name="travel"
                   type="empty" />
                 <xs:element name="tv"
                   type="empty" />
                 <xs:element name="vacation"
                   type="empty" />
                 <xs:element name="working"
                   type="empty" />
                 <xs:element name="worship"
                   type="empty" />
                 <xs:element name="other"
                   type="Note_t" />
                 <xs:any namespace="##other"
                   maxOccurs="unbounded" processContents="lax"/>
               </xs:choice>
             </xs:sequence>
           </xs:choice>
         </xs:sequence>
         <xs:attributeGroup ref="fromUntil"/>
         <xs:attribute name="id" type="xs:ID"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:complexType>
     </xs:element>

     <xs:element name="class" type="xs:token">
       <xs:annotation>
         <xs:documentation>
           Describes the class of the service, device or person.
         </xs:documentation>
       </xs:annotation>
     </xs:element>

     <xs:element name="mood">

Schulzrinne, et al.       Expires June 23, 2006                [Page 25]
Internet-Draft                    RPID                     December 2005

       <xs:annotation>
         <xs:documentation>
           Describes the mood of the presentity.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:sequence>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <xs:choice>
             <xs:element name="unknown" type="empty"/>
             <xs:sequence maxOccurs="unbounded">
               <xs:choice>
                 <xs:element name="afraid"
                   type="empty"/>
                 <xs:element name="amazed"
                   type="empty"/>
                 <xs:element name="angry"
                   type="empty"/>
                 <xs:element name="annoyed"
                   type="empty"/>
                 <xs:element name="anxious"
                   type="empty" />
                 <xs:element name="ashamed"
                   type="empty" />
                 <xs:element name="bored"
                   type="empty" />
                 <xs:element name="brave"
                   type="empty" />
                 <xs:element name="calm"
                   type="empty" />
                 <xs:element name="cold"
                   type="empty" />
                 <xs:element name="confused"
                   type="empty" />
                 <xs:element name="contented"
                   type="empty" />
                 <xs:element name="cranky"
                   type="empty" />
                 <xs:element name="curious"
                   type="empty" />
                 <xs:element name="depressed"
                   type="empty" />
                 <xs:element name="disappointed"
                   type="empty" />
                 <xs:element name="disgusted"
                   type="empty" />
                 <xs:element name="distracted"
                   type="empty" />

Schulzrinne, et al.       Expires June 23, 2006                [Page 26]
Internet-Draft                    RPID                     December 2005

                 <xs:element name="embarrassed"
                   type="empty" />
                 <xs:element name="excited"
                   type="empty" />
                 <xs:element name="flirtatious"
                   type="empty" />
                 <xs:element name="frustrated"
                   type="empty" />
                 <xs:element name="grumpy"
                   type="empty" />
                 <xs:element name="guilty"
                   type="empty" />
                 <xs:element name="happy"
                   type="empty" />
                 <xs:element name="hot"
                   type="empty" />
                 <xs:element name="humbled"
                   type="empty" />
                 <xs:element name="humiliated"
                   type="empty" />
                 <xs:element name="hungry"
                   type="empty" />
                 <xs:element name="hurt"
                   type="empty" />
                 <xs:element name="impressed"
                   type="empty" />
                 <xs:element name="in_awe"
                   type="empty" />
                 <xs:element name="in_love"
                   type="empty" />
                 <xs:element name="indignant"
                   type="empty" />
                 <xs:element name="interested"
                   type="empty" />
                 <xs:element name="invincible"
                   type="empty" />
                 <xs:element name="jealous"
                   type="empty" />
                 <xs:element name="lonely"
                   type="empty" />
                 <xs:element name="mean"
                   type="empty" />
                 <xs:element name="moody"
                   type="empty" />
                 <xs:element name="nervous"
                   type="empty" />
                 <xs:element name="neutral"
                   type="empty" />

Schulzrinne, et al.       Expires June 23, 2006                [Page 27]
Internet-Draft                    RPID                     December 2005

                 <xs:element name="offended"
                   type="empty" />
                 <xs:element name="playful"
                   type="empty" />
                 <xs:element name="proud"
                   type="empty" />
                 <xs:element name="relieved"
                   type="empty" />
                 <xs:element name="remorseful"
                   type="empty" />
                 <xs:element name="restless"
                   type="empty" />
                 <xs:element name="sad"
                   type="empty" />
                 <xs:element name="sarcastic"
                   type="empty" />
                 <xs:element name="serious"
                   type="empty" />
                 <xs:element name="shocked"
                   type="empty" />
                 <xs:element name="shy"
                   type="empty" />
                 <xs:element name="sick"
                   type="empty" />
                 <xs:element name="sleepy"
                   type="empty" />
                 <xs:element name="stressed"
                   type="empty" />
                 <xs:element name="surprised"
                   type="empty" />
                 <xs:element name="thirsty"
                   type="empty" />
                 <xs:element name="worried"
                   type="empty" />
                 <xs:element name="other"
                   type="Note_t" />
                 <xs:any namespace="##other"
                   maxOccurs="unbounded" processContents="lax"/>
               </xs:choice>
             </xs:sequence>
           </xs:choice>
         </xs:sequence>
         <xs:attributeGroup ref="fromUntil"/>
         <xs:attribute name="id" type="xs:ID"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:complexType>
     </xs:element>

Schulzrinne, et al.       Expires June 23, 2006                [Page 28]
Internet-Draft                    RPID                     December 2005

     <xs:element name="place-is">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <xs:element name="audio" minOccurs="0">
             <xs:complexType>
               <xs:choice>
                 <xs:element name="noisy" type="empty" />
                 <xs:element name="ok" type="empty" />
                 <xs:element name="quiet" type="empty" />
                 <xs:element name="unknown" type="empty" />
               </xs:choice>
             </xs:complexType>
           </xs:element>
           <xs:element name="video" minOccurs="0">
             <xs:complexType>
               <xs:choice>
                 <xs:element name="toobright" type="empty" />
                 <xs:element name="ok" type="empty" />
                 <xs:element name="dark" type="empty" />
                 <xs:element name="unknown" type="empty" />
               </xs:choice>
             </xs:complexType>
           </xs:element>
           <xs:element name="text" minOccurs="0">
             <xs:complexType>
               <xs:choice>
                 <xs:element name="uncomfortable" type="empty" />
                 <xs:element name="inappropriate" type="empty" />
                 <xs:element name="ok" type="empty" />
                 <xs:element name="unknown" type="empty" />
               </xs:choice>
             </xs:complexType>
           </xs:element>
         </xs:sequence>
         <xs:attributeGroup ref="fromUntil"/>
         <xs:attribute name="id" type="xs:ID"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:complexType>
     </xs:element>

     <xs:element name="place-type">
       <xs:annotation>
         <xs:documentation>
           Describes the type of place the person is currently at.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>

Schulzrinne, et al.       Expires June 23, 2006                [Page 29]
Internet-Draft                    RPID                     December 2005

         <xs:sequence>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <xs:choice>
             <xs:element name="aircraft" type="empty" />
             <xs:element name="airport" type="empty" />
             <xs:element name="arena" type="empty" />
             <xs:element name="automobile" type="empty" />
             <xs:element name="bank" type="empty" />
             <xs:element name="bar" type="empty" />
             <xs:element name="bus" type="empty" />
             <xs:element name="bus-station" type="empty" />
             <xs:element name="cafe" type="empty" />
             <xs:element name="classroom" type="empty" />
             <xs:element name="club" type="empty" />
             <xs:element name="construction" type="empty" />
             <xs:element name="convention-center" type="empty" />
             <xs:element name="cycle" type="empty" />
             <xs:element name="government" type="empty" />
             <xs:element name="hospital" type="empty" />
             <xs:element name="hotel" type="empty" />
             <xs:element name="industrial" type="empty" />
             <xs:element name="library" type="empty" />
             <xs:element name="office" type="empty" />
             <xs:element name="outdoors" type="empty" />
             <xs:element name="parking" type="empty" />
             <xs:element name="place-of-worship" type="empty" />
             <xs:element name="prison" type="empty" />
             <xs:element name="public" type="empty" />
             <xs:element name="public-transport" type="empty" />
             <xs:element name="residence" type="empty" />
             <xs:element name="restaurant" type="empty" />
             <xs:element name="school" type="empty" />
             <xs:element name="shopping-area" type="empty" />
             <xs:element name="stadium" type="empty" />
             <xs:element name="store" type="empty" />
             <xs:element name="street" type="empty" />
             <xs:element name="theater" type="empty" />
             <xs:element name="train" type="empty" />
             <xs:element name="train-station" type="empty" />
             <xs:element name="truck" type="empty" />
             <xs:element name="underway" type="empty" />
             <xs:element name="unknown" type="empty" />
             <xs:element name="warehouse" type="empty" />
             <xs:element name="water" type="empty" />
             <xs:element name="watercraft" type="empty" />
             <xs:element name="other"  type="Note_t"/>
             <xs:any namespace="##other" maxOccurs="unbounded"
               processContents="lax"/>

Schulzrinne, et al.       Expires June 23, 2006                [Page 30]
Internet-Draft                    RPID                     December 2005

           </xs:choice>
         </xs:sequence>
         <xs:attributeGroup ref="fromUntil"/>
         <xs:attribute name="id" type="xs:ID"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:complexType>
     </xs:element>

     <xs:element name="privacy">
       <xs:annotation>
          <xs:documentation>
            Indicates which type of communication third parties in the
            vicinity of the presentity are unlikely to be able to
            intercept accidentally or intentionally.
          </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:sequence>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <xs:choice>
             <xs:element name="unknown" type="empty"/>
             <xs:sequence minOccurs="1">
               <xs:element name="audio" type="empty" minOccurs="0"/>
               <xs:element name="text" type="empty" minOccurs="0"/>
               <xs:element name="video" type="empty" minOccurs="0"/>
               <xs:any namespace="##other" minOccurs="0"
                  maxOccurs="unbounded" processContents="lax"/>
             </xs:sequence>
           </xs:choice>
         </xs:sequence>
         <xs:attributeGroup ref="fromUntil"/>
         <xs:attribute name="id" type="xs:ID"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:complexType>
     </xs:element>

     <xs:element name="relationship">
         <xs:annotation>
            <xs:documentation>
              Designates the type of relationship an alternate contact
              has with the presentity.
            </xs:documentation>
         </xs:annotation>
         <xs:complexType>
           <xs:sequence>
             <xs:element name="note" type="Note_t" minOccurs="0"/>
             <xs:choice>
                <xs:element name="assistant" type="empty" />

Schulzrinne, et al.       Expires June 23, 2006                [Page 31]
Internet-Draft                    RPID                     December 2005

                <xs:element name="associate" type="empty" />
                <xs:element name="family" type="empty" />
                <xs:element name="friend" type="empty" />
                <xs:element name="other" type="Note_t" minOccurs="0" />
                <xs:element name="self" type="empty" />
                <xs:element name="supervisor" type="empty" />
                <xs:element name="unknown" type="empty" />
                <xs:any namespace="##other" maxOccurs="unbounded"
                  processContents="lax"/>
             </xs:choice>
           </xs:sequence>
         </xs:complexType>
     </xs:element>

     <xs:element name="service-class">
       <xs:annotation>
         <xs:documentation>
           Designates the type of service offered.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:sequence>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <xs:choice>
             <xs:element name="courier" type="empty" />
             <xs:element name="electronic" type="empty" />
             <xs:element name="freight" type="empty" />
             <xs:element name="in-person" type="empty" />
             <xs:element name="postal" type="empty" />
             <xs:element name="unknown" type="empty" />
             <xs:any namespace="##other" maxOccurs="unbounded"
               processContents="lax"/>
           </xs:choice>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

     <xs:element name="sphere">
       <xs:annotation>
         <xs:documentation>
           Designates the current state and role that the person plays.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType mixed="true">
         <xs:choice minOccurs="0">
           <xs:element name="home" type="empty" />
           <xs:element name="work" type="empty" />
           <xs:element name="unknown" type="empty" />

Schulzrinne, et al.       Expires June 23, 2006                [Page 32]
Internet-Draft                    RPID                     December 2005

           <xs:any namespace="##other" maxOccurs="unbounded"
              processContents="lax"/>
         </xs:choice>
         <xs:attributeGroup ref="fromUntil"/>
         <xs:attribute name="id" type="xs:ID"/>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
       </xs:complexType>
     </xs:element>

     <xs:element name="status-icon">
       <xs:annotation>
         <xs:documentation>
           A URI pointing to an image (icon) representing the current
           status of the person or service.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:anyURI">
             <xs:attributeGroup ref="fromUntil"/>
             <xs:attribute name="id" type="xs:ID"/>
             <xs:anyAttribute namespace="##any" processContents="lax"/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name="time-offset">
       <xs:annotation>
         <xs:documentation>
           Describes the number of minutes of offset from UTC at the
           user's current location.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:integer">
             <xs:attributeGroup ref="fromUntil"/>
             <xs:attribute name="description"
                type="xs:string"/>
             <xs:attribute name="id" type="xs:ID"/>
             <xs:anyAttribute namespace="##any" processContents="lax"/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name="user-input">

Schulzrinne, et al.       Expires June 23, 2006                [Page 33]
Internet-Draft                    RPID                     December 2005

       <xs:annotation>
         <xs:documentation>
           Records the user-input or usage state of the service or
           device.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
           <xs:simpleContent>
             <xs:extension base="activeIdle">
               <xs:attribute name="idle-threshold"
                 type="xs:positiveInteger"/>
               <xs:attribute name="last-input" type="xs:dateTime"/>
               <xs:attribute name="id" type="xs:ID"/>
               <xs:anyAttribute namespace="##any"
                 processContents="lax"/>
             </xs:extension>
           </xs:simpleContent>
       </xs:complexType>
     </xs:element>
   </xs:schema>

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 <activities>, <mood>,
   <place-type>, <privacy>, <relationship> and <service-class>, 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.

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
      RFCXXXX [RFC editor:  replace with RFC number] to describe rich
      presence information extensions for the status element in the PIDF
      presence document format in the application/pidf+xml content type.

Schulzrinne, et al.       Expires June 23, 2006                [Page 34]
Internet-Draft                    RPID                     December 2005

   Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
      Henning Schulzrinne, hgs@cs.columbia.edu
   XML:

    BEGIN
      <?xml version="1.0"?>
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
      "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml
      <head>
           <meta http-equiv="content-type"
           content="text/html;charset=iso-8859-1"/>
           <title>RPID: Rich Presence: Extensions to the Presence
             Information Data Format (PIDF)</title>
      </head>
      <body>
          <h1>Namespace for rich presence extension</h1>
          <h2>urn:ietf:params:xml:ns:pidf:rpid</h2>
          <p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
   editor: replace with RFC number]</a>.</p>
       </body>
       </html>
      END

7.2  Schema Registration for Schema
     urn:ietf:params:xml:ns:pidf:status:rpid'

   URI: please assign
   Registrant Contact: IESG
   XML: See Section 5

   Note that this document does not need a new content type.  It
   inherits the content type from [9], namely application/pidf+xml.

8.  Internationalization Considerations

   RPID contains mostly tokens that are meant for consumption by
   programs, not directly by humans.  Programs are expected to translate
   those tokens into language-appropriate text strings according to the
   preferences of the watcher.

   Some elements may contain <note> and <other> elements that can
   contain free text.  These elements SHOULD be labeled with the 'xml:
   lang' attribute to indicate their language and script.  The
   specification allows multiple occurrences of these elements so that
   the presentity can convey <note> and <other> elements in multiple
   scripts and languages.  If no 'xml:lang' attribute is provided, the

Schulzrinne, et al.       Expires June 23, 2006                [Page 35]
Internet-Draft                    RPID                     December 2005

   default value is "i-default" [3].

   Since RPID is represented in XML, it provides native support for
   encoding information using the Unicode character set and its more
   compact representations including UTF-8.  Conformant XML processors
   recognize both UTF-8 and UTF-16.  Though XML includes provisions to
   identify and use other character encodings through use of an
   "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
   RECOMMENDED in environments where parser encoding support
   incompatibility exists.

   A description of time-zone considerations can be found in
   Section 3.13.

9.  Security Considerations

   The security considerations in [9] apply, as well as [8].  Compared
   to PIDF, this presence document format reveals additional information
   about presentities 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 reference to an external object, the <status-icon> may allow
   the presentity to induce the watcher to retrieve data from a third
   party (content indirection attack), thus either retrieving harmful
   content or adding to the server load of the referenced resource.

10.  References

10.1  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [3]   Alvestrand, H., "IETF Policy on Character Sets and Languages",
         BCP 18, RFC 2277, January 1998.

   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

   [5]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

Schulzrinne, et al.       Expires June 23, 2006                [Page 36]
Internet-Draft                    RPID                     December 2005

   [6]   Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000.

   [7]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [8]   Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

   [9]   Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
         J. Peterson, "Presence Information Data Format (PIDF)",
         RFC 3863, August 2004.

   [10]  W3C, "Extensible Markup Language (XML) 1.0", W3C
         Recommendation XML 1.0, February 1998.

10.2  Informative References

   [11]  Dawson, F. and Stenerson, D., "Internet Calendaring and
         Scheduling Core Object Specification (iCalendar)", RFC 2445,
         November 1998.

   [12]  Peterson, J., "Common Profile for Instant Messaging (CPIM)",
         RFC 3860, August 2004.

   [13]  Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
         Language (CPL): A Language for User Control of Internet
         Telephony Services", RFC 3880, October 2004.

   [14]  Rosenberg, J., "A Data Model for Presence",
         draft-ietf-simple-presence-data-model-06 (work in progress),
         October 2005.

   [15]  Lisetti, C., "Personality, Affect, and Emotion Taxonomy for
         Socially Intelligent Agents", Proceedings of FLAIRS 2002, 2002.

   [16]  Open Mobile Alliance, "The Wireless Village Initiative:
         Presence Attributes 1.1", Recommendation WV-29, 2004.

Schulzrinne, et al.       Expires June 23, 2006                [Page 37]
Internet-Draft                    RPID                     December 2005

Authors' Addresses

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7042
   Email: hgs+simple@cs.columbia.edu
   URI:   http://www.cs.columbia.edu

   Vijay Gurbani
   Lucent
   2000 Naperville Rd.
   Room 6G-440
   Naperville, IL  60566-7033
   US

   Email: vkg@lucent.com

   Paul Kyzivat
   Cisco Systems
   BXB500 C2-2
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   US

   Email: pkyzivat@cisco.com

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054-2711
   US

   Email: jdrosen@cisco.com

Appendix A.  Acknowledgements

   The document reflects the discussion on the SIMPLE mailing list, with
   contributions from many individuals.  David L. Black, Aki Niemi,
   Miguel Garcia, Avshalom Houri, Markus Isomaki, Rick Jones, Hisham
   Khartabil, Paul Kyzivat, Jonathan Lennox, Eva-Maria Leppanen, Mikko

Schulzrinne, et al.       Expires June 23, 2006                [Page 38]
Internet-Draft                    RPID                     December 2005

   Lonnfors, Rohan Mahy, Miguel Marcia, Andrew Newton, Jon Peterson and
   Brian Rosen provided detailed comments and suggestions.  Xiaotao Wu
   assisted with schema testing.  Jari Urpalainen provided valuable
   advice on XML schema issues.

Schulzrinne, et al.       Expires June 23, 2006                [Page 39]
Internet-Draft                    RPID                     December 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Schulzrinne, et al.       Expires June 23, 2006                [Page 40]