can be drawn.

   Because the absence of a presence attribute conveys no information
   whatsoever, presence documents achieve their maximum value when they
   have as many presence attributes as possible.  As such, it is
   RECOMMENDED that a presence document contain as many presence
   attributes as the presentity is willing to and able to provide to a
   watcher.

3.7.  Status vs. Characteristics

   The data model tries to separate status information from
   characteristics, generally by defining status as a relatively dynamic
   state about a person, device, or service, whereas a characteristic is
   relatively static.  However, this distinction is often artificial.
   Almost any characteristic can change over time, and sometimes
   characteristics can change relatively quickly.  As a result, the
   distinction between status and characteristics is merely a conceptual
   one to facilitate understanding about the different types of presence
   information.  Nothing in a presence document indicates whether an
   element is a characteristic vs. a status, and when a presence
   attribute is defined, there is no need for it to be declared one or
   the other.  Presence documents allow any presence attribute, whether
   it can be thought of as a characteristic or a status, to change at
   any time.

   Unfortunately, the original PIDF specification did have a separate
   part of a tuple for describing status, and the basic status was
   defined to exist within that part of the tuple.  This specification
   does not change PIDF; however, all future presence attributes MUST be
   defined as children of the <tuple> and not the <status> element.
   Furthermore, the schemas defined here do not contain a <status>
   element for either the <person> or <device> elements.



Rosenberg                   Standards Track                    [Page 19]

RFC 4479                  Presence Data Model                  July 2006


3.8.  Presence Document Properties

   The overall presence document has several important properties that
   are essential to this model.

   First, a presence document has a concrete meaning independent of how
   it is transported or where it is found.  The semantics of a document
   are the same regardless of whether a document is published by a
   presence user agent to its compositor, or whether it is distributed
   from a presence agent to watchers.  There are no required or implied
   behaviors for a recipient of a document.  Rather, there are well-
   defined semantics for the document itself, and a recipient of a
   document can take whatever actions it chooses based on those
   semantics.

   A corollary of this property is that presence systems are infinitely
   composeable.  A presence user agent can publish a document to its
   presence server.  That presence server can compose it with other
   documents, and place the result in a notification to a watcher.  That
   watcher can actually be another presence agent, combining that
   document with others it has received, and placing those results in
   yet another notify.

   Yet another corollary of this property is that implied behaviors in
   reaction to the document cannot ever be assumed.  For example, just
   because a service indicates that it supports audio does not mean that
   a watcher will offer audio in a communications attempt to that
   service.  If doing so is necessary to reach the service, this must be
   indicated explicitly through reach information.

   It is also important to understand that the role of the presence
   document is to help a user make a choice amongst a set of services,
   and furthermore, to know ahead of time with as much certainty as
   possible whether a communications attempt will succeed or fail.
   Success is a combination of many factors: Does the watcher understand
   the service URI?  Can it act on all of the reach information?  Does
   it support a subset of the capabilities associated with the service?
   Does the person information indicate that the user is likely to
   answer?  All of these checks should ideally be made before attempting
   communication.

   Because the presence document serves to help a user to choose and
   establish communications, the presentity URI - as the index to that
   document - represents a form of "one-number" communications.
   Starting from this URI, all of the communications modalities and
   their URIs for a user can be discovered, and then used to invoke a
   particular communications service.  Rather than having to give out a
   separate phone number, email address, IM address, Voice over Internet



Rosenberg                   Standards Track                    [Page 20]

RFC 4479                  Presence Data Model                  July 2006


   Protocol (VoIP) address, and so on, the presentity URI can be
   provided, and all of the others can be learned from there.

4.  Motivation for the Model

   Presence is defined in [21] as the ability, willingness, or desire to
   communicate across a set of devices.  The core of this definition is
   the conveyance of information about the ability, willingness, or
   desire for communications.  Thus, the presence data model needs to be
   tailored around conveying information that achieves this goal.

   The person data component is targeted at conveying willingness and
   desire for communications.  It is used to represent information about
   the users themselves that affects willingness and desire to
   communicate.  Whether I am in a meeting, whether I am on the phone -
   each of these says something about my willingness to communicate, and
   thus makes sense for inclusion in a presence document.

   The service component of the data model aims to convey information on
   the ability to communicate.  The ability to communicate is defined by
   the services by which a user is reachable.  Thus, including them is
   essential.

   How do devices fit in?  For many users, devices represent the ability
   to communicate, not services.  Frequently, users make statements
   like, "Call me on my cell phone" or "I'm at my desk".  These are
   statements for preference for communications using a specific device,
   as opposed to a service.  Thus, it is our expectation that users will
   want to represent devices as part of the presence data.

   Furthermore, the concept of device adds the ability to correlate
   services together.  The device models the underlying platform that
   supports all of the services on the phone.  Its state therefore
   impacts all services.  For example, if a presence server can
   determine that a cell phone is off, this says something about the
   services that run on that device: they are all not available.  Thus,
   if services include indicators about the devices on which they run,
   device state can be obtained and thus used to compute the state of
   the services on the device.

   The data model tries hard to separate device, service, and person as
   different concepts.  Part of this differentiation is that many
   attributes will be applicable to some of these, but not others.  For
   example, geographic location is a meaningful attribute of the person
   (the user has a location) and of a device (the device has a
   location), but not of a service (services don't inherently have
   locations).  Based on this, geographic location information should
   only appear as part of device or person, never service.  Furthermore,



