view Side-By-Side changes

SIMPLE                                                    H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: September 18, 2004 April 25, 2005                                       V. Gurbani
                                                                  Lucent
                                                              P. Kyzivat
                                                                   Cisco
                                                            J. Rosenberg
                                                             dynamicsoft
                                                          March 20,
                                                                   Cisco
                                                        October 25, 2004


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, I certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I he or she become aware will be disclosed, in accordance with
   RFC 3667. 3668.

   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.
   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 September 18, 2004. April 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   The Presence Information Data Format (PIDF) defines a basic format
   for representing presence information for a presentity.  That format



Schulzrinne, et al.      Expires April 25, 2005                 [Page 1]

Internet-Draft                    RPID                      October 2004


   defines a textual note, an indication of availability (open or
   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) that (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.,



Schulzrinne, et al.    Expires September 18, 2004               [Page 1]

Internet-Draft                    RPID                        March 2004 from calendar
   files or user activity.

   This extension includes information about what the presentity person is
   doing (the activity element), doing, a
   grouping identifier for a tuple (the
   class element), the type of tuple (the contact-type element), whether tuple, when a contact is idle (the idle element), service or device was last
   used, the typle type of place a presentity person is in (the placetype element), whether the presentity is in a public
   or private space (the privacy element), in, what media might be private,
   the relationship of a service tuple to another presentity (the relationship element), presentity, the
   person's mood, the time zone it is located in, the type of service it
   offers and the overall role of the presentity (the sphere element). presentity.

   These extensions include characteristics and status information for
   person, service (tuple) and devices.

































Schulzrinne, et al.      Expires April 25, 2005                 [Page 2]

Internet-Draft                    RPID                      October 2004


Table of Contents

   1.  Scope  . . . .   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3   4
   2.   Terminology and Conventions  . . . . . . . . . . . . . . . . .  3   5
   3.  The Meaning of "open" and "closed" . .   RPID Elements  . . . . . . . . . . . .  3
   4.  RPID Elements . . . . . . . . . . .   5
     3.1  Introduction . . . . . . . . . . . . .  3
   4.1 Introduction . . . . . . . . . .   6
     3.2  Activities Element . . . . . . . . . . . . . . .  3
   4.2 Activities Element . . . . .   7
     3.3  Class Element  . . . . . . . . . . . . . . . . .  4
   4.3 Class . . . . .   9
     3.4  Mood Element . . . . . . . . . . . . . . . . . . . . . . .  6
   4.4 Contact-Type   9
     3.5  Place-type Element . . . . . . . . . . . . . . . . . . . . .  6
   4.5 Idle  11
     3.6  Privacy Element  . . . . . . . . . . . . . . . . . . . . .  12
     3.7  Relationship Element . . . .  6
   4.6 Type of Place Element  . . . . . . . . . . . . . . . .  13
     3.8  Service Class  . . . .  7
   4.7 Privacy Element . . . . . . . . . . . . . . . . . .  13
     3.9  Sphere Element . . . . .  8
   4.8 Relationship Element . . . . . . . . . . . . . . . . .  13
     3.10   Status-Icon Element  . . . .  8
   4.9 Sphere Element . . . . . . . . . . . . . .  14
     3.11   Time Zone  . . . . . . . . . .  8
   5.  Examples . . . . . . . . . . . . .  14
     3.12   User-Input Element . . . . . . . . . . . . . .  9
   5.1 Presentity with Activity . . . . .  14
   4.   Example  . . . . . . . . . . . . . .  9
   6.  XML Schema Definitions . . . . . . . . . . . .  15
   5.   XML Schema Definitions . . . . . . . . 10
   6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple . . . . . . . . . . .  17
     5.1  urn:ietf:params:xml:ns:pidf:rpid-person  . 11
   6.2 . . . . . . . .  17
     5.2  urn:ietf:params:xml:ns:pidf:rpid-tuple . . . . . . . . . .  21
     5.3  urn:ietf:params:xml:ns:pidf:status:rpid-status . . . . . .  22
     5.4  urn:ietf:params:xml:ns:pidf:rpid-device  . . 11
   7. . . . . . . .  23
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.1  25
     6.1  URN Sub-Namespace Registration for
          'urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . . . 13
   7.2  25
     6.2  URN Sub-Namespace Registration for
          'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 14
   7.3  26
     6.3  Schema Registration for Schema
          urn:ietf:params:xml:ns:pidf:rpid-tuple'  . . . . . . . . . . . 15
   7.4  26
     6.4  Schema Registration for Schema
          urn:ietf:params:xml:ns:pidf:status:rpid-status'  . . . . . . . 15
   7.5  26
     6.5  Token Registrations  . . . . . . . . . . . . . . . . . . .  27
   7.   Security Considerations  . . . . 15 . . . . . . . . . . . . . .  27
   8.  Security Considerations   References . . . . . . . . . . . . . . . . . . . . . . 16 . . .  27
   8.1  Normative References . . . . . . . . . . . . . . . . . . . . . 16  27
   8.2  Informative References . . . . . . . . . . . . . . . . . . . . 17  28
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17  29
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18  29
        Intellectual Property and Copyright Statements . . . . . . . . 19  31











Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                 [Page 2] 3]

Internet-Draft                    RPID                        March                      October 2004


1. Scope  Introduction

   The Presence Information Data Format (PIDF) defines definition [7] describes
   a basic format
   for representing presence information for a presentity.  That format
   defines a textual note, data format, encoded as an indication Extensible
   Markup Language (XML) document, for exchanging presence information
   in CPIM-compliant systems.  It consists of availability (open a <presence> root element,
   zero or
   closed) and more <tuple> elements carrying presence information including
   a URI 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 for placement in the note element of the
   PIDF document.  This document 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 sources
   describing the user's current physical environment.

2. Terminology and Conventions

   This memo makes use of the vocabulary defined in

   The presence data model [12] defines the IMPP Model
   document [5].  Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
   SERVICE, PRESENTITY, WATCHER, concepts of service, device,
   and WATCHER USER AGENT in person as the memo data elements that are used in to model the same meaning as state of a
   presentity.  Services are encoded using the <tuple> element, defined therein.  The key words MUST,
   MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and
   OPTIONAL
   in this document PIDF; devices and persons are to be interpreted as described in BCP
   14, RFC 2119 [1].

3. The Meaning of "open" represented by the <device> and "closed"
   <person> XML elements, respectively, defined in the the data model
   [12].  However, neither PIDF describes nor the basic status values of "open" or "closed" only as
   "have meanings of general availability for other communications
   means". We data model define "closed" in our context as meaning that
   communication to the contact address will in all likelihood not
   succeed, is undesired or will not reach presence
   attributes beyond the intended party.  (For
   example, a presentity may include a hotel phone number <basic> status element.

   This specification defines additional presence attributes to describe
   person, service and device data elements, summarized as a contact.
   After check-out, "Rich
   Presence Information Data Format for Presence" (RPID).  These
   attributes are specified by XML elements which extend the phone number will still ring, but reach PIDF
   <tuple> element and the
   chambermaid or <device> and <person> elements defined in the next guest.  Thus, it would be declared "closed".)
   For "pres" contacts, "closed" means that no
   data model.

   This extension has two main goals:

   1.  Provide rich presence status
   information indication that is available.


