rfc4479 a data model for presence.txt

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

   offer only an audio stream, or when contacting the second service, a
   user has to offer only a video stream.  A user can use local policy
   at its discretion in determining what capabilities or communications
   modalities are offered when they choose to connect with a service.
   It is not necessary for a watcher to add SIP caller preferences [2]
   to request routing of the request to a service with the
   characteristics described in the presence document.

   If, in order to reach a service, the user agent must generate a
   request that exhibits a particular capability or contains a specific
   header, then this is indicated separately in the reach information,
   described below.

   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
   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.

   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 watcher.  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.

3.3.2.  Reach Information

   The reach information for a service provides the instructions for the
   recipient of a document on how to correctly contact that service.

   When a service is accessible over a communications network, reach
   information includes a URI that can be "hit" to access the service.
   This URI is called the service URI.  However, some services are not




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


   accessible over a communications network (such as in-person
   communications or a written letter), and as such, may not utilize a
   URI.

   Even for services reachable over a communications network, the URI
   alone may not be sufficient.  For example, two applications may be
   running within a cellular telephone, both of which are reachable
   through the user's SIP Address of Record.  However, one application
   is launched when the INVITE request contains a body of a particular
   type, and the other is launched for other body types.  As another
   example, a service may provide complex application logic that
   operates correctly only when contacted from matching application
   software.  In such a case, even though the communications between
   instances utilizes a standard protocol (such as SIP), the user
   experience will not be correct unless the applications are matched.

   When the URI is not sufficient, additional attributes of the service
   can be present that define the instructions on how the service is to
   be reached.  These attributes must be understood for the service to
   be utilized.  If a watcher receives a presence document containing
   reach information it does not understand, it should discard the
   service information.

   The reach information 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 utilizes the reach information for that
   service.  For this reason, each service has to have a unique set of
   reach information.  If this was not the case, the user would have no
   way to choose between the services.  This means that the reach
   information represents a unique identifier for the service.  However,
   a presence document can contain multiple occurrences of a particular
   service, each of which contains the same reach information, but
   differs in its occurrence identifier.  Multiple occurrences of a
   service exist in a document when the state of the service is
   ambiguous, as discussed in Section 3.5.

   Because the reach information serves as an identifier for a service,
   it also serves as a way to figure out whether a communications
   capability should be represented as one service or more.  Something
   cannot be a service unless there is a way to reach it separately from
   another service.  As an example, consider a softphone application
   that is capable of audio and video.  It is not possible to describe
   this softphone as two services - one capable of just audio, and one
   capable of just video.  That's because there is no way to reach the
   video-only service; for example, sending a SIP INVITE with just a
   video stream doesn't suffice, since one can always add the audio
   stream later and it will work.  Video and audio, in this case,
   represent capabilities for a single service.



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


   The reach information represents a weak form of contract; the
   presentity tells the watcher that, if the watcher utilizes the reach
   information 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.
   First, 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.  Second, 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.

   This loose contract also provides some guidance on the type of URI
   that is most ideally suited for the service URI.  A URN [3] can be
   used as the service URI.  However, since a URN could be resolved to
   potentially any number of different URIs, the characteristics,
   status, and relative information need to be sensible for all of the
   URIs that can be resolved from the URN.  As the URN becomes
   increasingly "vague" in terms of the service it identifies, the
   number of presence attributes that can be included decreases
   correspondingly.

   The tel URI [11] shares similar properties with a URN, and the same
   considerations apply.  If, for example, the telephone number exists
   in ENUM [18] and multiple ENUM services are defined, including voice
   and messaging, it is likely that very little characteristic
   information can be included in that service.  If, however, a tel URI
   has only a single ENUM service defined, and it refers to a telephone
   service on the Public Switched Telephone Network (PSTN), more can be
   said about its characteristics, status, and relative priority.

   It is important to point out that there can be a many-to-one mapping
   of reach information to a service.  That is, a particular service can
   potentially be reachable through an infinite number of reach
   information sets.  This is true even if the reach information is just
   the service URI; it is permissible for multiple service URIs to reach
   the same service.  Within any particular document, for a particular
   service,  there will be a single service URI.  However, it is allowed
   and even valuable to provide different service URIs to different
   watchers, or to change the service URIs provided to a particular
   watcher over time.  Doing so affords many benefits, in fact.  It can
   allow the recipient of a communications attempt to determine the
   context for that attempt - that the attempt was made as a result of





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


   trying to reach a particular service in a particular presence
   document.  This can be used as a technique for preventing
   communications spam, for example [19].

   It is also possible for a presence document to contain a service that
   has no reach information at all.  In such a case, the presentity is
   indicating that the service exists, but is electing not to offer the
   watcher the opportunity to connect to it.  One such example would be
   to let a watcher know that a user has a telephony service, and that
   they are busy, but in order to avoid receipt of a call, no reach
   information is provided.

   In an ideal system, the URI alone would represent sufficient reach
   information for each service.  A URI is supposed to provide
   sufficient context for reaching the resource associated with the URI,
   and thus in theory there is no need for additional context.  However,
   sometimes, additional information is needed.  Since the reach
   information has to be understood in order for the service to be
   utilized, reach information beyond the URI should be defined and used
   sparingly.  Extensions to PIDF that define attributes that are reach
   information should clearly call those attributes out as such.

3.3.3.  Relative Information

   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
   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.

3.3.4.  Status

   Each service also has a status.  Status represents generally dynamic
   information about the availability of communications using that
   service.  This is in contrast 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.  It can have
   values of either "closed" or "open".  "Closed" means that
   communication to the service will, in all likelihood, fail, will not



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


   reach the intended party, or will not result in communications as
   described by the characteristics of the service.  As an example, if a
   call is forwarded to voicemail if the user is busy or unavailable,
   the service is marked as "closed".  Similarly, a presentity may
   include a hotel phone number as a service URI.  After checkout, the
   phone number will still ring, but reach the chambermaid or the next
   guest.  Thus, it would be declared "closed" by that presentity.  As
   another example, if a user has a SIP URI as their service URI that
   points to a SIP softphone application, and the PC shuts down, calls
   to that SIP URI will return a 480 response code.  This service would
   also be declared "closed".  "Open" implies the opposite - that
   communications to this service will likely succeed and reach the
   desired target.

   It is also possible to have status information that is dependent on
   the characteristics of the communications session that eventually
   gets set up.  For example, a status attribute can be defined that
   indicates that a softphone service is available if instant messaging
   is used, but unavailable if audio is used.

   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 dynamic 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 it is 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.  The
   statuses in this service include whether 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