SIMPLE H. Schulzrinne
Internet-Draft Columbia U.
Expires: August 9, 2004 V. Gurbani
Lucent
P. Kyzivat
Cisco
J. Rosenberg
dynamicsoft
February 9, 2004
RPID - Rich Presence Information Data Format
draft-ietf-simple-rpid-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Rich Presence Information Data Format (RPID) adds elements to the
Presence Information Data Format (PIDF) that provide additional
information about the presentity and its contacts. This information
can be translated into call routing behavior or be delivered to
watchers, for example. The information is designed so that much of
it can be derived automatically, e.g., from calendar files or user
activity.
Schulzrinne, et al. Expires August 9, 2004 [Page 1]
Internet-Draft RPID February 2004
Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. The Meaning of "open" and "closed" . . . . . . . . . . . . . . 5
4. RPID Elements . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Activity Element . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Contact-Type Element . . . . . . . . . . . . . . . . . . . . . 8
4.5 Idle Element . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Type of Place Element . . . . . . . . . . . . . . . . . . . . 8
4.7 Privacy Element . . . . . . . . . . . . . . . . . . . . . . . 9
4.8 Relationship Element . . . . . . . . . . . . . . . . . . . . . 10
4.9 Sphere Element . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Presentity with Activity . . . . . . . . . . . . . . . . . . . 11
6. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid-status' . . . . . . . . . . 16
7.2 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 17
7.3 Place Type, Tuple Type, Activities, Relationships . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
Schulzrinne, et al. Expires August 9, 2004 [Page 2]
Internet-Draft RPID February 2004
1. Scope
This extension does not replace media negotiation mechanisms defined
for SIP (e.g., SDP [8]), therefore media negotiation (e.g., choice of
voice and video codecs) MUST be performed according to RFC 3264 [10].
This extension is only aimed to give the watchers hints about the
presentity's preferences, willingness and capabilities to communicate
before watchers initiate SIP-based communication with the presentity.
Schulzrinne, et al. Expires August 9, 2004 [Page 3]
Internet-Draft RPID February 2004
2. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [4]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are
used in the same meaning as defined therein. The key words MUST,
MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and
OPTIONAL in this document are to be interpreted as described in BCP
XX, RFC 2119 [1].
Schulzrinne, et al. Expires August 9, 2004 [Page 4]
Internet-Draft RPID February 2004
3. The Meaning of "open" and "closed"
PIDF describes the basic status values of "open" or "closed" only as
"have meanings of general availability for other communications
means". We define "closed" in our context as meaning that
communication to the contact address will in all likelihood not
succeed, is undesired or will not reach the intended party. (For
example, a presentity may include a hotel phone number as a contact.
After check-out, the phone number will still ring, but reach the
chambermaid or the next guest. Thus, it would be declared "closed".)
For "pres" contacts, "closed" means that no presence status
information is available.
Schulzrinne, et al. Expires August 9, 2004 [Page 5]
Internet-Draft RPID February 2004
4. RPID Elements
4.1 Introduction
Below, we describe the RPID elements in detail. <activity>, <idle>
<placetype>, <privacy>, <relationship>, extend the PIDF <status>
element, while <class> and <contacttype> extend the PIDF <tuple>
element.
In general, it is highly unlikely that a presentity will publish or
announce all of these elements at the same time. Rather, these
elements were chosen to give the presentity maximum flexibility in
deriving this information from existing sources, such as calendaring
tools, device activity sensors or location trackers, as well as to
manually configure this information.
The namespace URIs for these elements defined by this specification
are URNs [2], using the namespace identifier 'ietf' defined by [3]
and extended by [5]:
urn:ietf:params:xml:ns:pidf:rpid-status
urn:ietf:params:xml:ns:pidf:rpid-tuple
4.2 Activity Element
The <activity> indication describes what the presentity is currently
doing. This can be quite helpful to the watcher in judging how
appropriate a communication attempt is and which means of
communications is most likely to succeed and not annoy the
presentity. The activity indications correspond roughly to the
category field in calendar entries, such as Section 4.8.1.2 of RFC
2445.
An activity indication consists of one or more values drawn from the
list below, any other token string or IANA-registered values (Section
Section 7). Communities of interest such as a profession or an
organization may define additional activity labels for their internal
use.
Depending on the presentity intent, all but the "available"
indication can be used with either status OPEN or CLOSED.
Available: The presentity is available for communication.
On-the-phone: The presentity is talking on the telephone. This
activity is included since it can often be derived automatically.
Schulzrinne, et al. Expires August 9, 2004 [Page 6]
Internet-Draft RPID February 2004
Away: The presentity is physically away from the device location.
This activity was included since it can often be derived
automatically from security systems, energy management systems or
entry badge systems.
Appointment: The presentity has a calendar appointment.
Holiday: This is a scheduled national or local holiday. This
information can typically be derived automatically from calendars.
Meal: The presentity is scheduled for a meal. This activity category
can often be generated automatically from a calendar.
Meeting: This activity category can often be generated automatically
from a calendar.
Steering: The presentity is controlling a vehicle, ship or plane.
In-transit: The presentity is riding in a vehicle, such as a car, but
not steering. Alternatively, the presentity MAY offer more
specific information.
Travel: The presentity is on a business or personal trip, but not
necessarily in-transit. This category can often be generated
automatically from a calendar.
Vacation: This activity category can often be generated automatically
from a calendar.
Sleeping: This activity category can often be generated automatically
from a calendar, local time information or biometric data.
Busy: User is busy, without further details. This activity category
would typically be indicated manually.
Permanent-absence: Presentity will not return for the foreseeable
future, e.g., because it is no longer working for the company.
The <activity> element MAY be qualified with the 'from' and 'until'
attributes to describe the time when the element assumed this value
and the time until which is element is expected to be valid. The
'from' time MUST be in the past, the 'until' time in the future
relative to the publication of the presence information.
4.3 Class
The 'class' attribute describes the class of the tuple. Multiple
tuples can have the same class name within a presence document. The
Schulzrinne, et al. Expires August 9, 2004 [Page 7]
Internet-Draft RPID February 2004
naming of classes is left to the presentity. The presentity can use
this information to group similar tuples or to convey information
that the presence agent can use for filtering.
4.4 Contact-Type Element
The <contacttype> element describes the type of the tuple. A tuple
can represent a communication facility ("device"), a face-to-face
communication tuple ("in-person"), a set of devices offering a common
service ("service"), or a whole presentity ("presentity").
Additional types can be registered with IANA.
4.5 Idle Element
The <idle> records the absolute time and date the communication
device was last used. This provides an indication as to how likely a
user is to answer the device. A device that has not been used in a
while may still be OPEN, but a watcher may choose to first contact a
device that is both OPEN and not marked as idle.
The <idle> element can be empty if the presentity wants to indicate
that the device has not been used for a while, but does not want to
reveal the precise duration:
<idle/>
The <idle> SHOULD be included in the presence document if the idle
time exceeds a user-setable threshold, with a RECOMMENDED default
value of 10 minutes. Configuration MUST include the option to omit
the timestamp.
4.6 Type of Place Element
The <placetype> element describes the type of place the presentity is
currently at. This offers the watcher an indication what kind of
communication is likely to be appropriate. We define an initial set
of values below:
home: The presentity is in a private or residential setting, not
necessarily the personal residence of the presentity, e.g.,
including hotel or a friend's home.
office: The presentity is in a business setting, such as an office.
Schulzrinne, et al. Expires August 9, 2004 [Page 8]
Internet-Draft RPID February 2004
public: The presentity is in a public area such as a shopping mall,
street, park, public building, train station, airport or in public
conveyance such as a bus, train, plane or ship. Alternatively, the
more detailed indications below may be provided.
street: Walking in a street.
public-transport: Any form of public transport, including aircraft,
bus, train or ship.
aircraft: The presentity is in a plane, helicopter or balloon.
ship: Water vessel, boat.
bus: Public bus.
train: The presentity is traveling in a train, cable car.
airport: Airport, heliport or similar location.
station: Bus or train station.
mall: Shopping mall or shopping area.
outdoors: General outdoors area, such as a park or city streets.
This list can be augmented by free-text values or additional
IANA-registered values (Section Section 7).
The <placetype> element MAY be qualified with the 'from' and 'until'
attributes to describe the time when the element assumed this value
and the time until which is element is expected to be valid. The
'from' time MUST be in the past, the 'until' time in the future
relative to the publication of the presence information.
4.7 Privacy Element
The 'privacy' element indicates whether third parties may be able to
hear or view parts of the communication.
public: Others may be able to see or hear the communications.
private: Inappropriate individuals are not likely to see or hear the
communications.
Schulzrinne, et al. Expires August 9, 2004 [Page 9]
Internet-Draft RPID February 2004
quiet: The presentity is in a place such as a library, restaurant,
place-of-worship, or theater that discourages noise, conversation
and other distractions.
This indication is not limited to voice communications. For example,
a presentity might label her privacy as "quiet" when giving a talk,
since it would be inappropriate if an instant message popped up on
the laptop screen that is being projected for the audience.
The 'activity' element MAY be qualified with the 'from' and 'until'
attributes to describe the time when the element assumed this value
and the time until which is element is expected to be valid. The
'from' time MUST be in the past, the 'until' time in the future
relative to the publication of the presence information.
4.8 Relationship Element
The <relationship> element designates the type of relationship an
alternate contact has with the presentity. This element is provided
only if the tuple refers to somebody other than the presentity.
Relationship values include "family", "associate" (e.g., for a
colleague), "assistant", "supervisor". Other free-text values and
additional IANA-registered values (Section Section 7) can be used as
well.
The <contact> element for tuples labeled with a relationship can
contain either a communication URI such as "im", "sip"/"sips",
"h323", "tel" or "mailto", or a presence URI, such as "pres" or
"sip".
4.9 Sphere Element
The <sphere> element designates the current state and role that the
presentity plays. For example, it might describe whether the
presentity is in a work mode or at home or participating in
activities related to some other organization such as the IETF or a
church. This document does not define names for these spheres except
for two common ones, "work" and "home".
Spheres are likely to be used for two purposes: they allow the
presentity to easily turn on or off certain rules that depend on what
groups of people should be made aware of the presentity's status.
For example, if the presentity is a Boy Scout leader, he might set
the sphere to 'scouting' and then have a rule set that allows other
scout masters in his troup to see his presence status. As soon as he
switches his status to 'work' or 'home' or some other sphere, the
fellow scouts would lose access.
Schulzrinne, et al. Expires August 9, 2004 [Page 10]
Internet-Draft RPID February 2004
5. Examples
5.1 Presentity with Activity
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:es="urn:ietf:params:xml:ns:pidf:rpid-status"
xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
entity="pres:someone@example.com">
<note>I'm in a boring meeting</note>
<tuple id="7c8dqui">
<et:class>assistant</et:class>
<et:contact-type>presentity</et:contact-type>
<status>
<basic>open</basic>
<contact>sip:secretary@example.com</contact>
<ep:relationship>assistant</ep:relationship>
</status>
<note>My secretary</note>
</tuple>
<tuple id="18x765">
<et:class>sip</et:class>
<et:contact-type>service</et:contact-type>
<status>
<basic>open</basic>
<ep:activity>meeting</ep:meeting>
<ep:placetype until="2003-01-27T17:30:00Z">office</ep:placetype>
<ep:privacy>quiet</ep:privacy>
<ep:idle>2003-01-27T10:43:00Z</ep:idle>
</status>
<contact priority="0.8">sip:someone@example.com</contact>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="35bs9r">
<et:class>phone</et:class>
<et:contact-type>device</et:contact-type>
<status>
<basic>open</basic>
<ep:privacy>quiet</ep:privacy>
</status>
<contact priority="0.8">im:someone@mobilecarrier.net</contact>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
Schulzrinne, et al. Expires August 9, 2004 [Page 11]
Internet-Draft RPID February 2004
<tuple id="8eg92n">
<et:class>mail</et:class>
<et:contact-type>device</et:contact-type>
<status>
<basic>open</basic>
</status>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
</presence>
Schulzrinne, et al. Expires August 9, 2004 [Page 12]
Internet-Draft RPID February 2004
6. XML Schema Definitions
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:params:xml:ns:pidf:rpid-tuple"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
Describes RPID tuple extensions for PIDF.
</xs:documentation>
</xs:annotation>
<xs:element name="contact-type">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="device"/>
<xs:enumeration value="in-person"/>
<xs:enumeration value="service"/>
<xs:enumeration value="presentity"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="class" type="xs:token"/>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
Schulzrinne, et al. Expires August 9, 2004 [Page 13]
Internet-Draft RPID February 2004
<xs:annotation>
<xs:documentation xml:lang="en">
Describes RPID status extensions for PIDF.
</xs:documentation>
</xs:annotation>
<xs:element name="activity" type="activity_t"/>
<xs:simpleType name="activityToken">
<xs:restriction base="xs:token">
</xs:restriction>
</xs:simpleType>
<xs:complexType name="activity_t">
<xs:sequence>
<xs:element name="activity" type="activityToken"/>
</xs:sequence>
<xs:attribute name="from" type="xs:dateTime"/>
</xs:complexType>
<xs:element name="placetype">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name="privacy_t">
<xs:restriction base="xs:token">
<xs:enumeration value="private"/>
<xs:enumeration value="public"/>
<xs:enumeration value="quiet"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="privacy">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="privacy_t">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
Schulzrinne, et al. Expires August 9, 2004 [Page 14]
Internet-Draft RPID February 2004
</xs:element>
<xs:simpleType name="sphereToken">
<xs:restriction base="xs:token">
</xs:restriction>
</xs:simpleType>
<xs:complexType name="sphere_t">
<xs:sequence>
<xs:element name="sphere" type="sphereToken"/>
</xs:sequence>
</xs:complexType>
<xs:element name="sphere">
<xs:complexType>
<xs:complexContent>
<xs:extension base="sphere_t">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="relationship" type="xs:token"/>
<xs:element name="idle" type="xs:dateTime"/>
</xs:schema>
Schulzrinne, et al. Expires August 9, 2004 [Page 15]
Internet-Draft RPID February 2004
7. IANA Considerations
This document calls for IANA to:
o register two new XML namespace URNs per [5];
o establish registry for activity categories (Section Section 4.2,
place types (Section Section 4.6), and relationships (Section
Section 4.8).
Note that this document does not need a new content type. It
inherits the content type from [6], namely application/cpim-pidf+xml.
7.1 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid-status'
URI: urn:ietf:params:xml:ns:rpid-status
Description: This is the XML namespace for XML elements defined by
RFCXXXX to describe rich presence information extensions for the
status element in the PIDF presence document format in the
application/cpim-pidf+xml content type.
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
Henning Schulzrinne, hgs@cs.columbia.edu
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>RPID -- Rich Presence Information Data Format
for Presence</title>
</head>
<body>
<h1>Namespace for rich presence extension (status)</h1>
<h2>application/pidf+xml</h2>
<p>See <a href="URL of published RFC">RFCXXXX</a>.</p>
</body>
</html>
END
Schulzrinne, et al. Expires August 9, 2004 [Page 16]
Internet-Draft RPID February 2004
7.2 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid-tuple'
urn:ietf:params:xml:ns:rpid-tuple
This is the XML namespace for XML elements defined by RFCXXXX to
describe rich presence information extensions for the tuple element
in the PIDF presence document format in the application/cpim-pidf+xml
content type.
IETF, SIMPLE working group, simple@ietf.org, Henning Schulzrinne,
hgs@cs.columbia.edu.
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>RPID -- Rich Presence Information Data Format
for Presence</title>
</head>
<body>
<h1>Namespace for rich presence extension (tuple)</h1>
<h2>application/pidf+xml</h2>
<p>See <a href="URL of published RFC">RFCXXXX</a>.</p>
</body>
</html>
END
7.3 Place Type, Tuple Type, Activities, Relationships
This document creates new IANA registries for activities, tuple
types, place types and relationships. All are XML tokens.
Registered tokens must be documented at the time of registration, as
most descriptions are expected to be brief.
The SIMPLE working group, or, if no longer available, the SIP working
group should be consulted prior to registration.
Schulzrinne, et al. Expires August 9, 2004 [Page 17]
Internet-Draft RPID February 2004
8. Security Considerations
The security considerations in [6] apply, as well as [7]. 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.
Schulzrinne, et al. Expires August 9, 2004 [Page 18]
Internet-Draft RPID February 2004
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] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[4] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[5] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003.
[6] Sugano, H. and S. Fujimoto, "Presence Information Data Format
(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
2003.
[7] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
Schulzrinne, et al. Expires August 9, 2004 [Page 19]
Internet-Draft RPID February 2004
Informative References
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[9] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
[10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for
User Control of Internet Telephony Services",
draft-ietf-iptel-cpl-08 (work in progress), August 2003.
[12] Dawson, F., Reddy, S., Royer, D. and E. Plamondon, "iCalendar
DTD Document (xCal)", draft-ietf-calsch-many-xcal-02 (work in
progress), July 2002.
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 9, 2004 [Page 20]
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
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054-2711
US
EMail: jdrosen@dynamicsoft.com
Schulzrinne, et al. Expires August 9, 2004 [Page 21]
Internet-Draft RPID February 2004
Appendix A. Acknowledgements
The document reflects the discussion on the SIMPLE mailing list, with
contributions from many individuals. Markus Isomaki, Hisham
Khartabil, Jon Peterson and Brian Rosen provided detailed comments
and suggestions. Xiaotao Wu assisted with schema testing.
Schulzrinne, et al. Expires August 9, 2004 [Page 22]
Internet-Draft RPID February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schulzrinne, et al. Expires August 9, 2004 [Page 23]
Internet-Draft RPID February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne, et al. Expires August 9, 2004 [Page 24]