4. RPID Elements

4.1 Introduction

   Below, we describe the RPID elements at least as powerful as
       common commercial presence systems.  Such feature-parity
       simplifies transition to CPIM-compliant systems, both in detail.  <activities>,
   <idle>, <placetype> terms of
       user acceptance and <privacy> extend the PIDF <status> element,
   while <class>, <contacttype> protocol conversion.
   2.  Maintain backwards-compatibility with PIDF, so that PIDF-only
       watchers and <relationship> extend gateways can continue to function properly,
       naturally without access to the PIDF functionality described here.




Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                 [Page 3] 4]

Internet-Draft                    RPID                        March                      October 2004


   <tuple> element.

   In general, it


   We make no assumptions how the information in the RPID is highly unlikely generated.
   Experience has shown that a presentity will publish or
   announce all of these elements at the same time.  Rather, these
   elements were chosen users are not always diligent about
   updating their presence status.  Thus, we want to give the presentity maximum flexibility in
   deriving this make it as easy as
   possible to derive RPID information from existing other information sources,
   such as calendaring
   tools, device activity sensors or location trackers, calendars, the status of communication devices such as well
   telephones, typing activity and physical presence detectors as to
   manually configure this information.

   The namespace URIs for these elements defined by this specification
   are URNs [2], using
   commonly found in energy-management systems.

   Many of the namespace identifier 'ietf' defined by [4]
   and extended by [6]:

      urn:ietf:params:xml:ns:pidf:status:rpid-status
      urn:ietf:params:xml:ns:pidf:status:rpid-tuple

   This document uses a separate namespace for extending the PIDF
   'status' namespace, elements correspond to data commonly found in accordance with Section 4.2.5 personal
   calendars.  Thus, we attempted to align some of [7].

   All elements described the extensions with
   the usage found in this document are optional. calendar formats such as iCal [10].

   The elements <activity>, <placetype>, <privacy> and <sphere> MAY information in a presence document can be
   qualified with the 'since' generated by a single
   entity or can be composed from information published by multiple
   entities.

   Note that PIDF documents 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.  The 'since'
   time MUST extension can be used in two
   different contexts, namely by the past, the 'until' time in the future relative presentity to publish its presence
   status and by the time of publication 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 and, if
   available, the PIDF 'timestamp' element.

4.2 Activities Element

   The <activities> element describes what the presentity is currently
   doing.  This can be quite helpful to
   the watcher watcher.  For example, it may merge presence information from
   multiple PUAs, remove whole elements, translate values in judging how
   appropriate a communication attempt is elements or
   remove information from elements.  Mechanisms that filter calls and which means of
   other communications is most likely to succeed and not annoy the
   presentity. The activity indications correspond roughly presentity can subscribe to the
   category field this presence
   information just like a regular watcher and in calendar entries, turn generate
   automated rules, such as Section 4.8.1.2 of RFC
   2445 [10].

   An activity enumeration consists scripts [11], that govern the actual
   communications behavior of one or more values drawn from the
   list below, any other token string or IANA-registered values (Section 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






Schulzrinne, et al.      Expires April 25, 2005                 [Page 5]

Internet-Draft                    RPID                      October 2004


3.1  Introduction

   Below, we describe the RPID elements in detail.  Some of these
   elements describe services, some devices, and some the person.  As
   such, they either extend <tuple>, <device> or <person>, respectively.
   Furthermore, some are dynamic status information, and others describe
   more static characteristics, and thus may extend <status> or the root
   <tuple>, <device> or <person> elements.

   Below, we describe the RPID elements in detail.  The following RPID
   elements are defined as <person> status attributes.
   activities: The <activities> status element describes what the person
      is doing, using an enumeration of <activity> elements.
   mood: The <mood> status element indicates the mood of the person.
   place-type: The <place-type> status elements reports the type of
      place the person is located in.
   sphere: The <sphere> element characterizes the overall role of the
      presentity.
   status-icon: The <status-icon> element depicts the current status of
      the person.
   timezone: The <time-zone> status element names the timezone the
      person finds itself in.

   The following RPID element is defined for <person>, <device> and
   <tuple> elements:
   class: An identifier that groups similar person elements, devices or
      services.

   The following RPID element is defined for both <device> and <tuple>
   attributes:
   user-input: The <user-input> element records the user-input or usage
      state of the service or device, based on human user input.

   The following RPID elements are defined as service attributes and
   thus extend <tuple>:
   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.  Relationship is a
      characteristic.
   service-type: The <service-type> element describes whether the
      service is delivered electronically, is a postal or delivery
      service or describes in-person communications.
   status-icon: The <status-icon> element depicts the current status of
      the service.

   In general, it is highly unlikely that a presentity will publish or



Schulzrinne, et al.      Expires April 25, 2005                 [Page 6]

Internet-Draft                    RPID                      October 2004


   announce all of these elements at the same time.  Rather, these
   elements were chosen to give the presentity maximum flexibility in
   deriving this information from existing sources, such as calendaring
   tools, device activity sensors or location trackers, as well as to
   manually configure this information.

   The namespace URIs for these elements defined by this specification
   are URNs [2], using the namespace identifier 'ietf' defined by [4]
   and extended by [6]:

      urn:ietf:params:xml:ns:pidf:status:rpid-status
      urn:ietf:params:xml:ns:pidf:rpid-tuple
      urn:ietf:params:xml:ns:pidf:rpid-person
      urn:ietf:params:xml:ns:pidf:rpid-device

   This document uses a separate namespace for extending the PIDF
   <status> namespace, in accordance with Sections 4.2.5 and 4.3.2 of
   [7].

   All elements described in this document are optional.

   The elements <activities>, <place-type>, <privacy> and <sphere> MAY
   be qualified with the 'since' 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.  The 'since'
   time MUST be in the past, the 'until' time in the future relative to
   the time of publication of the presence information and, if
   available, the PIDF <timestamp> element.

   All elements may be generated either automatically, derived from
   sensor information or a calendar, or provided manually, via some user
   interface, by the presentity.  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.

3.2  Activities Element

   The <activities> element describes what the person is currently
   doing, expressed as an enumeration of <activity> elements.  A person
   can be engaged in multiple activities at the same time, e.g.,
   traveling and having a meal.  This can be quite helpful to the
   watcher in judging how appropriate a communication attempt is and
   which means of communications is most likely to succeed and not annoy
   the person.  The activity indications correspond roughly to the
   category field in calendar entries, such as Section 7).

   Depending on 4.8.1.2 of RFC
   2445 [10].

   An activities enumeration consists of one or more elements using



