SIMPLE H. Schulzrinne
Internet-Draft Columbia U.
Expires: August 19, 2004 V. Gurbani
Lucent
P. Kyzivat
J. Rosenberg
Cisco
February 19, 2004
RPID: Rich Presence Extensions to the Presence Information Data
Format (PIDF)
draft-ietf-simple-rpid-05
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The Presence Information Data Format (PIDF) defines a basic format
for representing presence information for a presentity. That format
Schulzrinne, et al. Expires August 19, 2004 [Page 1]
Internet-Draft RPID February 2004
defines a textual note, an indication of availability (open or
closed) and a Universal Resource Identifier (URI) for communication.
The Rich Presence Information Data Format (RPID) described here is an
extension that adds optional elements to the Presence Information
Data Format (PIDF). These extensions provide additional information
about the presentity and its contacts. The information is designed
so that much of it can be derived automatically, e.g., from calendar
files or user activity.
This extension includes information about what the person is doing, a
grouping identifier for a tuple, when a service or device was last
used, the type of place a person is in, what media might be private,
the relationship of a service tuple to another presentity, the
person's mood, the time zone it is located in, the type of service it
offers and the overall role of the presentity.
These extensions include characteristics and status information for
person, service (tuple) and devices.
Schulzrinne, et al. Expires August 19, 2004 [Page 2]
Internet-Draft RPID February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . 5
3. RPID Elements . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Activities Element . . . . . . . . . . . . . . . . . . . . 8
3.3 Class Element . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Device Identifier . . . . . . . . . . . . . . . . . . . . 10
3.5 Mood Element . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Place-is Element . . . . . . . . . . . . . . . . . . . . . 12
3.7 Place-type Element . . . . . . . . . . . . . . . . . . . . 12
3.8 Privacy Element . . . . . . . . . . . . . . . . . . . . . 13
3.9 Relationship Element . . . . . . . . . . . . . . . . . . . 14
3.10 Service Class . . . . . . . . . . . . . . . . . . . . . 14
3.11 Sphere Element . . . . . . . . . . . . . . . . . . . . . 15
3.12 Status-Icon Element . . . . . . . . . . . . . . . . . . 15
3.13 Time Offset . . . . . . . . . . . . . . . . . . . . . . 15
3.14 User-Input Element . . . . . . . . . . . . . . . . . . . 16
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. XML Schema Definitions . . . . . . . . . . . . . . . . . . . 19
5.1 urn:ietf:params:xml:ns:pidf:rpid-person . . . . . . . . . 19
5.2 urn:ietf:params:xml:ns:pidf:rpid-tuple . . . . . . . . . . 24
5.3 urn:ietf:params:xml:ns:pidf:status:rpid-status . . . . . . 24
5.4 urn:ietf:params:xml:ns:pidf:rpid-device . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
6.1 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . 26
6.2 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . 27
6.3 Schema Registration for Schema
urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . 28
6.4 Schema Registration for Schema
urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . 28
6.5 Token Registrations . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29
8.2 Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . 32
Schulzrinne, et al. Expires August 19, 2004 [Page 3]
Internet-Draft RPID February 2004
1. Introduction
The Presence Information Data Format (PIDF) definition [7] describes
a basic presence information data format, encoded as an Extensible
Markup Language (XML) document, for exchanging presence information
in CPIM-compliant systems. It consists of a <presence> root element,
zero or more <tuple> elements carrying presence information including
a Universal 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".
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. 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 [12] defines the concepts of service, device,
and person as the data elements that are used to model the state of a
presentity. Services are encoded using the <tuple> element, defined
in PIDF; devices and persons are represented by the <device> and
<person> XML elements, respectively, defined in the the data model
[12]. However, neither PIDF nor the data model define 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 which 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 CPIM-compliant systems, both in terms of
user acceptance and protocol conversion.
2. Maintain backwards-compatibility with PIDF, so that PIDF-only
watchers and gateways can continue to function properly,
naturally without access to the functionality described here.
Schulzrinne, et al. Expires August 19, 2004 [Page 4]
Internet-Draft RPID February 2004
We make no assumptions 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 physical presence
detectors as commonly found in energy-management systems.
Many of the elements correspond to data commonly found in personal
calendars. Thus, we attempted to align some of the extensions with
the usage found in calendar formats such as iCal [10].
The information in a presence document can be generated by a single
entity or can be composed from information published by multiple
entities.
Note that PIDF documents and this extension can be used in two
different contexts, namely by the presentity to publish its presence
status and by the presence server to notify some set of watchers.
The presence server MAY compose, translate or filter the published
presence state before delivering customized presence information to
the watcher. For example, it may merge presence information from
multiple PUAs, remove whole elements, translate values in elements or
remove information from elements. Mechanisms that filter calls and
other communications to the presentity can subscribe to this presence
information just like a regular watcher and in turn generate
automated rules, such as scripts [11], that govern the actual
communications behavior of the presentity. Details are described in
the data model document.
Since RPID is a PIDF XML document, it also uses the content type
application/pidf+xml.
2. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [5]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are
used in the same meaning as defined therein.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC 2119 [1].
3. RPID Elements
Schulzrinne, et al. Expires August 19, 2004 [Page 5]
Internet-Draft RPID February 2004
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. Furthermore, some are dynamic status
information, and others describe more static characteristics, and
thus may extend <status> or the root <tuple>, <device> or <person>
elements.
Below, we summarize the RPID elements. The next sections will then
provide more detailed descriptions.
activities: The <activities> status element describes what the person
is doing, using an enumeration of <activity> elements.
class: An identifier that groups similar person elements, devices or
services.
device-id: A device identifier 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 elements reports on the properties,
such as light and noise, the person is in.
place-type: The <place-type> status elements reports the type of
place the person is located in.
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. Relationship is a
characteristic.
service-type: The <service-type> 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 role of the
presentity.
status-icon: The <status-icon> element depicts the current status of
the person.
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 usage of these elements within the <person>, <tuple> and <device>
elements is shown in Table Table 1. An 'x' in the respective column
indicates that the RPID element MAY appear as a child of that
element.
Schulzrinne, et al. Expires August 19, 2004 [Page 6]
Internet-Draft RPID February 2004
+-----------------+--------------+----------+---------+----------+
| Element | Since/until? | <person> | <tuple> | <device> |
+-----------------+--------------+----------+---------+----------+
| <activities> | x | x | | |
| <class> | | x | x | x |
| <device-id> | | | | x |
| <mood> | x | x | | |
| <place-is> | x | x | | |
| <place-type> | x | x | | |
| <privacy> | x | | x | |
| <relationship> | | | x | |
| <service-class> | | | x | |
| <sphere> | x | x | | |
| <status-icon> | 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.
The namespace URIs for these elements defined by this specification
are URNs [2], using the namespace identifier 'ietf' defined by [4]
and extended by [6]:
urn:ietf:params:xml:ns:pidf:status:rpid-status
urn:ietf:params:xml:ns:pidf:rpid-tuple
urn:ietf:params:xml:ns:pidf:rpid-person
urn:ietf:params:xml:ns:pidf:rpid-device
This document uses a separate namespace for extending the PIDF
<status> namespace, in accordance with Sections 4.2.5 and 4.3.2 of
[7].
All elements described in this document are optional.
The elements marked with the value 'x' in Table 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
Schulzrinne, et al. Expires August 19, 2004 [Page 7]
Internet-Draft RPID February 2004
<timestamp> element.
All elements may be generated either automatically, derived from
sensor information or a calendar, or provided manually, via some user
interface, by the presentity. In either case, there is no guarantee
that the information is accurate, as users forget to update calendars
or may not always adjust the presence information manually.
3.2 Activities Element
The <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. This can be quite helpful to the
watcher in judging how appropriate a communication attempt is and
which means of communications is most likely to succeed and not annoy
the person. The activity indications correspond roughly to the
category field in calendar entries, such as Section 4.8.1.2 of RFC
2445 [10].
An activities enumeration consists of one or more elements using
values drawn from the list below, any other token string or
IANA-registered values (Section 6).
If a person publishes an activity of "perment-absence", it is likely
that all services will report a status of CLOSED. In general,
services MAY advertise either service status for any activity value.
away: The person is physically away from all interactive
communication devices location. This activity was included since
it can often be derived automatically from security systems,
energy management systems or entry badge systems. While this
activity would typically be associated with a status of CLOSED
across all services, a person may declare itself away to
discourage communication, but indicate that it still can be
reached if needed, but communications might reach an answering
service, for example.
appointment: The person has a calendar appointment, without
specifying exactly of what type. This activity is indicated if
more detailed information is not available or the person chooses
not to reveal more information.
busy: User is busy, without further details. While this activity
would typically be associated with a status of CLOSED across all
services, a person may declare itself busy to discourage
communication, but indicate that it still can be reached if
needed.
Schulzrinne, et al. Expires August 19, 2004 [Page 8]
Internet-Draft RPID February 2004
holiday: This is a scheduled national or local holiday. This
information can typically be derived automatically from calendars.
in-transit: The person is riding in a vehicle, such as a car, but not
steering. The <place-type> element provides more specific
information about the type of conveyance the person is using.
meal: The person is scheduled for a meal. This activity category can
often be generated automatically from a calendar.
meeting: A meeting is a sub-class of an appointment. This activity
category can often be generated automatically from a calendar.
on-the-phone: The person is talking on the telephone. This activity
is included since it can often be derived automatically.
performance: A performance is a sub-class of an appointment and
includes musical, theatrical and cinematic performances as well as
lectures. It is distinguished from a meeting by the fact that the
person may either be lecturing or be in the audience, with a
potentially large number of other people, making interruptions
particularly noticeable. This activity category can often be
generated automatically from a calendar.
permanent-absence: person will not return for the foreseeable future,
e.g., because it is no longer working for the company. This
activity is associated with a status of CLOSED across all
services.
sleeping: This activity category can often be generated automatically
from a calendar, local time information or biometric data.
steering: The person is controlling a vehicle, ship or plane.
travel: The person is on a business or personal trip, but not
necessarily in-transit. This category can often be generated
automatically from a calendar.
vacation: Leisure travel. This activity category can often be
generated automatically from a calendar.
The <activities> element MAY be qualified with the 'since' and
'until' attributes as described in Section 3.
If the entity described by a tuple is involved in multiple activities
at the same time, the <activities> element enumerates all unique
values as child <activity> elements.
The <activities> element can be extended by adding elements from
other namespaces, e.g., to reflect activities appropriate for a
particular occupation.
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. The naming of classes is left to the presentity.
The presentity can use this information to group similar services,
Schulzrinne, et al. Expires August 19, 2004 [Page 9]
Internet-Draft RPID February 2004
devices or person elements or to convey information that the presence
agent can use for filtering or authorization.
3.4 Device Identifier
The <device-id> element references the device that provides a
particular service. One service can be provided by multiple devices,
so that each service tuple may contain zero or more <device-id>
elements. There is no significance in the order of these elements.
The <device-id> element generally contains a URN. It is only used
for identification and matching and conveys no further substantive
information. The choice of URN is beyond the scope of this document.
Such URNs SHOULD remain the same for the same physical device across
time even if the device is rebooted or acquires a different network
address. [TBD: should urn:mac: and urn:esn: be registered?]
The <device-id> element MUST NOT be qualified with the 'since' and
'until' attributes as described in Section 3.
3.5 Mood Element
The <mood> element describes the mood of the presentity. They are
enumerated chosen by the presentity. The mood itself is provided as
the element name of a defined child element of the <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 <text/> child of the element, which is OPTIONAL. (This
definition follows the Jabber Extension JEP-107.) It is RECOMMENDED
that an implementation support the mood values proposed in Jabber
Extension JEP-0107, which in turn are a superset of the Wireless
Village [14] mood values and the values enumerated in the Affective
Knowledge Representation that has been defined by Lisetti [13]:
afraid
amazed
angry
annoyed
anxious
ashamed
bored
brave
calm
cold
confused
contented
cranky
Schulzrinne, et al. Expires August 19, 2004 [Page 10]
Internet-Draft RPID February 2004
curious
depressed
disappointed
disgusted
distracted
embarrassed
excited
flirtatious
frustrated
grumpy
guilty
happy
hot
humbled
humiliated
hungry
hurt
impressed
in_awe
in_love
indignant
interested
invincible
jealous
lonely
mean
moody
nervous
neutral
offended
playful
proud
relieved
remorseful
restless
sad
sarcastic
serious
shocked
shy
sick
sleepy
stressed
surprised
thirsty
worried
Schulzrinne, et al. Expires August 19, 2004 [Page 11]
Internet-Draft RPID February 2004
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 what kind of
communication is likely to be successful. We define an initial set
of values below:
bright: The person is in a bright place, sufficient for good
rendering on video.
dark: The person is in a dark place, and thus may not be rendered
well on video.
noisy: The person is in a place with lots of background noise.
quiet: The person is in a place such as a library, restaurant,
place-of-worship, or theater that discourages noise, conversation
and other distractions.
This list can be augmented by free-text values in a note or
additional IANA-registered values (Section 6).
The <place-is> element contains other elements, e.g.,
<place-is><noisy /></place-is>
The <place-is> element MAY be qualified with the 'since' and 'until'
attributes as described in Section 3.
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 what kind of
communication is likely to be appropriate. We define an initial set
of values below:
aircraft: The person is in a plane, helicopter or balloon.
airport: The person is located in an airport, heliport or similar
location.
bus: The person is travling in a public or charter bus.
car: The person is in an automobile.
convention center: The person is in a convention center.
home: The person is in a private or residential setting, not
necessarily the personal residence of the person, e.g., including
hotel or a friend's home.
hotel: The person is in a hotel, motel, inn or other lodging
establishment.
industrial: The person is in an industrial setting, such as a
manufacturing floor or power plant.
Schulzrinne, et al. Expires August 19, 2004 [Page 12]
Internet-Draft RPID February 2004
library: The person is in a library or other public place that
provides access to books, music and reference materials.
mall: The person is frequenting a shopping mall or shopping area.
office: The person is in a business setting, such as an office.
outdoors: The person is in a general outdoors area, such as a park or
city streets.
public: The person is in a public area such as a shopping mall,
street, park, public building, train station, airport or in public
conveyance such as a bus, train, plane or ship. This general
description encompasses the more precise descriptors "street",
"public-transport", "aircraft", "ship", "bus", "train", "airport",
"mall" and "outdoors" below.
public-transport: The person is using any form of public transport,
including aircraft, bus, train or ship.
restaurant: The person is in a restaurant, coffee shop or other
public dining establishment.
school: The person is in a school or university, but not necessarily
in a classroom or library.
ship: The person is traveling in a water vessel or boat.
station: The person is located in a bus or train station.
street: The person is walking in a street.
theater: The person is in a theater, lecture hall, auditorium, class
room, movie theater or similar facility designed for
presentations, talks, plays, music performances and other events
involving an audience.
train: The person is traveling in a train, monorail, maglev, cable
car or similar conveyance.
truck: The person is in a truck, used primarily to carry goods rather
than people.
This list can be augmented by free-text values or additional
IANA-registered values (Section 6).
The <place-type> element is a tokenlist, e.g.,
<place-type>street public</place-type>
The <place-type> element MAY be qualified with the 'since' and
'until' attributes as described in Section 3.
3.8 Privacy Element
The <privacy> element indicates which type of communication third
parties in the vicinity of the presentity are unlikely to be able to
intercept accidentally or intentionally. This does not in any way
describe the privacy properties of the electronic communication
channel, e.g., properties of the encryption algorithm of the network
protocol used.
Schulzrinne, et al. Expires August 19, 2004 [Page 13]
Internet-Draft RPID February 2004
audio: Audio communication is likely only to be heard by the intended
recipient.
video: Inappropriate individuals are not likely to see video
communications.
text: Inappropriate individuals are not likely to see text
communications.
The <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 as "private" to a select subset of the watchers.
The <privacy> element MAY be qualified with the 'since' and 'until'
attributes as described in Section 3.
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", "associate"
(e.g., for a colleague), "assistant", "supervisor". Other free-text
values and additional IANA-registered values (Section 6) can be used
as well.
If a relationship is indicated, the URI in the <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".
3.10 Service Class
The <service-class> element extends <tuple> and designates the type
of service offered, namely electronic, delivery (including courier),
postal or in-person. Electronic service is implied if omitted. The
service types 'postal', 'delivery' and 'in-person' MUST NOT be used
unless the contact URI is empty. Additional data elements defined
elsewhere describe the physical service delivery address for the
in-person, postal or delivery services. Such addresses might be
specified in geospatial coordinates, civic addresses or some
specialized address format, e.g., for interstellar addresses or a
company-specific delivery system.
Schulzrinne, et al. Expires August 19, 2004 [Page 14]
Internet-Draft RPID February 2004
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 or at home or participating in activities related to
some other organization such as the IETF or a church. This document
does not define names for these spheres except for two common ones,
"work" and "home".
Spheres are likely to be used for two purposes: they allow the
person to easily turn on or off certain rules that depend on what
groups of people should be made aware of the person's status. For
example, if the person is a Boy Scout leader, he might set the sphere
to "scouting" and then have a rule set that allows other scout
masters in his troop to see his presence status. As soon as he
switches his status to "work" or "home" or some other sphere, the
fellow scouts would lose access.
The <sphere> element MAY be qualified with the 'since' and 'until'
attributes as described in Section 3.
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
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.
3.13 Time Offset
The <time-offset> element describes the number of minutes of offset
from UTC at the user'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. Since daylight savings time
adjustment 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.
Schulzrinne, et al. Expires August 19, 2004 [Page 15]
Internet-Draft RPID February 2004
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.
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
summarize 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
'since' attribute that records when the last user input has been
received. An optional 'idle-threshold' element records how long the
presentity will wait before reporting the service or device to be
idle, measured in seconds.
(A two-state model was chosen since it would otherwise be necessary
to send repeated last-input updates during continuous activity.)
A service that wants to indicate user input activity sends a
<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 'since'
attribute. An example is below:
<user-input idle-threshold="600"
since="2004-10-21T13:20:00.000-05:00">active</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.
Schulzrinne, et al. Expires August 19, 2004 [Page 16]
Internet-Draft RPID February 2004
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:
<user-input>idle</user-input>
Configuration MUST include the option to omit the 'since' attribute.
4. Example
The example below describes the presentity
'pres:someone@example.com', which has a SIP contact,
'sip:someone@example.com', representing a service. It also has a
device contact, as an email box. The presentity is in a meeting, in
a public office setting. The 'until' information indicates that he
will be there until 5.30 pm GMT. The presentity also has an
assistant, sip:secretary@example.com, who happens to be available for
communications.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf:person"
xmlns:d="urn:ietf:params:xml:ns:pidf:device"
xmlns:rs="urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns:rt="urn:ietf:params:xml:ns:pidf:rpid-tuple"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid-person"
xmlns:rd="urn:ietf:params:xml:ns:pidf:rpid-device"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
entity="pres:someone@example.com"
xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd
urn:ietf:params:xml:ns:pidf:status:rpid-device rpid-device.xsd
urn:ietf:params:xml:ns:pidf:status:rpid-tuple rpid-tuple.xsd
urn:ietf:params:xml:ns:pidf:status:rpid-person rpid-person.xsd
urn:ietf:params:xml:ns:pidf:status:rpid-status rpid-status.xsd
urn:ietf:params:xml:ns:pidf:rpid-tuple rpid-tuple.xsd">
<tuple id="t0">
<status>
<basic>open</basic>
</status>
<et:class>assistant</et:class>
<et:relationship>assistant</et:relationship>
<contact>sip:secretary@example.com</contact>
<note>My secretary</note>
</tuple>
<tuple id="t1">
<status>
<basic>open</basic>
Schulzrinne, et al. Expires August 19, 2004 [Page 17]
Internet-Draft RPID February 2004
<rs:privacy>
<audio/>
</rs:privacy>
<rs:idle since="2003-01-27T10:43:00Z"/>
</status>
<et:class>sip</et:class>
<contact priority="0.8">sip:someone@example.com</contact>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="t2">
<status>
<basic>open</basic>
<e:privacy>
<text/>
</e:privacy>
<e:timeoffset>300</e:timeoffset>
</status>
<contact priority="0.8">im:someone@mobilecarrier.net</contact>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="t3">
<status>
<basic>open</basic>
</status>
<et:class>mail</et:class>
<contact priority="1.0">mailto:someone@example.com</contact>
<note>I'm in a boring meeting</note>
</tuple>
<tuple id="t4">
<status>
<basic>closed</basic>
</status>
<et:service-class>in-person</et:class>
<note>Closed-door meeting</note>
</tuple>
<p:person>
<p:status>
<rp:activities>
<rp:meeting/>
</rp:activities>
<rp:class>composed</rp:class>
<rp:mood>
<rp:happy/>
<rp:text>I got my paycheck!</rp:text>
</rp:mood>
<rp:place-type until="2003-01-27T17:30:00Z">
<rp:office/>
</rp:place-type>
Schulzrinne, et al. Expires August 19, 2004 [Page 18]
Internet-Draft RPID February 2004
</person>
</presence>
5. XML Schema Definitions
5.1 urn:ietf:params:xml:ns:pidf:rpid-person
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:pidf:rpid-person"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid-person"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<annotation>
<documentation xml:lang="en">
Describes RPID tuple extensions for PIDF.
</documentation>
</annotation>
<attributeGroup name="SinceUntil">
<attribute name="since" type="dateTime"/>
<attribute name="until" type="dateTime"/>
</attributeGroup>
<element name='away' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='busy' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='appointment' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='holiday' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='in-transit' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
Schulzrinne, et al. Expires August 19, 2004 [Page 19]
Internet-Draft RPID February 2004
</element>
<element name='meal' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='meeting' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='on-the-phone' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='performance' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='permanent-absence' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='sleeping' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='steering' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='travel' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name='vacation' substitutionGroup="rp:activity-value">
<complexType><attributeGroup ref="rp:SinceUntil"/></complexType>
</element>
<element name="activities">
<complexType>
<sequence>
<element ref="rp:activity-value"
minOccurs="0" maxOccurs="unbounded">
</element>
<any maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="class" type="token"/>
<element name='mood'>
<complexType>
<sequence>
<choice>
<element name='afraid' type='rp:empty'/>
<element name='amazed' type='rp:empty'/>
Schulzrinne, et al. Expires August 19, 2004 [Page 20]
Internet-Draft RPID February 2004
<element name='angry' type='rp:empty'/>
<element name='annoyed' type='rp:empty'/>
<element name='anxious' type='rp:empty'/>
<element name='aroused' type='rp:empty'/>
<element name='ashamed' type='rp:empty'/>
<element name='bored' type='rp:empty'/>
<element name='brave' type='rp:empty'/>
<element name='calm' type='rp:empty'/>
<element name='cold' type='rp:empty'/>
<element name='confused' type='rp:empty'/>
<element name='contented' type='rp:empty'/>
<element name='cranky' type='rp:empty'/>
<element name='curious' type='rp:empty'/>
<element name='depressed' type='rp:empty'/>
<element name='disappointed' type='rp:empty'/>
<element name='disgusted' type='rp:empty'/>
<element name='distracted' type='rp:empty'/>
<element name='embarrassed' type='rp:empty'/>
<element name='excited' type='rp:empty'/>
<element name='flirtatious' type='rp:empty'/>
<element name='frustrated' type='rp:empty'/>
<element name='grumpy' type='rp:empty'/>
<element name='guilty' type='rp:empty'/>
<element name='happy' type='rp:empty'/>
<element name='hot' type='rp:empty'/>
<element name='humbled' type='rp:empty'/>
<element name='humiliated' type='rp:empty'/>
<element name='hungry' type='rp:empty'/>
<element name='hurt' type='rp:empty'/>
<element name='impressed' type='rp:empty'/>
<element name='in_awe' type='rp:empty'/>
<element name='in_love' type='rp:empty'/>
<element name='indignant' type='rp:empty'/>
<element name='interested' type='rp:empty'/>
<element name='intoxicated' type='rp:empty'/>
<element name='invincible' type='rp:empty'/>
<element name='jealous' type='rp:empty'/>
<element name='lonely' type='rp:empty'/>
<element name='mean' type='rp:empty'/>
<element name='moody' type='rp:empty'/>
<element name='nervous' type='rp:empty'/>
<element name='neutral' type='rp:empty'/>
<element name='offended' type='rp:empty'/>
<element name='playful' type='rp:empty'/>
<element name='proud' type='rp:empty'/>
<element name='relieved' type='rp:empty'/>
<element name='remorseful' type='rp:empty'/>
<element name='restless' type='rp:empty'/>
Schulzrinne, et al. Expires August 19, 2004 [Page 21]
Internet-Draft RPID February 2004
<element name='sad' type='rp:empty'/>
<element name='sarcastic' type='rp:empty'/>
<element name='serious' type='rp:empty'/>
<element name='shocked' type='rp:empty'/>
<element name='shy' type='rp:empty'/>
<element name='sick' type='rp:empty'/>
<element name='sleepy' type='rp:empty'/>
<element name='stressed' type='rp:empty'/>
<element name='surprised' type='rp:empty'/>
<element name='thirsty' type='rp:empty'/>
<element name='worried' type='rp:empty'/>
</choice>
<element name='text' minOccurs='0' type='string'/>
</sequence>
</complexType>
</element>
<element name="place-type">
<complexType>
<simpleContent>
<extension base="tokenlist">
<attributeGroup ref="SinceUntil"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="privacy">
<complexType name="privacy-list">
<all>
<element name="audio" type="rp:empty" minOccurs="0"/>
<element name="video" type="rp:empty" minOccurs="0"/>
<element name="text" type="rp:empty" minOccurs="0"/>
</all>
<attributeGroup ref="rp:SinceUntil"/>
</complexType>
</element>
<element name="sphere">
<complexType>
<simpleContent>
<extension base="tokenlist">
<attributeGroup ref="SinceUntil"/>
</extension>
</simpleContent>
</complexType>
</element>
Schulzrinne, et al. Expires August 19, 2004 [Page 22]
Internet-Draft RPID February 2004
<element name="status-icon" type="anyURI"/>
<element name="timeoffset">
<complexType>
<simpleContent>
<extension base="integer">
<attributeGroup ref="rp:SinceUntil"/>
</extension>
</simpleContent>
</complexType>
</element>
<simpleType name='empty'>
<restriction base='string'>
<enumeration value=''/>
</restriction>
</simpleType>
</schema>
Schulzrinne, et al. Expires August 19, 2004 [Page 23]
Internet-Draft RPID February 2004
5.2 urn:ietf:params:xml:ns:pidf:rpid-tuple
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:pidf:rpid-tuple"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid-tuple"
xmlns="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"/>
<annotation>
<documentation xml:lang="en">
Describes RPID tuple extensions for PIDF.
</documentation>
</annotation>
<element name="class" type="token"/>
<element name="relationship" type="token"/>
<element name="service-class">
<simpleType>
<restriction base="token">
<enumeration value="electronic"/>
<enumeration value="in-person"/>
<enumeration value="postal"/>
<enumeration value="delivery"/>
</restriction>
</simpleType>
</element>
</schema>
5.3 urn:ietf:params:xml:ns:pidf:status:rpid-status
Schulzrinne, et al. Expires August 19, 2004 [Page 24]
Internet-Draft RPID February 2004
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns:rp="urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<annotation>
<documentation xml:lang="en">
Describes RPID status extensions for PIDF.
</documentation>
</annotation>
<attributeGroup name="SinceUntil">
<attribute name="since" type="dateTime"/>
<attribute name="until" type="dateTime"/>
</attributeGroup>
<element name="privacy">
<complexType>
<simpleContent>
<extension base="tokenlist">
<attributeGroup ref="SinceUntil"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="status-icon" type="anyURI"/>
<element name="user-input">
<complexType>
<attribute name="idle-threshold" type="positiveInteger"/>
<attribute name="since" type="dateTime"/>
</complexType>
</element>
</schema>
Schulzrinne, et al. Expires August 19, 2004 [Page 25]
Internet-Draft RPID February 2004
5.4 urn:ietf:params:xml:ns:pidf:rpid-device
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:pidf:rpid-device"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid-device"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:p="urn:ietf:params:xml:ns:pidf:device"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:ietf:params:xml:ns:pidf:device"
schemaLocation="http://www.cs.columbia.edu/~hgs/tmp/device.xsd"/>
<annotation>
<documentation xml:lang="en">
Describes RPID status extensions for PIDF.
</documentation>
</annotation>
<element name="device-id" type="string" substitutionGroup="p:deviceCharacteristicAbstractType"/>
</schema>
6. IANA Considerations
This document calls for IANA to:
o register two new XML namespace URNs per [6];
o establish registries for <activities> (Section 3.2), <mood>
(Section 3.5) <place-type> (Section 3.7), <privacy> (Section 3.8,
and <relationship> (Section 3.9) categories.
Note that this document does not need a new content type. It
inherits the content type from [7], namely application/pidf+xml.
6.1 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:status:rpid-status'
URI: urn:ietf:params:xml:ns:pidf:status:rpid-status
Description: This is the XML namespace for XML elements defined by
RFCXXXX [RFC editor: replace with RFC number] to describe rich
presence information extensions for the status element in the PIDF
presence document format in the application/pidf+xml content type.
Schulzrinne, et al. Expires August 19, 2004 [Page 26]
Internet-Draft RPID February 2004
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
Henning Schulzrinne, hgs@cs.columbia.edu
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>RPID: Rich Presence: Extensions to the Presence
Information Data Format (PIDF)</title>
</head>
<body>
<h1>Namespace for rich presence extension (status)</h1>
<h2>urn:ietf:params:xml:ns:pidf:status:rpid-status</h2>
<p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
editor: replace with RFC number]</a>.</p>
</body>
</html>
END
6.2 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid-tuple'
URI: urn:ietf:params:xml:ns:pidf:rpid-tuple
Description: This is the XML namespace for XML elements defined by
RFCXXXX [RFC editor: replace with RFC number] to describe rich
presence information extensions for the tuple element in the PIDF
presence document format in the application/pidf+xml content type.
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
Henning Schulzrinne, hgs@cs.columbia.edu.
XML:
Schulzrinne, et al. Expires August 19, 2004 [Page 27]
Internet-Draft RPID February 2004
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>RPID: Rich Presence: Extensions to the Presence
Information Data Format (PIDF)</title>
</head>
<body>
<h1>Namespace for rich presence extension (tuple)</h1>
<h2>urn:ietf:params:xml:ns:pidf:rpid-tuple</h2>
<p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
editor: replace with RFC number]</a>.</p>
</body>
</html>
END
6.3 Schema Registration for Schema
urn:ietf:params:xml:ns:pidf:rpid-tuple'
URI: please assign
Registrant Contact: IESG
XML: See Section 5.2
6.4 Schema Registration for Schema
urn:ietf:params:xml:ns:pidf:status:rpid-status'
URI: please assign
Registrant Contact: IESG
XML: See Section 5.3
6.5 Token Registrations
This document creates new IANA registries for RPID elements:
activities: See Section 3.2
mood: See Section 3.5
place-type: See Section 3.7
privacy: See Section 3.8
relationship: See Section 3.9
All are XML tokens. Registered tokens must be documented at the time
of registration, as most descriptions are expected to be brief.
Schulzrinne, et al. Expires August 19, 2004 [Page 28]
Internet-Draft RPID February 2004
Following the policies outline in RFC 2434 [3], these tokens are
assigned after Expert Review by the SIMPLE working group or its
designated successor. Each registration must include the name of the
token and a brief description similar to the ones offered in for the
initial registrations contained this document:
Name of token: XML token describing the contact type, place type,
privacy or relationship.
Description: Brief description indicating the meaning of the token.
7. Security Considerations
The security considerations in [7] apply, as well as [8]. Compared
to PIDF, this presence document format reveals additional information
that can be highly sensitive. Beyond traditional security measures
to protect confidentiality and integrity, systems should offer a
means to selectively reveal information to particular watchers and to
inspect the information that is being published, particularly if it
is generated automatically from other sources, such as calendars or
sensors.
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
Schulzrinne, et al. Expires August 19, 2004 [Page 29]
Internet-Draft RPID February 2004
in progress), January 2003.
[9] W3C, "Extensible Markup Language (XML) 1.0", W3C Recommendation
XML 1.0, February 1998.
8.2 Informative References
[10] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
[11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for
User Control of Internet Telephony Services",
draft-ietf-iptel-cpl-09 (work in progress), April 2004.
[12] Rosenberg, J., "A Data Model for Presence",
draft-ietf-simple-presence-data-model-01 (work in progress),
October 2004.
[13] Lisetti, C., "Personality, Affect, and Emotion Taxonomy for
Socially Intelligent Agents", Proceedings of FLAIRS 2002, 2002.
[14] Open Mobile Alliance, "The Wireless Village Initiative:
Presence Attributes 1.1", Recommendation WV-29, 2004.
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
EMail: hgs+simple@cs.columbia.edu
URI: http://www.cs.columbia.edu
Vijay Gurbani
Lucent
2000 Naperville Rd.
Room 6G-440
Naperville, IL 60566-7033
US
EMail: vkg@lucent.com
Schulzrinne, et al. Expires August 19, 2004 [Page 30]
Internet-Draft RPID February 2004
Paul Kyzivat
Cisco Systems
BXB500 C2-2
1414 Massachusetts Avenue
Boxborough, MA 01719
US
EMail: pkzivat@cisco.com
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054-2711
US
EMail: jdrosen@dynamicsoft.com
Appendix A. Acknowledgements
The document reflects the discussion on the SIMPLE mailing list, with
contributions from many individuals. Aki Niemi, Miguel Garcia,
Markus Isomaki, Hisham Khartabil, Paul Kyzivat, Jonathan Lennox,
Eva-Maria Leppanen, Mikko Lonnfors, Jon Peterson and Brian Rosen
provided detailed comments and suggestions. Xiaotao Wu assisted with
schema testing.
Schulzrinne, et al. Expires August 19, 2004 [Page 31]
Internet-Draft RPID February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne, et al. Expires August 19, 2004 [Page 32]