rfc 3856 a presence event package for the session initiation protocol (sip).htm

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

   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



<SPAN class=grey>Rosenberg                   Standards Track                    [Page 12]</SPAN>
<A id=page-13 href="http://tools.ietf.org/html/rfc3856#page-13" name=page-13><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A>                      SIP Presence                   August 2004</SPAN>


   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.

<SPAN class=h3><A name=section-6.8>6.8</A>.  Subscriber Processing of NOTIFY Requests</SPAN>

   <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>] 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.

<SPAN class=h3><A name=section-6.9>6.9</A>.  Handling of Forked Requests</SPAN>

   <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>] 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.

   <A href="http://tools.ietf.org/html/rfc3265#section-4.4.9">Section&nbsp;4.4.9 of RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>] describes the processing that is
   required to guarantee the creation of a single dialog in response to
   a SUBSCRIBE request.








<SPAN class=grey>Rosenberg                   Standards Track                    [Page 13]</SPAN>
<A id=page-14 href="http://tools.ietf.org/html/rfc3856#page-14" name=page-14><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A>                      SIP Presence                   August 2004</SPAN>


<SPAN class=h3><A name=section-6.10>6.10</A>.  Rate of Notifications</SPAN>

   <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>] 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.

<SPAN class=h3><A name=section-6.11>6.11</A>.  State Agents</SPAN>

   <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>] 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.

<SPAN class=h4><A name=section-6.11.1>6.11.1</A>.  Aggregation, Authentication, and Authorization</SPAN>

   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.





<SPAN class=grey>Rosenberg                   Standards Track                    [Page 14]</SPAN>
<A id=page-15 href="http://tools.ietf.org/html/rfc3856#page-15" name=page-15><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A>                      SIP Presence                   August 2004</SPAN>


   The usage of state agents does, however, have a significant impact on
   authorization.  As stated in <A href="http://tools.ietf.org/html/rfc3856#section-6.6">Section 6.6</A>, 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 [<A title='"A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)"' href="http://tools.ietf.org/html/rfc3856#ref-8">8</A>].  All state agents SHOULD
   support the watcherinfo template-package.

<SPAN class=h4><A name=section-6.11.2>6.11.2</A>.  Migration</SPAN>

   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 <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>].  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 [<A title='"Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"' href="http://tools.ietf.org/html/rfc3856#ref-9">9</A>] 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.







<SPAN class=grey>Rosenberg                   Standards Track                    [Page 15]</SPAN>
<A id=page-16 href="http://tools.ietf.org/html/rfc3856#page-16" name=page-16><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A>                      SIP Presence                   August 2004</SPAN>


<SPAN class=h2><A name=section-7>7</A>.  Learning Presence State</SPAN>

   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.

<SPAN class=h3><A name=section-7.1>7.1</A>.  Co-location</SPAN>

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

<SPAN class=h3><A name=section-7.2>7.2</A>.  REGISTER</SPAN>

   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