Internet Engineering Task Force Internet Draft H. Schulzrinne (ed.) Columbia U. draft-ietf-simple-rpid-00.txt July 31, 2003 Expires: January 2004 RPID -- Rich Presence Information Data Format STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 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. This information can be translated into call routing behavior or be delivered to watchers, for example. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. H. Schulzrinne (ed.) [Page 1]
Internet Draft RPID July 31, 2003 1 Introduction The PIDF definition [1] describes a basic presence information data format for exchanging presence information in CPIM-compliant systems. It consists of a <presence> root element, zero or more <tuple> elements carrying presence information, 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". This document provides additional status information for presentities and defines a Rich Presence Information Data Format for Presence (RPID) to convey this information. This extension has three 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. 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. The information in a presence document can be generated by a single entity or can be composed from information published by multiple entities. 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] and xCal [11], as noted below. 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 H. Schulzrinne (ed.) [Page 2]
Internet Draft RPID July 31, 2003 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 [12], that govern the actual communications behavior of the presentity. The flow diagram below illustrates this process. presentity | --> publish | --> PA (filter) --> notification 1 to A, B, C --> notification 2 to D, E --> notification 3 to F --> notification 4 to script gen. 2 RPID Features Below, we summarize and motivate the major additional features that RPID adds to PIDF. The PIDF definition does not clearly describe what a <tuple> represents. We add an <class> element (Section 6.3) that allows a presentity to label tuples in ways that make sense to the presentity, e.g., to group similar tuples by name. The <contacttype> element describes whether a tuple is a device, a set of devices with a common address ("service"), a human face-to-face contact or a presentity. While the PIDF definition describes which means of communications are available for a presentity, it does not describe the activity that the presentity is currently engaged in. The <activity> (Section 6.2) element adds this information. The <idle> (Section 6.5) element indicates when the device was last used or simply whether it has been idle. To help the watcher gauge the appropriateness of different types of communications, we indicate the type of place the user is currently in, via the <placetype> element (Section 6.6) and hint at the privacy available via <privacy>. H. Schulzrinne (ed.) [Page 3]
Internet Draft RPID July 31, 2003 PIDF defines a <timestamp> element indicating the date and time of the status change of a tuple. RPID adds a validity period for <activity>, <placetype> and <privacy> values, as a hint how long the current status is likely to be valid. An important sub-case is that a presentity is interruptible only under unusual circumstances, after mediation by some, typically human, authority such as a secretary or supervisor. We allow the presentity to convey that certain contact addresses actually belong to a different person, presumably one that can either interrupt the presentity or otherwise assist. The <relationship> (Section 6.8) element allows to indicate that a particular tuple refers to a different principal or presentity. Note that this document does not defined a new content type. Rather, it inherits the content type from [1], namely application/cpim- pidf+xml 3 Scope This extension does not replace media negotiation mechanisms defined for SIP (e.g. SDP [2]), therefore media negotiation (e.g., choice of voice and video codecs) MUST be performed according to [3]. This extension is only aimed to give the watchers hints about the presentity's preferences, willingness and capabilities to communicate before watchers initiate SIP-based communication with the presentity. 4 Terminology and Conventions This memo makes use of the vocabulary defined in the IMPP Model document [4]. 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, MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP XX, RFC 2119 [5]. 5 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 H. Schulzrinne (ed.) [Page 4]
Internet Draft RPID July 31, 2003 information is available. The interpretation of "closed" was chosen since there is no other status value to indicate that a communications address is not reachable. Omitting the <contact> element does not work since it would confuse watchers that have not previously seen an "open" status for the same contact address. 6 RPID Elements 6.1 Introduction Below, we describe the RPID elements in detail. <activity>, <idle> <placetype>, <privacy>, <relationship>, extend the PIDF <status> element, while <class> and <contacttype> extend the PIDF <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 [6], using the namespace identifier 'ietf' defined by [7] and extended by [8]: urn:ietf:params:xml:ns:pidf:rpid-status urn:ietf:params:xml:ns:pidf:rpid-tuple 6.2 Activity Element The <activity> indication 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 [9]. Use of an enumerated, but extensible, set of activity H. Schulzrinne (ed.) [Page 5]
Internet Draft RPID July 31, 2003 categories simplifies automated generation and processing of presence information. The categories can be readily selected from a drop-down list by the user or translated from the corresponding activity field in calendars. Recipients of this information can render at least a subset as icons, automatically translate them into different languages or convert them to sound "jingles" and speech, or use them to generate call processing rules. An activity indication consists of one or more values drawn from the list below, any other token string or IANA-registered values (Section 10). Communities of interest such as a profession or an organization may define additional activity labels for their internal use. 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. 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: 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. Alternatively, the presentity MAY offer more specific information. 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: This activity category can often be generated H. Schulzrinne (ed.) [Page 6]
Internet Draft RPID July 31, 2003 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. This activity category would typically be indicated manually. Permanent-absence: Presentity will not return for the foreseeable future, e.g., because it is no longer working for the company. The activity element MAY be qualified with the 'from' and value and the time until which is element is expected to be valid. 6.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. The class description is similar in spirit to the 'class' attribute of XML elements, used to support Cascading Style Sheets. 6.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. URI schema are insufficient to distinguish the different types of tuples. For example, a SIP URI can designate a single device, a presentity or a subgroup of devices. 6.5 Idle Element The <idle> 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 the device. A device that has not been used in a while may still be OPEN, but a watcher may choose to first contact a H. Schulzrinne (ed.) [Page 7]
Internet Draft RPID July 31, 2003 device that is both OPEN and not marked as idle. 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: <idle/> The <idle> 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 to omit the timestamp. 6.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. 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. Alternatively, the more detailed indications below may be provided. 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 bus. train: The presentity is traveling in a train. H. Schulzrinne (ed.) [Page 8]
Internet Draft RPID July 31, 2003 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 10). The placetype element MAY be qualified with the 'from' and value and the time until which is element is expected to be valid. The relative to the publication of the presence information. The placetype 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 "home" tuples to a subset of the watchers. 6.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. quiet: The presentity is in a place such as a library, restaurant, place-of-worship, or theater that discourages noise, conversation and other distractions. 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 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 "quiet" to a select subset of the watchers. The activity element MAY be qualified with the 'from' and value and H. Schulzrinne (ed.) [Page 9]
Internet Draft RPID July 31, 2003 the time until which is element is expected to be valid. The relative to the publication of the presence information. 6.8 Relationship Element The <relationship> element 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 10) can be used as well. 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". 7 Examples 7.1 Presentity with Activity <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid-status" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" entity="pres:someone@example.com"> <note>I'm in a boring meeting</note> <tuple id="7c8dqui"> <et:class>assistant</et:class> <et:type>presentity</et:type> <status> <basic>open</basic> <contact>sip:secretary@example.com</contact> <ep:relationship>assistant</ep:relationship> </status> <note>My secretary</note> </tuple> <tuple id="18x765"> <et:class>sip</et:class> <et:type>service</et:type> <status> <basic>open</basic> <ep:activity>meeting</ep:meeting> <ep:placetype until="2003-01-27T17:30:00Z">office</ep:placetype> H. Schulzrinne (ed.) [Page 10]
Internet Draft RPID July 31, 2003 <ep:privacy>quiet</ep:privacy> <ep:idle>2003-01-27T10:43:00Z</ep:idle> </status> <contact priority="0.8">sip:someone@example.com</contact> <timestamp>2001-10-27T16:49:29Z</timestamp> </tuple> <tuple id="35bs9r"> <et:class>phone</et:class> <et:type>device</et:type> <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="8eg92n"> <et:class>mail</et:class> <et:type>device</et:type> <status> <basic>open</basic> </status> <contact priority="1.0">mailto:someone@example.com</contact> </tuple> </presence> 8 XML Schema Definitions H. Schulzrinne (ed.) [Page 11]
Internet Draft RPID July 31, 2003 <?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="type"> <xs:simpleType> <xs:restriction base="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:schema> H. Schulzrinne (ed.) [Page 12]
Internet Draft RPID July 31, 2003 <?xml version="1.0" encoding="UTF-8"?> <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> <xs:documentation xml:lang="en"> Describes RPID status extensions for PIDF. </xs:documentation> </xs:annotation> <xs:element name="activity"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:token"> <xs:attribute name="from" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="placetype"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:token"> <xs:attribute name="from" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:simpleType name="privacy_t"> <xs:restriction base="token"> <xs:enumeration value="private"/> <xs:enumeration value="public"/> <xs:enumeration value="quiet"/> </xs:restriction> </xs:simpleType> H. Schulzrinne (ed.) [Page 13]
Internet Draft RPID July 31, 2003 <xs:element name="privacy"> <xs:complexType> <xs:simpleContent> <xs:extension base="privacy_t"> <xs:attribute name="from" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="relationship" type="xs:token"/> <xs:element name="idle" type="xs:dateTime"/> </xs:schema> 9 Security Considerations The security considerations in [1] apply, as well as [9]. 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. Like any information retrieved by reference, the information provided in the <card>, <icon> and <info> elements may refer to data types that expose the watcher to security risks. 10 IANA Considerations This document calls for IANA to: o register two new XML namespace URNs per [8]; o establish registry for activity categories (Section 6.2), place types (Section 6.6), and relationships (Section 6.8). Note that this document does not need a new content type. It inherits the content type from [1], namely application/cpim-pidf+xml 10.1 URN Sub-Namespace Registration for URI: urn:ietf:params:xml:ns:rpid-status Description: This is the XML namespace for XML elements defined H. Schulzrinne (ed.) [Page 14]
Internet Draft RPID July 31, 2003 by RFCXXXX to describe rich presence information extensions for the status element in the PIDF presence document format in the application/cpim-pidf+xml content type. 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 Information Data Format for Presence</title> </head> <body> <h1>Namespace for rich presence extension (status)</h1> <h2>application/pidf+xml</h2> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> </body> </html> END 10.2 URN Sub-Namespace Registration for URI: urn:ietf:params:xml:ns:rpid-tuple Description: This is the XML namespace for XML elements defined by RFCXXXX to describe rich presence information extensions for the tuple element in the PIDF presence document format in the application/cpim-pidf+xml content type. H. Schulzrinne (ed.) [Page 15]
Internet Draft RPID July 31, 2003 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 Information Data Format for Presence</title> </head> <body> <h1>Namespace for rich presence extension (tuple)</h1> <h2>application/pidf+xml</h2> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> </body> </html> END 10.3 Place Type, Tuple Type, Activities, Relationships This document creates new IANA registries for activities, tuple types, place types and relationships. All are XML tokens. Registered tokens must be documented at the time of registration, as most descriptions are expected to be brief. The SIMPLE working group, or, if no longer available, the SIP working group should be consulted prior to registration. 11 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. The notion of external references in the <card>, <icon> and <info> elements is an evolution of the BINPIDF proposal by Khartabil et al. 12 References H. Schulzrinne (ed.) [Page 16]
Internet Draft RPID July 31, 2003 13 Normative References [1] H. Sugano, S. Fujimoto, et al., "Presence information data format (PIDF)," internet draft, Internet Engineering Task Force, May 2003. Work in progress. [2] M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998. [3] J. Rosenberg and H. Schulzrinne, "An offer/answer model with session description protocol (SDP)," RFC 3264, Internet Engineering Task Force, June 2002. [4] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and instant messaging," RFC 2778, Internet Engineering Task Force, Feb. 2000. [5] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [6] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task Force, May 1997. [7] R. Moats, "A URN namespace for IETF documents," RFC 2648, Internet Engineering Task Force, Aug. 1999. [8] M. Mealling, "The IETF XML registry," internet draft, Internet Engineering Task Force, June 2003. Work in progress. [9] J. Rosenberg, "A presence event package for the session initiation protocol (SIP)," internet draft, Internet Engineering Task Force, Jan. 2003. Work in progress. 14 Informative References [10] F. Dawson and D. Stenerson, "Internet calendaring and scheduling core object specification (icalendar)," RFC 2445, Internet Engineering Task Force, Nov. 1998. [11] F. D. Jr., S. M. Reddy, D. Royer, and E. Plamondon, "icalendar DTD document (xcal)," internet draft, Internet Engineering Task Force, July 2002. Work in progress. [12] J. Lennox and H. Schulzrinne, "CPL: a language for user control of Internet telephony services," internet draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 15 Authors' and Editor's Addresses H. Schulzrinne (ed.) [Page 17]
Internet Draft RPID July 31, 2003 The addresses of authors and editors are listed below in alphabetical order. Vijay Gurbani Lucent 2000 Naperville Rd., Room 6G-440 Naperville, IL 60566-7033 USA Email: vkg@lucent.com Paul Kyzivat Cisco Systems Mail Stop LWL3/12/2 900 Chelmsford St. Lowell, MA 01851 USA Email: pkzivat@cisco.com Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054-2711 USA Email: jdrosen@dynamicsoft.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any H. Schulzrinne (ed.) [Page 18]
Internet Draft RPID July 31, 2003 copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. H. Schulzrinne (ed.) [Page 19]
Table of Contents 1 Introduction ........................................ 2 2 RPID Features ....................................... 3 3 Scope ............................................... 4 4 Terminology and Conventions ......................... 4 5 The Meaning of "open" and "closed" .................. 4 6 RPID Elements ....................................... 5 6.1 Introduction ........................................ 5 6.2 Activity Element .................................... 5 6.3 Class ............................................... 7 6.4 Contact-Type Element ................................ 7 6.5 Idle Element ........................................ 7 6.6 Type of Place Element ............................... 8 6.7 Privacy Element ..................................... 9 6.8 Relationship Element ................................ 10 7 Examples ............................................ 10 7.1 Presentity with Activity ............................ 10 8 XML Schema Definitions .............................. 11 9 Security Considerations ............................. 14 10 IANA Considerations ................................. 14 10.1 URN Sub-Namespace Registration for .................. 14 10.2 URN Sub-Namespace Registration for .................. 15 10.3 Place Type, Tuple Type, Activities, Relationships ................................................................ 16 11 Acknowledgements .................................... 16 12 References .......................................... 16 13 Normative References ................................ 17 14 Informative References .............................. 17 15 Authors' and Editor's Addresses ..................... 17 H. Schulzrinne (ed.) [Page 1]