rfc4479 a data model for presence.txt

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

    |               \          /           \                         |
    |                V        V             V                        |
    |          +----------------+        +----------------+          |
    |         +----------------+|       +----------------+|          |
    |         |                ||       |                ||          |
    |         |                ||       |                ||          |
    |         |    Device      ||       |    Device      ||          |
    |         |                ||       |                ||          |
    |         |                |+       |                |+          |
    |         +----------------+        +----------------+           |
    |                                                                |
    |                                                                |
    | Presentity (URI)                                               |
    +----------------------------------------------------------------+

                                 Figure 1







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


   The data model for presence is shown in Figure 1.  The model seeks to
   describe the presentity, identified by a presentity URI.  There are
   three components in the model: the person, the service, and the
   device.  These three data components contain information (called
   attributes) that provide a description of some aspect of the service,
   person, or device.  It is central to this model that each attribute
   is affiliated with the service, person, or device because they
   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 an attribute as
   part of the person information, indicating a status of
   "in-a-meeting".  The presence information may also include
   information on the cell phone as a device.  However, even though it
   is the device that is reporting that the user is in a meeting, "in a
   meeting" is a fact that describes the human user, not their physical
   device.  Consequently, this attribute is placed in the person
   component of the document.

3.1.  Presentity URI

   The identifier for the presentity is a URI.  For each unique
   presentity in the network, there is one or more presentity URIs.  A
   presentity may have multiple URIs because they are identified by both
   a URI from the Presence (pres) scheme [12] and a protocol-specific
   URI, such as a SIP URI [11] or an Extensible Messaging and Presence
   Protocol Internationalized Resource Identifier (XMPP IRI) [13].  Or,
   it can be because a user has several aliases in a domain, all of
   which are equivalent identifiers for the presentity.

   When a document is constructed, the presentity URI is ideally set to
   the identifier used to request the document in the first place.  For
   example, if a document was requested through a SIP SUBSCRIBE request,
   the presentity URI would match the Request URI of the SUBSCRIBE
   request.  This follows the principle of least surprise, since the
   entity requesting the document may not be aware of the other
   identifiers for the presentity.

   Irrespective of the scheme from which the URI is taken, the
   presentity URI is independent of any of the services or devices that
   the presentity possesses.  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.  When the URI is a SIP URI, it will often be
   the Address of Record for the user, to which SIP calls can be
   directed.  This equivalence is not mandated by this specification,
   but is a recommended configuration for easing the burden of
   remembering and storing identifiers for users.



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


3.2.  Person

   The person data component models information about the user whom the
   presence data is trying to describe.  This information consists of
   characteristics of the user, and their status.

   Characteristics of a person 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.
   Another example of a person characteristic is an alias.  An alias is
   a URI that identities the same user, but with a different presentity
   URI.  For example, a presentity "sip:[e-mail]" might have a
   presence document with a person component that indicates an alias of
   "sip:[e-mail]" and "sip:[e-mail]".

   Status information about a presentity represents the dynamic
   information about a user.  This typically consists of things the
   *user* is doing, places the *user* is at, feelings the *user* has,
   and so on.  Examples of typical person status are "in a meeting", "on
   the phone", "out to lunch", "happy", and "writing Internet Drafts".
   The line between static status information and dynamic status
   information is fuzzy, and it is not important that a line be drawn.
   The model does not differentiate in a syntactically or semantically
   meaningful way between these two types of attributes.

   In the model, there can be only one person component per presentity.
   In other words, the person component models a single human being, and
   includes characteristics and statuses that are related to the
   communication states for a single human being.  Of course, the system
   has no way to verify that the human described by the person component
   is actually a single human being, as opposed to a group of users, or
   even a dog for that matter.  As the saying goes, "on the Internet, no
   one knows you are a dog", and the same is true here.  The person
   component is a facade for a single person; anything that can be made
   to look like a single person can be modeled with that facade.

   As an example, consider the task of using a presence document to
   describe a customer support help desk.  The person component can be
   considered to be "busy" if none of the support staff are available,
   and "at lunch" if the help desk department has a group lunch
   together.  The watcher that receives the document will consider the
   help desk to be a single person; nothing in the document (except
   perhaps the note element, should its value be "help desk" or
   something similar) conveys information that would indicate that the
   person in question is actually a help desk.






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


   However, there can be multiple occurrences of the person component.
   This happens in cases where the state of the person component is
   ambiguous, as discussed in Section 3.5.

