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

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

   expiration.

5.  Usage of Presence URIs

   A presentity is identified in the most general way through a presence
   URI [3], which is of the form pres:user@domain.  These URIs are
   resolved to protocol specific URIs, such as the SIP or SIPS URI,
   through domain-specific mapping policies maintained on a server.

   It is very possible that a user will have both a SIP (and/or SIPS)
   URI and a pres URI to identify both themself and other users.  This
   leads to questions about how these URI relate and which are to be
   used.

   In some instances, a user starts with one URI format, such as the
   pres URI, and learns a URI in a different format through some
   protocol means.  As an example, a SUBSCRIBE request sent to a pres
   URI will result in learning a SIP or SIPS URI for the presentity from
   the Contact header field of the 200 OK to the SUBSCRIBE request.  As
   another example, a DNS mechanism might be defined that would allow
   lookup of a pres URI to obtain a SIP or SIPS URI.  In cases where one
   URI is learned from another through protocol means, those means will
   often provide some kind of scoping that limit the lifetime of the
   learned URI.  DNS, for example, provides a TTL which would limit the
   scope of the URI.  These scopes are very useful to avoid stale or
   conflicting URIs for identifying the same resource.  To ensure that a
   user can always determine whether a learned URI is still valid, it is
   RECOMMENDED that systems which provide lookup services for presence
   URIs have some kind of scoping mechanism.




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


   If a subscriber is only aware of the protocol-independent pres URI
   for a presentity, it follows the procedures defined in [5].  These
   procedures will result in the placement of the pres URI in the
   Request-URI of the SIP request, followed by the usage of the DNS
   procedures defined in [5] to determine the host to send the SIP
   request to.  Of course, a local outbound proxy may alternatively be
   used, as specified in RFC 3261 [1].  If the subscriber is aware of
   both the protocol-independent pres URI and the SIP or SIPS URI for
   the same presentity, and both are valid (as discussed above) it
   SHOULD use the pres URI format.  Of course, if the subscriber only
   knows the SIP URI for the presentity, that URI is used, and standard
   RFC 3261 processing will occur. When the pres URI is used, any
   proxies along the path of the SUBSCRIBE request which do not
   understand the URI scheme will reject the request.  As such, it is
   expected that many systems will be initially deployed that only
   provide users with a SIP URI.

   SUBSCRIBE messages also contain logical identifiers that define the
   originator and recipient of the subscription (the To and From header
   fields).  These headers can take either a pres or SIP URI.  When the
   subscriber is aware of both a pres and SIP URI for its own identity,
   it SHOULD use the pres URI in the From header field.  Similarly, when
   the subscriber is aware of both a pres and a SIP URI for the desired
   presentity, it SHOULD use the pres URI in the To header field.

   The usage of the pres URI instead of the SIP URI within the SIP
   message supports interoperability through gateways to other
   CPP-compliant systems.  It provides a protocol-independent form of
   identification which can be passed between systems.  Without such an
   identity, gateways would be forced to map SIP URIs into the
   addressing format of other protocols.  Generally, this is done by
   converting the SIP URI to the form <foreign-protocol-scheme>:<encoded
   SIP URI>@<gateway>.  This is commonly done in email systems, and has
   many known problems.  The usage of the pres URI is a SHOULD, and not
   a MUST, to allow for cases where it is known that there are no
   gateways present, or where the usage of the pres URI will cause
   interoperability problems with SIP components that do not support the
   pres URI.

   The Contact, Record-Route and Route fields do not identify logical
   entities, but rather concrete ones used for SIP messaging.  SIP [1]
   specifies rules for their construction.

6.  Presence Event Package

   The SIP event framework [2] defines a SIP extension for subscribing
   to, and receiving notifications of, events.  It leaves the definition
   of many aspects of these events to concrete extensions, known as



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


   event packages.  This document qualifies as an event package.  This
   section fills in the information required for all event packages by
   RFC 3265 [2].

6.1.  Package Name

   The name of this package is "presence".  As specified in RFC 3265
   [2], this value appears in the Event header field present in
   SUBSCRIBE and NOTIFY requests.

   Example:

   Event: presence

6.2.  Event Package Parameters

   The SIP event framework allows event packages to define additional
   parameters carried in the Event header field.  This package,
   presence, does not define any additional parameters.

6.3.  SUBSCRIBE Bodies

   A SUBSCRIBE request MAY contain a body.  The purpose of the body
   depends on its type.  Subscriptions will normally not contain bodies.

   The Request-URI, which identifies the presentity, combined with the
   event package name, is sufficient for presence.

   One type of body that can be included in a SUBSCRIBE request is a
   filter document.  These filters request that only certain presence
   events generate notifications, or would ask for a restriction on the
   set of data returned in NOTIFY requests.  For example, a presence
   filter might specify that the notifications should only be generated
   when the status of the user's instant inbox [10] changes.  It might
   also say that the content of these notifications should only contain
   the status of the instant inbox.  Filter documents are not specified
   in this document, and at the time of writing, are expected to be the
   subject of future standardization activity.

   Honoring of these filters is at the policy discretion of the PA.

   If the SUBSCRIBE request does not contain a filter, this tells the PA
   that no filter is to be applied.  The PA SHOULD send NOTIFY requests
   at the discretion of its own policy.







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


6.4.  Subscription Duration

   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 RFC
   3265 [2], the subscriber MAY specify an alternate expiration in the
   Expires header field.

6.5.  NOTIFY Bodies

   As described in RFC 3265 [2], 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 [6].  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.

6.6.  Notifier Processing of SUBSCRIBE Requests

   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 Section 8.2 of RFC 3261 [1], in addition to general
   SUBSCRIBE processing in RFC 3265 [2].







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


   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.

6.6.1.  Authentication

   A presence agent MUST authenticate all subscription requests.  This
   authentication can be done using any of the mechanisms defined in RFC
   3261 [1].  Note that digest is mandatory to implement, as specified
   in RFC 3261.

   In single-domain systems, where the subscribers all have shared
   secrets with the PA, the combination of digest authentication over
   Transport Layer Security (TLS) [7] provides a secure and workable
   solution for authentication.  This use case is described in Section
   26.3.2.1 of RFC 3261 [1].

   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 [11].

   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 RFC 3261 [1], 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 RFC 3261 [1].  It provides an end-to-end
   authentication mechanism that can be used for a PA to establish the
   identity of the subscriber.

6.6.2.  Authorization

   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 [12] server, can also be



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


   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 [8] 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 RFC 3265 [2].

   If the resource is not in a meaningful state, RFC 3265 [2] 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 [13], 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