rfc3856 a presence event package for the session initiation protocol.txt

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

   "offline" or equivalent status for a single contact address.

6.7.  Notifier Generation of NOTIFY Requests

   RFC 3265 details the formatting and structure of NOTIFY messages.
   However, packages are mandated to provide detailed information on
   when to send a NOTIFY, how to compute the state of the resource, how



Rosenberg                   Standards Track                    [Page 11]

RFC 3856                      SIP Presence                   August 2004


   to generate neutral or fake state information, and whether state
   information is complete or partial.  This section describes those
   details for the presence event package.

   A PA MAY send a NOTIFY at any time.  Typically, it will send one when
   the state of the presentity changes.  The NOTIFY request MAY contain
   a body indicating the state of the presentity.  The times at which
   the NOTIFY is sent for a particular subscriber, and the contents of
   the body within that notification, are subject to any rules specified
   by the authorization policy that governs the subscription.  This
   protocol in no way limits the scope of such policies.  As a baseline,
   a reasonable policy is to generate notifications when the state of
   any of the presence tuples changes.  These notifications would
   contain the complete and current presence state of the presentity as
   known to the presence agent.  Future extensions can be defined that
   allow a subscriber to request that the notifications contain changes
   in presence information only, rather than complete state.

   In the case of a pending subscription, when final authorization is
   determined, a NOTIFY can be sent.  If the result of the authorization
   decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
   presence document with the current state of the presentity.  If the
   subscription is rejected, a NOTIFY MAY be sent.  As described in RFC
   3265 [2], the Subscription-State header field indicates the state of
   the subscription.

   The body of the NOTIFY MUST be sent using one of the types listed in
   the Accept header field in the most recent SUBSCRIBE request, or
   using the type "application/pidf+xml" if no Accept header field was
   present.

   The means by which the PA learns the state of the presentity are also
   outside the scope of this recommendation.  Registrations can provide
   a component of the presentity state.  However, the means by which a
   PA uses registrations to construct a presence document are an
   implementation choice.  If a PUA wishes to explicitly inform the
   presence agent of its presence state, it should explicitly publish
   the presence document (or its piece of it) rather than attempting to
   manipulate their registrations to achieve the desired result.

   For reasons of privacy, it will frequently be necessary to encrypt
   the contents of the notifications.  This can be accomplished using
   S/MIME.  The encryption can be performed using the key of the
   subscriber as identified in the From field of the SUBSCRIBE request.
   Similarly, integrity of the notifications is important to
   subscribers.  As such, the contents of the notifications MAY provide
   authentication and message integrity using S/MIME.  Since the NOTIFY
   is generated by the presence server, which may not have access to the



Rosenberg                   Standards Track                    [Page 12]

RFC 3856                      SIP Presence                   August 2004


   key of the user represented by the presentity, it will frequently be
   the case that the NOTIFY is signed by a third party.  It is
   RECOMMENDED that the signature be by an authority over the domain of
   the presentity.  In other words, for a user pres:[e-mail],
   the signator of the NOTIFY SHOULD be the authority for example.com.

6.8.  Subscriber Processing of NOTIFY Requests

   RFC 3265 [2] leaves it to event packages to describe the process
   followed by the subscriber upon receipt of a NOTIFY request,
   including any logic required to form a coherent resource state.

   In this specification, each NOTIFY contains either no presence
   document, or a document representing the complete and coherent state
   of the presentity.  Within a dialog, the presence document in the
   NOTIFY request with the highest CSeq header field value is the
   current one.  When no document is present in that NOTIFY, the
   presence document present in the NOTIFY with the next highest CSeq
   value is used.  Extensions which specify the use of partial state for
   presentities will need to dictate how coherent state is achieved.

6.9.  Handling of Forked Requests

   RFC 3265 [2] requires each package to describe handling of forked
   SUBSCRIBE requests.

   This specification only allows a single dialog to be constructed as a
   result of emitting an initial SUBSCRIBE request.  This guarantees
   that only a single PA is generating notifications for a particular
   subscription to a particular presentity.  The result of this is that
   a presentity can have multiple PAs active, but these should be
   homogeneous, so that each can generate the same set of notifications
   for the presentity.  Supporting heterogeneous PAs, each of which
   generates notifications for a subset of the presence data, is complex
   and difficult to manage.  Doing so would require the subscriber to
   act as the aggregator for presence data.  This aggregation function
   can only reasonably be performed by agents representing the
   presentity.  Therefore, if aggregation is needed, it MUST be done in
   a PA representing the presentity.

   Section 4.4.9 of RFC 3265 [2] describes the processing that is
   required to guarantee the creation of a single dialog in response to
   a SUBSCRIBE request.








Rosenberg                   Standards Track                    [Page 13]

RFC 3856                      SIP Presence                   August 2004


6.10.  Rate of Notifications

   RFC 3265 [2] requires each package to specify the maximum rate at
   which notifications can be sent.

   A PA SHOULD NOT generate notifications for a single presentity at a
   rate of more than once every five seconds.

6.11.  State Agents

   RFC 3265 [2] requires each package to consider the role of state
   agents in the package, and if they are used, to specify how
   authentication and authorization are done.

   State agents are core to this package.  Whenever the PA is not
   co-located with the PUA for the presentity, the PA is acting as a
   state agent.  It collects presence state from the PUA, and aggregates
   it into a presence document.  Because there can be multiple PUA, a
   centralized state agent is needed to perform this aggregation.  That
   is why state agents are fundamental to presence.  Indeed, they have a
   specific term that describes them - a presence server.