Schulzrinne, et al.      Expires April 25, 2005                 [Page 7]

Internet-Draft                    RPID                      October 2004


   values drawn from the list below, any other token string or
   IANA-registered values (Section 6).

   If a person publishes an activity of "perment-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.

   away: The person is physically away from all interactive
      communication devices location.  This activity 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
      discourage communication, but indicate that it still can be
      reached if needed, but communications might reach an answering
      service, for example.
   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 presentity intent, person chooses
      not to reveal more information.
   busy: User 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.
   holiday: This is a scheduled national or local holiday.  This
      information can typically be derived automatically from calendars.
   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 "permanent-absence"
   indication type of conveyance the person is using.
   meal: The person is scheduled for a meal.  This activity category can
      often be used generated automatically from a calendar.
   meeting: A meeting is a sub-class of an appointment.  This activity
      category can often be generated automatically from a calendar.
   on-the-phone: The person is talking on the telephone.  This activity
      is included since it can often be derived automatically.
   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.  This activity category can often be
      generated automatically from a calendar.
   permanent-absence: person will not return for the foreseeable future,
      e.g., because it is no longer working for the company.  This
      activity is associated with either a status OPEN or CLOSED. of CLOSED across all
      services.




Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                 [Page 4] 8]

Internet-Draft                    RPID                        March                      October 2004


   on-the-phone: The presentity is talking on the telephone.


   sleeping: This activity is included since it category can often be derived automatically.
   away: generated automatically
      from a calendar, local time information or biometric data.
   steering: The presentity person is physically away controlling a vehicle, ship or plane.
   travel: The person is on a business or personal trip, but not
      necessarily in-transit.  This category can often be generated
      automatically from the device location. a calendar.
   vacation: Leisure travel.  This activity was included since it category can often be derived
      generated automatically from security systems, energy management systems or
      entry badge systems.
   appointment: a calendar.

   The presentity has <activities> element MAY be qualified with the 'since' and
   'until' attributes as described in Section 3.

   If the entity described by a calendar appointment, without
      specifying exactly of what type.  This activity is indicated if
      more detailed information tuple is not available involved in multiple activities
   at the same time, the <activities> element enumerates all unique
   values as child <activity> elements.

   The <activities> element can be extended by adding elements from
   other namespaces, e.g., to reflect activities appropriate for a
   particular occupation.

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.  The naming of classes is left to the presentity.
   The presentity
      choses not can use this information to reveal more information.
   holiday: This is a scheduled national group similar services,
   devices or local holiday. This person elements or to convey information that the presence
   agent can typically be derived automatically from calendars.
   meal: use for filtering or authorization.


3.4  Mood Element

   The <mood> element describes the mood of the presentity.  They are
   enumerated chosen by the presentity.  The presentity mood itself is scheduled for a meal.  This activity category
      can often be generated automatically from provided as
   the element name of a calendar.
   meeting: A meeting defined child element of the <mood/> element
   (e.g., <happy/>); one such child element is REQUIRED.  The user MAY
   also specify a sub-class natural-language description of, or reason for, the
   mood in the <text/> child of the  element, which is OPTIONAL.  (This
   definition follows the Jabber Extension JEP-107.) It is RECOMMENDED
   that an appointment. implementation support the mood values proposed in Jabber
   Extension JEP-0107, which in turn are a superset of the Wireless
   Village [15] mood values and the values enumerated in the Affective
   Knowledge Representation that has been defined by Lisetti [14]:
      afraid
      amazed
      angry
      annoyed




Schulzrinne, et al.      Expires April 25, 2005                 [Page 9]

Internet-Draft                    RPID                      October 2004


      anxious
      ashamed
      bored
      brave
      calm
      cold
      confused
      contented
      cranky
      curious
      depressed
      disappointed
      disgusted
      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
      playful
      proud
      relieved
      remorseful
      restless
      sad
      sarcastic
      serious




Schulzrinne, et al.      Expires April 25, 2005                [Page 10]

Internet-Draft                    RPID                      October 2004


      shocked
      shy
      sick
      sleepy
      stressed
      surprised
      thirsty
      worried

3.5  Place-type Element

   The <place-type> element describes the type of place the person is
   currently at.  This activity
      category can often offers the watcher an indication what kind of
   communication is likely to be generated automatically from a calendar.
   steering: appropriate.  We define an initial set
   of values below:

   aircraft: The presentity person is controlling in a vehicle, ship plane, helicopter or plane.
   in-transit: balloon.
   airport: The presentity person is riding located in an airport, heliport or similar
      location.
   bus: The person is travling in a vehicle, such as a car, but
      not steering. public or charter bus.
   car: The 'placetype' element provides more specific
      information about the type of conveyance the presentity person is using.
   travel: in an automobile.
   home: The presentity person is on in a business private or personal trip, but residential setting, not
      necessarily in-transit.  This category can often be generated
      automatically from a calendar.
   vacation: Leisure travel.  This activity category can often be
      generated automatically from the personal residence of the person, e.g., including
      hotel or a calendar.
   sleeping: This activity category can often be generated automatically
      from friend's home.
   hotel: The person is in a calendar, local time information hotel, motel, inn or biometric data.
   busy: User other lodging
      establishment.
   industrial: The person is busy, without further details. While this activity
      would typically be associated with in an industrial setting, such as a status of CLOSED,
      manufacturing floor or power plant.
   library: The person is in a
      presentity may declare itself busy to discourage communication,
      but indicate library or other public place that it still can be reached if needed.
   permanent-absence: Presentity will not return for the foreseeable
      future, e.g., because it
      provides access to books, music and reference materials.
   mall: The person is no longer working for the company.
      This activity frequenting a shopping mall or shopping area.
   noisy: The person is associated with in a status place with lots of CLOSED. background noise.
   office: The <activity> element MAY be qualified with the 'since' and 'until'
   attributes person is in a business setting, such as described an office.
   outdoors: The person is in Section 4. a general outdoors area, such as a park or
      city streets.
   public: The <activities> element can be used with tuples of all values of
   <contact-type>.  For tuples consisting of multiple physical devices,
   i.e., of <contact-type> 'service' person is in a public area such as a shopping mall,
      street, park, public building, train station, airport or 'presentity', these components
   can engage in multiple types of activities, particularly if qualified
   by public
      conveyance such as a <relationship> element.  In those cases, bus, train, plane or ship.  This general
      description encompasses the <activities>
   element enumerates all unique values as child <activity> elements. more precise descriptors "street",
      "public-transport", "aircraft", "ship", "bus", "train", "airport",
      "mall" and "outdoors" below.
   public-transport: The <activities> element can be extended by adding elements from
   other namespaces, e.g., to reflect activities appropriate for person is using any form of public transport,
      including aircraft, bus, train or ship.
   quiet: The person is in a place such as a
   particular occupation. library, restaurant,
      place-of-worship, or theater that discourages noise, conversation
      and other distractions.





Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                [Page 5] 11]

