view Side-By-Side changes
Internet Engineering Task Force Internet DraftSIMPLE H. Schulzrinne(ed.)Internet-Draft Columbia U.draft-ietf-simple-rpid-00.txt July 31, 2003Expires:JanuarySeptember 11, 2004RPID --V. Gurbani Lucent P. Kyzivat Cisco J. Rosenberg dynamicsoft March 13, 2004 RPID: Rich Presence: Extensions to the Presence Information Data FormatSTATUS OF THIS MEMO This document is an Internet-Draft(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, andisany of which I become aware will be disclosed, infull conformanceaccordance withall provisions of Section 10 of RFC2026.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 asInternet- Drafts.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 inprogress".progress." The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt To view thehttp:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft ShadowDirectories, seeDirectories 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.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., Schulzrinne, et al. Expires September 11, 2004 [Page 1] Internet-Draft RPID March 2004 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 presenceThis extension includes informationdata formatabout what the presentity is doing (the activity element), a grouping identifier forexchanging presence information in CPIM-compliant systems. It consists ofa<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. Eachtupledefines(the class element), the type of tuple (the contact-type element), whether abasic statuscontact is idle (the idle element), the typle ofeither "open" or "closed". This document provides additional status information for presentities and definesplace aRich Presence Information Data Format for Presence (RPID) to convey this information. This extension has three main goals: 1. Provide rich presence indication thatpresentity is in (the placetype element), whether the presentity isat least as powerful as common commercial presence systems. Such feature-parity simplifies transition to CPIM-compliant systems, bothintermsa public or private space (the privacy element), the relationship ofuser acceptance and protocol conversion. 2. Maintain backwards-compatibility with PIDF, so that PIDF- only watchers and gateways can continue to function properly, naturally without accessa tuple to another presentity (the relationship element), and thefunctionality described here. We make no assumptions how the information inoverall 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. RPIDis 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 --> notificationElements . . . . . . . . . . . . . . . . . . . . . . . . 3to F --> notification4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2 Activities Element . . . . . . . . . . . . . . . . . . . . . . 4to 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 type4.3 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4 Contact-Type Element . . . . . . . . . . . . . . . . . . . . . 6 4.5 Idle Element . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.6 Type ofplace the user is currently in, via the <placetype> element (Section 6.6) and hint at the privacy available via <privacy>. H. Schulzrinne (ed.)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 [Page3] Internet Draft2] Internet-Draft RPIDJuly 31, 2003 PIDFMarch 2004 1. Scope The Presence Information Data Format (PIDF) defines a<timestamp> element indicating the date and time of the status change ofbasic format for representing presence information for atuple. RPID addspresentity. That format defines avalidity period for <activity>, <placetype>textual note, an indication of availability (open or closed) and<privacy> values, as a hint how long the current status is likely to be valid. An important sub-case is thatapresentityURI for communication. However, it isinterruptible only under unusual circumstances, after mediation by some, typically human, authority such as a secretary or supervisor. We allow the presentityfrequently useful to conveythat certain contact addresses actually belong toadditional information about adifferent person, presumably one that can either interrupt the presentity or otherwise assist. The <relationship> (Section 6.8) element allows to indicateuser thata particular tuple refersneeds toa 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 doesbe interpreted by an automata, and is therefore notreplace media negotiation mechanisms definedappropriate forSIP (e.g. SDP [2]), therefore media negotiation (e.g., choiceplacement in the note element ofvoice and video codecs) MUST be performed according to [3].the PIDF document. Thisextension is only aimeddocument defines extensions togivethewatchers hints aboutPIDF document format for conveying richer presence information. Generally, thepresentity's preferences, willingness and capabilitiesextensions have been chosen tocommunicate before watchers initiate SIP-based communication withprovide 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 thepresentity. 4user's current physical environment. 2. Terminology and Conventions This memo makes use of the vocabulary defined in the IMPP Model document[4].[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,MUSTNOT,MUST NOT, REQUIRED, SHOULD,SHOULDNOT,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCPXX,14, RFC 2119[5]. 5[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 statusH. Schulzrinne (ed.) [Page 4] Internet Draft RPID July 31, 2003information 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. 64. RPID Elements6.14.1 Introduction Below, we describe the RPID elements in detail.<activity>, <idle> <placetype>, <privacy>, <relationship>,<activities>, <idle>, <placetype> and <privacy> extend the PIDF <status> element, while<class> and<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[6],[2], using the namespace identifier 'ietf' defined by[7][4] and extended by[8]: urn:ietf:params:xml:ns:pidf:rpid-status urn:ietf:params:xml:ns:pidf:rpid-tuple 6.2 Activity[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<activity> indication<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[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.[10]. An activityindicationenumeration consists of one or more values drawn from the list below, any other token string or IANA-registered values (Section10). Communities of interest such as a professionSection 7). Depending on the presentity intent, all but the "permanent-absence" indication can be used with either status OPEN oran organization may define additional activity labels for their internal use. On-the-phone: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: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:appointment: The presentity has a calendarappointment. Holiday: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:meal: The presentity is scheduled for a meal. This activity category can often be generated automatically from a calendar.Meeting:meeting: A meeting is a sub-class of an appointment. This activity category can often be generated automatically from a calendar.Steering:steering: The presentity is controlling a vehicle, ship or plane.In-transit:in-transit: The presentity is riding in a vehicle, such as a car, but not steering.Alternatively, the presentity MAY offerThe 'placetype' element provides more specificinformation. Travel: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:vacation: Leisure travel. This activity category can often be generatedH. Schulzrinne (ed.) [Page 6] Internet Draft RPID July 31, 2003automatically from a calendar.Sleeping:sleeping: This activity category can often be generated automatically from a calendar, local time information or biometric data.Busy:busy: User is busy, without further details.ThisWhile this activitycategorywould typically beindicated manually. Permanent-absence: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.TheThis activity is associated with a status of CLOSED. The <activity> element MAY be qualified with the'from' and value'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, thetime until which is<activities> elementis expected toenumerates all unique values as child <activity> elements. The <activities> element can bevalid. 6.3extended 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.The class description is similar in spirit to the 'class' attribute of XML elements, used to support Cascading Style Sheets. 6.44.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.4.5 Idle Element Forexample, a SIP URI can designatetuples representing a single device, i.e., having apresentity or a subgroup<contact-type> ofdevices. 6.5 Idle Element The'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 answerthewhen 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 aH. Schulzrinne (ed.) [Page 7] Internet Draft RPID July 31, 2003devicethatthat 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' isboth OPEN andnotmarked as idle.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 preciseduration: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.6.64.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.Alternatively,This general description encompasses the moredetailed indications below may be provided.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 atrain. H. Schulzrinne (ed.) [Page 8] Internet Draft RPID July 31, 2003train, 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 additionalIANA- registeredIANA-registered values (Section10).Section 7). Theplacetype<placetype> elementMAYcan bequalifiedused withthe 'from' and value and the time until which is element is expected totuples of all values of <contact-type>. For tuples consisting of multiple physical devices, i.e., of <contact-type> 'service' or 'presentity', these devices can bevalid. The relative to the publicationin multiple types of places. In those cases, thepresence information.<placetype> element enumerates all unique values as a token list. Theplacetype<placetype> elementcanMAY beused by logic executing onqualified with thewatcher or by a composer to filter, sort'since' andlabel tuples. For example, a composer may have rules that limit the publication of "home" tuples to a subset of the watchers. 6.7'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>'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 messagepopped 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 ofpopped up on the laptop screen that is being projected for thewatchers.audience. Theactivity'placetype' element MAY be qualified with the'from' and value'since' andH. 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'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 (Section10)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".74.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. Examples7.15.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: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"><note>I'm in a boring meeting</note><tupleid="7c8dqui"> <et:class>assistant</et:class> <et:type>presentity</et:type>id="c8dqui"> <status> <basic>open</basic><contact>sip:secretary@example.com</contact><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> <tupleid="18x765"> <et:class>sip</et:class> <et:type>service</et:type>id="x765"> <status> <basic>open</basic><ep:activity>meeting</ep:meeting><ep:activity> <ep:activity>meeting</ep:activity></ep:activity> <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> <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> <tupleid="35bs9r"> <et:class>phone</et:class> <et:type>device</et:type>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> <tupleid="8eg92n"> <et:class>mail</et:class> <et:type>device</et:type>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>86. XML Schema DefinitionsH. Schulzrinne (ed.)Schulzrinne, et al. Expires September 11, 2004 [Page11] Internet Draft10] Internet-Draft RPIDJuly 31, 2003March 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:elementname="type">name="contact-type"> <xs:simpleType> <xs:restrictionbase="token">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>H. Schulzrinne (ed.) [Page 12] Internet Draft RPID July 31, 20036.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:element name="activity"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:token"><xs:attributeGroup name="SinceUntil"> <xs:attributename="from"name="since" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/></xs:extension> </xs:simpleContent></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:extensionbase="xs:token"> <xs:attribute name="from" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/>base="tokenlist"> <xs:attributeGroup ref="SinceUntil"/> </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> Schulzrinne, et al. Expires September 11, 2004 [Page 12] Internet-Draft RPID March 2004 <xs:simpleContent> <xs:extensionbase="privacy_t"> <xs:attribute name="from" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/>base="tokenlist"> <xs:attributeGroup ref="SinceUntil"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:elementname="relationship" type="xs:token"/>name="sphere"> <xs:complexType> <xs:simpleContent> <xs:extension base="tokenlist"> <xs:attributeGroup ref="SinceUntil"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:elementname="idle"name="idle"> <xs:complexType> <xs:attribute name="since" type="xs:dateTime"/> </xs:complexType> </xs:element> </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. 107. IANA Considerations This document calls for IANA to: o register two new XML namespace URNs per[8];[6]; o establish registry for activity categories (Section6.2),4.2), place types (Section6.6),4.6), and relationships (Section6.8).4.8). Note that this document does not need a new content type. It inherits the content type from[1],[7], namelyapplication/cpim-pidf+xml 10.1application/pidf+xml. 7.1 URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:pidf:status:rpid-status' URI:urn:ietf:params:xml:ns:rpid-statusurn:ietf:params:xml:ns:pidf:status:rpid-status Description: This is the XML namespace for XML elements definedH. Schulzrinne (ed.) [Page 14] Internet Draft RPID July 31, 2003byRFCXXXXRFC&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 theapplication/cpim-pidf+xmlapplication/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>,simple@ietf.org, Henning Schulzrinne,<hgs@cs.columbia.edu>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 --<title>RPID: Rich Presence: Extensions to the Presence Information Data Formatfor Presence</title>(PIDF)</title> </head> <body> <h1>Namespace for rich presence extension (status)</h1><h2>application/pidf+xml</h2><h2>urn:ietf:params:xml:ns:pidf:status:rpid-status</h2> <p>See <ahref="[[[URLhref="URL of publishedRFC]]]">RFCXXXX</a>.</p>RFC">RFC&rfc.number; [RFC editor: replace with RFC number]</a>.</p> </body> </html> END10.27.2 URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:pidf:rpid-tuple' URI:urn:ietf:params:xml:ns:rpid-tupleurn: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 theapplication/cpim-pidf+xmlapplication/pidf+xml content type.H. Schulzrinne (ed.) [Page 15] Internet Draft RPID July 31, 2003Registrant Contact: IETF, SIMPLE working group,<simple@ietf.org>,simple@ietf.org, Henning Schulzrinne,<hgs@cs.columbia.edu>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 --<title>RPID: Rich Presence: Extensions to the Presence Information Data Formatfor Presence</title>(PIDF)</title> </head> <body> <h1>Namespace for rich presence extension (tuple)</h1><h2>application/pidf+xml</h2><h2>urn:ietf:params:xml:ns:pidf:rpid-tuple</h2> <p>See <ahref="[[[URLhref="URL of publishedRFC]]]">RFCXXXX</a>.</p>RFC">RFC&rfc.number; [RFC editor: replace with RFC number]</a>.</p> </body> </html> END10.3 Place Type, Tuple Type, Activities, Relationships7.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 foractivities, tuple types, place types and relationships.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.The SIMPLE working group, or, if no longer available,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 theSIPSIMPLE working groupshould be consulted prior to registration. 11 Acknowledgements The document reflects the discussion onor its designated successor. Each registration must include theSIMPLE mailing list, with contributions from many individuals. Markus Isomaki, Hisham Khartabil, Jon Peterson and Brian Rosen provided detailed comments and suggestions. The notionname ofexternal references inthe<card>, <icon>token and<info> elements is an evolution ofa brief description similar to theBINPIDF 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. Workones offered inprogress. [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 modelfor 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 andinstant messaging," RFC 2778, Internet Engineering Task Force, Feb. 2000. [5] S.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 toindicate requirement levels,"Indicate Requirement Levels", BCP 14, RFC 2119,Internet Engineering Task Force, Mar.March 1997.[6] R.[2] Moats, R., "URNsyntax,"Syntax", RFC 2141,Internet Engineering Task Force,May 1997.[7] R.[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 URNnamespaceNamespace for IETFdocuments,"Documents", RFC 2648,Internet Engineering Task Force, Aug.August 1999.[8] M.[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [6] Mealling, M., "The IETF XMLregistry," internet draft, Internet Engineering Task Force, June 2003. WorkRegistry", BCP 81, RFC 3688, January 2004. [7] Sugano, H. and S. Fujimoto, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work inprogress. [9] J.progress), May 2003. [8] Rosenberg, J., "Apresence event packagePresence Event Package for thesession initiation protocol (SIP)," internet draft, Internet Engineering Task Force, Jan. 2003. WorkSession Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work inprogress. 14progress), 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.DawsonandD.Stenerson, D., "InternetcalendaringCalendaring andscheduling core object specification (icalendar),"Scheduling Core Object Specification (iCalendar)", RFC 2445,Internet Engineering Task Force, Nov.November 1998. [11]F. D. Jr., S. M. Reddy, D. Royer,Rosenberg, J. andE. Plamondon, "icalendar DTD document (xcal)," internet draft, Internet Engineering Task Force, JulyH. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.Work in progress.[12]J. LennoxLennox, J., Wu, X. and H. Schulzrinne, "CPL:a languageA Language foruser controlUser Control of Internettelephony services," internet draft, Internet Engineering Task Force, Nov. 2001. WorkTelephony Services", draft-ietf-iptel-cpl-08 (work inprogress. 15 Authors'progress), August 2003. [13] Dawson, F., Reddy, S., Royer, D. andEditor'sE. Plamondon, "iCalendar DTD Document (xCal)", draft-ietf-calsch-many-xcal-02 (work in progress), July 2002. Authors' AddressesH.Henning Schulzrinne(ed.) [Page 17] Internet Draft RPID July 31, 2003 The addressesColumbia University Department ofauthors and editors are listed below in alphabetical order.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 NapervilleRd.,Rd. Room 6G-440 Naperville, IL 60566-7033USA Email:US EMail: vkg@lucent.com Paul Kyzivat Cisco SystemsMail Stop LWL3/12/2 900 Chelmsford St. Lowell,BXB500 C2-2 1414 Massachusetts Avenue Boxborough, MA01851 USA Email: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-2711USA Email:US EMail: jdrosen@dynamicsoft.comHenning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.eduAppendix 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 anyintellectual propertyIntellectual 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;neithernor 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 instandards-track and standards-related documentationIETF Documents can be found inBCP-11.BCP 78 and BCP 79. Copies ofclaims of rightsIPR disclosures madeavailable for publicationto 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 byimplementorsimplementers or users of this specification can be obtained from the IETFSecretariat.on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention anyH. Schulzrinne (ed.) [Page 18] Internet Draft RPID July 31, 2003copyrights, patents or patent applications, or other proprietary rightswhichthat may cover technology that may be required topracticeimplement this standard. Please address the information to the IETFExecutive 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 purposeat ietf-ipr@ietf.org. Disclaimer ofdeveloping 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.Validity This document and the information contained hereinisare 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 FORCEDISCLAIMSDISCLAIM 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 5Copyright Statement Copyright (C) TheMeaning of "open"Internet Society (2004). This document is subject to the rights, licenses 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'restrictions contained in BCP 78, andEditor's Addresses ..................... 17 H. Schulzrinne (ed.)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 [Page1]19] ----