the ambiguity. The timestamp in particular is very useful for both
humans and automatons. As described in RFC 3863 [1], the timestamp
provides the time of most recent change for the tuple. This
specification defines the timestamp for person and device components
as well, with the same meaning. Absent other information, the
person, device, or service that most recently changed can be used as
the more reliable source of data. However, such a resolution
algorithm is not normatively required in any way.
3.6. The Meaning of Nothing
It is clear that the existence of a presence attribute in a document
tells something to a watcher about the value of that presence
attribute. However, what does the absence of a presence attribute
say? This data model follows the lead of RFC 3840 [17], which is
used to define capabilities for SIP user agents. In that
specification, if a capability declaration omits a particular feature
tag, it means that the agent is making no definitive statement either
way about whether this feature tag is supported. The same is true
here - the absence of a presence attribute from a document means that
a watcher cannot make any definitive statement about the value for
that presence attribute. It may be absent because it is being
withheld from the watcher, or it may be absent because that attribute
is not supported by the presentity’s software. Neither conclusion
can be drawn.
Because the absence of a presence attribute conveys no information
whatsoever, presence documents achieve their maximum value when they
have as many presence attributes as possible. As such, it is
RECOMMENDED that a presence document contain as many presence
attributes as the presentity is willing to and able to provide to a
watcher.
3.7. Status vs. Characteristics
The data model tries to separate status information from
characteristics, generally by defining status as a relatively dynamic
state about a person, device, or service, whereas a characteristic is
relatively static. However, this distinction is often artificial.
Almost any characteristic can change over time, and sometimes
characteristics can change relatively quickly. As a result, the
distinction between status and characteristics is merely a conceptual
one to facilitate understanding about the different types of presence
information. Nothing in a presence document indicates whether an
element is a characteristic vs. a status, and when a presence
attribute is defined, there is no need for it to be declared one or
the other. Presence documents allow any presence attribute, whether
it can be thought of as a characteristic or a status, to change at
any time.
Unfortunately, the original PIDF specification did have a separate
part of a tuple for describing status, and the basic status was
defined to exist within that part of the tuple. This specification
does not change PIDF; however, all future presence attributes MUST be
defined as children of the <tuple> and not the <status> element.
Furthermore, the schemas defined here do not contain a <status>
element for either the <person> or <device> elements.
3.8. Presence Document Properties
The overall presence document has several important properties that
are essential to this model.
First, a presence document has a concrete meaning independent of how
it is transported or where it is found. The semantics of a document
are the same regardless of whether a document is published by a
presence user agent to its compositor, or whether it is distributed
from a presence agent to watchers. There are no required or implied
behaviors for a recipient of a document. Rather, there are well-
defined semantics for the document itself, and a recipient of a
document can take whatever actions it chooses based on those
semantics.
A corollary of this property is that presence systems are infinitely
composeable. A presence user agent can publish a document to its
presence server. That presence server can compose it with other
documents, and place the result in a notification to a watcher. That
watcher can actually be another presence agent, combining that
document with others it has received, and placing those results in
yet another notify.
Yet another corollary of this property is that implied behaviors in
reaction to the document cannot ever be assumed. For example, just
because a service indicates that it supports audio does not mean that
a watcher will offer audio in a communications attempt to that
service. If doing so is necessary to reach the service, this must be
indicated explicitly through reach information.
It is also important to understand that the role of the presence
document is to help a user make a choice amongst a set of services,
and furthermore, to know ahead of time with as much certainty as
possible whether a communications attempt will succeed or fail.
Success is a combination of many factors: Does the watcher understand
the service URI? Can it act on all of the reach information? Does
it support a subset of the capabilities associated with the service?
Does the person information indicate that the user is likely to
answer? All of these checks should ideally be made before attempting
communication.
Because the presence document serves to help a user to choose and
establish communications, the presentity URI - as the index to that
document - represents a form of "one-number" communications.
Starting from this URI, all of the communications modalities and
their URIs for a user can be discovered, and then used to invoke a
particular communications service. Rather than having to give out a
separate phone number, email address, IM address, Voice over Internet
Protocol (VoIP) address, and so on, the presentity URI can be
provided, and all of the others can be learned from there.
4. Motivation for the Model
Presence is defined in [21] as the ability, willingness, or desire to
communicate across a set of devices. The core of this definition is
the conveyance of information about the ability, willingness, or
desire for communications. Thus, the presence data model needs to be
tailored around conveying information that achieves this goal.
The person data component is targeted at conveying willingness and
desire for communications. It is used to represent information about
the users themselves that affects willingness and desire to
communicate. Whether I am in a meeting, whether I am on the phone -
each of these says something about my willingness to communicate, and
thus makes sense for inclusion in a presence document.
The service component of the data model aims to convey information on
the ability to communicate. The ability to communicate is defined by
the services by which a user is reachable. Thus, including them is
essential.
How do devices fit in? For many users, devices represent the ability
to communicate, not services. Frequently, users make statements
like, "Call me on my cell phone" or "I’m at my desk". These are
statements for preference for communications using a specific device,
as opposed to a service. Thus, it is our expectation that users will
want to represent devices as part of the presence data.
Furthermore, the concept of device adds the ability to correlate
services together. The device models the underlying platform that
supports all of the services on the phone. Its state therefore
impacts all services. For example, if a presence server can
determine that a cell phone is off, this says something about the
services that run on that device: they are all not available. Thus,
if services include indicators about the devices on which they run,
device state can be obtained and thus used to compute the state of
the services on the device.
The data model tries hard to separate device, service, and person as
different concepts. Part of this differentiation is that many
attributes will be applicable to some of these, but not others. For
example, geographic location is a meaningful attribute of the person
(the user has a location) and of a device (the device has a
location), but not of a service (services don’t inherently have
locations). Based on this, geographic location information should
only appear as part of device or person, never service. Furthermore,
it is possible and meaningful for location information to be conveyed
for both device and person, and for these locations to be different.
The fact that the presence system might try to determine the location
of the person by extrapolation from the location of one of the
devices is irrelevant from a data modeling perspective. Person
location and device location are not the same thing.
[25] defines the <geopriv> XML element for conveying location
information, and indicates that it is carried as a child of the
<tuple> element in a PIDF document. [25] was developed prior to this
specification, and unfortunately, its recommendation to include
location objects underneath <tuple> runs contrary to the
recommendations here. As such, implementations based on this
specification SHOULD include <geopriv> location objects as part of
person and/or device components of the document, but SHOULD be
prepared to receive presence documents with that object as a child to
<tuple>. A <geopriv> location object would be included in a person
component when the document means to convey the location of the user,
and within a device component when it means to convey the location of
the device.
5. Encoding
Information represented according to the data model described above
needs to be mapped into an on-the-wire format for transport and
storage. The Presence Information Data Format [1] is used for
representation of presence data.
The <presence> element contains the presence information for the
presentity. The "entity" attribute of this element contains the
presentity URI.
The existing <tuple> element in the PIDF document is used to
represent the service. This is consistent with the original intent
of RFC 2778 and RFC 3863, and achieves backward compatibility with
implementations developed before the model described here was
complete. The <contact> element in the <tuple> element is used to
encode the service URI. New presence attributes, whether they
represent dynamic status or static characteristics, appear directly
as children of <tuple>. However, attributes defined prior to
publication of this specification that were defined as children of
<status> (such as <basic>) remain as children of <status>, for
purposes of backward compatibility. Consequently, a presence
attribute describing a service could appear as either a child of
<status> or directly as a child of <tuple>, but never both.
The "id" attribute of the <tuple> element conveys the service
occurrence. Each <tuple> element with the same <contact> URI
represents a different occurrence of a particular service.
This specification introduces the <person> element, which can appear
as a child to <presence>. There can be zero or more occurrences of
this element per document. Each one has a mandatory "id" attribute,
which contains the occurrence identifier for the person. Each
<person> element contains any number of elements that indicate status
and characteristic information. This is followed by zero or more
optional <note> elements and an optional <timestamp>. Multiple
<note> elements would appear to convey the same note in multiple
languages.
RFC 3863 defines a <note> element, zero or more of which can be
present as a child to <presence>. As it relates to the model defined
here, these note elements, if present in a document, apply to all
person occurrences that do not have any of their own <note> elements.
In other words, if a <person> element has one or more <note>
elements, those are the <note> elements for that <person> element.
If a <person> element does not have any of its own <note> elements,
the <note> elements that are the direct children of <presence> are
the <note> elements for that <person>. If there are no <note>
elements underneath the <person> element, and there are no <note>
elements that are a direct child of <presence>, then that <person>
element has no <note> elements.
This specification also introduces the <device> element, which can
appear as a child to <presence>. There can be zero or more
occurrences of this element per document. The <device> element can
appear either before or after the <person> element; there are no
constraints on order. Each <device> element has a mandatory "id"
attribute, which contains the occurrence identifier for the device.
Like <person>, <device> contains any number of elements that indicate
status and characteristic information. This is followed by
<deviceID>, which contains the URN for the device ID for this device.
This is followed by zero or more optional <note> elements and an
optional <timestamp>. Multiple <note> elements would appear to
convey the same note in multiple languages.
A client that receives a PIDF document containing the <device> and
<person> elements, but does not understand them (because it doesn’t
implement this specification), will ignore them. Furthermore, since
the semantics of service as defined here are aligned with the meaning
of a tuple as defined in RFC 2778 and RFC 3863, documents
incorporating the concepts defined in this model are compliant with
older implementations.
It’s important to note that the mapping of the presence data model
into a PIDF document is merely an exercise in syntax.
Presence documents created according to this model MUST be valid,
with the following exception. A compositor is permitted to create a
presence document that it cannot fully validate but that otherwise
validates when processed according to the lax processing rules
allowed by the schema of the compositor. However, it is not expected
that entities receiving these documents would perform schema
validation; rather, they would merely access the information from the
document in the places they were expecting it to be. Implementations
SHOULD be prepared to receive documents that are not valid, and
extract whatever information from them that they can parse.
5.1. XML Schemas
The XML schemas are broken into a common schema, called common-
schema.xsd, which contains common type definitions, and the rest of
the data model, data-model.xsd.
5.1.1. Common Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:simpleType name="Timestamp_t">
<xs:annotation>
<xs:documentation>Timestamp type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>
<xs:simpleType name="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="Note_t">
<xs:annotation>
<xs:documentation>Note type</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:attributeGroup name="fromUntil">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:attributeGroup>
<xs:complexType name="empty"/>
</xs:schema>
5.1.2. Data Model
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:pidf:data-model"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="common-schema.xsd"/>
<xs:element name="deviceID" type="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="device">
<xs:annotation>
<xs:documentation>Contains information about the
device</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="deviceID"/>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="person">
<xs:annotation>
<xs:documentation>Contains information about the human
user</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Characteristic and status
information</xs:documentation>
</xs:annotation>
</xs:any>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
6. Extending the Presence Model
When new presence attributes are added, any such extension has to
consider the following questions:
1. Is the new attribute applicable to person, service, or device
data components? If it is applicable to more than one, what is
its meaning in each context? An extension should strive to have
each attribute concisely defined for each area of applicability,
so that a source can clearly determine to which type of data
component it should be applied.
2. Does it belong in a new namespace, or an existing one?
Generally, new presence attributes defined within the same
specification SHOULD belong to the same namespace. Presence
attributes defined in separate specifications, but produced in a
coordinated way by a centralized administration, MAY be placed in
the same namespace. Doing so, however, requires the centralized
administration to ensure that there are no collisions of element
names across those specifications. Furthermore, if a new
extension has elements meant to be placed as the children of
another element at a point of extensibility defined by <any
namespace="##other">, the new extension MUST use a different
namespace than that of its parent elements.
3. Does the extension itself require extensibility? If so, points
of extension MUST be defined in the schema, and SHOULD be done
using the <any namespace="##other"> construct.
7. Example Presence Document
In this section, we give an example of a physical system, present the
model of that system using the concepts described here, and then show
the resulting presence document. The example makes use of presence
attributes defined in [23] and [24].
7.1. Basic IM Client
In this scenario, a provider is offering a service very similar to
the instant messaging services offered today by the public providers
like AOL, Yahoo!, and MSN. In this service, each user has a "screen
name" that identifies the user in the service. A single client,
generally a PC application, connects to the service at a time. When
the client connects, this fact is made available to other watchers of
that user in the system. The user has the ability to set a textual
note that describes what they are doing, and this note is seen by the
watchers in the system. The user can set one of several status
messages (busy, in a meeting, etc.), which are pre-defined notes that
the system understands. If a user does not type anything on their
keyboard for some time, the user’s status changes to idle on the
screens of the various watchers of the system. The system also
indicates the amount of time that the user has been idle.
Whenever a user is connected to the system, they are capable of
receiving instant messages. A user can set their status to
"invisible", which means that they appear as offline to other users.
However, if an IM is sent to them, it will still be delivered.
This system is modeled by representing each presentity in the system
with three data components: a person component, a service component,
and a device component. The person component describes the state of
the user, including the note and the pre-defined status messages.
These represent information about the human user, so they are
included in the person component. The service tuple represents the
IM service. No characteristics are included. The service URI
published by the client is set to the client’s Address of Record
(AOR). The device component is used to model the PC. The device
component includes the <user-input> element [23], since the idleness
refers to usage of the device, not the service.
The document published by the client would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
<caps:servcaps>
<caps:extensions>
<caps:supported>
<caps:pref/>
</caps:supported>
</caps:extensions>
<caps:methods>
<caps:supported>
<caps:MESSAGE/>
<caps:OPTIONS/>
</caps:supported>
</caps:methods>
</caps:servcaps>
<contact>sip:someone@example.com</contact>
</tuple>
<dm:person id="p1">
<rp:activities>
<rp:on-the-phone/>
</rp:activities>
</dm:person>
<dm:device id="pc122">
<rp:user-input>idle</rp:user-input>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</dm:device>
</presence>
It is worth commenting further on the value of having a separate
device element just to convey the idle indicator. The idle
indication of interest is really an indicator that the device is
idle. By making that explicit, the idle indicator can be used by the
presence server to affect the state of other services running on the
same device. For example, let’s say there is a VoIP application
running on the same device. This application reports its presence
state separately, but indicates that it runs on the same device.
Since it has indicated that it runs on the same device, the presence
server can use the status of the service to further refine the idle
indicator of the device. Specifically, if the user is using its VoIP
application, the presence server knows that the device is in use,
even if the IM application reports that the device is idle.
Typically, idleness is determined by lack of keyboard or mouse input,
neither of which might be used during a VoIP call.
In a more simplistic case, reporting the idle indicator as part of
the device status allows that indicator to be used for other services
on the same device. Taking, again, the example of the VoIP
application on the same device, if the VoIP application does not
report any device information, and a watcher is not provided
information on the IM service, the presence document sent to the
watcher can include the device status. Because of the usage of the
device IDs and the device information, the presence server can
correlate the device status as reported by the IM application with
the VoIP service, and use them together.