Internet-Draft                    RPID                        March                      October 2004


4.3 Class

   The 'class' attribute describes the class of the tuple.  Multiple
   tuples can have the same class name within a presence document.


   restaurant: The
   naming of classes person is left to the presentity.  The presentity can use
   this information to group similar tuples in a restaurant, coffee shop or to convey information
   that the presence agent can use for filtering.


4.4 Contact-Type Element other
      public dining establishment.
   school: The <contacttype> element describes the type of the tuple.  A tuple
   can represent a communication facility ("device"), a face-to-face
   communication tuple ("in-person"), a set of devices offering person is in a common
   service ("service"), school or university, but not necessarily
      in a whole presentity ("presentity").
   Additional types can be registered with IANA.


4.5 Idle Element

   For tuples representing a single device, i.e., having a
   <contact-type> of 'device', the <idle> element records the absolute
   time and date the communication device was last used.  This provides
   an indication as to how likely a user classroom or library.
   ship: The person is to answer when contacting
   that device.  A device that has not been used traveling in a while may still be
   OPEN, but water vessel or boat.
   station: The person is located in a watcher may choose to first contact bus or train station.
   street: The person is walking in a device that street.
   theater: The person is both
   OPEN and has been used more recently.  Note that the idle time refers
   to the whole device, not just the particular service.  For example, in a
   tuple describing an instant messaging device expresses the last time
   that the PC theater, lecture hall, auditorium, class
      room, movie theater or PDA was used, not the last time similar facility designed for
      presentations, talks, plays, music performances and other events
      involving an instant message has
   been sent.

   For tuples representing audience.
   train: The person is traveling in a train, monorail, maglev, cable
      car or similar conveyance.
   truck: The person is in a 'presentity' truck, used primarily to carry goods rather
      than people.

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

   The <place-type> element is a tokenlist, e.g.,
      <place-type>street noisy public</place-type>

   The <place-type> element MAY be qualified with multiple
   devices, the device with 'since' and
   'until' attributes as described in Section 3.


3.6  Privacy Element

   The <privacy> element indicates which type of communication third
   parties in the most recent usage, i.e., vicinity of the shortest
   idle time, determines presentity are unlikely to be able to
   intercept accidentally or intentionally.  This does not in any way
   describe the idle time for privacy properties of the whole tuple.

   The use electronic communication
   channel, e.g., properties of 'idle' for tuples with contact-type 'in-person' the encryption algorithm of the network
   protocol used.

   audio: Audio communication is likely only to be heard by the intended
      recipient.
   video: Inappropriate individuals are not likely to see video
      communications.
   text: Inappropriate individuals are not
   defined. likely to see text
      communications.

      The <idle> <privacy> element can be empty if used by logic executing on the presentity wants
      watcher or by a composer to indicate filter, sort and label tuples.  For
      example, a composer may have rules that limit the device has not been used for a while, but does not want publication of
      tuples labeled as "private" to
   reveal a select subset of the precise duration, as in:

     <idle/> watchers.

   The <idle> <privacy> element SHOULD MAY be included in the presence document if the
   idle time exceeds a user-setable threshold, qualified with a RECOMMENDED
   default value of 10 minutes.  Configuration MUST include the option 'since' and 'until'



Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                [Page 6] 12]

Internet-Draft                    RPID                        March                      October 2004


   to omit the timestamp.

4.6 Type of Place


   attributes as described in Section 3.

3.7  Relationship Element

   The <placetype> <relationship> element describes extends <tuple> and designates the type of place the presentity is
   currently at. This offers the watcher an indication what kind of
   communication is likely to be appropriate. We define
   relationship an initial set
   of values below:

   home: The presentity is in a private or residential setting, not
      necessarily the personal residence of alternate contact has with the presentity, e.g.,
      including hotel or a friend's home.
   office: The presentity presentity.  This
   element is in provided only if the tuple refers to somebody other than
   the presentity.  Relationship values include "family", "associate"
   (e.g., for a business setting, such as an office.
   industrial: The presentity is in an industrial setting, such colleague), "assistant", "supervisor".  Other free-text
   values and additional IANA-registered values (Section 6) can be used
   as well.

   If a
      manufacturing floor or powerplant.
   quiet: The presentity relationship is indicated, the URI in a place the <contact> element
   refers to the entity, such as a library, restaurant,
      place-of-worship, or theater the assistant, that discourages noise, conversation
      and other distractions.
   noisy: The has a relationship
   to the presentity, not the presentity is in itself.

   Like tuples without a place <relationship> qualifier, the <contact> element
   for tuples labeled with lots of background noise.
   public: The presentity is in a public area relationship can contain either a
   communication URI such as a shopping mall,
      street, park, public building, train station, airport "im", "sip", "sips", "h323", "tel" or in public
      conveyance
   "mailto", or a presence URI, such as a bus, train, plane "pres" or ship.  This general
      description encompasses the more precise descriptors 'street',
      'public-transport', 'aircraft', 'ship', 'bus', 'train', 'airport',
      'mall' "sip".

3.8  Service Class

   The <service-class> element extends <tuple> and 'outdoors' below.
   street: Walking in a street.
   public-transport: Any form designates the type
   of public transport, including aircraft,
      bus, train service offered, namely electronic, delivery (including courier),
   postal or ship.
   aircraft: in-person.  Electronic service is implied if omitted.  The presentity
   service types 'postal', 'delivery' 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 a plane, helicopter geospatial coordinates, civic addresses or balloon.
   ship: Water vessel, boat.
   bus: Public some
   specialized address format, e.g., for interstellar addresses or charter bus.
   train: a
   company-specific delivery system.

3.9  Sphere Element

   The presentity <sphere> element designates the current state and role that the
   person plays.  For example, it might describe whether the person is traveling
   in a train, monorail, maglev,
      cable car or similar conveyance.
   airport: Airport, heliport or similar location.
   station: Bus work mode or train station.
   mall: Shopping mall at home or shopping area.
   outdoors: General outdoors area, participating in activities related to
   some other organization such as a park the IETF or city streets. a church.  This list can be augmented by free-text values or additional
   IANA-registered values (Section Section 7).

   The <placetype> element can document
   does not define names for these spheres except for two common ones,
   "work" and "home".

   Spheres are likely to be used with tuples of all values of
   <contact-type>.  For tuples consisting of multiple physical devices,
   i.e., of <contact-type> 'service' for two purposes:  they allow the
   person to easily turn on or 'presentity', these devices can off certain rules that depend on what
   groups of people should be in multiple types made aware of places.  In those cases, the <placetype>
   element enumerates all unique values as person's status.  For
   example, if the person is a token list.

   The <placetype> element MAY be qualified with Boy Scout leader, he might set the 'since' sphere
   to "scouting" and 'until' then have a rule set that allows other scout



Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                [Page 7] 13]

