rfc4479 a data model for presence.txt

有关IMS SIP及Presence应用的RFC文档包

   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.






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


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



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


   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.



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


   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.



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


   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
   the ambiguity.  The timestamp in particular is very useful for both
   humans and automatons.  As described in RFC 3863 [1], the timestamp
   provides the time of most recent change for the tuple.  This
   specification defines the timestamp for person and device components
   as well, with the same meaning.  Absent other information, the
   person, device, or service that most recently changed can be used as
   the more reliable source of data.  However, such a resolution
   algorithm is not normatively required in any way.




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


3.6.  The Meaning of Nothing

   It is clear that the existence of a presence attribute in a document
   tells something to a watcher about the value of that presence
   attribute.  However, what does the absence of a presence attribute
   say?  This data model follows the lead of RFC 3840 [17], which is
   used to define capabilities for SIP user agents.  In that
   specification, if a capability declaration omits a particular feature
   tag, it means that the agent is making no definitive statement either
   way about whether this feature tag is supported.  The same is true
   here - the absence of a presence attribute from a document means that
   a watcher cannot make any definitive statement about the value for
   that presence attribute.  It may be absent because it is being
   withheld from the watcher, or it may be absent because that attribute
   is not supported by the presentity's software.  Neither conclusion