One document matched: draft-ietf-simple-rpids-00.txt
Internet Engineering Task Force
Internet Draft H. Schulzrinne (ed.)
Columbia U.
draft-ietf-simple-rpids-00.txt
June 22, 2003
Expires: December 2003
RPIDS -- Rich Presence Information Data Format for Presence Based
on the Session Initiation Protocol (SIP)
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The Rich Presence Information Data Format for the Session Initiation
Protocol (SIP) (RPIDS) 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. The information is
designed so that much of it can be derived automatically, e.g., from
calendar files or user activity. The capabilities information is
compatible with the caller preferences extensions to SIP, but does
not depend on these.
H. Schulzrinne (ed.) [Page 1]
Internet Draft RPIDS June 22, 2003
1 Introduction
The PIDF definition [1] describes a basic presence infornation data
format for exchanging presence information in CPIM-compliant systems.
It consists of a <presence> root element, zero or more <tuple>
elements carrying presence information, zero or more <note> elements
and zero or more extension elements from other name spaces. Each
tuple defines a basic status of either "open" or "closed".
This document provides additional status information for presentities
and defines a Rich Presence Information Data Format for Presence
Based on the Session Initiation Protocol (SIP) (RPIDS) to convey this
information.
This extension has three main goals:
1. Provide rich presence indication that is at least as
powerful as common commercial presence systems. Such
feature-parity simplifies transition to CPIM-compliant
systems, both in terms of user acceptance and protocol
conversion.
2. Maintain backwards-compatibility with PIDF, so that PIDF-
only watchers and gateways can continue to function
properly, naturally without access to the functionality
described here.
We make no assumptions how the information in the RPIDS 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 RPIDS information from other information sources,
such as calendars, the status of communication devices such as
telephones, typing activity and physical presence detectors as
commonly found in energy-management systems.
The information in a presence document can be generated by a single
entity or can be composed from information published by multiple
entities.
Many of the elements correspond to data commonly found in personal
calendars. Thus, we attempted to align some of the extensions with
the usage found in calendar formats such as iCal [12] and xCal [13],
as noted below.
Note that PIDF documents and this extension can be used in two
different contexts, namely by the presentity to publish its presence
status and by the presence server to notify some set of watchers. The
presence server MAY compose, translate or filter the published
H. Schulzrinne (ed.) [Page 2]
Internet Draft RPIDS June 22, 2003
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 [14], that govern the actual
communications behavior of the presentity.
The flow diagram below illustrates this process.
presentity
|
--> publish
|
--> PA (filter)
--> notification 1 to A, B, C
--> notification 2 to D, E
--> notification 3 to F
--> notification 4 to script gen.
2 RPIDS Features
Below, we summarize and motivate the major additional features that
RPIDS adds to PIDF.
The PIDF definition does not clearly describe what a <tuple>
represents. We add an <class> element (Section 6.6) that labels each
tuple as being a presentity, a group of presentities or a device.
While the PIDF definition describes which means of communications are
available for a presentity, it does not describe the activity that
the presentity is currently engaged in. The <category> (Section 6.4)
element adds this information.
To help the watcher gauge the appropriateness of different types of
communications, we indicate the type of place the user is currently
in, via the <placetype> element (Section 6.12).
PIDF defines a <timestamp> element indicating the date and time of
the status change of a tuple. RPIDS adds a validity period for status
values, <from> and <until>, as a hint how long the current status is
likely to be valid (Section 6.7 and Section 6.16).
The <activity> (Section 6.2) and <idlesince> (Section 6.10) provide
H. Schulzrinne (ed.) [Page 3]
Internet Draft RPIDS June 22, 2003
information on when the device has last been used.
Presence information can provide hints as to how interruptible the
presentity is, thus aiding in finding a time and manner of
communications that is mutually convenient for both watcher and
presentity. We express this as a SIP priority value, as this appears
to be more expressive than the simple "do-not-disturb" indication
found in some IM and presence systems.
An important sub-case is that a presentity is interruptible only
under unusual circumstances, after mediation by some, typically
human, authority such as a secretary or supervisor. We allow the
presentity to convey that certain contact addresses actually belong
to a different person, presumably one that can either interrupt the
presentity or otherwise assist. The <relationship> (Section 6.14)
element allows to indicate that a particular tuple refers to a
different principal or presentity.
The PIDF document format [1] defines a <contact> element which may
appear once inside every <tuple> element. The content of the
<contact> element encodes the CONTACT ADDRESS and CONTACT MEANS as
defined in [3]. The <contact> element is defined to be an URI. This
URI can be of any URI scheme. Some URI schemes uniquely identify the
application the tuple intends to describe (e.g., "im" URIs). However,
this is not be the case for all schemes. For example, a SIP URI can
represent different kinds of applications, including voice, video, or
messaging. If it is not known by other means, it can be hard for
applications processing the presence document containing only SIP URI
contact addresses to know what particular application the tuple
intends to describe. Also, watchers receiving presence information
would benefit for getting more descriptive information about what
particular communication means or applications are supported by the
presentity.
PIDF only defines tuples for one presentity. In many cases, it is
useful to allow presentities to refer to groups of other
presentities. For example, a presentity all@example.com might
consist of
marketing@example.com ,
engineering@example.com , finance@example.com
engineering@example.com might in turn have presentities
alice@example.com ,
bob@example.org (an intern), carol@example.com
We establish the convention that a tuple that has no contact address
H. Schulzrinne (ed.) [Page 4]
Internet Draft RPIDS June 22, 2003
indicates face-to-face communications. PIDF already notes that "there
might be tuples not related to any communications means".
We generally assume that the presence element describes a single
human being or a group of humans. However, this is not required. A
presentity can also be a "bot" or "avatar", for example.
Note that this document does not defined a new content type. Rather,
it inherits the content type from [1], namely application/cpim-
pidf+xml
3 Scope
This extension does not replace media negotiation mechanisms defined
for SIP (e.g. SDP [4]), therefore media negotiation (e.g., choice of
voice and video codecs) MUST be performed according to [5]. This
extension is only aimed to give the watchers hints about the
presentity's preferences, willingness and capabilities to communicate
before watchers initiate SIP-based communication with the presentity.
4 Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [3]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are
used in the same meaning as defined therein. The key words MUST,
MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL
in this document are to be interpreted as described in BCP XX, RFC
2119 [6].
5 The Meaning of "open" and "closed"
PIDF describes the basic status values of "open" or "closed" only as
"have meanings of general availability for other communications
means". We define "closed" in our context as meaning that
communication to the contact address will in all likelihood not
succeed, is undesired or will not reach the intended party. (For
example, a presentity may include a hotel phone number as a contact.
After check-out, the phone number will still ring, but reach the
chambermaid or the next guest. Thus, it would be declared "closed".)
For "pres" contacts, "closed" means that no presence status
information is available.
The interpretation of "closed" was chosen since there is no
other status value to indicate that a communications
address is not reachable. Omitting the <contact> element
does not work since it would confuse watchers that have not
H. Schulzrinne (ed.) [Page 5]
Internet Draft RPIDS June 22, 2003
previously seen an "open" status for the same contact
address.
6 RPIDS Elements
6.1 Introduction
Below, we describe the RPIDS elements in detail. <activity>,
<capabilities>, <category>, <class>, <from>, <idlesince> <label>,
<placetype>, <privacy>, <relationship>, <timed-status>, <until>
extend <status>. <members> extends the <presence> 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 URI for elements defined by this specification is a URN
[7], using the namespace identifier 'ietf' defined by [8] and
extended by [9]:
urn:ietf:params:xml:ns:sip-rpids
6.2 Activity Element
The <activity> element describes whether the owner of the device has
recently been actively using the device or not. It can take the
values "active" and "inactive". For example, for a PC, the value
"inactive" may be inferred from the lack of keyboard and mouse
activity. For a telephone, an ongoing call translates into "active".
The idle indication has been available in many "finger"
implementations for several decades.
The <activity> indication provides a qualitative indication
that reveals less information to watchers than the
<idlesince> element
6.3 Card
The <card> element provides a URI pointing to a business card, e.g.,
H. Schulzrinne (ed.) [Page 6]
Internet Draft RPIDS June 22, 2003
in LDIF or vCard format.
6.4 Category Element
The <category> indication describes what the presentity is currently
doing. This can be quite helpful to the watcher in judging how
appropriate a communication attempt is and which means of
communications is most likely to succeed and not annoy the
presentity. The activity indications correspond roughly to the
category field in calendar entries, such as Section 4.8.1.2 of RFC
2445 [9].
Use of an enumerated, but extensible, set of activity
categories simplifies automated generation and processing
of presence information. The categories can be readily
selected from a drop-down list by the user or translated
from the corresponding category field in calendars.
Recipients of this information can render at least a subset
as icons, automatically translate them into different
languages or convert them to sound "jingles" and speech, or
use them to generate call processing rules.
A category indication consists of one or more values drawn from the
list below, any other token string or IANA-registered values (Section
10). Communities of interest such as a profession or an organization
may define additional activity labels for their internal use.
On-the-phone: The presentity is talking on the telephone. This
category is included since it can often be derived
automatically.
Away: The presentity is physically away from the device
location. This category 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 category can
often be generated automatically from a calendar.
Meeting: This category can often be generated automatically from
a calendar.
H. Schulzrinne (ed.) [Page 7]
Internet Draft RPIDS June 22, 2003
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.
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 category can often be generated automatically
from a calendar.
Sleeping: This category can often be generated automatically
from a calendar or local time information.
Busy: User is busy, without further details. This category would
typically be indicated manually.
Permant-absence: Presentity will not return for the foreseeable
future, e.g., because it is no longer working for the
company.
6.5 Class
The 'class' attribute describes the class of the tuple. Multiple
tuples can have the same class name within a presence document. The
naming of classes is left to the presentity.
The class description is similar in spirit to the 'class'
attribute of XML elements, used to support Cascading Style
Sheets.
6.6 Contact-Type Element
The <contact-type> element describes the type of the tuple. A tuple
can represent a communication facility ("device"), a single
presentity ("individual") or a group of presentities ("group").
Additional classes can be registered with IANA.
URI schema are insufficient to distinguish the different
types of tuples. For example, a SIP URI can designate a
single device, a presentity, or a group of presentities.
6.7 From Element
H. Schulzrinne (ed.) [Page 8]
Internet Draft RPIDS June 22, 2003
The <from> element indicates how long the current status has been
valid, expressed as an absolute time.
6.8 Icon
The <icon> element provides a URI pointing to an image (icon)
representing the tuple. The watcher MAY use this information to
represent the tuple.
6.9 Info
The <info> element provides a URI pointing to general information
about the tuple, e.g., a web page.
6.10 Idlesince Element
The <idlesince> records the time and date the communication device
was last used. This provides an indication as to how likely a user is
to answer the device. Depending on the device, this element can be
used together with <activity>, either "active" or "inactive". For
example, a keyboard activity detector may still declare a PC that has
not seen keyboard activity in two minutes as "active". For session-
based devices such as telephones and video conferencing systems,
<idlesince> would only be used with an activity value of "inactive".
6.11 Label Element
The <label> attribute is used by the presentity to label tuples. The
value is chosen arbitrarily and MUST NOT be modified by a composing
server or PA. There is no requirement that all tuples within a
presence document differ in their label or have a label at all.
Typically, the label remains the same across subscriptions and across
watchers.
The <label> makes it easier for policies to operate on
presence documents. The 'id' <tuple> attribute is not
guaranteed to remain constant across subscriptions. The
PIDF specification does not prevent a PA from modifying the
'id' attribute. An element, rather than an attribute, was
chosen since it appears less likely to cause
interoperability problems with plain PIDF parsers.
6.12 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
H. Schulzrinne (ed.) [Page 9]
Internet Draft RPIDS June 22, 2003
of values below:
home: The presentity is in a private or residential setting, not
necessarily the personal residence of the presentity, e.g.,
including hotel or a friend's home.
office: The presentity is in a business setting, such as an
office.
public: The presentity is in a public area such as a shopping
mall, street, park, public building, train station, airport
or in public conveyance such as a bus, train, plane or
ship.
This list can be augmented by free-text values or additional IANA-
registered values (Section 10).
6.13 Privacy Element
The <privacy> element indicates whether third parties may be able to
hear or view parts of the communication.
public: Others may be able to see or hear the communications.
private: Inappropriate individuals are not likely to see or hear
the communications.
quiet: The presentity is in a place such as a library,
restaurant, place-of-worship, or theater that discourages
noise, conversation and other distractions.
This indication is not limited to voice communications. For example,
a presentity might label her privacy as "quiet" when giving a talk,
since it would be inappropriate if an instant message popped up on
the laptop screen that is being projected for the audience.
6.14 Relationship Element
The <relationship> element designates the type of relationship an
alternate contact has with the presentity. This element is provided
only if the tuple refers to somebody other than the presentity.
Relationship values include "family", "associate" (e.g., for a
colleague), "assistant", "supervisor". Other free-text values and
additional IANA-registered values (Section 10) can be used as well.
The <contact> element can contain either a communication URI such as
"im", "sip"/"sips", "h323", "tel" or "mailto", or a presence URI,
such as "pres" or "sip".
H. Schulzrinne (ed.) [Page 10]
Internet Draft RPIDS June 22, 2003
6.15 Timed Status Element
The <timed-status> element describes status information that is
either no longer valid or covers some future timeperiod.
Timed status cannot be expressed with <tuples> elements
where the period between <status> since PIDF parsers would
not be able to distinguish current from future or past
information. It is occasionally useful to represent past
information since it may be the only known presence
information; it may give watchers an indication of the
current status. For example, indicating that the presentity
was at a meeting that ended an hour ago indicates that the
presentity is likely in transit at the current time.
6.16 Until Element
The <until> element indicates how long the current basic status (open
or closed) is likely to be valid, expressed as an absolute time.
This indication allows the watcher to make better decisions. For
example, if a presentity indicates that it is likely to be
unreachable for an extended period of time, the watcher may decide to
request assistance from somebody else, rather than waiting for the
presentity to return.
Often, the duration of the status information is not known precisely.
Thus, it is helpful to indicate the precision, here expressed in
seconds. For example, an absence of "a few hours" can easily be
expressed as a time some hours into the future, with a precision of
7200 seconds.
An absolute time was chosen to simplify integration with
calendaring applications. This combination appears to be
sematically cleaner than enumerating various measurement
units such as "months", "weeks", "days" or "hours".
Both the <from> and <until> information might be derived from
calendar information, reflecting the start and end time of an
activity. (Examples include the Date Time Start and Date Time End
properties of RFC 2445. For simplicity, RPIDS only supports single
events, without repetition.)
Any statements such as anticipated validity are not historical facts
and are forward-looking statements that involve risks and
uncertainties; actual results may differ from the forward-looking
H. Schulzrinne (ed.) [Page 11]
Internet Draft RPIDS June 22, 2003
statements.
7 Examples
7.1 Presentity with Capabilities
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
xmlns:cap="urn:ietf:params:xml:ns:sip-prescaps"
xmlns:ep="urn:ietf:params:xml:ns:sip-rpids"
entity="pres:someone@example.com">
<note>I'm in a boring meeting</note>
<tuple id="7c8dqui">
<status>
<basic>open</basic>
<contact>sip:secretary@example.com</contact>
</status>
<ep:relationship>assistant</ep:relationship>
<note>My secretary</note>
</tuple>
<tuple id="18x765">
<status>
<basic>open</basic>
<ep:category>meeting</ep:category>
<ep:placetype>office</ep:placetype>
<ep:privacy>quiet</ep:privacy>
<ep:activity>inactive</ep:activity>
<ep:idlesince>2003-01-27T10:43:00Z</ep:idlesince>
<ep:until>2003-01-27T17:30:00Z</ep:unitl>
</status>
<contact priority="0.8">sip:someone@example.com</contact>
<timestamp>2001-10-27T16:49:29Z</timestamp>
<ep:timed-status>
<basic>closed</basic>
<ep:from>2003-01-27T17:30:00Z</ep:from>
<ep:until>2003-01-27T19:30:00Z</ep:until>
</ep:timed-status>
</tuple>
<tuple id="35bs9r" class="cellphone">
<status>
<basic>open</basic>
</status>
H. Schulzrinne (ed.) [Page 12]
Internet Draft RPIDS June 22, 2003
<contact priority="0.8">im:someone@mobilecarrier.net</contact>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="8eg92n" class="email">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
</presence>
8 XML Schema Definitions
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:sip-rpids"
xmlns:tns="urn:ietf:params:xml:ns:sip-rpids"
xmlns:pidf="urn:ietf:params:xml:ns:cpim-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"/>
<xsd:attribute name="class" type="xsd:token"/>
<xs:element name="contact-type" type="tns:contact-type"/>
<xs:element name="placetype" type="xs:token"/>
<xs:element name="privacy" type="tns:privacy"/>
<xs:element name="category" type="xs:token"/>
<xs:element name="relationship" type="xs:token"/>
<xs:element name="from" type="tns:fromuntil">
<xs:element name="until" type="tns:fromuntil">
<xs:element name="idlesince" type="xs:dateTime">
<xs:element name="icon" type="xs:anyURI">
<xs:element name="card" type="xs:anyURI">
<xs:element name="info" type="xs:anyURI">
<xs:element name="timed-status" type="tns:timed-status">
<xs:simpleType name="contact-type">
<xs:restriction base="xs:string">
<xs:enumeration value="individual"/>
H. Schulzrinne (ed.) [Page 13]
Internet Draft RPIDS June 22, 2003
<xs:enumeration value="device"/>
<xs:enumeration value="group"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="privacy">
<xs:restriction base="xs:string">
<xs:enumeration value="private"/>
<xs:enumeration value="public"/>
<xs:enumeration value="quiet"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="fromuntil">
<xs:simpleContent>
<xs:extension base="xs:dateTime">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="timed-status">
<xs:sequence>
<xs:element name="basic" type="pidf:basic" minOccurs="0"/>
<xs:element name="from" type="tns:fromuntil">
<xs:element name="until" type="tns:fromuntil">
<xs:element name="note" type="pidf:note">
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="members">
<xs:sequence>
<xs:any namespace="pidf" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
9 Security Considerations
The security considerations in [1] apply, as well as [11]. 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
H. Schulzrinne (ed.) [Page 14]
Internet Draft RPIDS June 22, 2003
is generated automatically from other sources, such as calendars or
sensors.
Like any information retrieved by reference, the information provided
in the <card>, <icon> and <info> elements may refer to data types
that expose the watcher to security risks.
10 IANA Considerations
This document calls for IANA to:
o register two new XML namespace URNs per [9];
o establish registry for categories (Section 6.4), place types
(Section 6.12), and relationships (Section 6.14).
Note that this document does not need a new content type. It inherits
the content type from [1], namely application/cpim-pidf+xml
10.1 URN Sub-Namespace Registration for
URI: urn:ietf:params:xml:ns:sip-rpids
Description: This is the XML namespace for XML elements defined
by RFCXXXX to describe a rich presence information
extension for the CPIM-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>RPIDS -- Rich Presence Information Data Format
for Presence Based on the Session
Initiation Protocol (SIP)</title>
H. Schulzrinne (ed.) [Page 15]
Internet Draft RPIDS June 22, 2003
</head>
<body>
<h1>Namespace for SIMPLE rich presence extension</h1>
<h2>application/cpim-pidf+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
10.2 URN Sub-Namespace Registration for
URI: urn:ietf:params:xml:ns:sip-prescaps
Description: This is the XML namespace for XML elements defined
by RFCXXXX to describe a capabilities presence information
extension for the CPIM-PIDF presence document format in the
application/cpim-pidf+xml
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>SIMPLE PIDF presence capabilities extension</title>
</head>
<body>
<h1>Namespace for SIMPLE presence capabilities extension</h1>
<h2>application/cpim-pidf+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
10.3 Place Type, Device Type, Categories, Relationships
H. Schulzrinne (ed.) [Page 16]
Internet Draft RPIDS June 22, 2003
This document creates new IANA registries for categories, device
types, place types and relationships. All are XML tokens. Registered
tokens must be documented at the time of registration, as most
descriptions are expected to be brief.
The SIMPLE working group, or, if no longer available, the SIP working
group should be consulted prior to registration.
11 Acknowledgements
The document reflects the discussion on the SIMPLE mailing list, with
contributions from many individuals. Markus Isomaki, Hisham
Khartabil, Jon Peterson and Brian Rosen provided detailed comments
and suggestions. The notion of external references in the <card>,
<icon> and <info> elements is an evolution of the BINPIDF proposal by
Khartabil et al.
12 References
13 Normative References
[1] H. Sugano, S. Fujimoto, et al., "Common presence and instant
messaging (cpim)presence information data format," internet draft,
Internet Engineering Task Force, Jan. 2003. Work in progress.
[2] H. Schulzrinne and J. Rosenberg, "Session initiation protocol
(SIP) caller preferences and callee capabilities," internet draft,
Internet Engineering Task Force, Nov. 2002. Work in progress.
[3] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
instant messaging," RFC 2778, Internet Engineering Task Force, Feb.
2000.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998.
[5] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
session description protocol (SDP)," RFC 3264, Internet Engineering
Task Force, June 2002.
[6] S. Bradner, "Key words for use in rfcs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[7] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task
Force, May 1997.
[8] R. Moats, "A URN namespace for IETF documents," RFC 2648,
Internet Engineering Task Force, Aug. 1999.
H. Schulzrinne (ed.) [Page 17]
Internet Draft RPIDS June 22, 2003
[9] M. Mealling, "The IETF XML registry," internet draft, Internet
Engineering Task Force, July 2002. Work in progress.
[10] K. Holtman, A. Mutz, and T. Hardie, "Media feature tag
registration procedure," RFC 2506, Internet Engineering Task Force,
Mar. 1999.
[11] J. Rosenberg, "A presence event package for the session
initiation protocol (SIP)," internet draft, Internet Engineering Task
Force, Jan. 2003. Work in progress.
14 Informative References
[12] F. Dawson and D. Stenerson, "Internet calendaring and scheduling
core object specification (icalendar)," RFC 2445, Internet
Engineering Task Force, Nov. 1998.
[13] F. D. Jr., S. M. Reddy, D. Royer, and E. Plamondon, "icalendar
DTD document (xcal)," internet draft, Internet Engineering Task
Force, July 2002. Work in progress.
[14] J. Lennox and H. Schulzrinne, "CPL: a language for user control
of Internet telephony services," internet draft, Internet Engineering
Task Force, Nov. 2001. Work in progress.
[15] A. B. Roach, J. Rosenberg, and B. Campbell, "A session
initiation protocol (SIP) event notification extension for
collections," internet draft, Internet Engineering Task Force, Feb.
2003. Work in progress.
15 Authors' and Editor's Addresses
The addresses of authors and editors are listed below in alphabetical
order.
Vijay Gurbani
Lucent
2000 Naperville Rd., Room 6G-440
Naperville, IL 60566-7033
USA
Email: vkg@lucent.com
Krisztian Kiss
Nokia Research Center
P.O BOX 100
33721 Tampere
Finland
EMail: krisztian.kiss@nokia.com
H. Schulzrinne (ed.) [Page 18]
Internet Draft RPIDS June 22, 2003
Paul Kyzivat
Cisco Systems
Mail Stop LWL3/12/2
900 Chelmsford St.
Lowell, MA 01851
USA
Email: pkzivat@cisco.com
Mikko Lonnfors
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
Email: mikko.lonnfors@nokia.com
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
USA
Email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: schulzrinne@cs.columbia.edu
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
H. Schulzrinne (ed.) [Page 19]
Internet Draft RPIDS June 22, 2003
this standard. Please address the information to the IETF Executive
Director.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
H. Schulzrinne (ed.) [Page 20]
Table of Contents
1 Introduction ........................................ 2
2 RPIDS Features ...................................... 3
3 Scope ............................................... 5
4 Terminology and Conventions ......................... 5
5 The Meaning of "open" and "closed" .................. 5
6 RPIDS Elements ...................................... 6
6.1 Introduction ........................................ 6
6.2 Activity Element .................................... 6
6.3 Card ................................................ 6
6.4 Category Element .................................... 7
6.5 Class ............................................... 8
6.6 Contact-Type Element ................................ 8
6.7 From Element ........................................ 8
6.8 Icon ................................................ 9
6.9 Info ................................................ 9
6.10 Idlesince Element ................................... 9
6.11 Label Element ....................................... 9
6.12 Type of Place Element ............................... 9
6.13 Privacy Element ..................................... 10
6.14 Relationship Element ................................ 10
6.15 Timed Status Element ................................ 11
6.16 Until Element ....................................... 11
7 Examples ............................................ 12
7.1 Presentity with Capabilities ........................ 12
8 XML Schema Definitions .............................. 13
9 Security Considerations ............................. 14
10 IANA Considerations ................................. 15
10.1 URN Sub-Namespace Registration for .................. 15
10.2 URN Sub-Namespace Registration for .................. 16
10.3 Place Type, Device Type, Categories, Relationships
................................................................ 16
11 Acknowledgements .................................... 17
12 References .......................................... 17
13 Normative References ................................ 17
14 Informative References .............................. 18
15 Authors' and Editor's Addresses ..................... 18
H. Schulzrinne (ed.) [Page 1]
| PAFTECH AB 2003-2026 | 2026-04-22 18:43:44 |