Internet-Draft                    RPID                        March                      October 2004


   attributes as described


   masters in Section 4.


4.7 Privacy Element

   The 'privacy' element indicates whether third parties may be able to
   hear or view parts of the communication.

   public: Others may be able his troop to see or hear the communications.
   private: Inappropriate individuals are not likely his presence status.  As soon as he
   switches his status to see "work" or hear the
      communications.

   This indication is not limited to voice communications.  For example,
   a presentity might label her privacy as "quiet" when giving a talk,
   since it would be inappropriate if an instant message popped up on
   the laptop screen that is being projected for "home" or some other sphere, the audience.
   fellow scouts would lose access.

   The 'placetype' <sphere> element MAY be qualified with the 'since' and 'until'
   attributes as described in Section 4.

4.8 Relationship 3.

3.10  Status-Icon Element

   The <relationship> <status-icon> element extends <tuple> and designates the type of
   relationship includes a URI pointing to an alternate contact has with image (icon)
   representing the presentity.  This
   element is provided only if current status of the tuple refers person or service.  The
   watcher MAY use this information to somebody other than represent the presentity.  Relationship values include "family", "associate"
   (e.g., for status in a colleague), "assistant", "supervisor".  Other free-text
   values
   graphical user interface.  Presentities SHOULD provide images of
   sizes and additional IANA-registered values (Section 7) can be used aspect ratios that are appropriate for rendering as well.

   If a relationship an
   icon.  Support for JPEG, PNG and GIF formats is indicated, the RPID <status> values describe RECOMMENDED.

3.11  Time Zone

   The <timezone> element describes the
   <contact>, not current time zone of the
   presentity.  The <contact> element for tuples labeled timezone is described by a time zone identifier.  If
   it begins with a relationship can
   contain either forward slash (solidus), it references a communication URI such as "im", "sip"/"sips",
   "h323", "tel" or "mailto", or
   to-be-defined global time zone registry; otherwise it is
   locally-defined at the server.

   While labels that do not begin with a presence URI, such as "pres" or
   "sip".

4.9 Sphere forward slash are locally
   defined, it is RECOMMENDED that servers support at least the naming
   scheme used by Olson Time Zone database [13].  Examples of timezone
   databases that use the Olson scheme are the zoneinfo files on most
   Unix-like systems, and the standard Java TimeZone class.

3.12  User-Input Element

   The <sphere> <user-input> element designates records the current user-input or usage state and role of the
   service or device, based on human user input, e.g., keyboard,
   pointing device or voice.  The element can assume one of two values,
   namely 'active' or 'idle', with an optional 'since' attribute that
   records when the
   presentity plays.  For example, it might describe whether last user input has been received.  An optional
   'idle-threshold' element records how long the presentity is in a work mode or at home will wait
   before reporting the service or participating device to be idle, measured in
   activities related
   seconds.

   (A two-state model was chosen since it would otherwise be necessary
   to some other organization such as 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 IETF or user has provided user
   input within a
   church.  This document does not define names for these spheres except
   for two common ones, "work" and "home".

   Spheres are likely configurable interval of time, the idle-threshold.  If
   the user ceases to be used for two purposes:  they allow provide input and the idle threshold has elapsed,



Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                [Page 8] 14]

Internet-Draft                    RPID                        March                      October 2004


   presentity to easily turn on or off certain rules that depend on what
   groups of people should be made aware of


   the presentity's status.
   For example, if tuple is marked with a <user-input> 'idle' indication instead,
   optionally including the presentity time of last activity in the 'since'
   attribute.  An example is below:

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

   Depending on device or service capabilities, user input may be
   detected only for a Boy Scout leader, he might set particular application, i.e., when the sphere to 'scouting' and then have
   application has user focus or when a rule set that allows other
   scout masters in his troup to see his presence status.  As soon as he
   switches his status to 'work' user has sent a message or 'home'
   placed a call, or some other sphere, the
   fellow scouts would lose access. can be based on user input across all applications
   running on one end system.

   The <sphere> <user-input> element can may be used by a watcher, typically in
   combination with tuples of all values of
   <contact-type>.  For tuples representing multiple physical devices,
   <contact-type> 'service' or 'presentity', these devices can 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
   controlled by people OPEN, but a watcher may choose to first
   contact a URI in multiple different spheres.  In those cases, 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 <sphere> element enumerates all unique values precise duration, as a token list.

   The <sphere> element MAY be qualified with in:

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

   Configuration MUST include the option to omit the 'since' and 'until'
   attributes 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 described an email box.  The presentity is in Section 4.

5. Examples

5.1 Presentity with Activity a meeting, in
   a public office setting.  The 'until' information indicates that he
   will be there until 5.30 pm GMT.  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:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status"
   xmlns:e="urn:ietf:params:xml:ns:pidf:status:rpid-status"
   xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     entity="pres:someone@example.com">
   entity="pres:someone@example.com"
   xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd
   urn:ietf:params:xml:ns:pidf:status:rpid-status rpid-status.xsd



Schulzrinne, et al.      Expires April 25, 2005                [Page 15]

Internet-Draft                    RPID                      October 2004


   urn:ietf:params:xml:ns:pidf:rpid-tuple rpid-tuple.xsd">
     <tuple id="c8dqui"> id="t0">
       <status>
         <basic>open</basic>
      <ep:relationship>assistant</ep:relationship>
       </status>
       <et:class>assistant</et:class>
     <et:contact-type>presentity</et:contact-type>
       <et:relationship>assistant</et:relationship>
       <contact>sip:secretary@example.com</contact>
       <note>My secretary</note>
     </tuple>
     <tuple id="x765"> id="t1">
       <status>
         <basic>open</basic>
      <ep:activity>
      <ep:activity>meeting</ep:activity></ep:activity>
      <ep:placetype until="2003-01-27T17:30:00Z">office</ep:placetype>
      <ep:privacy>quiet</ep:privacy>
      <ep:idle>2003-01-27T10:43:00Z</ep:idle>
         <e:activities>
           <e:activity>meeting</e:activity>
         </e:activities>
         <e:place-type until="2003-01-27T17:30:00Z">office</e:place-type>
         <e:privacy>public</e:privacy>
         <e:idle since="2003-01-27T10:43:00Z"/>
       </status>
       <et:class>sip</et:class>



Schulzrinne, et al.    Expires September 18, 2004               [Page 9]