Rosenberg                   Standards Track                    [Page 21]

RFC 4479                  Presence Data Model                  July 2006


   it is possible and meaningful for location information to be conveyed
   for both device and person, and for these locations to be different.
   The fact that the presence system might try to determine the location
   of the person by extrapolation from the location of one of the
   devices is irrelevant from a data modeling perspective.  Person
   location and device location are not the same thing.

   [25] defines the <geopriv> XML element for conveying location
   information, and indicates that it is carried as a child of the
   <tuple> element in a PIDF document. [25] was developed prior to this
   specification, and unfortunately, its recommendation to include
   location objects underneath <tuple> runs contrary to the
   recommendations here.  As such, implementations based on this
   specification SHOULD include <geopriv> location objects as part of
   person and/or device components of the document, but SHOULD be
   prepared to receive presence documents with that object as a child to
   <tuple>.  A <geopriv> location object would be included in a person
   component when the document means to convey the location of the user,
   and within a device component when it means to convey the location of
   the device.

5.  Encoding

   Information represented according to the data model described above
   needs to be mapped into an on-the-wire format for transport and
   storage.  The Presence Information Data Format [1] is used for
   representation of presence data.

   The <presence> element contains the presence information for the
   presentity.  The "entity" attribute of this element contains the
   presentity URI.

   The existing <tuple> element in the PIDF document is used to
   represent the service.  This is consistent with the original intent
   of RFC 2778 and RFC 3863, and achieves backward compatibility with
   implementations developed before the model described here was
   complete.  The <contact> element in the <tuple> element is used to
   encode the service URI.  New presence attributes, whether they
   represent dynamic status or static characteristics, appear directly
   as children of <tuple>.  However, attributes defined prior to
   publication of this specification that were defined as children of
   <status> (such as <basic>) remain as children of <status>, for
   purposes of backward compatibility.  Consequently, a presence
   attribute describing a service could appear as either a child of
   <status> or directly as a child of <tuple>, but never both.






Rosenberg                   Standards Track                    [Page 22]

RFC 4479                  Presence Data Model                  July 2006


   The "id" attribute of the <tuple> element conveys the service
   occurrence.  Each <tuple> element with the same <contact> URI
   represents a different occurrence of a particular service.

   This specification introduces the <person> element, which can appear
   as a child to <presence>.  There can be zero or more occurrences of
   this element per document.  Each one has a mandatory "id" attribute,
   which contains the occurrence identifier for the person.  Each
   <person> element contains any number of elements that indicate status
   and characteristic information.  This is followed by zero or more
   optional <note> elements and an optional <timestamp>.  Multiple
   <note> elements would appear to convey the same note in multiple
   languages.

   RFC 3863 defines a <note> element, zero or more of which can be
   present as a child to <presence>.  As it relates to the model defined
   here, these note elements, if present in a document, apply to all
   person occurrences that do not have any of their own <note> elements.
   In other words, if a <person> element has one or more <note>
   elements, those are the <note> elements for that <person> element.
   If a <person> element does not have any of its own <note> elements,
   the <note> elements that are the direct children of <presence> are
   the <note> elements for that <person>.  If there are no <note>
   elements underneath the <person> element, and there are no <note>
   elements that are a direct child of <presence>, then that <person>
   element has no <note> elements.

   This specification also introduces the <device> element, which can
   appear as a child to <presence>.  There can be zero or more
   occurrences of this element per document.  The <device> element can
   appear either before or after the <person> element; there are no
   constraints on order.  Each <device> element has a mandatory "id"
   attribute, which contains the occurrence identifier for the device.
   Like <person>, <device> contains any number of elements that indicate
   status and characteristic information.  This is followed by
   <deviceID>, which contains the URN for the device ID for this device.
   This is followed by zero or more optional <note> elements and an
   optional <timestamp>.  Multiple <note> elements would appear to
   convey the same note in multiple languages.

   A client that receives a PIDF document containing the <device> and
   <person> elements, but does not understand them (because it doesn't
   implement this specification), will ignore them.  Furthermore, since
   the semantics of service as defined here are aligned with the meaning
   of a tuple as defined in RFC 2778 and RFC 3863, documents
   incorporating the concepts defined in this model are compliant with
   older implementa