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

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

<A id=page-9 href="http://tools.ietf.org/html/rfc3856#page-9" name=page-9><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.4>6.4</A>.  Subscription Duration</SPAN>

   User presence changes as a result of many events.  Some examples are:

         o Turning on and off of a cell phone

         o Modifying the registration from a softphone

         o Changing the status on an instant messaging tool

   These events are usually triggered by human intervention, and occur
   with a frequency on the order of seconds to hours.  As such,
   subscriptions should have an expiration in the middle of this range,
   which is roughly one hour.  Therefore, the default expiration time
   for subscriptions within this package is 3600 seconds.  As per <A href="http://tools.ietf.org/html/rfc3265">RFC</A>
   <A href="http://tools.ietf.org/html/rfc3265">3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>], the subscriber MAY specify an alternate expiration in the
   Expires header field.

<SPAN class=h3><A name=section-6.5>6.5</A>.  NOTIFY Bodies</SPAN>

   As described in <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>], the NOTIFY message will contain bodies
   that describe the state of the subscribed resource.  This body is in
   a format listed in the Accept header field of the SUBSCRIBE, or a
   package-specific default if the Accept header field was omitted from
   the SUBSCRIBE.

   In this event package, the body of the notification contains a
   presence document.  This document describes the presence of the
   presentity that was subscribed to.  All subscribers and notifiers
   MUST support the "application/pidf+xml" presence data format
   described in [<A title='"Presence Information Data Format (PIDF)"' href="http://tools.ietf.org/html/rfc3856#ref-6">6</A>].  The subscribe request MAY contain an Accept header
   field.  If no such header field is present, it has a default value of
   "application/pidf+xml".  If the header field is present, it MUST
   include "application/pidf+xml", and MAY include any other types
   capable of representing user presence.

<SPAN class=h3><A name=section-6.6>6.6</A>.  Notifier Processing of SUBSCRIBE Requests</SPAN>

   Based on the proxy routing procedures defined in the SIP
   specification, the SUBSCRIBE request will arrive at a presence agent
   (PA).  This subsection defines package-specific processing at the PA
   of a SUBSCRIBE request.  General processing rules for requests are
   covered in <A href="http://tools.ietf.org/html/rfc3261#section-8.2">Section&nbsp;8.2 of RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>], in addition to general
   SUBSCRIBE processing in <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>].







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


   User presence is highly sensitive information.  Because the
   implications of divulging presence information can be severe, strong
   requirements are imposed on the PA regarding subscription processing,
   especially related to authentication and authorization.

<SPAN class=h4><A name=section-6.6.1>6.6.1</A>.  Authentication</SPAN>

   A presence agent MUST authenticate all subscription requests.  This
   authentication can be done using any of the mechanisms defined in <A href="http://tools.ietf.org/html/rfc3261">RFC</A>
   <A href="http://tools.ietf.org/html/rfc3261">3261</A> [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>].  Note that digest is mandatory to implement, as specified
   in <A href="http://tools.ietf.org/html/rfc3261">RFC 3261</A>.

   In single-domain systems, where the subscribers all have shared
   secrets with the PA, the combination of digest authentication over
   Transport Layer Security (TLS) [<A title='"The TLS Protocol Version 1.0"' href="http://tools.ietf.org/html/rfc3856#ref-7">7</A>] provides a secure and workable
   solution for authentication.  This use case is described in Section
   26.3.2.1 of <A href="http://tools.ietf.org/html/rfc3261">RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>].

   In inter-domain scenarios, establishing an authenticated identity of
   the subscriber is harder.  It is anticipated that authentication will
   often be established through transitive trust.  SIP mechanisms for
   network asserted identity can be applied to establish the identity of
   the subscriber [<A title='"Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"' href="http://tools.ietf.org/html/rfc3856#ref-11">11</A>].

   A presentity MAY choose to represent itself with a SIPS URI.  By
   "represent itself", it means that the user represented by the
   presentity hands out, on business cards, web pages, and so on, a SIPS
   URI for their presentity.  The semantics associated with this URI, as
   described in <A href="http://tools.ietf.org/html/rfc3261">RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>], require TLS usage on each hop between the
   subscriber and the server in the domain of the URI.  This provides
   additional assurances (but no absolute guarantees) that identity has
   been verified at each hop.

   Another mechanism for authentication is S/MIME.  Its usage with SIP
   is described fully in <A href="http://tools.ietf.org/html/rfc3261">RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>].  It provides an end-to-end
   authentication mechanism that can be used for a PA to establish the
   identity of the subscriber.

<SPAN class=h4><A name=section-6.6.2>6.6.2</A>.  Authorization</SPAN>

   Once authenticated, the PA makes an authorization decision.  A PA
   MUST NOT accept a subscription unless authorization has been provided
   by the presentity.  The means by which authorization are provided are
   outside the scope of this document.  Authorization may have been
   provided ahead of time through access lists, perhaps specified in a
   web page.  Authorization may have been provided by means of uploading
   of some kind of standardized access control list document.  Back end
   authorization servers, such as a DIAMETER [<A title='"Diameter Base Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-12">12</A>] server, can also be



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


   used.  It is also useful to be able to query the user for
   authorization following the receipt of a subscription request for
   which no authorization information has been provided.  The
   "watcherinfo" event template package for SIP [<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>] defines a means by
   which a presentity can become aware that a user has attempted to
   subscribe to it, so that it can then provide an authorization
   decision.

   Authorization decisions can be very complex.  Ultimately, all
   authorization decisions can be mapped into one of three states:
   rejected, successful, and pending.  Any subscription for which the
   client is authorized to receive information about some subset of
   presence state at some points in time is a successful subscription.
   Any subscription for which the client will never receive any
   information about any subset of the presence state is a rejected
   subscription.  Any subscription for which it is not yet known whether
   it is successful or rejected is pending.  Generally, a pending
   subscription occurs when the server cannot obtain authorization at
   the time of the subscription, but may be able to do so at a later
   time, perhaps when the presentity becomes available.

   The appropriate response codes for conveying a successful, rejected,
   or pending subscription (200, 403 or 603, and 202, respectively) are
   described in <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>].

   If the resource is not in a meaningful state, <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>] allows the
   body of the initial NOTIFY to be empty.  In the case of presence,
   that NOTIFY MAY contain a presence document.  This document would
   indicate whatever presence state the subscriber has been authorized
   to see; it is interpreted by the subscriber as the current presence
   state of the presentity.  For pending subscriptions, the state of the
   presentity SHOULD include some kind of textual note that indicates a
   pending status.

   Polite blocking, as described in [<A title='"Instant Messaging / Presence Protocol Requirements"' href="http://tools.ietf.org/html/rfc3856#ref-13">13</A>], is possible by generating a
   200 OK to the subscription even though it has been rejected (or
   marked pending).  Of course, an immediate NOTIFY will still be sent.
   The contents of the presence document in such a NOTIFY are at the
   discretion of the implementor, but SHOULD be constructed in such a
   way as to not reveal to the subscriber that their request has
   actually been blocked.  Typically, this is done by indicating
   "offline" or equivalent status for a single contact address.

<SPAN class=h3><A name=section-6.7>6.7</A>.  Notifier Generation of NOTIFY Requests</SPAN>

   <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> 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



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


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