Internet-Draft                    RPID                        March 2004


     <et:contact-type>service</et:contact-type>
       <contact priority="0.8">sip:someone@example.com</contact>
       <timestamp>2001-10-27T16:49:29Z</timestamp>
     </tuple>
     <tuple id="bs9r"> id="t2">
       <status>
         <basic>open</basic>
      <ep:privacy>quiet</ep:privacy>
         <e:privacy>private</e:privacy>
         <e:timezone>America/New_York</e:timezone>
       </status>
       <contact priority="0.8">im:someone@mobilecarrier.net</contact>
       <timestamp>2001-10-27T16:49:29Z</timestamp>
     </tuple>
     <tuple id="eg92n"> id="t3">
       <status>
         <basic>open</basic>
       </status>
       <et:class>mail</et:class>
     <nn:blah>blah</nn:blah>
     <et:contact-type>device</et:contact-type>
       <contact priority="1.0">mailto:someone@example.com</contact>
       <note>I'm in a boring meeting</note>
     </tuple>
     <tuple id="t4">
       <status>
         <basic>closed</basic>
       </status>
       <et:service-class>in-person</et:class>
       <note>Closed-door meeting</note>
     </tuple>



Schulzrinne, et al.      Expires April 25, 2005                [Page 16]

Internet-Draft                    RPID                      October 2004


     <person>
       <mood>
         <happy/>
         <text>I got my paycheck!</text>
       </mood>
     </person>
   </presence>




6.




5.  XML Schema Definitions

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


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

     <!-- This import brings in the XML language attribute xml:lang-->
     <import namespace="http://www.w3.org/XML/1998/namespace"
       schemaLocation="http://www.w3.org/2001/xml.xsd"/>

     <annotation>
       <documentation xml:lang="en">
         Describes RPID tuple extensions for PIDF.
       </documentation>
     </annotation>

     <attributeGroup name="SinceUntil">
       <attribute name="since" type="dateTime"/>
       <attribute name="until" type="dateTime"/>
     </attributeGroup>

     <element name='away' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='busy' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='appointment' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>



Schulzrinne, et al.      Expires September 18, April 25, 2005                [Page 17]

Internet-Draft                    RPID                      October 2004


     <element name='holiday' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='in-transit' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='meal' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='meeting' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='on-the-phone' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='performance' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='permanent-absence' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='sleeping' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='steering' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='travel' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>
     <element name='vacation' substitutionGroup="rp:activity-value">
       <complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
     </element>

     <element name="activities">
       <complexType>
         <sequence>
           <element ref="rp:activity-value"
             minOccurs="0" maxOccurs="unbounded">
           </element>
           <any maxOccurs="unbounded"/>
         </sequence>
       </complexType>
     </element>

     <element name="class" type="token"/>

     <element name='mood'>



Schulzrinne, et al.      Expires April 25, 2005                [Page 18]

Internet-Draft                    RPID                      October 2004


       <complexType>
         <sequence>
           <choice>
             <element name='afraid' type='rp:empty'/>
             <element name='amazed' type='rp:empty'/>
             <element name='angry' type='rp:empty'/>
             <element name='annoyed' type='rp:empty'/>
             <element name='anxious' type='rp:empty'/>
             <element name='aroused' type='rp:empty'/>
             <element name='ashamed' type='rp:empty'/>
             <element name='bored' type='rp:empty'/>
             <element name='brave' type='rp:empty'/>
             <element name='calm' type='rp:empty'/>
             <element name='cold' type='rp:empty'/>
             <element name='confused' type='rp:empty'/>
             <element name='contented' type='rp:empty'/>
             <element name='cranky' type='rp:empty'/>
             <element name='curious' type='rp:empty'/>
             <element name='depressed' type='rp:empty'/>
             <element name='disappointed' type='rp:empty'/>
             <element name='disgusted' type='rp:empty'/>
             <element name='distracted' type='rp:empty'/>
             <element name='embarrassed' type='rp:empty'/>
             <element name='excited' type='rp:empty'/>
             <element name='flirtatious' type='rp:empty'/>
             <element name='frustrated' type='rp:empty'/>
             <element name='grumpy' type='rp:empty'/>
             <element name='guilty' type='rp:empty'/>
             <element name='happy' type='rp:empty'/>
             <element name='hot' type='rp:empty'/>
             <element name='humbled' type='rp:empty'/>
             <element name='humiliated' type='rp:empty'/>
             <element name='hungry' type='rp:empty'/>
             <element name='hurt' type='rp:empty'/>
             <element name='impressed' type='rp:empty'/>
             <element name='in_awe' type='rp:empty'/>
             <element name='in_love' type='rp:empty'/>
             <element name='indignant' type='rp:empty'/>
             <element name='interested' type='rp:empty'/>
             <element name='intoxicated' type='rp:empty'/>
             <element name='invincible' type='rp:empty'/>
             <element name='jealous' type='rp:empty'/>
             <element name='lonely' type='rp:empty'/>
             <element name='mean' type='rp:empty'/>
             <element name='moody' type='rp:empty'/>
             <element name='nervous' type='rp:empty'/>
             <element name='neutral' type='rp:empty'/>
             <element name='offended' type='rp:empty'/>



Schulzrinne, et al.      Expires April 25, 2005                [Page 10] 19]

Internet-Draft                    RPID                      October 2004


             <element name='playful' type='rp:empty'/>
             <element name='proud' type='rp:empty'/>
             <element name='relieved' type='rp:empty'/>
             <element name='remorseful' type='rp:empty'/>
             <element name='restless' type='rp:empty'/>
             <element name='sad' type='rp:empty'/>
             <element name='sarcastic' type='rp:empty'/>
             <element name='serious' type='rp:empty'/>
             <element name='shocked' type='rp:empty'/>
             <element name='shy' type='rp:empty'/>
             <element name='sick' type='rp:empty'/>
             <element name='sleepy' type='rp:empty'/>
             <element name='stressed' type='rp:empty'/>
             <element name='surprised' type='rp:empty'/>
             <element name='thirsty' type='rp:empty'/>
             <element name='worried' type='rp:empty'/>
           </choice>
           <element name='text' minOccurs='0' type='string'/>
         </sequence>
       </complexType>
     </element>
     <element name="place-type">
       <complexType>
         <simpleContent>
           <extension base="tokenlist">
             <attributeGroup ref="SinceUntil"/>
           </extension>
         </simpleContent>
       </complexType>
     </element>

     <element name="sphere">
       <complexType>
         <simpleContent>
           <extension base="tokenlist">
             <attributeGroup ref="SinceUntil"/>
           </extension>
         </simpleContent>
       </complexType>
     </element>

     <element name="timezone">
       <complexType>
         <simpleContent>
           <extension base="token">
             <attributeGroup ref="SinceUntil"/>
           </extension>
         </simpleContent>



Schulzrinne, et al.      Expires April 25, 2005                [Page 20]

Internet-Draft                    RPID                      October 2004


       </complexType>
     </element>

     <element name="status-icon" type="anyURI"/>

     <simpleType name='empty'>
       <restriction base='string'>
         <enumeration value=''/>
       </restriction>
     </simpleType>
   </schema>




