One document matched: draft-rosenberg-simple-presence-data-model-00.txt
SIMPLE J. Rosenberg
Internet-Draft dynamicsoft
Expires: January 7, 2005 July 9, 2004
A Data Model for Presence
draft-rosenberg-simple-presence-data-model-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Over the last year of work, the SIMPLE group has tried to answer the
question of "what is a tuple". This document tries to answer that
question by proposing an abstract data model for presence, and then
mapping that data model onto the Presence Information Data Format
(PIDF). It then discusses the operations of publication,
composition, filtering as they relate to presence data processing.
Rosenberg Expires January 7, 2005 [Page 1]
Internet-Draft Presence Data Model July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Presentity . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Service . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Devices . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Motivation for the Model . . . . . . . . . . . . . . . . . . . 12
5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Presence Server Processing . . . . . . . . . . . . . . . . . . 16
7.1 Collection . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2 Composition . . . . . . . . . . . . . . . . . . . . . . . 18
7.2.1 Correlation . . . . . . . . . . . . . . . . . . . . . 18
7.2.2 Conflict Resolution . . . . . . . . . . . . . . . . . 19
7.2.3 Merging . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.4 Splitting . . . . . . . . . . . . . . . . . . . . . . 22
7.3 Privacy Filtering . . . . . . . . . . . . . . . . . . . . 23
7.4 Watcher Filtering . . . . . . . . . . . . . . . . . . . . 23
7.5 Post-Processing Composition . . . . . . . . . . . . . . . 23
8. Extending the Presence Model . . . . . . . . . . . . . . . . . 24
9. Example Presence Documents . . . . . . . . . . . . . . . . . . 24
9.1 Basic IM Client . . . . . . . . . . . . . . . . . . . . . 24
9.2 VoIP Application . . . . . . . . . . . . . . . . . . . . . 27
9.3 Cellphone . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Proposed Plan of Action . . . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . 33
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
13. Informative References . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . 36
Rosenberg Expires January 7, 2005 [Page 2]
Internet-Draft Presence Data Model July 2004
1. Introduction
Over the last year of work, the SIMPLE group has tried to answer the
question of "what is a tuple". In particular, RFC 2778 [1]
introduces the concept of a tuple, but merely states that it is an
element of presence information consisting of status, communications
address and other markup. As such, it can be used as a tool for
modeling different concepts, but there has not been consensus on
what, precisely, it models. At least four different concepts have
been put forward:
Service: In this view, a tuple models a communciations service, such
as instant messaging or telephony.
Device: In this view, a tuple models a communications device, such as
a phone, PDA or PC.
Presentity: In this view, a tuple models the user of the system, and
includes information about the user and all of their
communications modalities.
Person: In this view, a tuple represents a person as a communications
medium, i.e., face-to-face communications.
Status: Dynamic information about a service, presentity or device.
Characteristics: Static information about a service, presentity or
device. Useful in providing context that identifies the service
or device as different from another service or device.
A service or characteristic. It represents a single piece of
presence information.
Publication: The act of pushing a piece of event state, including
presence, to a state agent, such as a presence server.
Back end subscriptions: A subscription made from a state agent, such
as a presence server, to a source of presence, for the purpose of
collecting event state in order to perform composition.
The SIMPLE group has produced several documents in the process of
trying to answer this question. A use case document [4] was
developed to describe several different systems, and how a presence
document would be constructed to describe the system. This effort
quickly revealed that there was a lot of inconsistency in how
documents generated to describe one device in one system would be
interpreted in another system.
In a related document, Roach documents a technique [5] for indicating
the service associated with a tuple, by proposing that the service be
deduced from service characteristics.
Unfortunately, the question of "what is a tuple" still appears to be
unanswered, and as a result of this, there remains confusion on how
to properly specify several work items within the SIMPLE group.
These work items are:
Rosenberg Expires January 7, 2005 [Page 3]
Internet-Draft Presence Data Model July 2004
RPID: RPID defines a set of extensions to the PIDF document for
defining rich presence status [6]. This document defines a
<contacttype> element which indicates whether the tuple is a
device, service, in-person or presentity, but does not define what
that means. Furthermore, most of the other extensions indicate
whether or not they make sense in tuples of various types. There
has been disagreement on this, ultimately due to the lack of
definition on what these mean.
Presence Authorization Rules: The presence authorization rules [7]
defines a set of permissions that can be granted to watchers of
presence. There is a desire to include rules that allow watchers
access to tuples of a certain device or service, but little
understanding of what this means.
The SIMPLE group has also discussed concepts such as document
composition, pivoting and filtering, and these discussions have also
oftentimes suffered from confusion because of a disparity of
understanding on what was being done.
Ultimately, it is our belief that the problem is that the group has
never agreed on a well defined model for presence data. Such a model
gives the context that is necessary to talk about the various
operations that one performs on presence data - extending it,
encoding it, filtering it, and authorizing its usage. This document
attempts to remedy this situation by proposing a concrete model for
presence data, justifying the model based on the key goals of
presence and presence systems, and then exploring the impacts on
encoding, filtering, authorization, composition, and so on.
2. Definitions
This document makes use of many new terms, which are defined here.
Device: A device is a model that represents a common operating
environment across services, which in and of itself has
characteristics that defined and constrain the operation of those
services. Typically, a device models a physical operating
environment.
Service: A service models a form of communications that can be used
to interact with the user.
Presentity: A presentity models the principal or user of the system,
using a combination of presentity, device and service data
elements.
Data Element: One of the device, service, or presentity parts of a
presence document.
Composition: The act of combining a set of presence and event data
about a presentity into a coherent picture of the state of that
presentity.
Rosenberg Expires January 7, 2005 [Page 4]
Internet-Draft Presence Data Model July 2004
Raw Presence Document The result of an initial composition operation,
before privacy and watcher filtering operations have been applied.
Privacy Filtering: The act of applying permissions to a presence
document for the purposes of removing information that a watcher
is not authorized to see.
Watcher filtering The act of removing information from a presence
document at the request of a watcher, to reduce the information
flowing to that watcher.
Pivot: A presence attribute used to select a set of services or
devices that are to be combined as part of a composition
operation.
View: A view represents a stream of presence documents generated by a
presentity after composition and authorization policies have been
applied. Depending on how these policies are structured, each
watcher to a presentity may get a different view, or they may all
get the same view.
Rosenberg Expires January 7, 2005 [Page 5]
Internet-Draft Presence Data Model July 2004
3. The Model
+----------------+
| |
| |
| Presentity |
| |
| |\
/ +----------------+ \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
V V V
+----------------+ +----------------+ +----------------+
| | | | | |
| | | | | |
| Service | | Service | | Service |
| | | | | |
| | | | | |
+----------------+ +----------------+ +----------------+
\ / \
\ / \
\ / \
\ / \
V V V
+----------------+ +----------------+
| | | |
| | | |
| Device | | Device |
| | | |
| | | |
+----------------+ +----------------+
Figure 1
The data model for presence is shown in Figure 1. There are three
elements in the model. They are the presentity, the service, and the
device. Each of these data elements contains information (called
attributes) that provide a description about the service, presentity,
or device. It is central to this model that these attributes are
affilitated with the service, presentity, or device because they
Rosenberg Expires January 7, 2005 [Page 6]
Internet-Draft Presence Data Model July 2004
*describe* that service, presentity or device. This is in contrast
to a model whereby the attributes are associated with the service,
presentity, or device because they were *reported* by that service,
presentity, or device. As an example, if a cell phone reports that a
user is in a meeting, this would be done by including a presentity
element with an in-a-meeting attribute. The presence information may
also include information on the cell phone as a device. However,
even though it is that device which is reporting that the user is in
a meeting, the busy indicator is not associated with the device, it
is associated with the user.
3.1 Presentity
The presentity element models information about the user whom the
presence data is trying to describe. This information consists of an
identifier for the presentity, characteristics and status.
The URI for the presentity represents an identity for the user that
is independent of any of the services or devices that they possess.
However, the URI is not just a name - it represents a resource that
can be subscribed to, in order to find out the status of the user.
As such, it can either be a SIP URI for the user, to which SUBSCRIBE
requests can be directed, or else it can be a pres URI [8].
Characteristics of a presentity are the static information about a
user that does not change under normal circumstances. Such
information might include physical characteristics, such as age and
height. Status information about a presentity represent the dynamic
information about a user. These typically are things the *user* is
doing, places the *user* is at, feelings the *user* has, and so on.
Examples of typical presentity status are "in a meeting", "on the
phone", "out to lunch", "happy" and "writing Internet Drafts".
In the model, there can only be one presentity element. It is
possible for the presentity to model "users" that are in fact
multiple people, for example, a customer support desk. Nothing in
the model mandates that the entity being modeled is actually composed
of a single user. The model only mandates that this "user" be
represented by a single set of characteristics, and the
characteristics that are available are tailored for the case where a
single user is being modeled.
3.2 Service
Each presentity has access to a number of services. Each of these
represent a form of communications that can be used to interact with
the user. Examples of services are telephony (that is, traditional
circuit-based telephone service), push-to-talk, instant messaging,
Rosenberg Expires January 7, 2005 [Page 7]
Internet-Draft Presence Data Model July 2004
Short Message Service (SMS), and Multimedia Message Service (MMS).
When a service is accessible over a communications network, it is
represented with a URI that can be "hit" in order to access the
service. However, some services are not accessible over a
communications network (such as in-person communications or a written
letter), and as such, may not utilize a URI.
Each service is adorned with characteristics that describe the nature
of the service that will be experienced when a watcher invokes that
URI. Examples of such characteristics are the type of media that
might be used, the directionality of communications that are
permitted, the quality of the service, and so on. These
characteristics are important when multiple services are indicated.
That is because the purpose of listing multiple services in a
presence document is to give the watcher a *choice*. That is, the
presentity is explicitly offering the watcher an opportunity to
contact them using a multiplicity of different services. To help the
watcher make a decision, the presence document includes
characteristics of each service which help differentiate the services
from each other, and give the watcher the context in which to make a
choice.
In this model, services are not explicitly enumerated. That is,
there is no "service" attribute with values of "ptt" or "telephony".
Rather, the service is identified in one of two ways. In many cases,
the URI scheme is a clear indicator of service. An "sms" URI clearly
indicates SMS, and a "tel" URI clearly indicates telephony. For some
URIs, there may be many services available, for example, SIP. For
those services, each service has a set of characteristics, each of
which has a well-defined meaning, such that a system can
unequivocally determine whether or not the service has that
characteristic. This is discussed in more detail in [5]. [[NOTE:
What attributes do we use to determine that the service is in-person
communications or written communications?]]
One important characteristic of each service is the list of devices
on which that service executes. Each device is identified uniquely
by a device ID. As such, the service characteristics can include a
list of device IDs. A presence document might also contain a
information on each device, but this is a separate part of the
document. Indeed, the information on each device might not even be
present in the document. In that case, the device IDs listed for
each service are nothing more than correlation identifiers, useful
for determining when two services run on the same device. The
benefit of this model is that information on the devices can be
filtered out of a presence document, yet the service information,
which includes the device IDs, remains useful and meaningful.
Rosenberg Expires January 7, 2005 [Page 8]
Internet-Draft Presence Data Model July 2004
It is perfectly valid for a presence document to contain just a
single service. This is permitted even if the presentity actually
has multiple services at their disposal. The lack of multiple
services in the document merely means that the presentity is not
offering a choice to the presentity. In such a case, the service
characteristics are less important, but may be helpful in allowing a
watcher to decide if they wish to communicate at all.
The URI is an important part of the service. When the watcher makes
a decision about which service of the presentity they wish to access,
the watcher invokes the URI associated with that service. It is not
necessary for the watcher to add additional information to a message
generated by invoking that URI in order to reach the service
described in the document. Specifically, it is not necessary for a
watcher to add SIP caller preferences in order to request routing of
the request to a service with the characteristics described in the
document. As a result, each service in the presence document will
have a different URI.
The URI represents a weak form of contract; the presentity tells the
watcher that, if the watcher invokes the URI as included in the
presence document, the watcher might be connected to a service
described by the characteristics included in the presence document.
It is important to stress that this is not a guarantee in any way.
It cannot be a guarantee for two reasons. Firstly, the service in
the document might actually be modelling a number of actual services
used by the user, and it may not be possible to connect the watcher
to a service with all of the characteristics described in the
presence document. Secondly, the preferences of the presentity
always take precedence. The caller might ask to be connected to the
video service, but it is permissible to connect them to a different
service if that is the wish of the presentity.
The URI also plays another important role - it acts as the unique
identifier for the service. When two presence user agents publish
information about a service, the service URI is what indicates that
the service information they are publishing is for the same or
different services. For this reason, it is important that each PUA
use unique service URIs, and that these service URIs also be
persistent over time. These properties are readily met by using the
Globally Routable User Agent URI (GRUU) [10] as the service URI.
This is discussed further below.
Each service is also associated with a priority, which represents the
preference that the user has for usage of one service over another.
This does not mean that, when a watcher wishes to communicate with
the presentity, that they should always use the service with the
highest priority. If that were the case, there would be no point in
Rosenberg Expires January 7, 2005 [Page 9]
Internet-Draft Presence Data Model July 2004
including multiple services in the presence document. Rather, the
priority says, "If you, the watcher, cannot decide which of these to
use, or if it is not important to you, this is the order in which I
would like you to contact me. However, I am giving you a choice.".
The priorities are relative to each other, and have no meaning as
absolute numbers. If there are two services, and they have
priorities of 1 and .5 respectively, this is identical to giving them
priorities of .2 and .1 respectively.
Each service also has a status. Status represents dynamic
information about the availability of communications using that
service. This is in constrast to characteristics, which describe
fairly static properties of the various services. The simplest form
of status is the basic status, which is a binary indicator of
availability for communications using that service. Other status
information might indicate more details on why the service is
available or unavailable. For example, a telephony service might
have additional status to indicate that the user is on the phone, or
that the user is handling 3 calls for that service.
Services inherently have a lot of dyanmic state associated with them.
For example, consider a wireless telephony service (i.e., a cell
phone). There are many dynamic statuses of this service - whether or
not the phone is registered, whether or not its roaming, which
provider it has roamed into, its signal strength, how many calls it
has, what the state of those calls are, how long the user has been in
a call, and so on. As another example, consider an IM service. This
service has dynamic states like whether or not the user is
registered, how long they have been registered, whether they have an
IM conversation in progress, how many IM conversations are in
progress, whether the user is typing, to whom they are typing, and so
on.
However, not all of this dynamic state is appropriate to include
within a service element of a presence document. Information is
included only when it has a bearing on helping the watcher decide
whether or not to initiate communications with that service, or
helping them decide when to initiate it, if not now. As an example,
whether a cell phone has roamed or not does not pass this litmus
test. Knowing this is not likely to have an impact on a decision to
use this service.
3.3 Devices
Devices model the physical operating environment in which services
execute. Examples of devices include cell phones, PCs, laptops,
PDAs, consumer telephones, enterprise PBX extensions, and operator
dispatch consoles.
Rosenberg Expires January 7, 2005 [Page 10]
Internet-Draft Presence Data Model July 2004
The mapping of services to devices are many to many. A single
service can execute in multiple devices. Consider a SIP telephony
service. Two SIP phones can register against a single
address-of-record for this service. As a result, the SIP service is
associated with two devices. Similarly, a single device can support
a multiplicity of services. A cell phone can support a SIP telephony
service, an SMS service, and an MMS service. Similarly, a PC can
support a SIP telephony service and a SIP videophone service.
Devices are identified with a device ID. A device ID is a URI that
is a globally and temporally unique identifier for the device. The
device ID is also persistent across time. This makes it useful as a
correlation identifier, as discussed below. Practically speaking, it
is difficult to obtain device identifiers with these guaranteed
properties; however, there are many ways in which it can be done
reasonably well. For a cell phone, the ESN (Electronic Serial
Number) and MIN (Mobile Identification Number) are good choices. For
an IP device, the mac address of the primary interface is a good
choice, or the CPU serial number. In many cases, there might be
multiple good choices. For example, a cell phone with IP
connectivity might have an ESN, MIN and MAC address. In that case,
one of them needs to be chosen, and used as the device identifier.
Of course, if a device chooses to use two device identifiers, and
hands out different ones to different services, this will manifest
itself as two different devices as far as the model is concerned.
That might be a feature in some cases, or a bug. The choice is left
to local policy.
Like services and presentities, devices have static characteristics
and dynamic status. Characteristics of a device include its physical
dimensions and capabilities - the size of its display, the speed of
its CPU, and the amount of memory. Status information includes
dynamic information about the device. This includes whether or not
the device is powered on or off, the amount of battery power that
remains in the device, the geographic location of the device, and so
on.
Just like services, there is no enumeration of device types - PCs,
PDAs, cell phones, etc. Rather, the device is defined by its
characteristics, from which a watcher can extrapolate whether the
device is a PDA, cell phone, or what have you.
It is important to point out that the device is a *model* if the
underlying physical systems in which services execute. There is
nothing that says that this model cannot be used to talk about
systems where services run in virtualized systems, rather than real
ones. For example, if a PC is executing a virtual machine, and
running services within that virtual machine, it is perfectly
Rosenberg Expires January 7, 2005 [Page 11]
Internet-Draft Presence Data Model July 2004
acceptable to use this model to talk about that PC as being composed
of two separate devices.
4. Motivation for the Model
Presence is defined in [3] 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 presentity part of the model is targeted at conveying willingness
and desire for communications. It is used to represent information
about the user themselves that affects willingness and desire to
communicate. Whether or not I am in a meeting, whether or not 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
seems essential.
How do devices fit in? For many users, devices represent the ability
to communicate, not services. Frequently, users my 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 devices, services, and
presentities 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 presentity (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
Rosenberg Expires January 7, 2005 [Page 12]
Internet-Draft Presence Data Model July 2004
information should only appear as part of devices or presentities,
never services. Furthermore, it is possible and meaningful for
location information to be conveyed for both a device and a
presentity, and for these locations to be different. The fact that
the presence system might try to determine the location of the
presentity by extrapolation from the location of one of the devices
is irrelevant from a data modeling perspective. Presentity location
and device location are not the same thing.
It is important to be clear about what it means for an attribute to
be associated with a service, device or presentity. The lack of
clarity on this point is a core part of the "what is a tuple" problem
that the group has been facing. Furthermore, it is important to try
and restrict an attribute to appearing in as few different types of
tuples as possible. The more places an attribute can appear, with
the same meaning, the greater the possibility of interoperability
failures. Being concise on what the presence data represents, with
as little choice about how the same thing is represented, is
important.
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 Document Format [9] is used for
representation of presence data.
The approach suggested here is to use the <tuple> element to
represent presentity, service and device information. In order to
indicate which one of these the tuple represents, an RPID parameter,
<tuple-type>, is used, with values of "service", "presentity" and
"device". This approach was chosen largely because much of the
existing presence work views "tuple" as the fundamental unit of
information modelling. A more natural fit would have been to
translate the data model directly into XML, by defining explicit
<presentity>, <device> and <service> elements. However, that seems
to disruptive at this point.
When a <tuple> models a presentity, the <contact> element is omitted.
Similarly, for a device, the <contact> element is also omitted. It
is present only for a service. For services that are not readily
representable by a URI, for example, in person communications or
written communications, the <contact> element can be present, but
with some kind of bogus URN [[Yuck!]]. The <contact> element needs
to be there in order to contain the priority, which is meaningful
even for services without a URI.
Status information for devices, tuples and services are encoded
Rosenberg Expires January 7, 2005 [Page 13]
Internet-Draft Presence Data Model July 2004
within the <status> element if their respective tuples.
Characteristics (that is, static information) is encoded directly
underneath <tuple>.
When a watcher receives a presence document that doesn't contain the
<tuple-type> element, the watcher assumes that the tuple is modeling
a service. This is to provide backwards compatibility with simpler
systems that don't use RPID and the data model described here.
The entity attribute in the <presence> element is always present, and
identifies the presentity described by the document. [[The
terminology here is a bit confusing: we talk about the presentity as
a data element, and presentity as the entire thing being modeled by
the presence document, including the presentity element. Do we need
two terms?]]
Mapping of the data model into a PIDF document is done according to
the following table:
Data Element PIDF Encoding
--------------------------------------------------------
Presentity a <tuple> element
URI "entity" attribute of <presence>
characteristics children of the presentity <tuple>
status children of <status> within the
presentity <tuple>
Service a <tuple> element
URI the <contact> within the <tuple>
characteristics children of the service <tuple>
status children of <status> within the
service <tuple>
priority "priority" attribute of <contact>
Device a <tuple> element
device ID child of the <tuple> element
characteristics children of the device <tuple>
status children of <status> within the
device <tuple>
It's important to note that the mapping of the presence data into a
PIDF document is merely an exercise in syntax. Almost any of the
choices will do; what is important is agreement on what this data
represents.
6. Publication
Publication is defined as the process by which an event publication
Rosenberg Expires January 7, 2005 [Page 14]
Internet-Draft Presence Data Model July 2004
agent (EPA) pushes event state into the network [11]. In this
section, we consider how an EPA for the presence event package would
generate the presence document it will publish.
An EPA for presence (also known as a Presence User Agent (PUA))
computes the presence document as if it had full knowledge of the
state of the presentity. That is, it represents the complete view of
user presence as understood by that PUA.
In particular, this means that the document will include information
on the presentity - its URI, and any characteristics or status known
to the PUA. The URI (encoded in the "entity" attribute) will
typically be a SIP URI, and equal to the AOR of the presentity. This
will also usually be the same as the request URI in the PUBLISH
request itself, but it need not be so. The URI serve different
purposes. As described in [11], the request URI serves as a means to
route the request to the appropriate event state compositor, and
identity the target of the publication. As such, it is primary a
means for targeting the document. The entity about whom presence is
reported is always taken from the "entity" of the presence document.
As an example when the two might be different, consider an IT
helpdesk. The IT helpdesk is modeled as a presentity, and as such,
it has a SIP URI of the form sip:helpdesk@example.com. The
compositor knows that there are three users in the IT department,
sip:joe@example.com, sip:bob@example.com and sip:mary@example.com.
Joe's PUA knows that it needs to inform the compositor about its
state in order to compute the presence of the helpdesk. So, it might
construct a PUBLISH request where the reuqest URI is
sip:helpdesk@example.com, and the presentity URI is
sip:joe@example.com.
However, we anticipate that in the vast majority of cases, Joe's PUA
would not have to explicitly do this. The compositor would know,
based on provisioned composition logic, that the state of
sip:helpdesk@example.com is based on the other three URI, and it
would explicitly obtain the state of those presentities.
A PUA will also publish the services it knows about, and the device
its associated with. The service URI needs to be a unique identifier
that defines the service as far as the PUA is concerned. That URI
should be a GRUU, as discussed above. The device ID for the device
is obtained from the local operating system.
Its interesting to note that, if GRUU had been around before
PUBLISH, we may have found it easier to have each PUA publish to
its own GRUU as the request URI. This would eliminate the need
for multiple "slots" of published data, etags, and some of the
other complexity in the publish specification. Too late now...
Rosenberg Expires January 7, 2005 [Page 15]
Internet-Draft Presence Data Model July 2004
7. Presence Server Processing
In this section, we outline the processing a server does on presence
documents. The basic flow of operations is shown in Figure 3.
+---------+
|Presence |
| Source |\
+---------+ \ +-----------+
\ | |
\ /------\ | Raw | //------\\
+---------+ \// Create \\ | Presence | || Privacy ||-----+
|Presence |----| View |-->| Document |->|| Filtering|| |
| Source | \\ // | | \\------// |
+---------+ / \------/ | | |
/ ^ +-----------+ ^ |
/ | | |
+---------+ / +------------+ +------------+ |
|Presence |/ | Composition| | Presence | |
| Source | | Policy | | Auth | |
+---------+ | (TBD) | | | |
| | | | |
+--------| | | | |
| +------------+ +------------+ |
| |
V V
------ +-----------+ +-----------+
//// \\\\ | | ------ | |
| Post | | Filtered | /// \\\ | Candidate |
| Processing |<---| Presence |<--| Watcher | | Presence |
| Composition | | Document | | Filter | <---| Document |
\\\\ //// | | \\\ /// | |
------ | | ------ | |
| +-----------+ +-----------+
|
|
|
|
V
+-----------+
| |
| Final |
| Presence |
| Document |
| |
Rosenberg Expires January 7, 2005 [Page 16]
Internet-Draft Presence Data Model July 2004
| |
+-----------+
Figure 3
7.1 Collection
The first step is the process of collection. Collection is defined
as the process of obtaining the set of event state that is necessary
for performing the composition operation neccesary to create the
initial view. A view is defined as the particular stream of presence
documents seen by a watcher after the application of policy. In this
case, the initial view is the view of the presentity before the
application of authorization policies.
The event state that is collected includes all of the presence
documents that have been published for the presentity. This, by
definition, is the set of documents whose "entity" attribute in the
<presence> element in the presence document is the same as that of
the presentity. However, it may also include other presence
documents for other presentities, in cases where the presence server
knows that the state of one presentity is a function of the state of
another. An example is the helpdesk presentity, whose state is a
function of the state of the users in the help desk.
In addition to presence events, other event state can be used as
well. As an example, registration state has a bearing on presence,
as does dialog state, and the state of non-SIP systems, such as
traditional telephony equipment, layer 2 devices, and so on. This
state can be obtained by a presence server in several ways. Firstly,
publishers for that state can send PUBLISH requests for it to the
presence server. In another approach, the presence server acts as a
watcher, and subscribes to the event state for the resources it
needs. This is referred to as a back-end subscription.
Each of these non-presence events can then be converted into a piece
of presence state (presentity, device or service information) based
on local policy. For example, if the presence server has somehow
obtained information that says that the user's cell-phone is on, this
can be converted into device state (using the device ID of the phone)
along with service state, if the presence server knows about the
services on the device.
Registration state is of particular importance. It can be obtained
by a presence server by having the presence server co-located with
the registrar, or by having the presence server subscribe to the
Rosenberg Expires January 7, 2005 [Page 17]
Internet-Draft Presence Data Model July 2004
registration event package for the user [2]. Each registered contact
is considered a service. The service URI (expressed in the <contact>
element in each tuple of the presence document) is obtained from the
GRUU for each contact, if it exists, else it is set to the Contact
URI from the registration. Service parameters can be extracted from
any callee capabilities provided in the registration [12]. The
presentity URI is set to the address-of-record. This mapping has the
advantage that it is readily correlated to any service information
that might also be PUBLISHed explicitly by that UA. As such, a UA
that registers should also PUBLISH its state, in the event the
presence server cannot access registration information.
Once the non-presence event state is converted into pieces of
presence state, the compositor will have, at its disposal, a set of
presence data, each of which is for the same presentity.
7.2 Composition
The next step in the process is the composition operation, which
produces the raw presence document, also known as the initial view,
from the document sources. This document is "raw" because it
contains more information than any watcher might actually see.
Authorization policy may eliminate some of the data from the
document.
The means by which composition is done is a matter of local policy.
However, there are some general tools and techniques that merit
discussion.
7.2.1 Correlation
A key part of composition is using information in one presence
document, describing a presentity, service or device, to affect
information in another. As an example, if the presence server has a
document indicating that the user has a telephony service that is
busy, the server can use this to extract information about the
presentity - that they are on the phone. Similarly, if one document
indicates that a device with ID 1 is off, and another document that
indicates a telephony service is running on the device with ID 1, the
server can determine that the telephony service is closed.
The way in which the various input data impact each other are a
matter of local policy. However, a key to performing such
combination operations is the usage of a correlation identifier that
can match services, devices, and presenties together across input
sources. The presence document provides the service URI, presentity
URI and device ID as correlation identifiers. All three of these
identifiers have uniquess and temporal persistence properties that
Rosenberg Expires January 7, 2005 [Page 18]
Internet-Draft Presence Data Model July 2004
make them useful for purposes of correlation. Indeed, its not just
that the identifiers have temporal persistence; its that they have a
common value that is used persistently across different sources. In
the example above, the device ID of 1 is useful for correlating the
device state to the service state, if, and only if, the source
indicating the device state uses the same device ID as the source
indicating the service state. This makes selection of the device ID
a critically important operation.
7.2.2 Conflict Resolution
In some cases, there may be multiple sources that provide conflicting
information about a service, presentity, or device. In this case,
"conflicting" means that there are multiple presentity objects that
say different things, multiple service objects for the same service
(where the same service is defined as two services with the same
service URI), or multiple device objects with the same device ID.
Conflicting presentity information is very likely. Consider the case
of a user that has an IM application running at work. This IM
application was told by the user to indicate a status of "in a
meeting". The status of "in a meeting" is presentity status. So,
the IM client publishes a presence document with two tuples. One
tuple is the presentity tuple, indicating that the user is in a
meeting. The other tuple is the IM service tuple, indicating
availability for IM service. The service URI is equal to the GRUU
for that client. When the user gets home, they start another IM
application on the same provider, for the same presentity. The user
tells this application to set the status to "at home". This will
cause the application to publish two tuples. One is a presentity
tuple, with a status of "at home". The other is a service tuple for
IM, indicating availablility. That IM service uses a different
service URI than the one at work, since the two are running on
separate UA instances.
The presence server now has two documents about the same presentity.
These documents have non-conflicting IM services (though there are
two of them), but they both have a presentity tuple, and this tuple
is different. Here, there is a conflict. The presence server can
choose, based on administrator or user-provided policy, which
presentity tuple to use (or indeed to combine them).
A key way in which conflicts can be resolved is by measuring the
likelihood that the information from each source is accurate. In
this simple case, the presentity information is reported from two IM
clients. However, one IM client may report an idle indicator for the
device, whilst the other (the home IM client) reports that it is not
idle. The presence server can use this information to believe the
Rosenberg Expires January 7, 2005 [Page 19]
Internet-Draft Presence Data Model July 2004
device which is not idle.
More generally, when a source publishes information, it publishes its
"world view", including information it thinks it knows about the
presentity, about the service it is providing, and the device it runs
on. The fact that all of these are reported together in a presence
document is key. It provides additional context that can be used to
determine the level of accuracy of a source for particular
information. For example, if a cell phone reports that the user is
in a meeting, the cell phone's document will include, in addition to
the presentity status, cell phone device and cell phone service
information. Simimlarly, if a calendaring application acts as a
source, and indicates that the user is in a meeting, it would include
only information about the meeting. The presence server might decide
to trust the information that reports *just* the meeting, more than a
cell phone that reports a meeting.
The presence server may also know the source of the presence data,
based on authenticated identities. For example, in the case above,
the calendaring application may have a separate identity it uses to
authenticate itself to the presence server. The presence server can
be configured to know that the owner of that particular authenticated
identity is a calendar application, and therefore, it can trust its
information on meeting status information more than another source.
[[OPEN ISSUE: do we want a <source> attribute that can be used to
explicitly define information about the publisher of the
information?? How would this be authorized??]].
Conflicts of services or devices are less likely to occur in the
model presented here, due to the unique nature of the service URI and
device ID. However, it is possible. Indeed, a client might
explicitly choose to publish with the same service URI as another
client, if its goal is to explicitly override the service of the
other. Using the same service ID is the "hint" to the presence
server that conflicting data exists, and one needs to be chosen.
7.2.3 Merging
Merging is an operation that allows a presence server to combine
together a set of different services or devices into a single
composite service or device. Two services are different if they have
different service URIs, and two devices are different if they have
different device IDs. This operation is a common one in composition
operations.
To merge a set of services, the characteristics and status of each
service must be combined, and then a single composite service URI
must be generated. How the characteristics and status are combined
Rosenberg Expires January 7, 2005 [Page 20]
Internet-Draft Presence Data Model July 2004
will vary for each attribute. For many attributes, if the value is
the same across all services, the combination operation is easy - use
that value. If the attribute differs across services, it is a matter
of local policy as to how they are combined.
As an example, consider the <basic> status as defined in [9]. The
most sensible combination operation is the boolean OR operation.
That is, a composite service is said to be available as long as one
of its component services is available.
One way to identify the set of services that will be combined is by
defining a "pivot". A pivot is a particular attribute (either
characteristic or status) of a service that is used as the selector.
All of the services in the raw presence document for whom the pivot
attribute has the same value, are all combined together, and the
resulting service will clearly have that value for that particular
pivot attribute. If the raw presence document has three distinct
values for the pivot attribute, the presence document, after
combination, will have three services.
For example, if the video prescaps [13] attribute is used as the
pivot, then all services that support video will be combined, and all
of those that don't will be combined. The resulting presence
document after mergin will have two services - one with a
characteristic of video, and one with a characteristic of no-video.
Combining service URIs is more complicated. If the service URIs are
GRUUs within the same AOR, they can easily be combined by using the
AOR as the result of the combination function. Indeed, even if the
presence server is not combining multiple services together, it might
make sense to change the GRUU to the AOR in the presence document
delivered to a watcher. If the service URIs are SIP URIs but are not
GRUUs, the presence server may need to create a URI which represents
the collection of services. Requests made to that URI could fork to
the set of services that were combined together. If the service URIs
are not even the same URI scheme, for example, a mailto and a tel
URI, there is little that can be done. In such a case, the <contact>
URI should be removed from the document. There are some cases where
URIs with distinct URI schemes can be combined. For example, if one
service has a tel URI, and the other has a SIP URI, a combined
service can be represented by a SIP URI generated by the presence
server. If the watcher generates a request towards this SIP URI, the
proxy server could fork the request to the original tel URI and the
original SIP URI. This works in this specific case (sip and tel URI
combination) because SIP requests can sensibly be directed to a tel
URI. These cases aside, it is generally not a good idea to combine
services together that have radically different URIs.
Rosenberg Expires January 7, 2005 [Page 21]
Internet-Draft Presence Data Model July 2004
The merging operation takes place for devices identically to the way
it takes place for services. Fortunately, combining of device IDs is
a bit less complicated than combining service URIs. The server can
manufacture new device IDs that represent a "virtual" device that
represents a collection of other devices.
It is perfectly valid for the merging operation to eliminate all
services from the final document, or all devices from the final
document. A presence document that includes only presentity
information is referred to as a "presentity view". A presence
document that includes only service information is referred to as a
"service view". A presence document that includes only device
information is called a "device view". [[NOTE: Do we want to allow
reduction to throw away all services? The presentity? Do we need at
least one of each??]].
7.2.4 Splitting
Splitting is the process of taking a single service or device data
element, and splitting into two services or devices. This is useful
when the presence server or presence user agent wishes to model a
complex application (such as a voice, video and IM enabled client) by
a multiplicity of distinct services.
The process of splitting involves taking the attributes (both status
and characteristics) for the service, and determine which of the
component services that attribute will describe. In some cases, a
single attribute will be split so that it is present in both
components. For example, if the composite service has an idle
indication, meaning that the service has not been used in some time,
the component services would both inherit the same value for the idle
indicator. In other cases, an attribute gets assigned only to one
service, or in other cases, its value is changed as it is split up.
The way in which this is done is a matter of local policy.
In all cases, it is important to remember that the purpose of having
multiple services or devices described in a document is to give the
watcher choice about what service to use. Therefore, the splitting
operation should result in multiple services that have sufficient
characteristics associated with them to differentiate them to a
watcher.
Splitting of a service URI is a relatively simple operation. The
entity performing the split creates two new service URIs, each of
which, should a request be received for that URI, would get
translated to, or routed to, the composite service URI. If a
presence user agent is performing the split, it can use the grid
parameter of the GRUU to manufacture an infinite supply of URIs that
Rosenberg Expires January 7, 2005 [Page 22]
Internet-Draft Presence Data Model July 2004
all get routed to itself. If a presence server is doing the split,
it can manufacture an entirely new URI (in conjunction with the
domain owner, of course) as needed.
When a service is split, there is usually no reason to split the
device as well. The component services all run on the same device,
and there is much benefit to indicating that this is the case. For
example, it would allow a presence server that is compositing the
presence document for the presentity, to determine that all of the
component services are inactive if the device should fail.
7.3 Privacy Filtering
Once the merging operation has been applied, the next step is to
perform privacy filtering. Privacy filtering is a process by which
information is removed or transformed in a raw presence document, for
the purposes of withholding sensitive information that the presentity
does not want a watcher to see. The exact privacy filtering
operation that takes place depends on the identity of the watcher,
and can also depend on other variables, such as time of day, the
weather in Helsinki, and so on.
Authorization policy is expressed using the document format defined
in [7].
7.4 Watcher Filtering
Watcher filtering is the process by which information is further
removed from the presence document. However, it is the watcher which
specifies the information subset that they would like to receive.
Watcher filtering is accomplished by including filter documents in
subscription requests. These filters are then bound to the
subscription, and applied to any presence document generated during
the lifetime of that subscription.
Filters are described using the document format defined in [14].
7.5 Post-Processing Composition
After the privacy and watcher filtering operations have been applied,
the resulting presence document may contain service or device
elements which no longer contain enough information to differentiate
one from another. As discussed above, the purpose of having multiple
services or devices described in a document is to give the watcher
choice about which service to invoke. If the services defined in a
document all appear the same, differing only in the service URI,
there is no reason for a user to choose one over another. In such a
case, composition rules, and in particular, merging of services, will
Rosenberg Expires January 7, 2005 [Page 23]
Internet-Draft Presence Data Model July 2004
need to be done. The result is the final presence document that can
be delivered to watchers.
8. 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 presentity, service or device
data elements? 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 element
it should be applied.
2. Is this new attribute a dynamic status, or a static
characteristic? Characteristics are information that describe
information about devices that help provide context for a
consumer of the document to make a decision about whether
communications is desired in one place or another. They are
therefore descriptive in nature.
9. Example Presence Documents
In this section, we give examples of different physical systems,
present the model of that system using the concepts described here,
and then show the resulting presence document.
Some of the examples and content in this section are lifted from [4].
9.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 them 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 - such as 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, their 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.
Rosenberg Expires January 7, 2005 [Page 24]
Internet-Draft Presence Data Model July 2004
However, if an IM is sent to them, it will still be delivered.
This system is modeled by representing each client in the system with
three data elements - a presentity element, a service element, and a
device element. The presentity elements describes the state of the
user, including the note and the pre-defined status messages. These
represent information about the user, so they are included in the
presentity element. The service tuple represents the IM service. No
characteristics are included. The service URI published by the
client is set to the client's GRUU. The device element is used to
model the PC. The device element includes the idle indicator, since
the idleness refers to usage of the *device*, not the service.
Inclusion of the idle indicator in a service tuple is permitted, but
would imply something different - that the user hasnt used the
service (i.e., has not used their IM client) in some time.
The document published by the client would look like this:
Rosenberg Expires January 7, 2005 [Page 25]
Internet-Draft Presence Data Model July 2004
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<tuple-type>service</tuple-type>
<device-id>mac:8asd7d7d70</device-id>
<prescaps>
<methods>
<method>MESSAGE</method>
<method>OPTIONS</method>
</methods>
</prescaps>
<status>
<basic>open</basic>
</status>
<contact>sip:gruu-someone-1@example.com</contact>
</tuple>
<tuple id="sg89af">
<tuple-type>presentity</tuple-type>
<status>
<activities>
<activity>on-the-phone</activity>
</activities>
</status>
</tuple>
<tuple id="sg89ag">
<tuple-type>device</tuple-type>
<device-id>mac:8asd7d7d70</device-id>
<status>
<idle/>
</status>
</tuple>
</presence>
It is worth commenting further on the value of having a separate
device element just to convey the idle indicator. As described
above, 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 say there is a voip
application running on the same device. This application reports its
presence information using the example below. Since it reports 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 their 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
Rosenberg Expires January 7, 2005 [Page 26]
Internet-Draft Presence Data Model July 2004
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.
9.2 VoIP Application
In this example, consider a SIP network. The user has a SIP AOR of
sip:user@example.com. The user has a single SIP PC client that they
run on their office machine. This is a simple SIP softphone,
supporting audio only.
The PC client publishes a presence document that has a single tuple,
representing the service. It does not include any presentity or
device elements, although it does include a device-id as part of its
service characteristics.
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"
entity="sip:user@example.com">
<tuple id="sg89ae">
<tuple-type>service</tuple-type>
<device-id>urn:mac:8asd7d7d70</device-id>
<prescaps>
<methods>
<method>INVITE</method>
<method>OPTIONS</method>
<method>BYE</method>
<method>ACK</method>
<method>CANCEL</method>
</methods>
<audio/>
</prescaps>
<status>
<basic>open</basic>
Rosenberg Expires January 7, 2005 [Page 27]
Internet-Draft Presence Data Model July 2004
</status>
<contact>sip:gruu2@example.com</contact>
</tuple>
</presence>
9.3 Cellphone
In this example, the user has a cellphone. This cellphone has an SMS
client and a SIP push-to-talk client running. The phone also has a
switch that allows the user to select "silent mode". This
information is also used by the phone as an indicator of business.
As it turns out, the SMS and PTT applications on the phone are
totally separate, and each publishes its own information. Indeed,
both happen to publish information about the silent mode switch.
The SMS application models itself with three elements - a service
element, representing the actual SMS service, a device element,
modeling the phone, and a presentity element, modeling the user.
Similarly, the PTT app has three elements, representing the PTT
service, device, and presentity.
If the user is in a PTT call, the PTT application might generate a
document that looks like this. Note the inclusion of the busy
element as part of the presentity state, which was set based on the
silent switch:
Rosenberg Expires January 7, 2005 [Page 28]
Internet-Draft Presence Data Model July 2004
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<tuple-type>service</tuple-type>
<device-id>urn:esn:600b40c7</device-id>
<prescaps>
<methods>
<method>INVITE</method>
<method>OPTIONS</method>
<method>BYE</method>
<method>ACK</method>
<method>CANCEL</method>
</methods>
<audio/>
<duplex>half</duplex>
</prescaps>
<status>
<basic>closed</basic>
</status>
<contact>sip:gruu-aa@example.com</contact>
</tuple>
<tuple id="sg89af">
<tuple-type>presentity</tuple-type>
<status>
<activities>
<activity>on-the-phone</activity>
<activity>busy</activity>
</activities>
</status>
</tuple>
<tuple id="sg89ag">
<tuple-type>device</tuple-type>
<device-id>urn:esn:600b40c7</device-id>
<prescaps>
<mobility>mobile</mobility>
</prescaps>
</tuple>
</presence>
The SMS application would publish a document that looks like this:
Rosenberg Expires January 7, 2005 [Page 29]
Internet-Draft Presence Data Model July 2004
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<tuple-type>service</tuple-type>
<device-id>urn:esn:600b40c7</device-id>
<status>
<basic>open</basic>
</status>
<contact>sms:1234567</contact>
</tuple>
<tuple id="sg89af">
<tuple-type>presentity</tuple-type>
<status>
<activities>
<activity>busy</activity>
<activity>on-the-phone</activity>
</activities>
</status>
</tuple>
<tuple id="sg89ag">
<tuple-type>device</tuple-type>
<device-id>urn:esn:600b40c7</device-id>
</tuple>
</presence>
The presence server now has two presence documents for a single user.
It has conflicting information for the presentity and device
elements. It knows it has two services, both of which run on the
same device. It merges the two devices into one, and unions the
information it has for them. It keeps the services as separate, but
changes the PTT URI from the GRUU to the AOR. It merges the
presentity information together, unioning that as well. The
resulting raw presence document, after composition, would look like:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<tuple-type>service</tuple-type>
<device-id>urn:esn:600b40c7</device-id>
<status>
<basic>open</basic>
</status>
Rosenberg Expires January 7, 2005 [Page 30]
Internet-Draft Presence Data Model July 2004
<contact>sms:1234567</contact>
</tuple>
<tuple id="sg89ae">
<tuple-type>service</tuple-type>
<device-id>urn:esn:600b40c7</device-id>
<prescaps>
<methods>
<method>INVITE</method>
<method>OPTIONS</method>
<method>BYE</method>
<method>ACK</method>
<method>CANCEL</method>
</methods>
<audio/>
<duplex>half</duplex>
</prescaps>
<status>
<basic>closed</basic>
</status>
<contact>sip:someone@example.com</contact>
</tuple>
<tuple id="sg89af">
<tuple-type>presentity</tuple-type>
<status>
<activities>
<activity>busy</activity>
</activities>
</status>
</tuple>
<tuple id="sg89ag">
<tuple-type>device</tuple-type>
<device-id>urn:esn:600b40c7</device-id>
<prescaps>
<mobility>mobile</mobility>
</prescaps>
</tuple>
</presence>
10. Proposed Plan of Action
The proposal is to accept this basic model as the presence data model
that is the basis for the various working items in the SIMPLE group
that relate to presence document management. If such a proposal is
accepted, the following plan of action is proposed:
o Accept this document as a working item of the SIMPLE group,
targeted for informational.
Rosenberg Expires January 7, 2005 [Page 31]
Internet-Draft Presence Data Model July 2004
o Add a reference from RPID and the other documents to this
document. Note that this is an informative reference. RPID,
CIPID [16] and the other work can proceed quickly after some of
the relatively minor modifications defined below.
o Include the few normative statements in this document into RPID
(namely, around how many tuples of each type need to be in a
presence document)
o Add the device-id element to RPID. Specify that it is a URN.
Specify that, if the URN scheme is known, functional equality is
used. If unknown, lexical equality. This gives us the ability to
define URN formats for things like MAC addresses and ESNs later
(see below).
o Change the contact-type element in RPID to tuple-type, identify
its values as device, service and presentity, and include a
reference to this document for more information on it.
o Change the existing attributes in RPID in the following ways: The
activity element becomes applicable only to presentity tuples.
Class can continue as defined. Idle becomes applicable to a
service or device, but has very different meanings for the two.
Clarify that. The placetype element becomes applicable to
presentity and devices only. There are different meanings for the
two. Clarify that. Specify that the privacy element is specific
to services. Relationship is applicable to services and devices;
it specifies that the service or device is "owned" by someone
other than the presentity. Specify that sphere is only applicable
to the presentity. In all cases, clarify which attributes are
status, and which are characteristics. The schema already
appropriately models the split.
o Change prescaps in the following way. All of the information
currently listed are characteristics, and thus belong as direct
children of the tuple element, not status. Make this change.
Specify that all of the prescaps elements are service
characteristics, with the exception of class and mobility, which
are device characteristics. Actor is tricky, but I believe its a
service or device characteristic - it indicates whether the
service or device connects to thepresentity, or whether its
something else. Closely related to the relationship element in
RPID, which effectively identifies the thing described by the
actor. Also, add a reference to this document as informational.
o Change CIPID to clearly indicate that all of the information is
presentity characteristics. Add a reference to this document as
informational.
o Change timed-status [15] to indicate that it is applicable to
presentities, devices and services. Clarify that it is applicable
only to status information, since that is the only dynamic
information. Add a reference to this document as informational.
o One of the source of confusion around the XCAP manipulation of
PIDF [17] is that it was unclear as to why one would use it as
Rosenberg Expires January 7, 2005 [Page 32]
Internet-Draft Presence Data Model July 2004
opposed to PUBLISH. The presence data model presented here sheds
some light on that. PUBLISH is appropriate for communicating
information about services and devices. PUBLISH is designed for
the model where there can be more than one such source (as there
is for devices and servcies), and where such state is soft-state
(as it should be for devices and services). However, presentity
state is not clearly soft-state, and the model here clearly
indicates that each presence document can have a single presentity
element. Thus, it might make sense to change the
pidf-manipulation spec to only allow setting of presentity tuples.
Now, that doesnt forbid a source from trying to PUBLISH presentity
information, but there is clearly a need for a hard-state approach
for setting presentity information.
o The presence rules specification [7] should be updated to allow
permissions that grant access to services and devices identified
by service URI and device ID respectively.
o Fold in the text from [5] and [4] into this specification.
o Consider a new work item to define some URN formats that would be
appropriate for usage within the device-id. MAC address, ESN are
good examples. There does not appear to be URNs for these types.
11. Security Considerations
The presence information described by the model defined here is very
sensitive. It is for this reason that privacy filtering plays a key
role in the processing of presence data, as described above.
Presence systems based on this model need to provide such a privacy
capability, and furthermore, need to protect the integrity and
confidentiality of the data.
12. Acknowledgements
This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different
participants in the SIMPLE working group. Henning Schulzrinne
initially described the "pivot" operation described above for
composition. Brian Rosen deserves credit for the "presentity view".
Aki Niemi, Paul Kyzivat, Cullen Jennings, Ben Campbell, Robert
Sparks, Dean Willis, Adam Roach, Hisham Khartabil, and Jon Peterson
contributed many of the concepts that are described here. A special
thanks to Steve Donovan for discussions on the topics discussed here.
13 Informative References
[1] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Rosenberg Expires January 7, 2005 [Page 33]
Internet-Draft Presence Data Model July 2004
Package for Registrations", RFC 3680, March 2004.
[3] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[4] Sparks, R., "SIMPLE Presence Document Usage Examples",
draft-sparks-simple-pdoc-usage-00 (work in progress), October
2003.
[5] Roach, A., "Identification of Services in RPID (Rich Presence
Information Data)", draft-roach-simple-service-features-00
(work in progress), February 2004.
[6] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg,
"RPID: Rich Presence: Extensions to the Presence Information
Data Format (PIDF)", draft-ietf-simple-rpid-03 (work in
progress), March 2004.
[7] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-00 (work in progress), May
2004.
[8] Peterson, J., "Common Profile for Presence (CPP)",
draft-ietf-impp-pres-04 (work in progress), October 2003.
[9] Sugano, H. and S. Fujimoto, "Presence Information Data Format
(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
2003.
[10] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-01 (work in progress), February
2004.
[11] Niemi, A., "An Event State Publication Extension to the Session
Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in
progress), May 2004.
[12] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), January 2004.
[13] Lonnfors, M. and K. Kiss, "User agent capability presence
status extension", draft-ietf-simple-prescaps-ext-01 (work in
progress), May 2004.
[14] Khartabil, H., "An Extensible Markup Language (XML) Based
Rosenberg Expires January 7, 2005 [Page 34]
Internet-Draft Presence Data Model July 2004
Format for Event Notification Filtering",
draft-ietf-simple-filter-format-01 (work in progress), June
2004.
[15] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format(PIDF) to Indicate Presence Information
for Past and Future Time Intervals",
draft-ietf-simple-future-01 (work in progress), April 2004.
[16] Schulzrinne, H., "CIPID: Contact Information in Presence
Information Data Format", draft-ietf-simple-cipid-01 (work in
progress), March 2004.
[17] Isomaki, M., "An Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) Usage for Manipulating Presence
Document Contents",
draft-ietf-simple-xcap-pidf-manipulation-usage-01 (work in
progress), June 2004.
Author's Address
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Rosenberg Expires January 7, 2005 [Page 35]
Internet-Draft Presence Data Model July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires January 7, 2005 [Page 36]
| PAFTECH AB 2003-2026 | 2026-04-22 06:48:25 |