draft-ietf-simple-rpids-00.txt   draft-ietf-simple-rpids-01.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft H. Schulzrinne (ed.) Internet Draft H. Schulzrinne (ed.)
Columbia U. Columbia U.
draft-ietf-simple-rpids-00.txt draft-ietf-simple-rpids-01.txt
June 22, 2003 June 29, 2003
Expires: December 2003 Expires: December 2003
RPIDS -- Rich Presence Information Data Format for Presence Based RPIDS -- Rich Presence Information Data Format for Presence Based
on the Session Initiation Protocol (SIP) on the Session Initiation Protocol (SIP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Rich Presence Information Data Format for the Session Initiation The Rich Presence Information Data Format for the Session Initiation
Protocol (SIP) (RPIDS) adds elements to the Presence Information Data Protocol (SIP) (RPIDS) adds elements to the Presence Information Data
Format (PIDF) that provide additional information about the Format (PIDF) that provide additional information about the
presentity and its contacts. This information can be translated into presentity and its contacts. This information can be translated into
call routing behavior or be delivered to watchers. The information is call routing behavior or be delivered to watchers. The information is
designed so that much of it can be derived automatically, e.g., from designed so that much of it can be derived automatically, e.g., from
calendar files or user activity. The capabilities information is calendar files or user activity.
compatible with the caller preferences extensions to SIP, but does
not depend on these.
1 Introduction 1 Introduction
The PIDF definition [1] describes a basic presence infornation data The PIDF definition [1] describes a basic presence information data
format for exchanging presence information in CPIM-compliant systems. format for exchanging presence information in CPIM-compliant systems.
It consists of a <presence> root element, zero or more <tuple> It consists of a <presence> root element, zero or more <tuple>
elements carrying presence information, zero or more <note> elements elements carrying presence information, zero or more <note> elements
and zero or more extension elements from other name spaces. Each and zero or more extension elements from other name spaces. Each
tuple defines a basic status of either "open" or "closed". tuple defines a basic status of either "open" or "closed".
This document provides additional status information for presentities This document provides additional status information for presentities
and defines a Rich Presence Information Data Format for Presence and defines a Rich Presence Information Data Format for Presence
Based on the Session Initiation Protocol (SIP) (RPIDS) to convey this Based on the Session Initiation Protocol (SIP) (RPIDS) to convey this
information. information.
skipping to change at page 1, line 121 skipping to change at page 1, line 119
--> notification 2 to D, E --> notification 2 to D, E
--> notification 3 to F --> notification 3 to F
--> notification 4 to script gen. --> notification 4 to script gen.
2 RPIDS Features 2 RPIDS Features
Below, we summarize and motivate the major additional features that Below, we summarize and motivate the major additional features that
RPIDS adds to PIDF. RPIDS adds to PIDF.
The PIDF definition does not clearly describe what a <tuple> The PIDF definition does not clearly describe what a <tuple>
represents. We add an <class> element (Section 6.6) that labels each represents. We add an <class> attribute (Section 6.4) that allows a
tuple as being a presentity, a group of presentities or a device. presentity to label tuples in ways that make sense to the presentity,
e.g., to group similar tuples by name.
While the PIDF definition describes which means of communications are While the PIDF definition describes which means of communications are
available for a presentity, it does not describe the activity that available for a presentity, it does not describe the activity that
the presentity is currently engaged in. The <category> (Section 6.4) the presentity is currently engaged in. The <activity> (Section 6.2)
element adds this information. element adds this information.
The <idle> (Section 6.7) element indicates when the device was last
used or simply whether it has been idle.
To help the watcher gauge the appropriateness of different types of To help the watcher gauge the appropriateness of different types of
communications, we indicate the type of place the user is currently communications, we indicate the type of place the user is currently
in, via the <placetype> element (Section 6.12). in, via the <placetype> element (Section 6.9) and hint at the privacy
available via <privacy>.
PIDF defines a <timestamp> element indicating the date and time of PIDF defines a <timestamp> element indicating the date and time of
the status change of a tuple. RPIDS adds a validity period for status 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 values, <from> and <until>, as a hint how long the current status is
likely to be valid (Section 6.7 and Section 6.16). likely to be valid (Section 6.5 and Section 6.13).
The <activity> (Section 6.2) and <idlesince> (Section 6.10) provide
information on when the device has last been used.
Presence information can provide hints as to how interruptible the Information about a tuple can be conveyed using the <card>, <info>
presentity is, thus aiding in finding a time and manner of and <icon> elements.
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 An important sub-case is that a presentity is interruptible only
under unusual circumstances, after mediation by some, typically under unusual circumstances, after mediation by some, typically
human, authority such as a secretary or supervisor. We allow the human, authority such as a secretary or supervisor. We allow the
presentity to convey that certain contact addresses actually belong presentity to convey that certain contact addresses actually belong
to a different person, presumably one that can either interrupt the to a different person, presumably one that can either interrupt the
presentity or otherwise assist. The <relationship> (Section 6.14) presentity or otherwise assist. The <relationship> (Section 6.11)
element allows to indicate that a particular tuple refers to a element allows to indicate that a particular tuple refers to a
different principal or presentity. different principal or presentity.
The PIDF document format [1] defines a <contact> element which may The PIDF document format [1] defines a <contact> element which may
appear once inside every <tuple> element. The content of the appear once inside every <tuple> element. The content of the
<contact> element encodes the CONTACT ADDRESS and CONTACT MEANS as <contact> element encodes the CONTACT ADDRESS and CONTACT MEANS as
defined in [3]. The <contact> element is defined to be an URI. This 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 URI can be of any URI scheme. Some URI schemes uniquely identify the
application the tuple intends to describe (e.g., "im" URIs). However, 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 this is not be the case for all schemes. For example, a SIP URI can
represent different kinds of applications, including voice, video, or represent different kinds of applications, including voice, video, or
messaging. If it is not known by other means, it can be hard for messaging. If it is not known by other means, it can be hard for
applications processing the presence document containing only SIP URI applications processing the presence document containing only SIP URI
contact addresses to know what particular application the tuple contact addresses to know what particular application the tuple
intends to describe. Also, watchers receiving presence information intends to describe. Also, watchers receiving presence information
would benefit for getting more descriptive information about what would benefit for getting more descriptive information about what
particular communication means or applications are supported by the particular communication means or applications are supported by the
presentity. 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
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 We generally assume that the presence element describes a single
human being or a group of humans. However, this is not required. A human being or a group of humans. However, this is not required. A
presentity can also be a "bot" or "avatar", for example. presentity can also be a "bot" or "avatar", for example.
Note that this document does not defined a new content type. Rather, Note that this document does not defined a new content type. Rather,
it inherits the content type from [1], namely application/cpim- it inherits the content type from [1], namely application/cpim-
pidf+xml pidf+xml
3 Scope 3 Scope
skipping to change at page 1, line 241 skipping to change at page 1, line 220
other status value to indicate that a communications other status value to indicate that a communications
address is not reachable. Omitting the <contact> element address is not reachable. Omitting the <contact> element
does not work since it would confuse watchers that have not does not work since it would confuse watchers that have not
previously seen an "open" status for the same contact previously seen an "open" status for the same contact
address. address.
6 RPIDS Elements 6 RPIDS Elements
6.1 Introduction 6.1 Introduction
Below, we describe the RPIDS elements in detail. <activity>, Below, we describe the RPIDS elements in detail. <activity>, <card>
<capabilities>, <category>, <class>, <from>, <idlesince> <label>, <category>, <class>, <from>, <icon> <idle> <info> <label>,
<placetype>, <privacy>, <relationship>, <timed-status>, <until> <placetype>, <privacy>, <relationship>, <timed-status>, <until>
extend <status>. <members> extends the <presence> element. extend <status>.
In general, it is highly unlikely that a presentity will publish or In general, it is highly unlikely that a presentity will publish or
announce all of these elements at the same time. Rather, these announce all of these elements at the same time. Rather, these
elements were chosen to give the presentity maximum flexibility in elements were chosen to give the presentity maximum flexibility in
deriving this information from existing sources, such as calendaring deriving this information from existing sources, such as calendaring
tools, device activity sensors or location trackers, as well as to tools, device activity sensors or location trackers, as well as to
manually configure this information. manually configure this information.
The namespace URI for elements defined by this specification is a URN The namespace URI for elements defined by this specification is a URN
[7], using the namespace identifier 'ietf' defined by [8] and [7], using the namespace identifier 'ietf' defined by [8] and
extended by [9]: extended by [9]:
urn:ietf:params:xml:ns:sip-rpids urn:ietf:params:xml:ns:sip-rpids
6.2 Activity Element 6.2 Activity Element
The <activity> element describes whether the owner of the device has The <activity> indication describes what the presentity is currently
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.,
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 doing. This can be quite helpful to the watcher in judging how
appropriate a communication attempt is and which means of appropriate a communication attempt is and which means of
communications is most likely to succeed and not annoy the communications is most likely to succeed and not annoy the
presentity. The activity indications correspond roughly to the presentity. The activity indications correspond roughly to the
category field in calendar entries, such as Section 4.8.1.2 of RFC category field in calendar entries, such as Section 4.8.1.2 of RFC
2445 [9]. 2445 [9].
Use of an enumerated, but extensible, set of activity Use of an enumerated, but extensible, set of activity
categories simplifies automated generation and processing categories simplifies automated generation and processing
of presence information. The categories can be readily of presence information. The categories can be readily
selected from a drop-down list by the user or translated selected from a drop-down list by the user or translated
from the corresponding category field in calendars. from the corresponding activity field in calendars.
Recipients of this information can render at least a subset Recipients of this information can render at least a subset
as icons, automatically translate them into different as icons, automatically translate them into different
languages or convert them to sound "jingles" and speech, or languages or convert them to sound "jingles" and speech, or
use them to generate call processing rules. use them to generate call processing rules.
A category indication consists of one or more values drawn from the An activity indication consists of one or more values drawn from the
list below, any other token string or IANA-registered values (Section list below, any other token string or IANA-registered values (Section
10). Communities of interest such as a profession or an organization 10). Communities of interest such as a profession or an organization
may define additional activity labels for their internal use. may define additional activity labels for their internal use.
On-the-phone: The presentity is talking on the telephone. This On-the-phone: The presentity is talking on the telephone. This
category is included since it can often be derived activity is included since it can often be derived
automatically. automatically.
Away: The presentity is physically away from the device Away: The presentity is physically away from the device
location. This category was included since it can often be location. This activity was included since it can often be
derived automatically from security systems, energy derived automatically from security systems, energy
management systems or entry badge systems. management systems or entry badge systems.
Appointment: The presentity has a calendar appointment. Appointment: The presentity has a calendar appointment.
Holiday: This is a scheduled national or local holiday. This Holiday: This is a scheduled national or local holiday. This
information can typically be derived automatically from information can typically be derived automatically from
calendars. calendars.
Meal: The presentity is scheduled for a meal. This category can Meal: The presentity is scheduled for a meal. This activity
often be generated automatically from a calendar. category can often be generated automatically from a
calendar.
Meeting: This category can often be generated automatically from Meeting: This activity category can often be generated
a calendar. automatically from a calendar.
Steering: The presentity is controlling a vehicle, ship or Steering: The presentity is controlling a vehicle, ship or
plane. plane.
In-transit: The presentity is riding in a vehicle, such as a In-transit: The presentity is riding in a vehicle, such as a
car, but not steering. car, but not steering.
Travel: The presentity is on a business or personal trip, but Travel: The presentity is on a business or personal trip, but
not necessarily in-transit. This category can often be not necessarily in-transit. This category can often be
generated automatically from a calendar. generated automatically from a calendar.
Vacation: This category can often be generated automatically Vacation: This activity category can often be generated
from a calendar. automatically from a calendar.
Sleeping: This category can often be generated automatically Sleeping: This activity category can often be generated
from a calendar or local time information. automatically from a calendar or local time information.
Busy: User is busy, without further details. This category would Busy: User is busy, without further details. This activity
typically be indicated manually. category would typically be indicated manually.
Permant-absence: Presentity will not return for the foreseeable Permant-absence: Presentity will not return for the foreseeable
future, e.g., because it is no longer working for the future, e.g., because it is no longer working for the
company. company.
6.5 Class 6.3 Card
The <card> element provides a URI pointing to a business card, e.g.,
in LDIF or vCard format.
6.4 Class
The 'class' attribute describes the class of the tuple. Multiple The 'class' attribute describes the class of the tuple. Multiple
tuples can have the same class name within a presence document. The tuples can have the same class name within a presence document. The
naming of classes is left to the presentity. naming of classes is left to the presentity. The presentity can use
this information to group similar tuples or to convey information
that the presence agent can use for filtering.
The class description is similar in spirit to the 'class' The class description is similar in spirit to the 'class'
attribute of XML elements, used to support Cascading Style attribute of XML elements, used to support Cascading Style
Sheets. Sheets.
6.6 Contact-Type Element 6.5 From 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
The <from> element indicates how long the current status has been The <from> element indicates how long the current status has been
valid, expressed as an absolute time. valid, expressed as an absolute time.
6.8 Icon 6.6 Icon
The <icon> element provides a URI pointing to an image (icon) The <icon> element provides a URI pointing to an image (icon)
representing the tuple. The watcher MAY use this information to representing the tuple. The watcher MAY use this information to
represent the tuple. represent the tuple.
6.9 Info 6.7 Idle Element
The <info> element provides a URI pointing to general information The <idle> records the absolute time and date the communication
about the tuple, e.g., a web page. 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.
6.10 Idlesince Element 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:
The <idlesince> records the time and date the communication device <idle/>
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 <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.
The <label> attribute is used by the presentity to label tuples. The 6.8 Info
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 The <info> element provides a URI pointing to general information
presence documents. The 'id' <tuple> attribute is not about the tuple, e.g., a web page.
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 6.9 Type of Place Element
The <placetype> element describes the type of place the presentity is The <placetype> element describes the type of place the presentity is
currently at. This offers the watcher an indication what kind of currently at. This offers the watcher an indication what kind of
communication is likely to be appropriate. We define an initial set communication is likely to be appropriate. We define an initial set
of values below: of values below:
home: The presentity is in a private or residential setting, not home: The presentity is in a private or residential setting, not
necessarily the personal residence of the presentity, e.g., necessarily the personal residence of the presentity, e.g.,
including hotel or a friend's home. including hotel or a friend's home.
skipping to change at page 1, line 434 skipping to change at page 1, line 382
office. office.
public: The presentity is in a public area such as a shopping public: The presentity is in a public area such as a shopping
mall, street, park, public building, train station, airport mall, street, park, public building, train station, airport
or in public conveyance such as a bus, train, plane or or in public conveyance such as a bus, train, plane or
ship. ship.
This list can be augmented by free-text values or additional IANA- This list can be augmented by free-text values or additional IANA-
registered values (Section 10). registered values (Section 10).
6.13 Privacy Element The placetype element can be used by logic executing on the
watcher or by a composer to filter, sort and label tuples.
For example, a composer may have rules that limit the
publication of "home" tuples to a subset of the watchers.
6.10 Privacy Element
The <privacy> element indicates whether third parties may be able to The <privacy> element indicates whether third parties may be able to
hear or view parts of the communication. hear or view parts of the communication.
public: Others may be able to see or hear the communications. public: Others may be able to see or hear the communications.
private: Inappropriate individuals are not likely to see or hear private: Inappropriate individuals are not likely to see or hear
the communications. the communications.
quiet: The presentity is in a place such as a library, quiet: The presentity is in a place such as a library,
restaurant, place-of-worship, or theater that discourages restaurant, place-of-worship, or theater that discourages
noise, conversation and other distractions. noise, conversation and other distractions.
This indication is not limited to voice communications. For example, This indication is not limited to voice communications. For example,
a presentity might label her privacy as "quiet" when giving a talk, a presentity might label her privacy as "quiet" when giving a talk,
since it would be inappropriate if an instant message popped up on since it would be inappropriate if an instant message popped up on
the laptop screen that is being projected for the audience. the laptop screen that is being projected for the audience.
6.14 Relationship Element The placetype element can be used by logic executing on the
watcher or by a composer to filter, sort and label tuples.
For example, a composer may have rules that limit the
publication of tuples labeled as "quiet" to a select subset
of the watchers.
6.11 Relationship Element
The <relationship> element designates the type of relationship an The <relationship> element designates the type of relationship an
alternate contact has with the presentity. This element is provided alternate contact has with the presentity. This element is provided
only if the tuple refers to somebody other than the presentity. only if the tuple refers to somebody other than the presentity.
Relationship values include "family", "associate" (e.g., for a Relationship values include "family", "associate" (e.g., for a
colleague), "assistant", "supervisor". Other free-text values and colleague), "assistant", "supervisor". Other free-text values and
additional IANA-registered values (Section 10) can be used as well. additional IANA-registered values (Section 10) can be used as well.
The <contact> element can contain either a communication URI such as The <contact> element for tuples labeled with a relationship can
"im", "sip"/"sips", "h323", "tel" or "mailto", or a presence URI, contain either a communication URI such as "im", "sip"/"sips",
such as "pres" or "sip". "h323", "tel" or "mailto", or a presence URI, such as "pres" or
"sip".
6.15 Timed Status Element 6.12 Timed Status Element
The <timed-status> element describes status information that is The <timed-status> element describes status information that is
either no longer valid or covers some future timeperiod. either no longer valid or covers some future timeperiod.
Timed status cannot be expressed with <tuples> elements Timed status cannot be expressed with <tuples> elements
where the period between <status> since PIDF parsers would where the period between <status> since PIDF parsers would
not be able to distinguish current from future or past not be able to distinguish current from future or past
information. It is occasionally useful to represent past information. It is occasionally useful to represent past
information since it may be the only known presence information since it may be the only known presence
information; it may give watchers an indication of the information; it may give watchers an indication of the
current status. For example, indicating that the presentity current status. For example, indicating that the presentity
was at a meeting that ended an hour ago indicates that the was at a meeting that ended an hour ago indicates that the
presentity is likely in transit at the current time. presentity is likely in transit at the current time.
6.16 Until Element 6.13 Until Element
The <until> element indicates how long the current basic status (open The <until> element indicates how long the current basic status (open
or closed) is likely to be valid, expressed as an absolute time. or closed) is likely to be valid, expressed as an absolute time.
This indication allows the watcher to make better decisions. For This indication allows the watcher to make better decisions. For
example, if a presentity indicates that it is likely to be example, if a presentity indicates that it is likely to be
unreachable for an extended period of time, the watcher may decide to unreachable for an extended period of time, the watcher may decide to
request assistance from somebody else, rather than waiting for the request assistance from somebody else, rather than waiting for the
presentity to return. presentity to return.
skipping to change at page 1, line 530 skipping to change at page 1, line 491
xmlns:cap="urn:ietf:params:xml:ns:sip-prescaps" xmlns:cap="urn:ietf:params:xml:ns:sip-prescaps"
xmlns:ep="urn:ietf:params:xml:ns:sip-rpids" xmlns:ep="urn:ietf:params:xml:ns:sip-rpids"
entity="pres:someone@example.com"> entity="pres:someone@example.com">
<note>I'm in a boring meeting</note> <note>I'm in a boring meeting</note>
<tuple id="7c8dqui"> <tuple id="7c8dqui">
<status> <status>
<basic>open</basic> <basic>open</basic>
<contact>sip:secretary@example.com</contact> <contact>sip:secretary@example.com</contact>
</status>
<ep:relationship>assistant</ep:relationship> <ep:relationship>assistant</ep:relationship>
</status>
<note>My secretary</note> <note>My secretary</note>
</tuple> </tuple>
<tuple id="18x765"> <tuple id="18x765">
<status> <status>
<basic>open</basic> <basic>open</basic>
<ep:category>meeting</ep:category> <ep:category>meeting</ep:category>
<ep:placetype>office</ep:placetype> <ep:placetype>office</ep:placetype>
<ep:privacy>quiet</ep:privacy> <ep:privacy>quiet</ep:privacy>
<ep:activity>inactive</ep:activity> <ep:activity>inactive</ep:activity>
<ep:idlesince>2003-01-27T10:43:00Z</ep:idlesince> <ep:idle>2003-01-27T10:43:00Z</ep:idle>
<ep:until>2003-01-27T17:30:00Z</ep:unitl> <ep:until>2003-01-27T17:30:00Z</ep:unitl>
</status> </status>
<contact priority="0.8">sip:someone@example.com</contact> <contact priority="0.8">sip:someone@example.com</contact>
<timestamp>2001-10-27T16:49:29Z</timestamp> <timestamp>2001-10-27T16:49:29Z</timestamp>
<ep:timed-status> <ep:timed-status>
<basic>closed</basic> <basic>closed</basic>
<ep:from>2003-01-27T17:30:00Z</ep:from> <ep:from>2003-01-27T17:30:00Z</ep:from>
<ep:until>2003-01-27T19:30:00Z</ep:until> <ep:until>2003-01-27T19:30:00Z</ep:until>
</ep:timed-status> </ep:timed-status>
skipping to change at page 1, line 574 skipping to change at page 1, line 535
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
<contact priority="1.0">mailto:someone@example.com</contact> <contact priority="1.0">mailto:someone@example.com</contact>
</tuple> </tuple>
</presence> </presence>
8 XML Schema Definitions 8 XML Schema Definitions
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:sip-rpids" <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
xmlns:tns="urn:ietf:params:xml:ns:sip-rpids" xmlns:tns="urn:ietf:params:xml:ns:pidf:status"
xmlns:pidf="urn:ietf:params:xml:ns:cpim-pidf" xmlns:pidf="urn:ietf:params:xml:ns:cpim-pidf"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang--> <!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<redefine
schemaLocation="urn:ietf:params:xml:ns:cpim-pidf">
<!-- redefinition of tuple -->
<complexType name="tuple">
<complexContent>
<extension base="pidf:tuple">
<xsd:attribute name="class" type="xsd:token"/> <xsd:attribute name="class" type="xsd:token"/>
</extension>
</complexContent>
</complexType>
</redefine>
<xs:element name="contact-type" type="tns:contact-type"/>
<xs:element name="placetype" type="xs:token"/> <xs:element name="placetype" type="xs:token"/>
<xs:element name="privacy" type="tns:privacy"/> <xs:element name="privacy" type="tns:privacy"/>
<xs:element name="category" type="xs:token"/> <xs:element name="activity" type="xs:token"/>
<xs:element name="relationship" type="xs:token"/> <xs:element name="relationship" type="xs:token"/>
<xs:element name="from" type="tns:fromuntil"> <xs:element name="from" type="tns:fromuntil">
<xs:element name="until" type="tns:fromuntil"> <xs:element name="until" type="tns:fromuntil">
<xs:element name="idlesince" type="xs:dateTime"> <xs:element name="idle" type="xs:dateTime">
<xs:element name="icon" type="xs:anyURI"> <xs:element name="icon" type="xs:anyURI">
<xs:element name="card" type="xs:anyURI"> <xs:element name="card" type="xs:anyURI">
<xs:element name="info" type="xs:anyURI"> <xs:element name="info" type="xs:anyURI">
<xs:element name="timed-status" type="tns:timed-status"> <xs:element name="timed-status" type="tns:timed-status">
<xs:simpleType name="contact-type">
<xs:restriction base="xs:string">
<xs:enumeration value="individual"/>
<xs:enumeration value="device"/>
<xs:enumeration value="group"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="privacy"> <xs:simpleType name="privacy">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="private"/> <xs:enumeration value="private"/>
<xs:enumeration value="public"/> <xs:enumeration value="public"/>
<xs:enumeration value="quiet"/> <xs:enumeration value="quiet"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="fromuntil"> <xs:complexType name="fromuntil">
<xs:simpleContent> <xs:simpleContent>
skipping to change at page 1, line 635 skipping to change at page 1, line 598
<xs:sequence> <xs:sequence>
<xs:element name="basic" type="pidf:basic" minOccurs="0"/> <xs:element name="basic" type="pidf:basic" minOccurs="0"/>
<xs:element name="from" type="tns:fromuntil"> <xs:element name="from" type="tns:fromuntil">
<xs:element name="until" type="tns:fromuntil"> <xs:element name="until" type="tns:fromuntil">
<xs:element name="note" type="pidf:note"> <xs:element name="note" type="pidf:note">
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </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 9 Security Considerations
The security considerations in [1] apply, as well as [11]. Compared The security considerations in [1] apply, as well as [11]. Compared
to PIDF, this presence document format reveals additional information to PIDF, this presence document format reveals additional information
that can be highly sensitive. Beyond traditional security measures to that can be highly sensitive. Beyond traditional security measures to
protect confidentiality and integrity, systems should offer a means protect confidentiality and integrity, systems should offer a means
to selectively reveal information to particular watchers and to to selectively reveal information to particular watchers and to
inspect the information that is being published, particularly if it inspect the information that is being published, particularly if it
is generated automatically from other sources, such as calendars or is generated automatically from other sources, such as calendars or
sensors. sensors.
skipping to change at page 1, line 663 skipping to change at page 1, line 619
Like any information retrieved by reference, the information provided Like any information retrieved by reference, the information provided
in the <card>, <icon> and <info> elements may refer to data types in the <card>, <icon> and <info> elements may refer to data types
that expose the watcher to security risks. that expose the watcher to security risks.
10 IANA Considerations 10 IANA Considerations
This document calls for IANA to: This document calls for IANA to:
o register two new XML namespace URNs per [9]; o register two new XML namespace URNs per [9];
o establish registry for categories (Section 6.4), place types o establish registry for activity categories (Section 6.2),
(Section 6.12), and relationships (Section 6.14). place types (Section 6.9), and relationships (Section 6.11).
Note that this document does not need a new content type. It inherits Note that this document does not need a new content type. It inherits
the content type from [1], namely application/cpim-pidf+xml the content type from [1], namely application/cpim-pidf+xml
10.1 URN Sub-Namespace Registration for 10.1 URN Sub-Namespace Registration for
URI: urn:ietf:params:xml:ns:sip-rpids URI: urn:ietf:params:xml:ns:sip-rpids
Description: This is the XML namespace for XML elements defined Description: This is the XML namespace for XML elements defined
by RFCXXXX to describe a rich presence information by RFCXXXX to describe a rich presence information
skipping to change at page 1, line 918 skipping to change at page 1, line 876
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents Table of Contents
1 Introduction ........................................ 2 1 Introduction ........................................ 2
2 RPIDS Features ...................................... 3 2 RPIDS Features ...................................... 3
3 Scope ............................................... 5 3 Scope ............................................... 4
4 Terminology and Conventions ......................... 5 4 Terminology and Conventions ......................... 5
5 The Meaning of "open" and "closed" .................. 5 5 The Meaning of "open" and "closed" .................. 5
6 RPIDS Elements ...................................... 6 6 RPIDS Elements ...................................... 5
6.1 Introduction ........................................ 6 6.1 Introduction ........................................ 5
6.2 Activity Element .................................... 6 6.2 Activity Element .................................... 6
6.3 Card ................................................ 6 6.3 Card ................................................ 7
6.4 Category Element .................................... 7 6.4 Class ............................................... 7
6.5 Class ............................................... 8 6.5 From Element ........................................ 8
6.6 Contact-Type Element ................................ 8 6.6 Icon ................................................ 8
6.7 From Element ........................................ 8 6.7 Idle Element ........................................ 8
6.8 Icon ................................................ 9 6.8 Info ................................................ 8
6.9 Info ................................................ 9 6.9 Type of Place Element ............................... 8
6.10 Idlesince Element ................................... 9 6.10 Privacy Element ..................................... 9
6.11 Label Element ....................................... 9 6.11 Relationship Element ................................ 9
6.12 Type of Place Element ............................... 9 6.12 Timed Status Element ................................ 10
6.13 Privacy Element ..................................... 10 6.13 Until Element ....................................... 10
6.14 Relationship Element ................................ 10 7 Examples ............................................ 11
6.15 Timed Status Element ................................ 11 7.1 Presentity with Capabilities ........................ 11
6.16 Until Element ....................................... 11 8 XML Schema Definitions .............................. 12
7 Examples ............................................ 12 9 Security Considerations ............................. 13
7.1 Presentity with Capabilities ........................ 12 10 IANA Considerations ................................. 14
8 XML Schema Definitions .............................. 13 10.1 URN Sub-Namespace Registration for .................. 14
9 Security Considerations ............................. 14 10.2 URN Sub-Namespace Registration for .................. 15
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 10.3 Place Type, Device Type, Categories, Relationships
................................................................ 16 ................................................................ 16
11 Acknowledgements .................................... 17 11 Acknowledgements .................................... 16
12 References .......................................... 17 12 References .......................................... 16
13 Normative References ................................ 17 13 Normative References ................................ 16
14 Informative References .............................. 18 14 Informative References .............................. 17
15 Authors' and Editor's Addresses ..................... 18 15 Authors' and Editor's Addresses ..................... 17
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/