[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/