[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-simple-rpids) 00 01 02 03 04 05 06 07 08 09 10 RFC 4480

SIMPLE                                                    H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: September 11, 2004                                   V. Gurbani
                                                                  Lucent
                                                              P. Kyzivat
                                                                   Cisco
                                                            J. Rosenberg
                                                             dynamicsoft
                                                          March 13, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3667.

   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 September 11, 2004.

Copyright Notice

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

Abstract

   The Rich Presence Information Data Format (RPID) adds elements to the
   Presence Information Data Format (PIDF) that provide additional
   information about the presentity and its contacts.  The information
   is designed so that much of it can be derived automatically, e.g.,



Schulzrinne, et al.    Expires September 11, 2004               [Page 1]


Internet-Draft                    RPID                        March 2004


   from calendar files or user activity.

   This extension includes information about what the presentity is
   doing (the activity element), a grouping identifier for a tuple (the
   class element), the type of tuple (the contact-type element), whether
   a contact is idle (the idle element), the typle of place a presentity
   is in (the placetype element), whether the presentity is in a public
   or private space (the privacy element), the relationship of a tuple
   to another presentity (the relationship element), and the overall
   role of the presentity (the sphere element).

Table of Contents

   1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Conventions  . . . . . . . . . . . . . . . . .  3
   3.  The Meaning of "open" and "closed" . . . . . . . . . . . . . .  3
   4.  RPID Elements  . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.2 Activities Element . . . . . . . . . . . . . . . . . . . . . .  4
   4.3 Class  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.4 Contact-Type Element . . . . . . . . . . . . . . . . . . . . .  6
   4.5 Idle Element . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.6 Type of Place Element  . . . . . . . . . . . . . . . . . . . .  7
   4.7 Privacy Element  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.8 Relationship Element . . . . . . . . . . . . . . . . . . . . .  8
   4.9 Sphere Element . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.1 Presentity with Activity . . . . . . . . . . . . . . . . . . .  9
   6.  XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 10
   6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple . . . . . . . . . . . . 11
   6.2 urn:ietf:params:xml:ns:pidf:status:rpid-status . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.1 URN Sub-Namespace Registration for
       'urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . . . 13
   7.2 URN Sub-Namespace Registration for
       'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 14
   7.3 Schema Registration for Schema
       urn:ietf:params:xml:ns:pidf:rpid-tuple'  . . . . . . . . . . . 15
   7.4 Schema Registration for Schema
       urn:ietf:params:xml:ns:pidf:status:rpid-status'  . . . . . . . 15
   7.5 Token Registrations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
       Normative References . . . . . . . . . . . . . . . . . . . . . 16
       Informative References . . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19




Schulzrinne, et al.    Expires September 11, 2004               [Page 2]


Internet-Draft                    RPID                        March 2004


1. Scope

   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
   closed) and a URI for communication.  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
   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 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. The Meaning of "open" and "closed"

   PIDF describes the basic status values of "open" or "closed" only as
   "have meanings of general availability for other communications
   means". We define "closed" in our context as meaning that
   communication to the contact address will in all likelihood not
   succeed, is undesired or will not reach the intended party.  (For
   example, a presentity may include a hotel phone number as a contact.
   After check-out, the phone number will still ring, but reach the
   chambermaid or the next guest.  Thus, it would be declared "closed".)
   For "pres" contacts, "closed" means that no presence status
   information is available.


4. RPID Elements

4.1 Introduction

   Below, we describe the RPID elements in detail.  <activities>,
   <idle>, <placetype> and <privacy> extend the PIDF <status> element,
   while <class>, <contacttype> and <relationship> extend the PIDF



Schulzrinne, et al.    Expires September 11, 2004               [Page 3]


