XCAP-Client
view release on metacpan or search on metacpan
docs/rfcs/rfc4479.html view on Meta::CPAN
a watcher cannot make any definitive statement about the value for
that presence attribute. It may be absent because it is being
withheld from the watcher, or it may be absent because that attribute
is not supported by the presentity's software. Neither conclusion
can be drawn.
Because the absence of a presence attribute conveys no information
whatsoever, presence documents achieve their maximum value when they
have as many presence attributes as possible. As such, it is
RECOMMENDED that a presence document contain as many presence
attributes as the presentity is willing to and able to provide to a
watcher.
<span class="h3"><h3><a name="section-3.7">3.7</a>. Status vs. Characteristics</h3></span>
The data model tries to separate status information from
characteristics, generally by defining status as a relatively dynamic
state about a person, device, or service, whereas a characteristic is
relatively static. However, this distinction is often artificial.
Almost any characteristic can change over time, and sometimes
characteristics can change relatively quickly. As a result, the
distinction between status and characteristics is merely a conceptual
one to facilitate understanding about the different types of presence
information. Nothing in a presence document indicates whether an
element is a characteristic vs. a status, and when a presence
attribute is defined, there is no need for it to be declared one or
the other. Presence documents allow any presence attribute, whether
it can be thought of as a characteristic or a status, to change at
any time.
Unfortunately, the original PIDF specification did have a separate
part of a tuple for describing status, and the basic status was
defined to exist within that part of the tuple. This specification
does not change PIDF; however, all future presence attributes MUST be
defined as children of the <tuple> and not the <status> element.
Furthermore, the schemas defined here do not contain a <status>
element for either the <person> or <device> elements.
<span class="grey">Rosenberg Standards Track [Page 19]</span>
</pre><pre class="newpage"><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc4479">RFC 4479</a> Presence Data Model July 2006</span>
<span class="h3"><h3><a name="section-3.8">3.8</a>. Presence Document Properties</h3></span>
The overall presence document has several important properties that
are essential to this model.
First, a presence document has a concrete meaning independent of how
it is transported or where it is found. The semantics of a document
are the same regardless of whether a document is published by a
presence user agent to its compositor, or whether it is distributed
from a presence agent to watchers. There are no required or implied
behaviors for a recipient of a document. Rather, there are well-
defined semantics for the document itself, and a recipient of a
document can take whatever actions it chooses based on those
semantics.
A corollary of this property is that presence systems are infinitely
composeable. A presence user agent can publish a document to its
presence server. That presence server can compose it with other
documents, and place the result in a notification to a watcher. That
watcher can actually be another presence agent, combining that
document with others it has received, and placing those results in
yet another notify.
Yet another corollary of this property is that implied behaviors in
reaction to the document cannot ever be assumed. For example, just
because a service indicates that it supports audio does not mean that
a watcher will offer audio in a communications attempt to that
service. If doing so is necessary to reach the service, this must be
indicated explicitly through reach information.
It is also important to understand that the role of the presence
document is to help a user make a choice amongst a set of services,
and furthermore, to know ahead of time with as much certainty as
possible whether a communications attempt will succeed or fail.
Success is a combination of many factors: Does the watcher understand
the service URI? Can it act on all of the reach information? Does
it support a subset of the capabilities associated with the service?
Does the person information indicate that the user is likely to
answer? All of these checks should ideally be made before attempting
communication.
Because the presence document serves to help a user to choose and
establish communications, the presentity URI - as the index to that
document - represents a form of "one-number" communications.
Starting from this URI, all of the communications modalities and
their URIs for a user can be discovered, and then used to invoke a
particular communications service. Rather than having to give out a
separate phone number, email address, IM address, Voice over Internet
<span class="grey">Rosenberg Standards Track [Page 20]</span>
</pre><pre class="newpage"><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc4479">RFC 4479</a> Presence Data Model July 2006</span>
Protocol (VoIP) address, and so on, the presentity URI can be
provided, and all of the others can be learned from there.
<span class="h2"><h2><a name="section-4">4</a>. Motivation for the Model</h2></span>
Presence is defined in [<a href="#ref-21" title=""A Presence Event Package for the Session Initiation Protocol (SIP)"">21</a>] as the ability, willingness, or desire to
communicate across a set of devices. The core of this definition is
the conveyance of information about the ability, willingness, or
desire for communications. Thus, the presence data model needs to be
tailored around conveying information that achieves this goal.
The person data component is targeted at conveying willingness and
desire for communications. It is used to represent information about
the users themselves that affects willingness and desire to
communicate. Whether I am in a meeting, whether I am on the phone -
each of these says something about my willingness to communicate, and
thus makes sense for inclusion in a presence document.
The service component of the data model aims to convey information on
the ability to communicate. The ability to communicate is defined by
the services by which a user is reachable. Thus, including them is
essential.
How do devices fit in? For many users, devices represent the ability
to communicate, not services. Frequently, users make statements
like, "Call me on my cell phone" or "I'm at my desk". These are
statements for preference for communications using a specific device,
as opposed to a service. Thus, it is our expectation that users will
( run in 0.527 second using v1.01-cache-2.11-cpan-df04353d9ac )