5.2  urn:ietf:params:xml:ns:pidf:rpid-tuple


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

     <!-- This import brings in the XML language attribute xml:lang-->
     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
       schemaLocation="http://www.w3.org/2001/xml.xsd"/>

     <annotation>
       <documentation xml:lang="en">
         Describes RPID tuple extensions for PIDF.
       </documentation>
     </annotation>

     <element name="class" type="token"/>

     <element name="relationship" type="token"/>

     <element name="service-class">
       <simpleType>
         <restriction base="token">
           <enumeration value="electronic"/>
           <enumeration value="in-person"/>
           <enumeration value="postal"/>
           <enumeration value="delivery"/>
         </restriction>



Schulzrinne, et al.      Expires April 25, 2005                [Page 21]

Internet-Draft                    RPID                      October 2004


       </simpleType>
     </element>

     <element name="user-input">
       <complexType>
         <attribute name="idle-threshold" type="positiveInteger"/>
         <attribute name="since" type="dateTime"/>
       </complexType>
     </element>
   </schema>




5.3  urn:ietf:params:xml:ns:pidf:status:rpid-status




































Schulzrinne, et al.      Expires April 25, 2005                [Page 22]

Internet-Draft                    RPID                        March                      October 2004


6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple


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

     <!-- This import brings in the XML language attribute xml:lang-->
     <xs:import
     <import namespace="http://www.w3.org/XML/1998/namespace"
          schemaLocation="http://www.w3.org/2001/xml.xsd"/>

     <xs:annotation>
       <xs:documentation
     <annotation>
       <documentation xml:lang="en">
       Describes RPID tuple status extensions for PIDF.
          </xs:documentation>
     </xs:annotation>

     <xs:element name="contact-type">
       <xs:simpleType>
         <xs:restriction base="xs:token">
           <xs:enumeration value="device"/>
           <xs:enumeration value="in-person"/>
           <xs:enumeration value="service"/>
           <xs:enumeration value="presentity"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:element>

     <xs:element name="class" type="xs:token"/>

     <xs:element name="relationship" type="xs:token"/>
   </xs:schema>




6.2 urn:ietf:params:xml:ns:pidf:status:rpid-status
       </documentation>
     </annotation>
     <attributeGroup name="SinceUntil">
       <attribute name="since" type="dateTime"/>
       <attribute name="until" type="dateTime"/>
     </attributeGroup>

     <element name="privacy">
       <complexType>
         <simpleContent>
           <extension base="tokenlist">
             <attributeGroup ref="SinceUntil"/>
           </extension>
         </simpleContent>
       </complexType>
     </element>

     <element name="status-icon" type="anyURI"/>

     <element name="user-input">
       <complexType>
         <attribute name="idle-threshold" type="positiveInteger"/>
         <attribute name="since" type="dateTime"/>
       </complexType>
     </element>
   </schema>




5.4  urn:ietf:params:xml:ns:pidf:rpid-device


   <?xml version="1.0" encoding="UTF-8"?>
   <!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by Henning Schulzrinne (Columbia University) -->
   <xs:schema xmlns="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:pidf="urn:ietf:params:xml:ns:pidf" xmlns:xs="http://www.w3.org/2001/XMLSchema"
   <schema



Schulzrinne, et al.      Expires April 25, 2005                [Page 23]

Internet-Draft                    RPID                      October 2004


     targetNamespace="urn:ietf:params:xml:ns:pidf:rpid-device"
     xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid-device"
     xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified" attributeFormDefault="unqualified">

     <!-- This import brings in the XML language attribute xml:lang-->
   	<xs:import
     <import namespace="http://www.w3.org/XML/1998/namespace"
          schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   	<xs:annotation>



Schulzrinne, et al.    Expires September 18, 2004              [Page 11]

Internet-Draft                    RPID                        March 2004


   		<xs:documentation
     <annotation>
       <documentation xml:lang="en">
       Describes RPID status extensions for PIDF.
       </xs:documentation>
   	</xs:annotation>
   	<xs:attributeGroup
       </documentation>
     </annotation>
     <attributeGroup name="SinceUntil">
   		<xs:attribute
       <attribute name="since" type="xs:dateTime"/>
   		<xs:attribute type="dateTime"/>
       <attribute name="until" type="xs:dateTime"/>
   	</xs:attributeGroup>
   	<xs:simpleType type="dateTime"/>
     </attributeGroup>

     <simpleType name="tokenlist">
   		<xs:list itemType="xs:token"/>
   	</xs:simpleType>
   	<xs:element name="activities">
   		<xs:complexType>
   			<xs:sequence>
   				<xs:element name="activity" minOccurs="0" maxOccurs="unbounded">
   					<xs:simpleType>
   						<xs:restriction base="xs:token">
   							<xs:enumeration value="holiday"/>
   							<xs:enumeration value="on-the-phone"/>
   							<xs:enumeration value="away"/>
   							<xs:enumeration value="appointment"/>
   							<xs:enumeration value="meal"/>
   							<xs:enumeration value="meeting"/>
   							<xs:enumeration value="steering"/>
   							<xs:enumeration value="in-transit"/>
   							<xs:enumeration value="travel"/>
   							<xs:enumeration value="vacation"/>
   							<xs:enumeration value="sleeping"/>
   							<xs:enumeration value="busy"/>
   							<xs:enumeration value="permanent-absence"/>
   						</xs:restriction>
   					</xs:simpleType>
   				</xs:element>
   				<xs:any maxOccurs="unbounded"/>
   			</xs:sequence>
   		</xs:complexType>
   	</xs:element>
   	<xs:element name="placetype">
   		<xs:complexType>
   			<xs:simpleContent>
   				<xs:extension base="tokenlist">
   					<xs:attributeGroup ref="SinceUntil"/>
   				</xs:extension>
   			</xs:simpleContent>
   		</xs:complexType>
   	</xs:element>
   	<xs:element
       <list itemType="token"/>
     </simpleType>

     <element name="privacy">
   		<xs:complexType>
       <complexType name='privacy-list'>
         <sequence>
          <choice>
            <element name='audio' type='rp:empty'/>
            <element name='video' type='rp:empty'/>
            <element name='text'  type='rp:empty'/>
          </choice>
         </sequence>
         <attributeGroup ref="rp:SinceUntil"/>
       </complexType>
     </element>

     <element name="status-icon" type="anyURI"/>

     <element name="user-input">
       <complexType>
         <attribute name="idle-threshold" type="positiveInteger"/>
         <attribute name="since" type="dateTime"/>
       </complexType>
     </element>

     <simpleType name='empty'>
       <restriction base='string'>
         <enumeration value=''/>
       </restriction>



Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                [Page 12] 24]