Internet-Draft                    RPID                        March 2004


   <tuple> element.

   In general, it is highly unlikely that a presentity will publish or
   announce all of these elements at the same time.  Rather, these
   elements were chosen to give the presentity maximum flexibility in
   deriving this information from existing sources, such as calendaring
   tools, device activity sensors or location trackers, as well as to
   manually configure this information.

   The namespace URIs for these elements defined by this specification
   are URNs [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:status:rpid-tuple

   This document uses a separate namespace for extending the PIDF
   'status' namespace, in accordance with Section 4.2.5 of [7].

   All elements described in this document are optional.

   The elements <activity>, <placetype>, <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.

4.2 Activities Element

   The <activities> element describes what the presentity is currently
   doing.  This can be quite helpful to the watcher in judging how
   appropriate a communication attempt is and which means of
   communications is most likely to succeed and not annoy the
   presentity. The activity indications correspond roughly to the
   category field in calendar entries, such as Section 4.8.1.2 of RFC
   2445 [10].

   An activity enumeration consists of one or more values drawn from the
   list below, any other token string or IANA-registered values (Section
   Section 7).

   Depending on the presentity intent, all but the "permanent-absence"
   indication can be used with either status OPEN or CLOSED.






Schulzrinne, et al.    Expires September 11, 2004               [Page 4]


Internet-Draft                    RPID                        March 2004


   on-the-phone: The presentity is talking on the telephone. This
      activity is included since it can often be derived automatically.
   away: The presentity is physically away from the device location.
      This activity was included since it can often be derived
      automatically from security systems, energy management systems or
      entry badge systems.
   appointment: The presentity has a calendar appointment, without
      specifying exactly of what type.  This activity is indicated if
      more detailed information is not available or the presentity
      choses not to reveal more information.
   holiday: This is a scheduled national or local holiday. This
      information can typically be derived automatically from calendars.
   meal: The presentity is scheduled for a meal.  This activity category
      can often be generated automatically from a calendar.
   meeting: A meeting is a sub-class of an appointment. This activity
      category can often be generated automatically from a calendar.
   steering: The presentity is controlling a vehicle, ship or plane.
   in-transit: The presentity is riding in a vehicle, such as a car, but
      not steering.  The 'placetype' element provides more specific
      information about the type of conveyance the presentity is using.
   travel: The presentity is on a business or personal trip, but not
      necessarily in-transit.  This category can often be generated
      automatically from a calendar.
   vacation: Leisure travel.  This activity category can often be
      generated automatically from a calendar.
   sleeping: This activity category can often be generated automatically
      from a calendar, local time information or biometric data.
   busy: User is busy, without further details. While this activity
      would typically be associated with a status of CLOSED, a
      presentity may declare itself busy to discourage communication,
      but indicate that it still can be reached if needed.
   permanent-absence: Presentity 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.

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

   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' or 'presentity', these components
   can engage in multiple types of activities, particularly if qualified
   by a <relationship> element.  In those cases, 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.



Schulzrinne, et al.    Expires September 11, 2004               [Page 5]


Internet-Draft                    RPID                        March 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.  The
   naming of classes is left to the presentity.  The presentity can use
   this information to group similar tuples or to convey information
   that the presence agent can use for filtering.


4.4 Contact-Type Element

   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 a common
   service ("service"), or 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 is to answer when contacting
   that device.  A device that has not been used in a while may still be
   OPEN, but a watcher may choose to first contact a device that 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, a
   tuple describing an instant messaging device expresses the last time
   that the PC or PDA was used, not the last time an instant message has
   been sent.

   For tuples representing a 'presentity' or 'service' with multiple
   devices, the device with the most recent usage, i.e., the shortest
   idle time, determines the idle time for the whole tuple.

   The use of 'idle' for tuples with contact-type 'in-person' is not
   defined.

   The <idle> element can be empty if the presentity wants to indicate
   that the device has not been used for a while, but does not want to
   reveal the precise duration, as in:

     <idle/>

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



Schulzrinne, et al.    Expires September 11, 2004               [Page 6]


Internet-Draft                    RPID                        March 2004


   to omit the timestamp.

4.6 Type of Place Element

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

   home: The presentity is in a private or residential setting, not
      necessarily the personal residence of the presentity, e.g.,
      including hotel or a friend's home.
   office: The presentity is in a business setting, such as an office.
   quiet: The presentity is in a place such as a library, restaurant,
      place-of-worship, or theater that discourages noise, conversation
      and other distractions.
   public: The presentity is in a public area such as a shopping mall,
      street, park, public building, train station, airport or in public
      conveyance such as a bus, train, plane or ship.  This general
      description encompasses the more precise descriptors 'street',
      'public-transport', 'aircraft', 'ship', 'bus', 'train', 'airport',
      'mall' and 'outdoors' below.
   street: Walking in a street.
   public-transport: Any form of public transport, including aircraft,
      bus, train or ship.
   aircraft: The presentity is in a plane, helicopter or balloon.
   ship: Water vessel, boat.
   bus: Public or charter bus.
   train: The presentity is traveling in a train, monorail, maglev,
      cable car or similar conveyance.
   airport: Airport, heliport or similar location.
   station: Bus or train station.
   mall: Shopping mall or shopping area.
   outdoors: General outdoors area, such as a park or city streets.

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

   The <placetype> 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' or 'presentity', these devices can
   be in multiple types of places.  In those cases, the <placetype>
   element enumerates all unique values as a token list.

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





Schulzrinne, et al.    Expires September 11, 2004               [Page 7]


Internet-Draft                    RPID                        March 2004


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 to see or hear the communications.
   private: Inappropriate individuals are not likely to see 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 the audience.

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

4.8 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", "associate"
   (e.g., for a colleague), "assistant", "supervisor".  Other free-text
   values and additional IANA-registered values (Section 7) can be used
   as well.

   If a relationship is indicated, the RPID <status> values describe the
   <contact>, not the presentity.

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

4.9 Sphere Element

   The <sphere> element designates the current state and role that the
   presentity plays.  For example, it might describe whether the
   presentity 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 does not define names for these spheres except
   for two common ones, "work" and "home".

   Spheres are likely to be used for two purposes:  they allow the
   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 the presentity is a Boy Scout leader, he might set



Schulzrinne, et al.    Expires September 11, 2004               [Page 8]


Internet-Draft                    RPID                        March 2004


   the sphere to 'scouting' and then have 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' or 'home' or some other sphere, the
   fellow scouts would lose access.

   The <sphere> element can be used with tuples of all values of
   <contact-type>.  For tuples representing multiple physical devices,
   <contact-type> 'service' or 'presentity', these devices can be
   controlled by people in multiple different spheres.  In those cases,
   the <sphere> element enumerates all unique values as a token list.

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

5. Examples

5.1 Presentity with Activity


   <?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:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     entity="pres:someone@example.com">
    <tuple id="c8dqui">
     <status>
      <basic>open</basic>
      <ep:relationship>assistant</ep:relationship>
     </status>
     <et:class>assistant</et:class>
     <et:contact-type>presentity</et:contact-type>
     <contact>sip:secretary@example.com</contact>
     <note>My secretary</note>
    </tuple>
    <tuple id="x765">
     <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>
     </status>
     <et:class>sip</et:class>
     <et:contact-type>service</et:contact-type>
     <contact priority="0.8">sip:someone@example.com</contact>
     <timestamp>2001-10-27T16:49:29Z</timestamp>



Schulzrinne, et al.    Expires September 11, 2004               [Page 9]


Internet-Draft                    RPID                        March 2004


    </tuple>
    <tuple id="bs9r">
     <status>
      <basic>open</basic>
      <ep:privacy>quiet</ep:privacy>
     </status>
     <contact priority="0.8">im:someone@mobilecarrier.net</contact>
     <timestamp>2001-10-27T16:49:29Z</timestamp>
    </tuple>
    <tuple id="eg92n">
     <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>
   </presence>




6. XML Schema Definitions


























Schulzrinne, et al.    Expires September 11, 2004              [Page 10]


Internet-Draft                    RPID                        March 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"
     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"/>

     <xs:annotation>
       <xs:documentation xml:lang="en">
            Describes RPID tuple 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


   <?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" 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"/>
        <xs:annotation>



Schulzrinne, et al.    Expires September 11, 2004              [Page 11]


Internet-Draft                    RPID                        March 2004


                <xs:documentation xml:lang="en">
       Describes RPID status extensions for PIDF.
       </xs:documentation>
        </xs:annotation>
        <xs:attributeGroup name="SinceUntil">
                <xs:attribute name="since" type="xs:dateTime"/>
                <xs:attribute name="until" type="xs:dateTime"/>
        </xs:attributeGroup>
        <xs: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 name="privacy">
                <xs:complexType>



Schulzrinne, et al.    Expires September 11, 2004              [Page 12]


Internet-Draft                    RPID                        March 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. IANA Considerations

   This document calls for IANA to:

   o  register two new XML namespace URNs per [6];
   o  establish registry for activity categories (Section 4.2), place
      types (Section 4.6), and relationships (Section 4.8).

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

7.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 [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 September 11, 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>
       </html>
      END


7.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 11, 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 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 Schema Registration for Schema
    urn:ietf:params:xml:ns:pidf:status:rpid-status'

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

7.5 Token Registrations

   This document creates new IANA registries for RPID tokens:

   contact-type: See Section 4.4
   placetype: See Section 4.6
   privacy: See Section 4.7
   relationship: See Section 4.8

   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 11, 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.

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

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

Informative References

   [9]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.



Schulzrinne, et al.    Expires September 11, 2004              [Page 16]


Internet-Draft                    RPID                        March 2004


   [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 (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 (work in
         progress), July 2002.


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: pkzivat@cisco.com



Schulzrinne, et al.    Expires September 11, 2004              [Page 17]


Internet-Draft                    RPID                        March 2004


   Jonathan Rosenberg
   dynamicsoft
   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.  Markus Isomaki, Hisham
   Khartabil, Jon Peterson and Brian Rosen provided detailed comments
   and suggestions. Xiaotao Wu assisted with schema testing.





































Schulzrinne, et al.    Expires September 11, 2004              [Page 18]


Internet-Draft                    RPID                        March 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 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 11, 2004              [Page 19]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/