6.11.1.  Aggregation, Authentication, and Authorization

   The means by which aggregation is done in the state agent is purely a
   matter of policy.  The policy will typically combine the desires of
   the presentity along with the desires of the provider.  This document
   in no way restricts the set of policies which may be applied.

   However, there is clearly a need for the state agent to have access
   to the state of the presentity.  This state is manipulated by the
   PUA.  One way in which the state agent can obtain this state is to
   subscribe to it.  As a result, if there were 5 PUA manipulating
   presence state for a single presentity, the state agent would
   generate 5 subscriptions, one to each PUA.  For this mechanism to be
   effective, all PUA SHOULD be capable of acting as a PA for the state
   that they manipulate, and that they authorize subscriptions that can
   be authenticated as coming from the domain of the presentity.

   The usage of state agents does not significantly alter the way in
   which authentication is done by the PA.  Any of the SIP
   authentication mechanisms can be used by a state agent.  However,
   digest authentication will require the state agent to be aware of the
   shared secret between the presentity and the subscriber.  This will
   require some means to securely transfer the shared secrets from the
   presentity to the state agent.





Rosenberg                   Standards Track                    [Page 14]

RFC 3856                      SIP Presence                   August 2004


   The usage of state agents does, however, have a significant impact on
   authorization.  As stated in Section 6.6, a PA is required to
   authorize all subscriptions.  If no explicit authorization policy has
   been defined, the PA will need to query the user for authorization.
   In a presence edge server (where the PUA is co-located with the PUA),
   this is trivially accomplished.  However, when state agents are used
   (i.e., a presence server), a means is needed to alert the user that
   an authorization decision is required.  This is the reason for the
   watcherinfo event template-package [8].  All state agents SHOULD
   support the watcherinfo template-package.

6.11.2.  Migration

   On occasion, it makes sense for the PA function to migrate from one
   server to another.  For example, for reasons of scale, the PA
   function may reside in the presence server when the PUA is not
   running, but when the PUA connects to the network, the PA migrates
   subscriptions to it in order to reduce state in the network.  The
   mechanism for accomplishing the migration is described in Section
   3.3.5 of RFC 3265 [2].  However, packages need to define under what
   conditions such a migration would take place.

   A PA MAY choose to migrate subscriptions at any time, through
   configuration, or through dynamic means.  The REGISTER request
   provides one dynamic means for a presence server to discover that the
   function can migrate to a PUA.  Specifically, if a PUA wishes to
   indicate support for the PA function, it SHOULD use the callee
   capabilities specification [9] to indicate that it supports the
   SUBSCRIBE request method and the presence event package.  The
   combination of these two define a PA.  Of course, a presence server
   can always attempt a migration without these explicit hints.  If it
   fails with either a 405 or 489 response code, the server knows that
   the PUA does not support the PA function.  In this case, the server
   itself will need to act as a PA for that subscription request.  Once
   such a failure has occurred, the server SHOULD NOT attempt further
   migrations to that PUA for the duration of its registration.
   However, to avoid the extra traffic generated by these failed
   requests, a presence server SHOULD support the callee capabilities
   extension.

   Furthermore, indication of support for the SUBSCRIBE request and the
   presence event package is not sufficient for migration of
   subscriptions.  A PA SHOULD NOT migrate the subscription if it is
   composing aggregated presence documents received from multiple PUA.







Rosenberg                   Standards Track                    [Page 15]

RFC 3856                      SIP Presence                   August 2004


7.  Learning Presence State

   Presence information can be obtained by the PA in many ways.  No
   specific mechanism is mandated by this specification.  This section
   overviews some of the options, for informational purposes only.

7.1.  Co-location

   When the PA function is co-located with the PUA, presence is known
   directly by the PA.

7.2.  REGISTER

   A UA uses the SIP REGISTER method to inform the SIP network of its
   current communications addresses (i.e., Contact addresses).  Multiple
   UA can independently register Contact addresses for the same
   address-of-record.  This registration state represents an important
   piece of the overall presence information for a presentity.  It is an
   indication of basic reachability for communications.

   Usage of REGISTER information to construct presence is only possible
   if the PA has access to the registration database, and can be
   informed of changes to that database.  One way to accomplish that is
   to co-locate the PA with the registrar.

   The means by which registration state is converted into presence
   state is a matter of local policy, and beyond the scope of this
   specification.  However, some general guidelines can be provided.
   The address-of-record in the registration (the To header field)
   identifies the presentity.  Each registered Contact header field
   identifies a point of communications for that presentity, which can
   be modeled using a tuple.  Note that the contact address in the tuple
   need not be the same as the registered contact address.  Using an
   address-of-record instead allows subsequent communications from a
   watcher to pass through proxies.  This is useful for policy
   processing on behalf of the presentity and the provider.

   A PUA that uses registrations to manipulate presence state SHOULD
   make use of the SIP callee capabilities extension [9].  This allows
   the PUA to provide the PA with richer information about itself.  For
   example, the presence of the methods parameter listing the method
   "MESSAGE" indicates support for instant messaging.

   The q values from the Contact header field [1] can be used to
   establish relative priorities amongst the various communications
   addresses in the Contact header fields.





Rosenberg                   Standards Track                    [Page 16]

RFC 3856                      SIP Presence                   August 2004


   The usage of registrations to obtain presence information increases
   the requirements for authenticity and integrity of registrations.
   Therefore, REGISTER requests used by presence user agents MUST be
   authenticated.

7.3.  Uploading Presence Documents

   If a means exists to upload presence documents from PUA to the PA,