3.3.  Service

   Each presentity has access to a number of services.  Each of these
   represents a point of reachability for 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, Short Message Service (SMS), and Multimedia
   Message Service (MMS).

   It is difficult to give a precise definition for service.  One
   reasonable approach is to model each software or hardware agent in
   the system as a service.  If a user starts a softphone application on
   their PC, then that represents a service.  If a user has a videophone
   device, then that represents another service.  This is effectively a
   physical view of services.  This definition, however, starts to fall
   apart when a service is spread across multiple software agents or
   devices.  For example, a SIP URI representing an address-of-record
   can be routed to a softphone or a videophone, or both.  In that case,
   one might attempt instead to define a service based on its address on
   the network.  This definition also falls apart when modeling devices
   or applications that receive calls and dispatch them to different
   "helpers" based on potentially complex logic.  For example, a
   cellular telephone might house multiple SIP applications, each of
   which can "register" different handlers based on the method or even
   body type of the request.  Each of those applications or handlers can
   rightfully be considered a service, but it doesn't have an address on
   the network distinct from the others.

   Because of this inherent difficulty in precisely defining a service,
   the data model doesn't try to constrain what can be considered a
   service.  Rather, anything can be considered a service so long as it
   exhibits a set of key properties defined by this model.  In
   particular, each service is associated with characteristics that
   identify the nature and capabilities of that service, with reach
   information that indicates how to connect to the service, with status
   information representing the state of that service, and relative
   information that describes the ways in which that service relates to
   others associated with the presentity.

   As a consequence, in this model, services are not explicitly
   enumerated.  There is no central registry where one finds identifiers
   for each service.  Consequently, each service does not have a single
   "service" attribute with values such as "ptt" or "telephony".  That
   doesn't mean that these consolidated monikers aren't useful; indeed,



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


   they represent an essential summary of what the service is.  Such
   summarization is useful in creating icons that allow a user to choose
   one service over another.  A watcher is free to create such
   summarization information from any of the information associated with
   a service.  The reach information often provides valuable information
   for creating such a summarization.  Oftentimes, the scheme of the URI
   is synonymous with the view of what a service is.  An "sms" URI [14]
   clearly indicates SMS, for example.  For some URIs, there may be many
   services available, for example, SIP or tel [15], in which case the
   scheme is less meaningful as a way of creating a summary.  The reach
   information could also indicate that certain application software has
   to be invoked (such as a videogame), in which case that aspect of the
   reach information would be useful for generating an iconic
   representation of the game.

3.3.1.  Characteristics

   Each service is adorned with characteristics that describe the nature
   and capabilities of the service that will be experienced when a
   watcher invokes that URI.  The nature of a service is a set of
   properties that are relatively static across communication sessions
   established to that service.  The nature of a service tends to be
   descriptive.  Examples of the nature of a service are that it
   represents an interactive voice response or voicemail server, that it
   is an automaton, or that it is a telephony service used for the
   purposes of work.  Capabilities, on the other hand, represent
   properties that might be exhibited, and whether they are exhibited
   depends on negotiation and other dynamic functions that take place
   during session establishment.  Examples of such capabilities are the
   type of media that might be used, the directionality of
   communications that are permitted, the SIP extensions supported, and
   so on.  Capabilities can be very complex; for example, RFC 2533 [16]
   describes a model for representing capabilities through N-ary boolean
   functions.  It is difficult to differentiate a capability with one
   modality (e.g., this service only does voice) from a characteristic
   that represents the nature of a service.  However, it is not
   important to do so.

   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 that help differentiate the services
   from each other and give the watcher the context in which to make a
   choice.




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


   Because their purpose is primarily to facilitate choice, capabilities
   do not impose a requirement on the way in which a user reaches that
   service.  For example, if a presence document includes two services,
   and one supports audio only while the other supports only video, this
   does not mean that, when contacting the first service, a user has to