watcher make a decision, the presence document includes
characteristics of each service that help differentiate the services
from each other and give the watcher the context in which to make a
choice.
Because their purpose is primarily to facilitate choice, capabilities
do not impose a requirement on the way in which a user reaches that
service. For example, if a presence document includes two services,
and one supports audio only while the other supports only video, this
does not mean that, when contacting the first service, a user has to
offer only an audio stream, or when contacting the second service, a
user has to offer only a video stream. A user can use local policy
at its discretion in determining what capabilities or communications
modalities are offered when they choose to connect with a service.
It is not necessary for a watcher to add SIP caller preferences [2]
to request routing of the request to a service with the
characteristics described in the presence document.
If, in order to reach a service, the user agent must generate a
request that exhibits a particular capability or contains a specific
header, then this is indicated separately in the reach information,
described below.
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
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.
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 watcher. 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.
3.3.2. Reach Information
The reach information for a service provides the instructions for the
recipient of a document on how to correctly contact that service.
When a service is accessible over a communications network, reach
information includes a URI that can be "hit" to access the service.
This URI is called the service URI. 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.
Even for services reachable over a communications network, the URI
alone may not be sufficient. For example, two applications may be
running within a cellular telephone, both of which are reachable
through the user’s SIP Address of Record. However, one application
is launched when the INVITE request contains a body of a particular
type, and the other is launched for other body types. As another
example, a service may provide complex application logic that
operates correctly only when contacted from matching application
software. In such a case, even though the communications between
instances utilizes a standard protocol (such as SIP), the user
experience will not be correct unless the applications are matched.
When the URI is not sufficient, additional attributes of the service
can be present that define the instructions on how the service is to
be reached. These attributes must be understood for the service to
be utilized. If a watcher receives a presence document containing
reach information it does not understand, it should discard the
service information.
The reach information 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 utilizes the reach information for that
service. For this reason, each service has to have a unique set of
reach information. If this was not the case, the user would have no
way to choose between the services. This means that the reach
information represents a unique identifier for the service. However,
a presence document can contain multiple occurrences of a particular
service, each of which contains the same reach information, but
differs in its occurrence identifier. Multiple occurrences of a
service exist in a document when the state of the service is
ambiguous, as discussed in Section 3.5.
Because the reach information serves as an identifier for a service,
it also serves as a way to figure out whether a communications
capability should be represented as one service or more. Something
cannot be a service unless there is a way to reach it separately from
another service. As an example, consider a softphone application
that is capable of audio and video. It is not possible to describe
this softphone as two services - one capable of just audio, and one
capable of just video. That’s because there is no way to reach the
video-only service; for example, sending a SIP INVITE with just a
video stream doesn’t suffice, since one can always add the audio
stream later and it will work. Video and audio, in this case,
represent capabilities for a single service.
The reach information represents a weak form of contract; the
presentity tells the watcher that, if the watcher utilizes the reach
information 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.
First, 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. Second, 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.
This loose contract also provides some guidance on the type of URI
that is most ideally suited for the service URI. A URN [3] can be
used as the service URI. However, since a URN could be resolved to
potentially any number of different URIs, the characteristics,
status, and relative information need to be sensible for all of the
URIs that can be resolved from the URN. As the URN becomes
increasingly "vague" in terms of the service it identifies, the
number of presence attributes that can be included decreases
correspondingly.
The tel URI [11] shares similar properties with a URN, and the same
considerations apply. If, for example, the telephone number exists
in ENUM [18] and multiple ENUM services are defined, including voice
and messaging, it is likely that very little characteristic
information can be included in that service. If, however, a tel URI
has only a single ENUM service defined, and it refers to a telephone
service on the Public Switched Telephone Network (PSTN), more can be
said about its characteristics, status, and relative priority.
It is important to point out that there can be a many-to-one mapping
of reach information to a service. That is, a particular service can
potentially be reachable through an infinite number of reach
information sets. This is true even if the reach information is just
the service URI; it is permissible for multiple service URIs to reach
the same service. Within any particular document, for a particular
service, there will be a single service URI. However, it is allowed
and even valuable to provide different service URIs to different
watchers, or to change the service URIs provided to a particular
watcher over time. Doing so affords many benefits, in fact. It can
allow the recipient of a communications attempt to determine the
context for that attempt - that the attempt was made as a result of
trying to reach a particular service in a particular presence
document. This can be used as a technique for preventing
communications spam, for example [19].
It is also possible for a presence document to contain a service that
has no reach information at all. In such a case, the presentity is
indicating that the service exists, but is electing not to offer the
watcher the opportunity to connect to it. One such example would be
to let a watcher know that a user has a telephony service, and that
they are busy, but in order to avoid receipt of a call, no reach
information is provided.
In an ideal system, the URI alone would represent sufficient reach
information for each service. A URI is supposed to provide
sufficient context for reaching the resource associated with the URI,
and thus in theory there is no need for additional context. However,
sometimes, additional information is needed. Since the reach
information has to be understood in order for the service to be
utilized, reach information beyond the URI should be defined and used
sparingly. Extensions to PIDF that define attributes that are reach
information should clearly call those attributes out as such.
3.3.3. Relative Information
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
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.
3.3.4. Status
Each service also has a status. Status represents generally dynamic
information about the availability of communications using that
service. This is in contrast 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. It can have
values of either "closed" or "open". "Closed" means that
communication to the service will, in all likelihood, fail, will not
reach the intended party, or will not result in communications as
described by the characteristics of the service. As an example, if a
call is forwarded to voicemail if the user is busy or unavailable,
the service is marked as "closed". Similarly, a presentity may
include a hotel phone number as a service URI. After checkout, the
phone number will still ring, but reach the chambermaid or the next
guest. Thus, it would be declared "closed" by that presentity. As
another example, if a user has a SIP URI as their service URI that
points to a SIP softphone application, and the PC shuts down, calls
to that SIP URI will return a 480 response code. This service would
also be declared "closed". "Open" implies the opposite - that
communications to this service will likely succeed and reach the
desired target.
It is also possible to have status information that is dependent on
the characteristics of the communications session that eventually
gets set up. For example, a status attribute can be defined that
indicates that a softphone service is available if instant messaging
is used, but unavailable if audio is used.
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 dynamic 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 it is 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. The
statuses in this service include whether 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 data component of a presence document. Information
is included only when it has a bearing on helping the watcher decide
whether to initiate communications with that service, or helping the
watcher decide when to initiate it, if not now. As an example,
whether a cell phone has strong signal strength or just good signal
strength does not pass the litmus test. Knowing this is not likely
to have an impact on a decision to use this service.
3.4. Device
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.
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.
Furthermore, a single device can support no services. In such a
case, the device has no useful presence information by itself.
However, when composed with other documents that describe this same
device in relation to a service, a richer presence document can be
created. For example, consider a Radio Frequency ID (RFID) tag as a
device. This device does not execute any services. However, as a
device, it has properties, such as location, and it may have network
connectivity with which it can report its status and characteristics.
If a video telephone were to report that it was running a video
service, and one of its properties was that it was tagged with that
RFID, a compositor could combine the two documents together, and use
the location of the RFID to say something about the location of the
video telephony device.
Devices are identified with a device ID. A device ID is a URI that
is a globally and temporally unique identifier for the device. In
particular, a device ID is a URN. The URN has to be unique across
all other devices for a particular presentity. However, it is also
highly desirable that it be persistent across time, globally unique,
and computable in a fashion so that different systems are likely to
refer to the device using the same ID. With these properties,
differing sources of presence information based on device status can
be combined. The last of these three properties - readily computable
- is particularly useful. It allows for a compositor to combine
disparate sources of information about a device, all linked by a
common device ID that each source has independently used to identify
the device in question.
Unfortunately, due to the variety of different devices in existence,
it is difficult for a single URN scheme to be used that will have
these properties. It is anticipated that multiple schemes will be
defined, with different ones appropriate for different types of
devices. For cellular telephones, the Electronic Serial Number
(ESN), for example, is a good identifier. For IP devices, the MAC
address is another good one. The MAC address has the property of
being readily computable, but lacks persistence across time (it would
change if the interface card on a device were to change). In any
case, neither of these are associated with URN schemes at this time.
In the interim, the Universally Unique IDentifier (UUID) URN [20] can
be used. For devices with a MAC address, version 1 UUIDs are
RECOMMENDED, as they result in a time-based identifier that makes use
of the MAC address. For devices without a MAC, a version 4 UUID is
RECOMMENDED. This is a purely random identifier, providing
uniqueness. The UUID for a device would typically be chosen at the
time of fabrication in the device, and then persisted in the device
within flash or some other kind of non-volatile storage. The UUID
URN has the properties of being globally and temporally unique, but
because of its random component, it is not at all readily computable,
and therefore useless as a correlation ID with other presence sources
on a network. It is anticipated that future specifications will be
developed that provide additional, superior device IDs.
Though each device is identified by a unique device ID, there can be
multiple occurrences of a particular device represented in a
document. Each one will share the same device ID, but differ in its
occurrence identifier. Multiple occurrences of a device exist in a
document when the state of the device is ambiguous, as discussed in
Section 3.5.
Though this document does not mandate a particular implementation
approach, the device ID is most useful when all of the services on
the device have a way to obtain the device ID and get the same value
for it. This would argue for its placement as an operating system
feature. Operating system developers interested in implementing this
specification are encouraged to provide APIs that allow applications
to obtain the device ID. Absent such APIs, applications that report
presence information about their devices will have to generate their
own device IDs. This leads to the possibility that the applications
may choose different device IDs, using different algorithms or data.
In the worst case, these may mean that two services that run on the
same device, do not appear to.
Like services and person data components, device data components have
generally static characteristics and generally 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 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.
The characteristics and status information reported about a device
are for the purposes of choice - to allow the user to choose the
service based on knowledge of what the device is. The device
characteristics and status cannot, in any reliable way, be used to
extract information about the nature of the service that will be
received on the device. For example, if the device characteristics
include the speed of the CPU, and the speed is sufficient to support
high-quality video compression, this cannot be interpreted to mean
that video quality would be good for a video service on that device.
Other constraints on the system may reduce the amount of CPU
available to that service. If there is a desire to indicate that
higher-quality video is available on a device, that should be done by
including service characteristics that say just that. The speed of
the CPU might be useful in helping the watcher differentiate between
a device that is a PC and one that is a cell phone, in the case where
the watcher wishes to call the user’s cell phone.
Similarly, if there is dynamic device status (such as whether the
device is on or off), and this state impacts the state of the
service, this is represented by adjusting the state of the service.
Unless a consumer of a presence document has a priori knowledge
indicating otherwise (note that presence agents often do), the state
of a device has no bearing on the state of the service.
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* of 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
acceptable to use this model to talk about that PC as being composed
of two separate devices.
3.5. Modeling Ambiguity
Ambiguity is a reality of a presence system, and it is explicitly
modeled by this specification. Ambiguity exists when there are
multiple pieces of information about a person, a particular device,
or a particular service. This ambiguity naturally arises when
multiple elements publish information about the person, a particular
service, or a particular device. In some cases, a compositor can
resolve the ambiguity in an automated way, and combine the data about
the person, device, or service into a single coherent description.
In other cases, it cannot, perhaps because the compositor lacks the
ability to do so.
However, in many cases, the resolution of this ambiguity is best left
to the watcher that consumes the document. This consumer could be an
application with more information than the compositor, and thus be
able to do a better job of resolving the ambiguity. Or, it may be
presented to the human user, and the human can often resolve the
ambiguity. Unsurprisingly, a human can often do this far better than
an automaton can.
To model ambiguity, the model allows each service, each device, or
the person component to contain multiple occurrences. Each
occurrence has a unique identifier, called the occurrence identifier.
This identifier is unique across all other occurrence identifiers for
any service, device, or person. That is, its uniqueness is scoped
within all of the services, devices, and person elements for a
particular presentity. The identifier ideally persists over time,
since it serves as a valuable handle for setting composition and
authorization policies. Even if there is a single occurrence for a
particular device, service, or person, the occurrence has an
occurrence identifier.
The occurrence identifier is not to be confused with the instance ID
defined in the SIP Outbound specification [27]. A user agent
instance is best modeled as a service, and indeed, a Globally
Routable User Agent URI (GRUU) [22], which is derived from the
instance ID, represents a reasonable choice for a service URI.
However, if the status of such a UA instance could not be determined
unambiguously, a presence document could include two or more
occurrences of the service modeling that UA instance. In such a
case, each occurrence has a unique occurrence ID, but they share the
same service URI, and consequently, the same instance ID.
When multiple occurrences exist in a document, it is important that
some of the attributes of the device, service, or person help the
recipient resolve the ambiguity. For humans, the note field and
timestamp serve as valuable tools. For an automaton, nearly any
attribute of the device, service, or person can be used to resolve