diff options
Diffstat (limited to 'doc/rfc/rfc4480.txt')
| -rw-r--r-- | doc/rfc/rfc4480.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc4480.txt b/doc/rfc/rfc4480.txt new file mode 100644 index 0000000..744264f --- /dev/null +++ b/doc/rfc/rfc4480.txt @@ -0,0 +1,2075 @@ + + + + + + +Network Working Group H. Schulzrinne +Request for Comments: 4480 Columbia U. +Category: Standards Track V. Gurbani + Lucent + P. Kyzivat + J. Rosenberg + Cisco + July 2006 + + + RPID: Rich Presence Extensions to the + Presence Information Data Format (PIDF) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Presence Information Data Format (PIDF) defines a basic format + for representing presence information for a presentity. This format + defines a textual note, an indication of availability (open or + closed) and a Uniform 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 communications + might remain 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, an icon reflecting the presentity's + status, and the overall role of the presentity. + + These extensions include presence information for persons, services + (tuples), and devices. + + + +Schulzrinne, et al. Standards Track [Page 1] + +RFC 4480 RIPD July 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology and Conventions .....................................4 + 3. RPID Elements ...................................................4 + 3.1. Overview ...................................................4 + 3.2. Activities Element .........................................7 + 3.3. Class Element .............................................10 + 3.4. Device Identifier .........................................10 + 3.5. Mood Element ..............................................10 + 3.6. Place-is Element ..........................................12 + 3.7. Place-type Element ........................................13 + 3.8. Privacy Element ...........................................14 + 3.9. Relationship Element ......................................15 + 3.10. Service Class ............................................15 + 3.11. Sphere Element ...........................................16 + 3.12. Status-Icon Element ......................................16 + 3.13. Time Offset ..............................................17 + 3.14. User-Input Element .......................................17 + 4. Example ........................................................18 + 5. XML Schema Definitions .........................................20 + 5.1. urn:ietf:params:xml:ns:pidf:rpid ..........................20 + 6. Extending RPID .................................................30 + 7. IANA Considerations ............................................31 + 7.1. URN Sub-Namespace Registration for ........................31 + 'urn:ietf:params:xml:ns:pidf:rpid' + 7.2. Schema Registration for Schema ............................32 + 'urn:ietf:params:xml:ns:pidf:status:rpid' + 8. Internationalization Considerations ............................32 + 9. Security Considerations ........................................32 + 10. References ....................................................33 + 10.1. Normative References .....................................33 + 10.2. Informative References ...................................34 + Appendix A. Acknowledgements .....................................35 + +1. Introduction + + The Presence Information Data Format (PIDF) definition [8] describes + a basic presence information data format, encoded as an Extensible + Markup Language (XML) [9] (SCHEMA-1 [10]) (SCHEMA-2 [11]), for + exchanging presence information in systems compliant with the common + model for presence and instant messaging [5]. It consists of a + <presence> root element, zero or more <tuple> elements carrying + presence information including a Uniform Resource Identifier (URI) + for communication, zero or more <note> elements, and zero or more + extension elements from other name spaces. Each tuple defines a + basic status of either "open" or "closed". + + + + +Schulzrinne, et al. Standards Track [Page 2] + +RFC 4480 RIPD July 2006 + + + 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 to be placed in the <note> element of the + PIDF document, which is typically intended for the human observer. + Therefore, 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 communication devices, or + sources describing the user's current physical environment. + + The presence data model [16] defines the concepts of service, device, + and person as the data elements that are used to model the state of a + presentity. (The term "presentity" is defined in RFC 2778 [5] and + abbreviates presence entity. A presentity provides presence + information to a presence service.) Services are encoded using the + <tuple> element, defined in PIDF; devices and persons are represented + by the <device> and <person> XML elements, respectively, defined in + the data model [16]. However, neither PIDF nor the data model + defines presence attributes beyond the <basic> 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 that extend the PIDF <tuple> + element and the <device> and <person> elements defined in the data + model. + + This extension has two main goals: + + 1. Provide rich presence information that is at least as powerful as + common commercial presence systems. Such feature-parity + simplifies transition to systems complying with the Common + Profile for Instant Messaging (CPIM) [14], both in terms of user + acceptance and protocol conversion. + + 2. Maintain backward-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 as to how the information in the RPID elements + 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 personal calendars, the status of + communication devices such as telephones, typing activity, and + + + + +Schulzrinne, et al. Standards Track [Page 3] + +RFC 4480 RIPD July 2006 + + + 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 [13]. + + 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 presence user agents, 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 [15], 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 + +3.1. Overview + + Some of the RPID elements describe services, some devices, and some + the person. As such, they either extend <tuple>, <device>, or + <person>, respectively. Below, we summarize the RPID elements. The + next sections will then provide more detailed descriptions. + + + + +Schulzrinne, et al. Standards Track [Page 4] + +RFC 4480 RIPD July 2006 + + + activities: The <activities> status element enumerates what the + person is doing. + + class: An identifier that groups similar person elements, devices, + or services. + + deviceID: A device identifier in a tuple references a <device> + element, indicating that this device contributes to the service + described by the tuple. + + mood: The <mood> status element indicates the mood of the person. + + place-is: The <place-is> status element reports on the properties of + the place the presentity is currently at, such as the levels of + light and noise. + + place-type: The <place-type> status elements reports the type of + place the person is located in, such as 'classroom' or 'home'. + + privacy: The <privacy> element distinguishes whether the + communication service is likely to be observable by other parties. + + relationship: When a service is likely to reach a user besides the + person associated with the presentity, the relationship indicates + how that user relates to the person. + + service-class: The <service-class> element describes whether the + service is delivered electronically, is a postal or delivery + service, or describes in-person communications. + + sphere: The <sphere> element characterizes the overall current role + of the presentity. + + status-icon: The <status-icon> element depicts the current status of + the person or service. + + time-offset: The <time-offset> status element quantifies the time + zone the person is in, expressed as the number of minutes away + from UTC. + + user-input: The <user-input> element records the user-input or usage + state of the service or device, based on human user input. + + The 'From/until?' column in Table 1 indicates by an 'x' that the + element can take 'from' and 'until' attributes. An 'x' in the + 'Note?' column marks elements that can include a <note> element. The + usage of these elements within the <person>, <tuple>, and <device> + elements is shown in columns 4 through 6. An 'x' in the respective + + + +Schulzrinne, et al. Standards Track [Page 5] + +RFC 4480 RIPD July 2006 + + + column indicates that the RPID element MAY appear as a child of that + element. + + +-----------------+------------+------+----------+---------+----------+ + | Element | From/until | Note | <person> | <tuple> | <device> | + | | ? | ? | | | | + +-----------------+------------+------+----------+---------+----------+ + | <activities> | x | x | x | | | + | <class> | | | x | x | x | + | <deviceID> | | | | x | | + | <mood> | x | x | x | | | + | <place-is> | x | x | x | | | + | <place-type> | x | x | x | | | + | <privacy> | x | x | x | x | | + | <relationship> | | x | | x | | + | <service-class> | | x | | x | | + | <sphere> | x | | x | | | + | <status-icon> | x | | x | x | | + | <time-offset> | x | | x | | | + | <user-input> | | | x | x | x | + +-----------------+------------+------+----------+---------+----------+ + + Table 1 + + In general, it is 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. 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. + + 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:rpid + + The elements marked with the value 'x' in column 2 of Table 1 MAY be + qualified with the 'from' and 'until' attributes to describe the + absolute time when the element assumed this value and the absolute + time until which this element is expected to be valid. Note that + there can be multiple elements of the same type, whose time ranges + SHOULD NOT overlap. + + Elements MAY contain an 'id' attribute that allows to uniquely + reference the element. + + + +Schulzrinne, et al. Standards Track [Page 6] + +RFC 4480 RIPD July 2006 + + + Enumerations can be extended by elements from other namespaces, as + described in Section 6. The <activities>, <mood>, and <place-type> + elements can also take <other> elements containing text, for custom + free-text values specific to an application. + + All elements described in this document are optional within PIDF + documents. + +3.2. Activities Element + + The <activities> element describes what the person is currently + doing, expressed as an enumeration of activity-describing elements. + A person can be engaged in multiple activities at the same time, + e.g., traveling and having a meal. The <activities> element 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 [13]. + + An activities enumeration consists of one or more elements using + elements drawn from the list below, a string enclosed in the <other> + element, or IANA-registered values from other namespaces (Section 7). + + If a person publishes an activity of "permanent-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. + + Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, + <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> + can often be derived from calendar information. + + 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. + + away: The person is physically away from all interactive + communication devices. This activity element was included since + it can often be derived automatically from security systems, + energy management systems, or entry badge systems. Although this + activity would typically be associated with a status of CLOSED + across all services, a person may declare himself or herself away + + + + + + + + +Schulzrinne, et al. Standards Track [Page 7] + +RFC 4480 RIPD July 2006 + + + to discourage communication, but indicate that he or she still can + be reached if needed. However, communication attempts might reach + an answering service, for example. + + breakfast: The person is eating the first meal of the day, usually + eaten in the morning. + + busy: The person is busy, without further details. Although this + activity would typically be associated with a status of CLOSED + across all services, a person may declare himself or herself busy + to discourage communication, but indicate that he or she still can + be reached if needed. + + dinner: The person is having his or her main meal of the day, eaten + in the evening or at midday. + + holiday: This is a scheduled national or local holiday. + + in-transit: The person is riding in a vehicle, such as a car, but + not steering. The <place-type> element provides more specific + information about the type of conveyance the person is using. + + looking-for-work: The presentity is looking for (paid) work. + + lunch: The person is eating his or her midday meal. + + meal: The person is scheduled for a meal, without specifying whether + it is breakfast, lunch, or dinner, or some other meal. + + meeting: The person is in an assembly or gathering of people, as for + a business, social, or religious purpose. A meeting is a sub- + class of an appointment. + + on-the-phone: The person is talking on the telephone. This activity + is included since it can often be derived automatically. + + other: The person is engaged in an activity with no defined + representation as an <activities> element. The enclosed string + describes the activity in plain text. + + 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. + + + + + +Schulzrinne, et al. Standards Track [Page 8] + +RFC 4480 RIPD July 2006 + + + permanent-absence: The 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. + + playing: The person is occupying himself or herself in amusement, + sport, or other recreation. + + presentation: The person is giving a presentation, lecture, or + participating in a formal round-table discussion. + + shopping: The person is visiting stores in search of goods or + services. + + sleeping: This activity category can often be generated + automatically from a calendar, local time information, or + biometric data. + + spectator: The person is observing an event, such as a sports event. + + steering: The person is controlling a vehicle, watercraft, or plane. + + travel: The person is on a business or personal trip, but not + necessarily in-transit. + + tv: The person is watching television. + + unknown: The activity of the person is unknown. This element is + generally not used together with other activities. + + vacation: A period of time devoted to pleasure, rest, or relaxation. + + working: The presentity is engaged in, typically paid, labor, as + part of a profession or job. + + worship: The presentity is participating in religious rites. + + The <activities> element MAY be qualified with the 'from' and 'until' + attributes as described in Section 3.1. + + Example: + + <activities> + <note>Enjoying the morning paper</note> + <vacation/> + <breakfast/> + <other>reading</other> + </activities> + + + +Schulzrinne, et al. Standards Track [Page 9] + +RFC 4480 RIPD July 2006 + + +3.3. Class Element + + The <class> element describes the class of the service, device, or + person. Multiple elements can have the same class name within a + presence document, but each person, service, or device can only have + one class label. 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. This + information is not generally presented to the watcher user interface. + + The <class> element MUST NOT be qualified with the 'from' and 'until' + attributes as described in Section 3.1. + +3.4. Device Identifier + + The <deviceID> element in the <tuple> element references the device + that provides a particular service. The element is defined + syntactically in the data model [16] schema. One service can be + provided by multiple devices, so that each service tuple may contain + zero or more <deviceID> elements. There is no significance in the + order of these elements. + + The <deviceID> element MUST NOT be qualified with the 'from' and + 'until' attributes as described in Section 3.1. + +3.5. Mood Element + + The <mood> element describes the mood of the presentity. The mood + values are enumerated chosen by the presentity. The mood itself is + provided as the element name of a defined child element of the <mood> + element (e.g., <happy/>); one such child element is REQUIRED. The + user MAY also specify a natural-language description of, or reason + for, the mood in the <note> child of the <mood> 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 [18] mood values and the values enumerated in + the Affective Knowledge Representation that has been defined by + Lisetti [17]: + + A mood enumeration consists of one or more elements using elements + drawn from the list below, a string enclosed in the <other> element, + or IANA-registered values from other namespaces (Section 7). + + The <mood> element MAY be qualified with the 'from' and 'until' + attributes as described in Section 3.1. + + + + +Schulzrinne, et al. Standards Track [Page 10] + +RFC 4480 RIPD July 2006 + + + o afraid + o amazed + o angry + o annoyed + o anxious + o ashamed + o bored + o brave + o calm + o cold + o confused + o contented + o cranky + o curious + o depressed + o disappointed + o disgusted + o distracted + o embarrassed + o excited + o flirtatious + o frustrated + o grumpy + o guilty + o happy + o hot + o humbled + o humiliated + o hungry + o hurt + o impressed + o in_awe + o in_love + o indignant + o interested + o invincible + o jealous + o lonely + o mean + o moody + o nervous + o neutral + o offended + o other + o playful + o proud + o relieved + o remorseful + + + +Schulzrinne, et al. Standards Track [Page 11] + +RFC 4480 RIPD July 2006 + + + o restless + o sad + o sarcastic + o serious + o shocked + o shy + o sick + o sleepy + o stressed + o surprised + o thirsty + o unknown + o worried + + Example: + + <mood> + <note>I'm ready for the bar BOF!</note> + <sleepy/> + <thirsty/> + </mood> + +3.6. Place-is Element + + The <place-is> element describes properties of the place the person + is currently at. This offers the watcher an indication of what kind + of communication is likely to be successful. Each major media type + has its own set of attributes. Omitting the element indicates that + the property is unknown. + + For audio, we define the following attributes: + + noisy: The person is in a place with a level of background noise + that makes audio communications difficult. + + ok: The environmental conditions are suitable for audio + communications. + + quiet: The person is in a place such as a library, restaurant, place + of worship, or theater that discourages noise, conversation, and + other distractions. + + unknown: The place attributes for audio are unknown. + + For video, we define the following attributes: + + toobright: The person is in a bright place, sufficient for good + rendering on video. + + + +Schulzrinne, et al. Standards Track [Page 12] + +RFC 4480 RIPD July 2006 + + + ok: The environmental conditions are suitable for video. + + dark: The person is in a dark place, and thus the camera may not be + able to capture a good image. + + unknown: The place attributes for video are unknown. + + For text (real-time text and instant messaging), we define + + uncomfortable: Typing or other text entry is uncomfortable. + + inappropriate: Typing or other text entry is inappropriate, e.g., + since the user is in a vehicle or house of worship. + + ok: The environmental conditions are suitable for text-based + communications. + + unknown: The place attributes for text are unknown. + + This list can be augmented by free-text values in a note or + additional IANA-registered values (Section 7). + + The <place-is> element contains other elements, e.g., + + <place-is> + <audio> + <noisy /> + </audio> + <video> + <dark /> + </video> + </place-is> + + The <place-is> element MAY be qualified with the 'from' and 'until' + attributes as described in Section 3.1. + +3.7. Place-type Element + + The <place-type> element describes the type of place the person is + currently at. This offers the watcher an indication of what kind of + communication is likely to be appropriate. The initial set of values + is contained in RFC 4589 [12]. + + This list can be augmented by free-text values or additional IANA- + registered values as described in RFC 4589. + + + + + + +Schulzrinne, et al. Standards Track [Page 13] + +RFC 4480 RIPD July 2006 + + + The <place-type> element is a choice of elements, as in + + <place-type> + <pt:street/> + </place-type> + + The <place-type> element MAY be qualified with the 'from' and 'until' + attributes as described in Section 3.1. + +3.8. Privacy Element + + The <privacy> element indicates which types 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 or the network + protocol used. + + audio: Inappropriate individuals are not likely to overhear audio + communications. + + text: Inappropriate individuals are not likely to see text + communications. + + unknown: This information is unknown. + + video: Inappropriate individuals are not likely to see video + communications. + + The <privacy> 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 "private" to a select subset of the watchers. + + The <privacy> element MAY be qualified with the 'from' and 'until' + attributes as described in Section 3.1. + + Example: + + <privacy> + <text/> + <audio/> + </privacy> + + + + + + + + +Schulzrinne, et al. Standards Track [Page 14] + +RFC 4480 RIPD July 2006 + + +3.9. 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", "friend", + "associate" (e.g., for a colleague), "assistant", "supervisor", + "self", and "unknown". The default is "self". + + If a relationship is indicated, the URI in the <contact> element + refers to the entity, such as the assistant, that has a relationship + to the presentity, not the presentity itself. + + Like tuples without a <relationship> qualifier, 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". + + Example: + + <relationship> + <friend/> + </relationship> + +3.10. Service Class + + The <service-class> element extends <tuple> and designates the type + of service offered. + + electronic: Delivery of information by electronic means, i.e., + without delivering physical objects. Examples include telephone, + fax, email, instant messaging, and SMS. + + postal: Delivery by the postal service, e.g., as a letter, parcel, + or postcard. Delivery could be to a post office box or central + mailroom rather than the presentity's office location, for + example. + + courier: Delivery by messenger, overnight delivery, or courier. + Courier-delivered messages are usually delivered to a receptionist + rather than, say, a mailroom or receiving department. + + freight: Delivery by freight carrier, typically of larger objects + that are not sent by postal mail or courier. The recipient is + often the shipping department or a loading dock. + + in-person: Describes the coordinates for visits in person, as by a + visitor, i.e., usually somebody's office or residence. + + + +Schulzrinne, et al. Standards Track [Page 15] + +RFC 4480 RIPD July 2006 + + + unknown: The type of service is unknown. + + Electronic service is implied if omitted. The service types + 'postal', 'courier', 'freight', 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. + + Example: + + <service-class><postal/></service-class> + +3.11. Sphere Element + + The <sphere> element designates the current state and role that the + person plays. For example, it might describe whether the person is + in a work mode, 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", as well as "unknown". + + Spheres 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 masters in his troop to see his presence status. As soon + as he switches his status to "work", "home", or some other sphere, + the fellow scouts would lose access. + + The <sphere> element MAY be qualified with the 'from' and 'until' + attributes as described in Section 3.1. + + Example: + + <sphere> + <home/> + </sphere> + +3.12. Status-Icon Element + + The <status-icon> 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 + + + + +Schulzrinne, et al. Standards Track [Page 16] + +RFC 4480 RIPD July 2006 + + + sizes and aspect ratios that are appropriate for rendering as an + icon. Support for JPEG, PNG, and GIF formats is RECOMMENDED. + + Watchers resolving the URI MUST validate whether the local copy of + the icon is current when receiving a notification, using the standard + cache control mechanism in the URI-identified retrieval protocol. + + Example: + + <status-icon>http://www.example.com/playing.gif</status-icon> + +3.13. Time Offset + + The <time-offset> element describes the number of minutes of offset + from UTC at the person's current location. A positive number + indicates that the local time-of-day is ahead (i.e., east of) + Universal Time, while a negative number indicates that the local + time-of-day is behind (i.e., west of) Universal Time. Transitions + into and out of daylight savings time may temporarily cause a + difference between the true offset from UTC and the time offset + element. + + An optional attribute, description, can be used to describe the + offset, e.g., by labeling the time zone. This description is meant + for human consumption. + + Publishers on mobile devices SHOULD NOT publish this information + unless they know the time offset information to reflect the current + location. (For example, many laptop users do not update their time + zone when traveling.) Publishers SHOULD update the information + whenever they discover that their UTC offset has changed. + + Example: + + <time-offset description="America/New_York">-300 + </time-offset> + +3.14. User-Input Element + + The <user-input> 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. If contained in a <person> element, it + summarizes any user input activity across all services and devices + operated by the presentity. The mechanism for such aggregation is + beyond the scope of this document, but generally reflects the most + recent user input across all devices and services. The element can + assume one of two values, namely, 'active' or 'idle', with an + optional 'last-input' attribute that records when the last user input + + + +Schulzrinne, et al. Standards Track [Page 17] + +RFC 4480 RIPD July 2006 + + + was 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 <user- + input> '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, the + tuple is marked with a <user-input> 'idle' indication instead, + optionally including the time of last activity in the 'last-input' + attribute. An example is below: + + <user-input idle-threshold="600" + last-input="2004-10-21T13:20:00.000-05:00">idle</user-input> + + 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 <user-input> 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 <user-input> attribute can be omitted if the presentity wants to + indicate that the device has not been used for a while, but does not + want to reveal the precise duration, as in the following: + + <user-input>idle</user-input> + + Configuration MUST include the option to omit the 'last-input' + 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 local time. The presentity also has an + + + +Schulzrinne, et al. Standards Track [Page 18] + +RFC 4480 RIPD July 2006 + + + assistant, sip:secretary@example.com, who happens to be available for + communications. + + <?xml version="1.0" encoding="UTF-8"?> + <presence xmlns="urn:ietf:params:xml:ns:pidf" + xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" + xmlns:lt="urn:ietf:params:xml:ns:location-type" + xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" + entity="pres:someone@example.com"> + + <tuple id="bs35r9"> + <status> + <basic>open</basic> + </status> + <dm:deviceID>urn:device:0003ba4811e3</dm:deviceID> + <rpid:relationship><rpid:self/></rpid:relationship> + <rpid:service-class><rpid:electronic/></rpid:service-class> + <contact priority="0.8">im:someone@mobile.example.net</contact> + <note xml:lang="en">Don't Disturb Please!</note> + <note xml:lang="fr">Ne derangez pas, s'il vous plait</note> + <timestamp>2005-10-27T16:49:29Z</timestamp> + </tuple> + + <tuple id="ty4658"> + <status> + <basic>open</basic> + </status> + <rpid:relationship><rpid:assistant/></rpid:relationship> + <contact priority="1.0">mailto:secretary@example.com</contact> + </tuple> + + <tuple id="eg92n8"> + <status> + <basic>open</basic> + </status> + <dm:deviceID>urn:x-mac:0003ba4811e3</dm:deviceID> + <rpid:class>email</rpid:class> + <rpid:service-class><rpid:electronic/></rpid:service-class> + <rpid:status-icon>http://example.com/mail.png</rpid:status-icon> + <contact priority="1.0">mailto:someone@example.com</contact> + </tuple> + + <note>I'll be in Tokyo next week</note> + + <dm:device id="pc147"> + <rpid:user-input idle-threshold="600" + last-input="2004-10-21T13:20:00-05:00">idle</rpid:user-input> + <dm:deviceID>urn:device:0003ba4811e3</dm:deviceID> + + + +Schulzrinne, et al. Standards Track [Page 19] + +RFC 4480 RIPD July 2006 + + + <dm:note>PC</dm:note> + </dm:device> + + <dm:person id="p1"> + <rpid:activities from="2005-05-30T12:00:00+05:00" + until="2005-05-30T17:00:00+05:00"> + <rpid:note>Far away</rpid:note> + <rpid:away/> + </rpid:activities> + <rpid:class>calendar</rpid:class> + <rpid:mood> + <rpid:angry/> + <rpid:other>brooding</rpid:other> + </rpid:mood> + <rpid:place-is> + <rpid:audio> + <rpid:noisy/> + </rpid:audio> + </rpid:place-is> + <rpid:place-type><lt:residence/></rpid:place-type> + <rpid:privacy><rpid:unknown/></rpid:privacy> + <rpid:sphere>bowling league</rpid:sphere> + <rpid:status-icon>http://example.com/play.gif</rpid:status-icon> + + <rpid:time-offset>-240</rpid:time-offset> + <dm:note>Scoring 120</dm:note> + <dm:timestamp>2005-05-30T16:09:44+05:00</dm:timestamp> + </dm:person> + </presence> + +5. XML Schema Definitions + + The RPID schema is shown below. Due to limitations in composing + schemas, not all XML documents that validate against the schema below + are semantically valid RPID documents. In particular, the schema + allows each element to appear anyhere in PIDF or data-model elements; + Table 1 restricts where these elements can appear for semantically + valid RPID documents. Elements that do not have from/until + parameters MUST NOT appear more than once in each <person>, <tuple>, + or <device>. + +5.1. urn:ietf:params:xml:ns:pidf:rpid + + <?xml version="1.0" encoding="UTF-8"?> + <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:rpid" + xmlns="urn:ietf:params:xml:ns:pidf:rpid" + xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + + + +Schulzrinne, et al. Standards Track [Page 20] + +RFC 4480 RIPD July 2006 + + + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:simpleType name="activeIdle"> + <xs:restriction base="xs:string"> + <xs:enumeration value="active"/> + <xs:enumeration value="idle"/> + </xs:restriction> + </xs:simpleType> + + <xs:element name="activities"> + <xs:annotation> + <xs:documentation> + Describes what the person is currently doing, expressed as + an enumeration of activity-describing elements. A person + can be engaged in multiple activities at the same time, + e.g., traveling and having a meal. + </xs:documentation> + </xs:annotation> + + <xs:complexType> + <xs:sequence> + <xs:element name="note" type="Note_t" minOccurs="0" + maxOccurs="unbounded" /> + <xs:choice> + <xs:element name="unknown" type="empty" minOccurs="0"/> + <xs:sequence maxOccurs="unbounded"> + <xs:choice> + <xs:element name="appointment" + type="empty" /> + <xs:element name="away" + type="empty" /> + <xs:element name="breakfast" + type="empty" /> + <xs:element name="busy" + type="empty" /> + <xs:element name="dinner" + type="empty" /> + <xs:element name="holiday" + type="empty" /> + <xs:element name="in-transit" + type="empty" /> + <xs:element name="looking-for-work" + type="empty" /> + <xs:element name="meal" + type="empty" /> + <xs:element name="meeting" + type="empty" /> + + + +Schulzrinne, et al. Standards Track [Page 21] + +RFC 4480 RIPD July 2006 + + + <xs:element name="on-the-phone" + type="empty" /> + <xs:element name="performance" + type="empty" /> + <xs:element name="permanent-absence" + type="empty" /> + <xs:element name="playing" + type="empty" /> + <xs:element name="presentation" + type="empty" /> + <xs:element name="shopping" + type="empty" /> + <xs:element name="sleeping" + type="empty" /> + <xs:element name="spectator" + type="empty" /> + <xs:element name="steering" + type="empty" /> + <xs:element name="travel" + type="empty" /> + <xs:element name="tv" + type="empty" /> + <xs:element name="vacation" + type="empty" /> + <xs:element name="working" + type="empty" /> + <xs:element name="worship" + type="empty" /> + <xs:element name="other" + type="Note_t" /> + <xs:any namespace="##other" + maxOccurs="unbounded" processContents="lax"/> + </xs:choice> + </xs:sequence> + </xs:choice> + </xs:sequence> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + </xs:element> + + <xs:element name="class" type="xs:token"> + <xs:annotation> + <xs:documentation> + Describes the class of the service, device or person. + </xs:documentation> + </xs:annotation> + + + +Schulzrinne, et al. Standards Track [Page 22] + +RFC 4480 RIPD July 2006 + + + </xs:element> + + <xs:element name="mood"> + <xs:annotation> + <xs:documentation> + Describes the mood of the presentity. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:sequence> + <xs:element name="note" type="Note_t" minOccurs="0" + maxOccurs="unbounded" /> + <xs:choice> + <xs:element name="unknown" type="empty"/> + <xs:sequence maxOccurs="unbounded"> + <xs:choice> + <xs:element name="afraid" + type="empty"/> + <xs:element name="amazed" + type="empty"/> + <xs:element name="angry" + type="empty"/> + <xs:element name="annoyed" + type="empty"/> + <xs:element name="anxious" + type="empty" /> + <xs:element name="ashamed" + type="empty" /> + <xs:element name="bored" + type="empty" /> + <xs:element name="brave" + type="empty" /> + <xs:element name="calm" + type="empty" /> + <xs:element name="cold" + type="empty" /> + <xs:element name="confused" + type="empty" /> + <xs:element name="contented" + type="empty" /> + <xs:element name="cranky" + type="empty" /> + <xs:element name="curious" + type="empty" /> + <xs:element name="depressed" + type="empty" /> + <xs:element name="disappointed" + type="empty" /> + + + +Schulzrinne, et al. Standards Track [Page 23] + +RFC 4480 RIPD July 2006 + + + <xs:element name="disgusted" + type="empty" /> + <xs:element name="distracted" + type="empty" /> + <xs:element name="embarrassed" + type="empty" /> + <xs:element name="excited" + type="empty" /> + <xs:element name="flirtatious" + type="empty" /> + <xs:element name="frustrated" + type="empty" /> + <xs:element name="grumpy" + type="empty" /> + <xs:element name="guilty" + type="empty" /> + <xs:element name="happy" + type="empty" /> + <xs:element name="hot" + type="empty" /> + <xs:element name="humbled" + type="empty" /> + <xs:element name="humiliated" + type="empty" /> + <xs:element name="hungry" + type="empty" /> + <xs:element name="hurt" + type="empty" /> + <xs:element name="impressed" + type="empty" /> + <xs:element name="in_awe" + type="empty" /> + <xs:element name="in_love" + type="empty" /> + <xs:element name="indignant" + type="empty" /> + <xs:element name="interested" + type="empty" /> + <xs:element name="invincible" + type="empty" /> + <xs:element name="jealous" + type="empty" /> + <xs:element name="lonely" + type="empty" /> + <xs:element name="mean" + type="empty" /> + <xs:element name="moody" + type="empty" /> + + + +Schulzrinne, et al. Standards Track [Page 24] + +RFC 4480 RIPD July 2006 + + + <xs:element name="nervous" + type="empty" /> + <xs:element name="neutral" + type="empty" /> + <xs:element name="offended" + type="empty" /> + <xs:element name="playful" + type="empty" /> + <xs:element name="proud" + type="empty" /> + <xs:element name="relieved" + type="empty" /> + <xs:element name="remorseful" + type="empty" /> + <xs:element name="restless" + type="empty" /> + <xs:element name="sad" + type="empty" /> + <xs:element name="sarcastic" + type="empty" /> + <xs:element name="serious" + type="empty" /> + <xs:element name="shocked" + type="empty" /> + <xs:element name="shy" + type="empty" /> + <xs:element name="sick" + type="empty" /> + <xs:element name="sleepy" + type="empty" /> + <xs:element name="stressed" + type="empty" /> + <xs:element name="surprised" + type="empty" /> + <xs:element name="thirsty" + type="empty" /> + <xs:element name="worried" + type="empty" /> + <xs:element name="other" + type="Note_t" /> + <xs:any namespace="##other" + maxOccurs="unbounded" processContents="lax"/> + </xs:choice> + </xs:sequence> + </xs:choice> + </xs:sequence> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="id" type="xs:ID"/> + + + +Schulzrinne, et al. Standards Track [Page 25] + +RFC 4480 RIPD July 2006 + + + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + </xs:element> + + <xs:element name="place-is"> + <xs:complexType> + <xs:sequence> + <xs:element name="note" type="Note_t" minOccurs="0" + maxOccurs="unbounded" /> + <xs:element name="audio" minOccurs="0"> + <xs:complexType> + <xs:choice> + <xs:element name="noisy" type="empty" /> + <xs:element name="ok" type="empty" /> + <xs:element name="quiet" type="empty" /> + <xs:element name="unknown" type="empty" /> + </xs:choice> + </xs:complexType> + </xs:element> + <xs:element name="video" minOccurs="0"> + <xs:complexType> + <xs:choice> + <xs:element name="toobright" type="empty" /> + <xs:element name="ok" type="empty" /> + <xs:element name="dark" type="empty" /> + <xs:element name="unknown" type="empty" /> + </xs:choice> + </xs:complexType> + </xs:element> + <xs:element name="text" minOccurs="0"> + <xs:complexType> + <xs:choice> + <xs:element name="uncomfortable" type="empty" /> + <xs:element name="inappropriate" type="empty" /> + <xs:element name="ok" type="empty" /> + <xs:element name="unknown" type="empty" /> + </xs:choice> + </xs:complexType> + </xs:element> + </xs:sequence> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + </xs:element> + + <xs:element name="place-type"> + <xs:annotation> + + + +Schulzrinne, et al. Standards Track [Page 26] + +RFC 4480 RIPD July 2006 + + + <xs:documentation> + Describes the type of place the person is currently at. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:sequence> + <xs:element name="note" type="Note_t" minOccurs="0" + maxOccurs="unbounded" /> + <xs:choice> + <xs:element name="other" type="Note_t"/> + <xs:any namespace="##other" maxOccurs="unbounded" + processContents="lax"/> + </xs:choice> + </xs:sequence> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + </xs:element> + + <xs:element name="privacy"> + <xs:annotation> + <xs:documentation> + Indicates which type of communication third parties in the + vicinity of the presentity are unlikely to be able to + intercept accidentally or intentionally. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:sequence> + <xs:element name="note" type="Note_t" minOccurs="0" + maxOccurs="unbounded" /> + <xs:choice> + <xs:element name="unknown" type="empty"/> + <xs:sequence minOccurs="1"> + <xs:element name="audio" type="empty" minOccurs="0"/> + <xs:element name="text" type="empty" minOccurs="0"/> + <xs:element name="video" type="empty" minOccurs="0"/> + <xs:any namespace="##other" minOccurs="0" + maxOccurs="unbounded" processContents="lax"/> + </xs:sequence> + </xs:choice> + </xs:sequence> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + </xs:element> + + + +Schulzrinne, et al. Standards Track [Page 27] + +RFC 4480 RIPD July 2006 + + + <xs:element name="relationship"> + <xs:annotation> + <xs:documentation> + Designates the type of relationship an alternate contact + has with the presentity. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:sequence> + <xs:element name="note" type="Note_t" minOccurs="0" + maxOccurs="unbounded" /> + <xs:choice> + <xs:element name="assistant" type="empty" /> + <xs:element name="associate" type="empty" /> + <xs:element name="family" type="empty" /> + <xs:element name="friend" type="empty" /> + <xs:element name="other" type="Note_t" minOccurs="0" /> + <xs:element name="self" type="empty" /> + <xs:element name="supervisor" type="empty" /> + <xs:element name="unknown" type="empty" /> + <xs:any namespace="##other" maxOccurs="unbounded" + processContents="lax"/> + </xs:choice> + </xs:sequence> + </xs:complexType> + </xs:element> + + <xs:element name="service-class"> + <xs:annotation> + <xs:documentation> + Designates the type of service offered. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:sequence> + <xs:element name="note" type="Note_t" minOccurs="0" + maxOccurs="unbounded" /> + <xs:choice> + <xs:element name="courier" type="empty" /> + <xs:element name="electronic" type="empty" /> + <xs:element name="freight" type="empty" /> + <xs:element name="in-person" type="empty" /> + <xs:element name="postal" type="empty" /> + <xs:element name="unknown" type="empty" /> + <xs:any namespace="##other" maxOccurs="unbounded" + processContents="lax"/> + </xs:choice> + </xs:sequence> + + + +Schulzrinne, et al. Standards Track [Page 28] + +RFC 4480 RIPD July 2006 + + + </xs:complexType> + </xs:element> + + <xs:element name="sphere"> + <xs:annotation> + <xs:documentation> + Designates the current state and role that the person plays. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:choice minOccurs="0"> + <xs:element name="home" type="empty" /> + <xs:element name="work" type="empty" /> + <xs:element name="unknown" type="empty" /> + <xs:any namespace="##other" maxOccurs="unbounded" + processContents="lax"/> + </xs:choice> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + </xs:element> + + <xs:element name="status-icon"> + <xs:annotation> + <xs:documentation> + A URI pointing to an image (icon) representing the current + status of the person or service. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:simpleContent> + <xs:extension base="xs:anyURI"> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + <xs:element name="time-offset"> + <xs:annotation> + <xs:documentation> + Describes the number of minutes of offset from UTC at the + user's current location. + </xs:documentation> + </xs:annotation> + + + +Schulzrinne, et al. Standards Track [Page 29] + +RFC 4480 RIPD July 2006 + + + <xs:complexType> + <xs:simpleContent> + <xs:extension base="xs:integer"> + <xs:attributeGroup ref="fromUntil"/> + <xs:attribute name="description" + type="xs:string"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + <xs:element name="user-input"> + <xs:annotation> + <xs:documentation> + Records the user-input or usage state of the service or + device. + </xs:documentation> + </xs:annotation> + <xs:complexType> + <xs:simpleContent> + <xs:extension base="activeIdle"> + <xs:attribute name="idle-threshold" + type="xs:positiveInteger"/> + <xs:attribute name="last-input" type="xs:dateTime"/> + <xs:attribute name="id" type="xs:ID"/> + <xs:anyAttribute namespace="##any" + processContents="lax"/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + </xs:schema> + +6. Extending RPID + + Any developer can introduce their own element names, avoiding + conflict by choosing an appropriate namespace URI. To add new + standardized elements to the enumerations <activities>, <mood>, + <privacy>, <relationship> and <service-class>, the extension process + described in PIDF [9] is followed, i.e., such extensions would use + namespace designators such as urn:ietf:params:xml:ns:pidf:ext, where + 'ext' is the name of the extension. Any new values for the <place- + type> element are assigned according to [12] and are given a + namespace designator at their time of registration. + + + + + +Schulzrinne, et al. Standards Track [Page 30] + +RFC 4480 RIPD July 2006 + + + To avoid the unnecessary proliferation of XML namespaces containing a + single element, groups of element registrations for each of these + enumerations, such as <privacy>, SHOULD be bundled into a single + namespace rather than assigning a new namespace to each new element. + +7. IANA Considerations + +7.1. URN Sub-Namespace Registration for + 'urn:ietf:params:xml:ns:pidf:rpid' + + URI: urn:ietf:params:xml:ns:pidf:rpid + Description: This is the XML namespace for XML elements defined by + RFC 4480 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 + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>RPID: Rich Presence Extensions to the Presence + Information Data Format (PIDF)</title> + </head> + <body> + <h1>Namespace for rich presence extension</h1> + <h2>urn:ietf:params:xml:ns:pidf:rpid</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc4480.txt"> + RFC&4480;</a>.</p> + </body> + </html> + END + + + + + + + + + + + + +Schulzrinne, et al. Standards Track [Page 31] + +RFC 4480 RIPD July 2006 + + +7.2. Schema Registration for Schema + 'urn:ietf:params:xml:ns:pidf:status:rpid' + + URI: urn:ietf:params:xml:ns:pidf:status:rpid + Registrant Contact: IESG + XML: See Section 5 + + Note that this document does not need a new content type. It + inherits the content type from [8], namely, application/pidf+xml. + +8. Internationalization Considerations + + RPID contains mostly tokens that are meant for consumption by + programs, not directly by humans. Programs are expected to translate + those tokens into language-appropriate text strings according to the + preferences of the watcher. + + Some elements may contain <note> and <other> elements that can + contain free text. These elements SHOULD be labeled with the 'xml: + lang' attribute to indicate their language and script. The + specification allows multiple occurrences of these elements so that + the presentity can convey <note> and <other> elements in multiple + scripts and languages. If no 'xml:lang' attribute is provided, the + default value is "i-default" [3]. + + Since RPID is represented in XML, it provides native support for + encoding information using the Unicode character set and its more + compact representations including UTF-8. Conformant XML processors + recognize both UTF-8 and UTF-16. Though XML includes provisions to + identify and use other character encodings through use of an + "encoding" attribute in an <?xml?> declaration, use of UTF-8 is + RECOMMENDED in environments where parser encoding support + incompatibility exists. + + A description of time-zone considerations can be found in + Section 3.13. + +9. Security Considerations + + The security considerations in [8] apply, as well as [7]. Compared + to PIDF, this presence document format reveals additional information + about presentities 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. + + + + +Schulzrinne, et al. Standards Track [Page 32] + +RFC 4480 RIPD July 2006 + + + Like any reference to an external object, the <status-icon> may allow + the presentity to induce the watcher to retrieve data from a third + party (content indirection attack), thus either retrieving harmful + content or adding to the server load of the referenced resource. + +10. References + +10.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] Alvestrand, H., "IETF Policy on Character Sets and Languages", + BCP 18, RFC 2277, January 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] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004. + + [8] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and + J. Peterson, "Presence Information Data Format (PIDF)", RFC + 3863, August 2004. + + [9] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. + Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)," + W3C REC REC-xml-20040204, February 2004. + + [10] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML + Schema Part 1: Structures Second Edition", W3C REC REC- + xmlschema-1-20041028, October 2004. + + [11] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second + Edition", W3C REC REC-xmlschema-2-20041028, October 2004. + + [12] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", + RFC 4589, July 2006. + + + + + +Schulzrinne, et al. Standards Track [Page 33] + +RFC 4480 RIPD July 2006 + + +10.2. Informative References + + [13] Dawson, F. and D. Stenerson, "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", RFC 2445, + November 1998. + + [14] Peterson, J., "Common Profile for Instant Messaging (CPIM)", + RFC 3860, August 2004. + + [15] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing + Language (CPL): A Language for User Control of Internet + Telephony Services", RFC 3880, October 2004. + + [16] Rosenberg, J., "A Data Model for Presence", RFC 4479, July + 2006. + + [17] Lisetti, C., "Personality, Affect, and Emotion Taxonomy for + Socially Intelligent Agents", Proceedings of FLAIRS 2002, 2002. + + [18] Open Mobile Alliance, "The Wireless Village Initiative: + Presence Attributes 1.1", Recommendation WV-29, 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schulzrinne, et al. Standards Track [Page 34] + +RFC 4480 RIPD July 2006 + + +Appendix A. Acknowledgements + + The document reflects the discussion on the SIMPLE mailing list, with + contributions from many individuals. David L. Black, Miguel Garcia, + Avshalom Houri, Markus Isomaki, Rick Jones, Hisham Khartabil, + Jonathan Lennox, Eva-Maria Leppanen, Mikko Lonnfors, Rohan Mahy, + Miguel Marcia, Andrew Newton, Aki Niemi, Jon Peterson, and Brian + Rosen provided detailed comments and suggestions. Xiaotao Wu + assisted with schema testing. Jari Urpalainen provided valuable + advice on XML schema issues. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schulzrinne, et al. Standards Track [Page 35] + +RFC 4480 RIPD July 2006 + + +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: pkyzivat@cisco.com + + + Jonathan Rosenberg + Cisco Systems + 600 Lanidex Plaza + Parsippany, NJ 07054-2711 + US + + EMail: jdrosen@cisco.com + + + + + + + + + + +Schulzrinne, et al. Standards Track [Page 36] + +RFC 4480 RIPD July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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. + + 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Schulzrinne, et al. Standards Track [Page 37] + |