SIMPLE H. Schulzrinne Internet-Draft Columbia U. Expires: April 25, 2005 V. Gurbani Lucent P. Kyzivat J. Rosenberg Cisco October 25, 2004 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) 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, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media might be private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers and the overall role of the 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . 5 3. RPID Elements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Activities Element . . . . . . . . . . . . . . . . . . . . 7 3.3 Class Element . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Mood Element . . . . . . . . . . . . . . . . . . . . . . . 9 3.5 Place-type Element . . . . . . . . . . . . . . . . . . . . 11 3.6 Privacy Element . . . . . . . . . . . . . . . . . . . . . 12 3.7 Relationship Element . . . . . . . . . . . . . . . . . . . 13 3.8 Service Class . . . . . . . . . . . . . . . . . . . . . . 13 3.9 Sphere Element . . . . . . . . . . . . . . . . . . . . . . 13 3.10 Status-Icon Element . . . . . . . . . . . . . . . . . . 14 3.11 Time Zone . . . . . . . . . . . . . . . . . . . . . . . 14 3.12 User-Input Element . . . . . . . . . . . . . . . . . . . 14 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. XML Schema Definitions . . . . . . . . . . . . . . . . . . . 17 5.1 urn:ietf:params:xml:ns:pidf:rpid-person . . . . . . . . . 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 . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 6.1 URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . 25 6.2 URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . 26 6.3 Schema Registration for Schema urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . 26 6.4 Schema Registration for Schema urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . 26 6.5 Token Registrations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 8.2 Informative References . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . 31 Schulzrinne, et al. Expires April 25, 2005 [Page 3] Internet-Draft RPID October 2004 1. Introduction The Presence Information Data Format (PIDF) definition [7] describes a basic presence information data format, encoded as an Extensible Markup Language (XML) document, for exchanging presence information in CPIM-compliant systems. It consists of a root element, zero or more elements carrying presence information including a Universal Resource Identifier (URI) for communication. zero or more elements and zero or more extension elements from other name spaces. Each tuple defines a basic status of either "open" or "closed". 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 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. The presence data model [12] defines the concepts of service, device, and person as the data elements that are used to model the state of a presentity. Services are encoded using the element, defined in PIDF; devices and persons are represented by the and XML elements, respectively, defined in the the data model [12]. However, neither PIDF nor the data model define presence attributes beyond the status element. This specification defines additional presence attributes to describe person, service and device data elements, summarized as "Rich Presence Information Data Format for Presence" (RPID). These attributes are specified by XML elements which extend the PIDF element and the and elements defined in the data model. This extension has two main goals: 1. Provide rich presence indication that is at least as powerful as common commercial presence systems. Such feature-parity simplifies transition to CPIM-compliant systems, both in terms of user acceptance and protocol conversion. 2. Maintain backwards-compatibility with PIDF, so that PIDF-only watchers and gateways can continue to function properly, naturally without access to the functionality described here. Schulzrinne, et al. Expires April 25, 2005 [Page 4] Internet-Draft RPID October 2004 We make no assumptions how the information in the RPID is generated. Experience has shown that users are not always diligent about updating their presence status. Thus, we want to make it as easy as possible to derive RPID information from other information sources, such as calendars, the status of communication devices such as telephones, typing activity and physical presence detectors as commonly found in energy-management systems. Many of the elements correspond to data commonly found in personal calendars. Thus, we attempted to align some of the extensions with the usage found in calendar formats such as iCal [10]. The information in a presence document can be generated by a single entity or can be composed from information published by multiple entities. Note that PIDF documents and this extension can be used in two different contexts, namely by the presentity to publish its presence status and by the presence server to notify some set of watchers. The presence server MAY compose, translate or filter the published presence state before delivering customized presence information to the watcher. For example, it may merge presence information from multiple PUAs, remove whole elements, translate values in elements or remove information from elements. Mechanisms that filter calls and other communications to the presentity can subscribe to this presence information just like a regular watcher and in turn generate automated rules, such as scripts [11], that govern the actual communications behavior of the presentity. Details are described in the data model document. Since RPID is a PIDF XML document, it also uses the content type application/pidf+xml. 2. Terminology and Conventions This memo makes use of the vocabulary defined in the IMPP Model document [5]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are used in the same meaning as defined therein. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. 3. RPID Elements 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 , or , respectively. Furthermore, some are dynamic status information, and others describe more static characteristics, and thus may extend or the root , or elements. Below, we describe the RPID elements in detail. The following RPID elements are defined as status attributes. activities: The status element describes what the person is doing, using an enumeration of elements. mood: The status element indicates the mood of the person. place-type: The status elements reports the type of place the person is located in. sphere: The element characterizes the overall role of the presentity. status-icon: The element depicts the current status of the person. timezone: The status element names the timezone the person finds itself in. The following RPID element is defined for , and elements: class: An identifier that groups similar person elements, devices or services. The following RPID element is defined for both and attributes: user-input: The 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 : privacy: The element distinguishes whether the communication service is likely to be observable by other parties. relationship: When a service is likely to reach a user besides the person associated with the presentity, the relationship indicates how that user relates to the person. Relationship is a characteristic. service-type: The element describes whether the service is delivered electronically, is a postal or delivery service or describes in-person communications. status-icon: The 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 namespace, in accordance with Sections 4.2.5 and 4.3.2 of [7]. All elements described in this document are optional. The elements , , and 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 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 element describes what the person is currently doing, expressed as an enumeration of 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 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 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 element provides more specific information about the type of conveyance the person is using. meal: The person 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. 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 a status of CLOSED across all services. Schulzrinne, et al. Expires April 25, 2005 [Page 8] Internet-Draft RPID October 2004 sleeping: This activity category can often be generated automatically from a calendar, local time information or biometric data. steering: The person is controlling a vehicle, ship or plane. travel: The person is on a business or personal trip, but not necessarily in-transit. This category can often be generated automatically from a calendar. vacation: Leisure travel. This activity category can often be generated automatically from a calendar. The element MAY be qualified with the 'since' and 'until' attributes as described in Section 3. If the entity described by a tuple is involved in multiple activities at the same time, the element enumerates all unique values as child elements. The 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 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 can use this information to group similar services, devices or person elements or to convey information that the presence agent can use for filtering or authorization. 3.4 Mood Element The element describes the mood of the presentity. They are enumerated chosen by the presentity. The mood itself is provided as the element name of a defined child element of the element (e.g., ); one such child element is REQUIRED. The user MAY also specify a natural-language description of, or reason for, the mood in the child of the element, which is OPTIONAL. (This definition follows the Jabber Extension JEP-107.) It is RECOMMENDED that an implementation support the mood values proposed in Jabber Extension JEP-0107, which in turn are a superset of the Wireless Village [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 element describes the type of place the person is currently at. This offers the watcher an indication what kind of communication is likely to be appropriate. We define an initial set of values below: aircraft: The person is in a plane, helicopter or balloon. airport: The person is located in an airport, heliport or similar location. bus: The person is travling in a public or charter bus. car: The person is in an automobile. home: The person is in a private or residential setting, not necessarily the personal residence of the person, e.g., including hotel or a friend's home. hotel: The person is in a hotel, motel, inn or other lodging establishment. industrial: The person is in an industrial setting, such as a manufacturing floor or power plant. library: The person is in a library or other public place that provides access to books, music and reference materials. mall: The person is frequenting a shopping mall or shopping area. noisy: The person is in a place with lots of background noise. office: The person is in a business setting, such as an office. outdoors: The person is in a general outdoors area, such as a park or city streets. public: The person is in a public area such as a shopping mall, street, park, public building, train station, airport or in public conveyance such as a bus, train, plane or ship. This general description encompasses the more precise descriptors "street", "public-transport", "aircraft", "ship", "bus", "train", "airport", "mall" and "outdoors" below. public-transport: The person is using any form of public transport, including aircraft, bus, train or ship. quiet: The person is in a place such as a library, restaurant, place-of-worship, or theater that discourages noise, conversation and other distractions. Schulzrinne, et al. Expires April 25, 2005 [Page 11] Internet-Draft RPID October 2004 restaurant: The person is in a restaurant, coffee shop or other public dining establishment. school: The person is in a school or university, but not necessarily in a classroom or library. ship: The person is traveling in a water vessel or boat. station: The person is located in a bus or train station. street: The person is walking in a street. theater: The person is in a theater, lecture hall, auditorium, class room, movie theater or similar facility designed for presentations, talks, plays, music performances and other events involving an audience. train: The person is traveling in a train, monorail, maglev, cable car or similar conveyance. truck: The person is in a truck, used primarily to carry goods rather than people. This list can be augmented by free-text values or additional IANA-registered values (Section 6). The element is a tokenlist, e.g., street noisy public The element MAY be qualified with the 'since' and 'until' attributes as described in Section 3. 3.6 Privacy Element The element indicates which type of communication third parties in the vicinity of the presentity are unlikely to be able to intercept accidentally or intentionally. This does not in any way describe the privacy properties of the electronic communication channel, e.g., properties of the encryption algorithm 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 likely to see text communications. The element can be used by logic executing on the watcher or by a composer to filter, sort and label tuples. For example, a composer may have rules that limit the publication of tuples labeled as "private" to a select subset of the watchers. The element MAY be qualified with the 'since' and 'until' Schulzrinne, et al. Expires April 25, 2005 [Page 12] Internet-Draft RPID October 2004 attributes as described in Section 3. 3.7 Relationship Element The element extends and designates the type of relationship an alternate contact has with the presentity. This element is provided only if the tuple refers to somebody other than the presentity. Relationship values include "family", "associate" (e.g., for a colleague), "assistant", "supervisor". Other free-text values and additional IANA-registered values (Section 6) can be used as well. If a relationship is indicated, the URI in the element refers to the entity, such as the assistant, that has a relationship to the presentity, not the presentity itself. Like tuples without a qualifier, the element for tuples labeled with a relationship can contain either a communication URI such as "im", "sip", "sips", "h323", "tel" or "mailto", or a presence URI, such as "pres" or "sip". 3.8 Service Class The element extends and designates the type of service offered, namely electronic, delivery (including courier), postal or in-person. Electronic service is implied if omitted. The 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 geospatial coordinates, civic addresses or some specialized address format, e.g., for interstellar addresses or a company-specific delivery system. 3.9 Sphere Element The element designates the current state and role that the person plays. For example, it might describe whether the person is in a work mode or at home or participating in activities related to some other organization such as the IETF or a church. This document 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 person to easily turn on or off certain rules that depend on what groups of people should be made aware of the person's status. For example, if the person is a Boy Scout leader, he might set the sphere to "scouting" and then have a rule set that allows other scout Schulzrinne, et al. Expires April 25, 2005 [Page 13] Internet-Draft RPID October 2004 masters in his troop to see his presence status. As soon as he switches his status to "work" or "home" or some other sphere, the fellow scouts would lose access. The element MAY be qualified with the 'since' and 'until' attributes as described in Section 3. 3.10 Status-Icon Element The element includes a URI pointing to an image (icon) representing the current status of the person or service. The watcher MAY use this information to represent the status in a graphical user interface. Presentities SHOULD provide images of sizes and aspect ratios that are appropriate for rendering as an icon. Support for JPEG, PNG and GIF formats is RECOMMENDED. 3.11 Time Zone The element describes the current time zone of the presentity. The timezone is described by a time zone identifier. If it begins with a forward slash (solidus), it references a to-be-defined global time zone registry; otherwise it is locally-defined at the server. While labels that do not begin with a 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 element records the user-input or usage state of the service or device, based on human user input, e.g., keyboard, pointing device or voice. The element can assume one of two values, namely 'active' or 'idle', with an optional 'since' attribute that records when the last user input has been received. An optional 'idle-threshold' element records how long the presentity will wait before reporting the service or device to be idle, measured in seconds. (A two-state model was chosen since it would otherwise be necessary to send repeated last-input updates during continuous activity.) A service that wants to indicate user input activity sends a 'active' indication when the user has provided user input within a configurable interval of time, the idle-threshold. If the user ceases to provide input and the idle threshold has elapsed, Schulzrinne, et al. Expires April 25, 2005 [Page 14] Internet-Draft RPID October 2004 the tuple is marked with a 'idle' indication instead, optionally including the time of last activity in the 'since' attribute. An example is below: active Depending on device or service capabilities, user input may be detected only for a particular application, i.e., when the application has user focus or when a user has sent a message or placed a call, or can be based on user input across all applications running on one end system. The element may be used by a watcher, typically in combination with other data, to estimate how likely a user is to answer when contacting the service. A tuple that has not been used in a while may still be OPEN, but a watcher may choose to first contact a URI in a tuple that is both OPEN and has been used more recently. The attribute can be omitted if the presentity wants to indicate that the device has not been used for a while, but does not want to reveal the precise duration, as in: idle Configuration MUST include the option to omit the 'since' attribute. 4. Example The example below describes the presentity 'pres:someone@example.com', which has a SIP contact, 'sip:someone@example.com', representing a service. It also has a device contact, as an email box. The presentity is in a meeting, in a public office setting. The 'until' information indicates that he will be there until 5.30 pm GMT. The presentity also has an assistant, sip:secretary@example.com, who happens to be available for communications. open assistant assistant sip:secretary@example.com My secretary open meeting office public sip sip:someone@example.com 2001-10-27T16:49:29Z open private America/New_York im:someone@mobilecarrier.net 2001-10-27T16:49:29Z open mail mailto:someone@example.com I'm in a boring meeting closed in-person Closed-door meeting Schulzrinne, et al. Expires April 25, 2005 [Page 16] Internet-Draft RPID October 2004 I got my paycheck! 5. XML Schema Definitions 5.1 urn:ietf:params:xml:ns:pidf:rpid-person Describes RPID tuple extensions for PIDF. Schulzrinne, et al. Expires April 25, 2005 [Page 17] Internet-Draft RPID October 2004 Schulzrinne, et al. Expires April 25, 2005 [Page 18] Internet-Draft RPID October 2004 Schulzrinne, et al. Expires April 25, 2005 [Page 19] Internet-Draft RPID October 2004 Schulzrinne, et al. Expires April 25, 2005 [Page 20] Internet-Draft RPID October 2004 5.2 urn:ietf:params:xml:ns:pidf:rpid-tuple Describes RPID tuple extensions for PIDF. Schulzrinne, et al. Expires April 25, 2005 [Page 21] Internet-Draft RPID October 2004 5.3 urn:ietf:params:xml:ns:pidf:status:rpid-status Schulzrinne, et al. Expires April 25, 2005 [Page 22] Internet-Draft RPID October 2004 Describes RPID status extensions for PIDF. 5.4 urn:ietf:params:xml:ns:pidf:rpid-device Describes RPID status extensions for PIDF. Schulzrinne, et al. Expires April 25, 2005 [Page 24] Internet-Draft RPID October 2004 6. IANA Considerations This document calls for IANA to: o register two new XML namespace URNs per [6]; o establish registries for (Section 3.2), (Section 3.4) (Section 3.5), (Section 3.6, and (Section 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. 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 RFCXXXX [RFC editor: replace with RFC number] to describe rich presence information extensions for the status element in the PIDF presence document format in the application/pidf+xml content type. Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, Henning Schulzrinne, hgs@cs.columbia.edu XML: BEGIN RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)

Namespace for rich presence extension (status)

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

See RFC&rfc.number; [RFC editor: replace with RFC number].

Schulzrinne, et al. Expires April 25, 2005 [Page 25] Internet-Draft RPID October 2004 END 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: BEGIN RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)

Namespace for rich presence extension (tuple)

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

See RFC&rfc.number; [RFC editor: replace with RFC number].

END 6.3 Schema Registration for Schema urn:ietf:params:xml:ns:pidf:rpid-tuple' URI: please assign Registrant Contact: IESG XML: See Section 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 5.3 6.5 Token Registrations This document creates new IANA registries for RPID elements: activities: See Section 3.2 mood: See Section 3.4 place-type: See Section 3.5 privacy: See Section 3.6 relationship: See Section 3.7 All are XML tokens. Registered tokens must be documented at the time of registration, as most descriptions are expected to be brief. 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. 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. [9] 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] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", draft-ietf-iptel-cpl-09 (work in progress), 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 Paul Kyzivat Cisco Systems BXB500 C2-2 1414 Massachusetts Avenue Boxborough, MA 01719 US EMail: pkzivat@cisco.com Jonathan Rosenberg 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 April 25, 2005 [Page 30] Internet-Draft RPID 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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (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 April 25, 2005 [Page 31]