Internet-Draft                    RPID                        March                      October 2004


   			<xs:simpleContent>
   				<xs:extension base="tokenlist">
   					<xs:attributeGroup ref="SinceUntil"/>
   				</xs:extension>
   			</xs:simpleContent>
   		</xs:complexType>
   	</xs:element>
   	<xs:element name="sphere">
   		<xs:complexType>
   			<xs:simpleContent>
   				<xs:extension base="tokenlist">
   					<xs:attributeGroup ref="SinceUntil"/>
   				</xs:extension>
   			</xs:simpleContent>
   		</xs:complexType>
   	</xs:element>
   	<xs:element name="idle">
   		<xs:complexType>
   			<xs:attribute name="since" type="xs:dateTime"/>
   		</xs:complexType>
   	</xs:element>
   </xs:schema>




7.


     </simpleType>
   </schema>





6.  IANA Considerations

   This document calls for IANA to:

   o  register two new XML namespace URNs per [6];
   o  establish registry registries for activity categories <activities> (Section 4.2), place
      types 3.2), <mood>
      (Section 4.6), 3.4) <place-type> (Section 3.5), <privacy> (Section 3.6,
      and relationships <relationship> (Section 4.8). 3.7) categories.

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

7.1

6.1  URN Sub-Namespace Registration for
    'urn:ietf:params:xml:ns:pidf:status:rpid-status'

   URI: urn:ietf:params:xml:ns:pidf:status:rpid-status
   Description: This is the XML namespace for XML elements defined by
      RFC&rfc.number
      RFCXXXX [RFC editor:  replace with RFC number]; 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 September 18, 2004              [Page 13]

Internet-Draft                    RPID                        March 2004
   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 (status)</h1>
          <h2>urn:ietf:params:xml:ns:pidf:status:rpid-status</h2>
          <p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
   editor: replace with RFC number]</a>.</p>
       </body>



Schulzrinne, et al.      Expires April 25, 2005                [Page 25]

Internet-Draft                    RPID                      October 2004


       </html>
      END


7.2


6.2  URN Sub-Namespace Registration for
    'urn:ietf:params:xml:ns:pidf:rpid-tuple'

   URI: urn:ietf:params:xml:ns:pidf:rpid-tuple
   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 tuple element in the PIDF
      presence document format in the application/pidf+xml content type.
   Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
      Henning Schulzrinne, hgs@cs.columbia.edu.
   XML:















Schulzrinne, et al.    Expires September 18, 2004              [Page 14]

Internet-Draft                    RPID                        March 2004

    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 (tuple)</h1>
          <h2>urn:ietf:params:xml:ns:pidf:rpid-tuple</h2>
          <p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
   editor: replace with RFC number]</a>.</p>
       </body>
       </html>
      END



7.3



6.3  Schema Registration for Schema
    urn:ietf:params:xml:ns:pidf:rpid-tuple'

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

7.4 5.2

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




Schulzrinne, et al.      Expires April 25, 2005                [Page 26]

Internet-Draft                    RPID                      October 2004


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

7.5 5.3

6.5  Token Registrations

   This document creates new IANA registries for RPID tokens:

   contact-type: elements:

   activities: See Section 4.4
   placetype: 3.2
   mood: See Section 4.6 3.4
   place-type: See Section 3.5
   privacy: See Section 4.7 3.6
   relationship: See Section 4.8 3.7

   All are XML tokens.  Registered tokens must be documented at the time
   of registration, as most descriptions are expected to be brief.




Schulzrinne, et al.    Expires September 18, 2004              [Page 15]

Internet-Draft                    RPID                        March 2004

   Following the policies outline in RFC 2434 [3], these tokens are
   assigned after Expert Review by the SIMPLE working group or its
   designated successor.  Each registration must include the name of the
   token and a brief description similar to the ones offered in for the
   initial registrations contained this document:

   Name of token: XML token describing the contact type, place type,
      privacy or relationship.
   Description: Brief description indicating the meaning of the token.

8.

7.  Security Considerations

   The security considerations in [7] apply, as well as [8].  Compared
   to PIDF, this presence document format reveals additional information
   that can be highly sensitive.  Beyond traditional security measures
   to protect confidentiality and integrity, systems should offer a
   means to selectively reveal information to particular watchers and to
   inspect the information that is being published, particularly if it
   is generated automatically from other sources, such as calendars or
   sensors.

8.  References

8.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]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA



Schulzrinne, et al.      Expires April 25, 2005                [Page 27]

Internet-Draft                    RPID                      October 2004


        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

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

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

   [7]  Sugano, H. and S. Fujimoto, "Presence Information Data Format
        (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
        2003.

   [8]  Rosenberg, J., "A Presence Event Package for the Session
        Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
        in progress), January 2003.




Schulzrinne, et al.    Expires September 18, 2004              [Page 16]

Internet-Draft                    RPID                        March 2004


Informative References

   [9]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April  W3C, "Extensible Markup Language (XML) 1.0", W3C Recommendation
        XML 1.0, February 1998.

8.2  Informative References

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

   [11]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [12]  Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for
         User Control of Internet Telephony Services",
         draft-ietf-iptel-cpl-08
         draft-ietf-iptel-cpl-09 (work in progress), August 2003.

   [13]  Dawson, F., Reddy, S., Royer, D. and E. Plamondon, "iCalendar
         DTD Document (xCal)", draft-ietf-calsch-many-xcal-02 April 2004.

   [12]  Rosenberg, J., "A Data Model for Presence",
         draft-rosenberg-simple-presence-data-model-00 (work in
         progress), July 2004.

   [13]  Eggert, P., "Sources for time zone and daylight saving time
         data".

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

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







Schulzrinne, et al.      Expires April 25, 2005                [Page 28]

Internet-Draft                    RPID                      October 2004


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








Schulzrinne, et al.    Expires September 18, 2004              [Page 17]

Internet-Draft                    RPID                        March 2004


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

   EMail: pkzivat@cisco.com


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

   EMail: jdrosen@dynamicsoft.com

Appendix A.  Acknowledgements

   The document reflects the discussion on the SIMPLE mailing list, with
   contributions from many individuals.  Aki Niemi, Miguel Garcia,
   Markus Isomaki, Hisham Khartabil, Paul Kyzivat, Eva-Maria Leppanen,
   Mikko Lonnfors, Jon Peterson and Brian Rosen provided detailed



Schulzrinne, et al.      Expires April 25, 2005                [Page 29]

Internet-Draft                    RPID                      October 2004


   comments and suggestions.  Xiaotao Wu assisted with schema testing.


















































Schulzrinne, et al.      Expires September 18, 2004 April 25, 2005                [Page 18] 30]

Internet-Draft                    RPID                        March                      October 2004


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 IETF's procedures with respect to rights in IETF Documents 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 (2004).  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 September 18, 2004 April 25, 2005                [Page 19] 31]

----