[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3856

Internet Engineering Task Force                                SIMPLE WG
Internet Draft                                          Rosenberg et al.
draft-ietf-simple-presence-04.txt                         Various Places
November 21, 2001
Expires: May 2002


                      SIP Extensions for Presence

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   This document describes the usage of SIP for subscriptions and
   notifications of user presence. User presence is defined as the
   willingness and ability of a user to communicate with other users on
   the network. Historically, presence has been limited to "on-line" and
   "off-line" indicators; the notion of presence here is broader.
   Subscriptions and notifications of user presence are supported by
   defining an event package within the general SIP event notification
   framework. This protocol is also compliant with the Common Presence
   and Instant Messaging (CPIM) framework.


1 Introduction

   Presence is (indirectly) defined in RFC2778 [1] as subscription to
   and notification of changes in the communications state of a user.



Rosenberg et al.                                              [Page 1]

Internet Draft                  presence               November 21, 2001


   This communications state consists of the set of communications
   means, communications address, and status of that user. A presence
   protocol is a protocol for providing such a service over the Internet
   or any IP network.

   This document proposes the usage of the Session Initiation Protocol
   (SIP) [2] for presence. This is accomplished through a concrete
   instantiation of the general event notification framework defined for
   SIP [3], and as such, makes use of the SUBSCRIBE and NOTIFY methods
   defined there. Specifically, this document defines an event package,
   as described in [3]. User presence is particularly well suited for
   SIP. SIP registrars and location services already hold user presence
   information; it is uploaded to these devices through REGISTER
   messages, and used to route calls to those users. Furthermore, SIP
   networks already route INVITE messages from any user on the network
   to the proxy that holds the registration state for a user. As this
   state is user presence, those SIP networks can also allow SUBSCRIBE
   requests to be routed to the same proxy. This means that SIP networks
   can be reused to establish global connectivity for presence
   subscriptions and notifications.

   This event package is based on the concept of a presence agent, which
   is a new logical entity that is capable of accepting subscriptions,
   storing subscription state, and generating notifications when there
   are changes in user presence. The entity is defined as a logical one,
   since it is generally co-resident with another entity, and can even
   move around during the lifetime of a subscription.

   This event package is also compliant with the Common Presence and
   Instant Messaging (CPIM) framework that has been defined in [4]. This
   allows SIP for presence to easily interwork with other presence
   systems compliant to CPIM.

2 Definitions

   This document uses the terms as defined in [1]. Additionally, the
   following terms are defined and/or additionally clarified:

        Presence User Agent (PUA): A Presence User Agent manipulates
             presence information for a presentity. This manipulation
             can be the side effect of some other action (such as
             sending a SIP REGISTER request to add a new Contact) or can
             be done explicitly through the publication of presence
             documents. We explicitly allow multiple PUAs per
             presentity. This means that a user can have many devices
             (such as a cell phone and PDA), each of which is
             independently generating a component of the overall
             presence information for a presentity. PUAs push data into



Rosenberg et al.                                              [Page 2]

Internet Draft                  presence               November 21, 2001


             the presence system, but are outside of it, in that they do
             not receive SUBSCRIBE messages, or send NOTIFY.

        Presence Agent (PA): A presence agent is a SIP user agent which
             is capable of receiving SUBSCRIBE requests, responding to
             them, and generating notifications of changes in presence
             state. A presence agent must have knowledge of the presence
             state of a presentity. This means that it must have access
             to presence data manipulated by PUAs for the presentity.
             One way to do this is by co-locating the PA with the
             proxy/registrar, or the presence user agent of the
             presentity. However, this is not the only way, and this
             specification makes no recommendations about where the PA
             function should be located. A PA is always addressable with
             a SIP URL that uniquely identifies the presentity (i.e,
             sip:joe@example.com). There can be multiple PAs for a
             particular presentity, each of which handles some subset of
             the total subscriptions currently active for the
             presentity. A PA is also a notifier (defined in [3] that
             supports the presence events package.

        Presence Server: A presence server is a physical entity that can
             act as either a presence agent or as a proxy server for
             SUBSCRIBE requests. When acting as a PA, it is aware of the
             presence information of the presentity through some
             protocol means. This protocol means can be SIP REGISTER
             requests, but other mechanisms are allowed. When acting as
             a proxy, the SUBSCRIBE requests are proxied to another
             entity that may act as a PA.

        Presence Client: A presence client is a presence agent that is
             colocated with a PUA. It is aware of the presence
             information of the presentity because it is co-located with
             the entity that manipulates this presence information.

3 Overview of Operation

   In this section, we present an overview of the operation of this
   event package.

   When an entity, the subscriber, wishes to learn about presence
   information from some user, it creates a SUBSCRIBE request. This
   request identifies the desired presentity in the request URI, using a
   SIP URL or a presence URL [4]. The subscription is carried along SIP
   proxies as any other request would be. It eventually arrives at a
   presence server, which can either terminate the subscription (in
   which case it acts as the presence agent for the presentity), or
   proxy it on to a presence client. If the presence client handles the



Rosenberg et al.                                              [Page 3]

Internet Draft                  presence               November 21, 2001


   subscription, it is effectively acting as the presence agent for the
   presentity. The decision about whether to proxy or terminate the
   SUBSCRIBE is a local matter; however, we describe one way to effect
   such a configuration, using REGISTER.

   The presence agent (whether in the presence server or presence
   client) first authenticates the subscription, then authorizes it. The
   means for authorization are outside the scope of this protocol, and
   we expect that many mechanisms will be used. If authorized, a 200 OK
   response is returned. If authorization could not be obtained at this
   time, the subscription is considered "pending", and a 202 response is
   returned. In both cases, the PA sends an immediate NOTIFY message
   containing the state of the presentity (this state may be bogus in
   the case of a pending subscription). As the state of the presentity
   changes, the PA generates NOTIFYs for all subscribers with authorized
   subscriptions.

   The SUBSCRIBE message effectively establishes a "dialog" with the
   presence agent, which persists for some amount of time, and may
   involve subsequent messaging (like a refresh or notification). As a
   result, the SUBSCRIBE can be record-routed, and rules for tag
   handling and Contact processing mirror those for INVITE. Similarly,
   the NOTIFY message is handled in much the same way a re-INVITE within
   a call leg is handled.

4 Usage of Presence URLs

   A presentity is identified in the most general way through a presence
   URL [4], which is of the form pres:user@domain. These URLs are
   protocol independent. They are resolved to protocol specific URLs,
   such as a SIP URL, through DNS procedures defined in [4].

   When subscribing to a presentity, the subscription can be addressed
   using the protocol independent form or the sip URL form. In the SIP
   context, "addressed" refers to the request URI. It is RECOMMENDED
   that if the entity sending a SUBSCRIBE is capable of resolving the
   protocol independent form to the SIP form, this resolution is done
   before sending the request. However, if the entity is incapable of
   doing this translation, the protocol independent form is used in the
   request URI. Performing the translation as early as possible means
   that these requests can be routed by SIP proxies that are not aware
   of the presence namespace.

   SUBSCRIBE messages also contain logical identifiers that define the
   originator and recipient of the subscription (the To and From header
   fields). These SHOULD contain SIP URLs whenever possible, but MAY
   contain a pres URL if a SIP URL is not known or available.




Rosenberg et al.                                              [Page 4]

Internet Draft                  presence               November 21, 2001


   The Contact, Record-Route and Route fields do not identify logical
   entities, but rather concrete ones used for SIP messaging. As such,
   they MUST use the SIP URL forms in both SUBSCRIBE and NOTIFY.

5 Presence Event Package

   The SIP event framework [3] defines an abstract SIP extension for
   subscribing to, and receiving notifications of, events. It leaves the
   definition of many additional aspects of these events to concrete
   extensions, also known as event packages. This document qualifies as
   an event package. This section fills in the information required by
   [5].

5.1 Package Name

   The name of this package is "presence". This name MUST appear within
   the Event header in SUBSCRIBE request and NOTIFY request.

   Example:



   Event: presence



5.2 Event Package Parameters

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

5.3 SUBSCRIBE bodies

   The body of 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 user presence.

   We anticipate that document formats could be defined to act as
   filters for subscriptions. These filters would request that only
   certain user presence events that would generate notifies, or 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 users instant message
   inbox changes. It might also say that the content of these
   notifications should only contain the IM related information.




Rosenberg et al.                                              [Page 5]

Internet Draft                  presence               November 21, 2001


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

   When no body is present, this specifies to the presence agent that no
   filter is being requested. All presence changes SHOULD be conveyed in
   NOTIFY requests.

5.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 [3], the
   subscriber MAY include an alternate expiration time.

5.5 NOTIFY Bodies

   The body of the notification contains a presence document. This
   document describes the user presence of the presentity that was
   subscribed to. All subscribers MUST support the presence data format
   described in [6], and MUST list its MIME type, "application/cpim-
   pidf+xml" in an Accept header present in the SUBSCRIBE request.

   Other presence data formats might be defined in the future. In that
   case, the subscriptions MAY indicate support for other presence
   formats. However, they MUST always support and list
   "application/cpim-pidf+xml" as an allowed format.

   Of course, the notifications generated by the presence agent MUST be
   in one of the formats specified in the Accept header in the SUBSCRIBE
   request.

5.6 Subscriber Generation of SUBSCRIBE Requests

   If a user wishes to subscribe to a user's presence, they formulate a
   SIP SUBSCRIBE request. The Request-URI SHOULD contain the SIP URL of
   the presentity whose presence is desired, but MAY contain a presence
   URL if no SIP URL is known. The To field SHOULD contain the same
   value as the Request-URI. The From field MUST be present, and SHOULD
   contain a logical identifier for the subscriber (i.e.,



Rosenberg et al.                                              [Page 6]

Internet Draft                  presence               November 21, 2001


   sip:joe@yahoo.com as opposed to sip:joe@1.2.3.4). The request MUST
   contain a Contact header, Via header, Call-ID header and CSeq header
   as defined by SIP [2]. Other header usage is described in [2].

   This request is then sent. This MAY be done using the DNS procedures
   defined in [2] if the Request-URI contains a SIP URL, else the
   request MAY be sent to a configured local outbound proxy. If the
   client placed a presence URL in the Request-URI because it was unable
   to translate it, it MUST forward the request to a configured local
   outbound proxy.

   The SUBSCRIBE request is a non-INVITE transaction and follows the
   transaction rules defined in [2] as specified for BYE.

   A 2xx response to the SUBSCRIBE indicates that the subscription
   request has been accepted. A 202 in particular indicates that the
   subscription is pending (see below for the definition); however, the
   processing rules at the subscriber are independent of the particular
   2xx code.

   As discussed in [3], any accepted subscription needs to be refreshed
   as it is soft-state. When refreshing the subscription, the tag in the
   To field SHOULD equal the value of the tag in the To field in the 2xx
   response to SUBSCRIBE. Furthermore, the refresh SHOULD follow the
   rules in RFC 2543 [2] for request routing (using the Route, Record-
   Route, and Contact headers) as if a refresh were a re-INVITE within a
   call-leg. This results in efficient usage of proxy resources, ideally
   delivering refreshes directly to the PA that sent the 2xx.

5.7 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 processing at the PA of a SUBSCRIBE
   request.

   If a PA gets a SUBSCRIBE request, and the Request-URI identifies a
   user the PA is responsible for, but the To header does not, this
   means that the SUBSCRIBE was forwarded for some reason. Whether the
   PA is willing to accept subscriptions originally targeted to the user
   in the To field is a matter of local policy. If a PA decides not to,
   it SHOULD generate a 403 response.

   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.




Rosenberg et al.                                              [Page 7]

Internet Draft                  presence               November 21, 2001


   A presence agent MUST authenticate all subscription requests. This
   authentication can be done using any of the mechanisms defined for
   SIP, except that the SIP basic authentication mechanism MUST NOT be
   used. It is anticipated that authentication will often be established
   through transitive trust. Specifically, when user A generates a
   SUBSCRIBE for B@bar.com, his domain (say, foo.com) will use SIP proxy
   authentication mechanisms to identify him. The SUBSCRIBE is forwarded
   to the target domain over a secure connection, such as TLS. The
   nature of the trust relationship between bar.com and foo.com is that
   bar.com trusts that foo.com has authenticated all subscribes it
   receives over that secure connection. As such, the bar.com server
   need only verify that the SUBSCRIBE came over the secure connection.
   The SIP extension for caller identity and privacy [7] can be used to
   allow one domain to provide the authenticated identity to another,
   even while maintaining privacy. These mechanisms apply equally well
   to SUBSCRIBE requests for presence.

   It is RECOMMENDED that any subscriptions that are not authenticated
   do not cause state to be established in the PA. This can be
   accomplished by generating a 401 in response to the SUBSCRIBE, and
   then discarding all state for that transaction. Retransmissions of
   the SUBSCRIBE generate the same response, guaranteeing reliability
   even over UDP.

   Furthermore, 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 [8],
   RADIUS [9], or COPS [10], can also be 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 was
   present. The "watcherinfo" event sub-package for SIP [11] defines a
   means by which a PUA can become aware that a user has attempted to
   subscribe to it, and no authorization exists.

   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 known yet whether
   it is successful or rejected is pending. Generally, pending occurs
   when the server cannot obtain authorization at this time, and may be



Rosenberg et al.                                              [Page 8]

Internet Draft                  presence               November 21, 2001


   able to do so at a later time, when the presentity becomes available.

   If a PA wishes to communicate a successful subscription to the
   subscriber, it MUST send a 200 OK response to the SUBSCRIBE. If a PA
   wishes to communicate a rejected subscription to the subscriber, it
   MUST send a 603 response. If a PA wishes to communicate a pending
   subscription to the subscriber, it MUST send a 202 response. Note
   that the actual state of the subscription need not be what is
   communicated to the subscriber.

   Any other valid responses, as specified in [2] MAY be used as well.
   Any subscription that generates a 2xx response (which includes
   pending and successful subscriptions)MUST generate an immediate
   NOTIFY request which MAY conntain a presence document in a format
   acceptable to the subscriber (based on the Accept header in the
   subscription). 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.


        OPEN ISSUE: Once we finalize how subscription status is
        conveyed in the NOTIFY, that text will go here.

   Polite blocking, as described in [12], is possible by generating a
   200 OK to the subscription even though it has been rejected (or
   marked pending). Of course, an immediate NOTIFY MUST be sent also.
   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.

   In many cases, it is useful for the response to the SUBSCRIBE to
   provide the logical identity of the PA which generated the response.
   This may not be the same as the user that the SUBSCRIBE was
   originally targeted at, because of request forwarding. SIP extensions
   have been defined to provide this capability [7].

5.8 Notifier Generation of NOTIFY Requests

   If a subscription results in any 2xx response, that response MUST be
   followed by an immediate NOTIFY.


        OPEN ISSUE: handling of 2xx/NOTIFY race condition?

   That NOTIFY request MAY contain a body indicating the state of the



Rosenberg et al.                                              [Page 9]

Internet Draft                  presence               November 21, 2001


   presentity. In the case of a pending subscription, when final
   authorization is determined, another NOTIFY SHOULD be sent. If the
   result of the authorization decision was success, the NOTIFY SHOULD
   contain a presence document with the current state of the presentity.
   If the subscription is rejected, a NOTIFY MAY be sent, with a
   Subscription-Expires of duration zero and a reason code of "refused"
   to indicate the failure of the subscription.

   For any subscription that is immediately or eventually determined to
   be successful, notifications MAY be sent at later times, possibly
   when the presence state of the presentity changes.

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

   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 communications addresses
   changes. These notifications contain the complete and current
   presence state of the presentity as known to the presence agent.
   Future extensions MAY be defined that allow a subscriber to request
   that the notifications contain changes in presence information only,
   rather than complete state.

   The means by which the PA learns the state of the presentity are also
   outside the scope of this recommendation. Registrations can provide
   one way, although the means (if any) 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 upload 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 the
   standard SIP encryption mechanisms. The encryption should be
   performed using the key of the subscriber as identified in the From
   field of the SUBSCRIBE. Similarly, integrity of the notifications is
   important to subscribers. As such, the contents of the notifications
   SHOULD be authenticated using one of the standardized SIP mechanisms.
   Since the NOTIFY are generated by the presence server, which may not
   have access to the key of the user represented by the presentity, it
   will frequently be the case that the NOTIFY are signed by a third
   party. It is RECOMMENDED that the signature be by an authority over



Rosenberg et al.                                             [Page 10]

Internet Draft                  presence               November 21, 2001


   domain of the presentity. In other words, for a user
   pres:user@example.com, the signator of the NOTIFY SHOULD be the
   authority for example.com.


        OPEN ISSUE: We should do better here; recommending more
        specific things than "standard SIP encryption" - S/MIME,
        for example.

5.9 Subscriber Processing of NOTIFY Requests

   The NOTIFY requests contain presence documents which describe the
   presentity. The subscriber SHOULD reject, with a 481 response, all
   NOTIFY requests whose From field tag does not match the tag in the To
   field of the 2xx to the SUBSCRIBE. This means that only a single PA
   can be active for a particular subscription.


        OPEN ISSUE: What if the NOTIFY beats the 2xx back to the
        SUBSCRIBER? This is a sip-events issue, but the resolution
        affects us.

   The presence documents delivered in NOTIFY are ordered through the
   CSeq in the NOTIFY requests. The presence document in the NOTIFY
   request with the highest CSeq value is the current one.

   Assuming the NOTIFY request is valid, and authenticated, a 200
   response MUST be sent.

5.10 Handling of Forked Requests

   Since SUBSCRIBE is routed by proxies as any other method, it is
   possible that a subscription might fork. The result is that it might
   arrive at multiple devices which are configured to act as a PA for
   the same presentity. Some of these may respond with a 2xx response to
   the SUBSCRIBE. Based on the forking rules in SIP, only one of these
   responses is passed to the subscriber. However, the subscriber will
   receive notifications from each of those PA which accepted the
   subscriptions. The SIP event framework allows each package to define
   the handling for this case.

   The processing in this case is identical to the way INVITE would be
   handled. The 2xx response to the SUBSCRIBE will result in the
   installation of subscription state in the subscriber. The
   subscription is associated with the To and From (both with tags) and
   Call-ID from the 2xx. When notifications arrive, those from the PA's
   whose 2xx's were discarded in the forking proxy will not match the
   subscription ID stored at the subscriber (the From tags will differ).



Rosenberg et al.                                             [Page 11]

Internet Draft                  presence               November 21, 2001


   These SHOULD be responded to with a 481. This will disable the
   subscriptions from those PA.

   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 generated 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 present in a network server representing the
   presentity that has access to the total set of user presence to be
   aggregated.

5.11 Rate of Notifications

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive. As a result, it is RECOMMENDED
   that the PA not generate notifications for a single presentity at a
   rate faster than once every 5 seconds.

5.12 State Agents and Notifier Migration

   It is important to realize that the PA function can be colocated with
   several elements:

        o It can be co-located with the SIP registrar handling
          registrations for the presentity (the co-location of the PA
          within the proxy/registrar is known as a presence server). In
          this way, the presence server knows the presence of the user
          through registrations or other means.

        o It can be co-located with a PUA for that presentity (the co-
          location of the PA within the PUA is known as a presence
          client). In the case of a single PUA per presentity, the PUA
          knows the state of the presentity by sheer nature of its co-
          location.

        o It can be co-located in any server along the call setup path.
          That proxy can learn the presence state of the presentity by
          generating its own SUBSCRIBE in order to determine it. In this
          case, the PA is effectively a B2BUA.

   On occassion, it makes sense for the PA function to migrate from one
   of these places 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 decides to



Rosenberg et al.                                             [Page 12]

Internet Draft                  presence               November 21, 2001


   migrate subscriptions to it in order to reduce state in the network.

   There are three phases to this migration:

        o The element currently providing the PA function determines
          that another element is capable of handling the subscription.

        o That element currently hosting the PA function destroys
          subscription state, and inform those subscribers that the
          state needs to be re-established with a new SUBSCRIBE.

        o When the subscribers re-SUBSCRIBE, the request is proxied,
          eventually arriving at the new element performing the PA
          function. That element accepts the request and creates a
          subscription.

   The first of these phases can occur through configuration, or through
   dynamic means. One dynamic means for a presence server to discover
   that the function can migrate to a PUA is through the REGISTER
   message. Specifically, if a PUA wishes to indicate support for the PA
   function, it SHOULD include a contact address in its registration
   with a caller preferences "methods" parameter listing SUBSCRIBE [13].
   This indicates that it is capable of terminating and processing
   SUBSCRIBE, and therefore can act as a PA. However, just because a PUA
   indicates it can accept subscriptions, does not mean a PA should
   migrate the subscriptions there. In particular, a PA SHOULD NOT
   migrate the subscription if it is composing aggregated presence
   documents from state received from several PUA.

   Because of the forking rules described in Section 5.10, a subscriber
   will only get presence information from one PA, and this information
   has to be complete. Because the "methods" parameter does not convey
   the set of event packages for which the PUA can accept SUBSCRIBE, it
   is possible that the PUA will begin receiving SUBSCRIBE requests for
   other packages, possibly ones it doesn't support. As specified in
   [3], the PUA SHOULD reject those requests with a 489.

   For the second phase, the PA destroys the subscriptions and then
   sends a NOTIFY to each subscriber, with an Subscription-Expires
   header with value 0 [3] and a reason code of "migration". This
   informs the subscribers that their subscription was destroyed, and
   should be re-established with a new SUBSCRIBE (with a new Call-ID). A
   PA SHOULD rate limit the notifications, in order to avoid a flood of
   simultaneous re-SUBSCRIBEs from all subscribers.

   The subscribers then create brand new subscriptions, with a new
   Call-ID, no route set and no To tag, and this is sent to recreate the
   subscription. In the case where the subscription has migrated to the



Rosenberg et al.                                             [Page 13]

Internet Draft                  presence               November 21, 2001


   presence server, the presence server will simply act as a PA for
   these new subscriptions. In the case where the subscription has
   migrated from the presence server to the PUA, the presence server
   MUST operate like a proxy. Furthermore, it SHOULD implement the SIP
   Caller preferences extension [13]. Because of the existence of a
   registered Contact with a "methods" parameter containing SUBSCRIBE,
   the caller preferences extension will cause the proxy to send the
   SUBSCRIBEs to that Contact. Assuming it accepts, a 2xx is generated
   and forwarded to the subscriber. The subscriber will now receive and
   accept notifications from that PA.

   Migration of subscriptions will still work if the proxy does not
   support the caller preferences extension. However, the proxy will
   instead fork the SUBSCRIBE, possibly to Contacts which have not
   indicated that they support SUBSCRIBE. The result will be 405
   responses from those UAS. However, the one UAS which does support the
   method will generate a 2xx class response (assuming the subscription
   is accepted), and this will be correctly forwarded towards the
   subscriber based on proxy response processing rules [2]. The penalty
   of not supporting caller preferences is the additional unneeded SIP
   traffic.

6 Publication

   The user presence for a presentity can be obtained from any number of
   different ways. None of these mechanisms are mandated by this
   specification. The discussion here is for informational purposes
   only.

6.1 Co-location

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

6.2 REGISTER

   Baseline SIP defines a method that is used by all SIP clients - the
   REGISTER method. This method allows a UA to inform a SIP network of
   its current communications addresses (ie., Contact addresses) .
   Furthermore, multiple UA can independently register Contact addresses
   for the same SIP URL. These Contact addresses can be SIP URLs, or
   they can be any other valid URL.

   Usage of REGISTER information to construct presence is only possible
   if the PA is co-located with, or shares information with, the SIP
   registrar. In this case, the combined PA/registrar/proxy is known as
   a presence server.




Rosenberg et al.                                             [Page 14]

Internet Draft                  presence               November 21, 2001


   Using the register information for presence is straightforward. The
   address of record in the REGISTER (the To field) identifies the
   presentity. The Contact headers define communications addresses that
   describe the state of the presentity. The use of the SIP caller
   preferences extension [13] is RECOMMENDED for use with UAs that are
   interested in presence. It provides additional information about the
   Contact addresses that can be used to construct a richer presence
   document.

   The presence of a registered Contact with a "methods" parameter [13]
   listing the MESSAGE method implies that the presentity supports
   instant messaging as a communications means.

   The q values from the Contact header [2] can be used to establish
   priorities amongst the various communications addresses in the
   Contact headers.

   The application of registered contacts to presence increases the
   requirements for authenticity. Therefore, REGISTER requests used by
   presence user agents SHOULD be authenticated using either SIP
   authentication mechanisms, or a hop-by-hop mechanism.

6.3 Uploading Presence Documents

   If a means exists to upload presence documents from PUA to the PA,
   the PA can act as an aggregator and redistributor of those documents.
   The PA, in this case, would take the presence documents received from
   each PUA for the same presentity, and merge the communications means
   across all of those PUA into a single presence document. Typically,
   this aggregation would be accomplished through administrator or user
   defined policies about how the aggregation should be done.

   The specific means by which a presence document are uploaded to a
   presence agent are outside the scope of this specification. When a
   PUA wishes to have direct manipulation of the presence that is
   distributed to subscribers, direct uploading of presence documents is
   RECOMMENDED.

7 Security considerations

   There are numerous security considerations for presence. Many are
   outlined above; this section considers them issue by issue.

7.1 Firewall and NAT Traversal

   It is anticipated that presence services will be used by clients and
   presentities that are connected to proxy servers on the other side of
   firewalls and NATs. Fortunately, since the SIP presence messages do



Rosenberg et al.                                             [Page 15]

Internet Draft                  presence               November 21, 2001


   not establish independent media streams, as INVITE does, firewall and
   NAT traversal is straightforward.

   Specifically, the SIP extensions for NAT traversal [14] are directly
   applicable to SUBSCRIBE and NOTIFY, and will allow operation of the
   protocol through NATs. Firewall administrators can set policies that
   allow or disallow communications services by opening or closing
   access to port 5060 (the default SIP port).

7.2 Privacy

   Privacy encompasses many aspects of a presence system:

        o Subscribers may not want to reveal the fact that they have
          subscribed to certain users

        o Users may not want to reveal that they have accepted
          subscriptions from certain users

        o Notifications (and fetch results) may contain sensitive data
          which should not be revealed to anyone but the subscriber

   Privacy is provided through a combination of hop by hop encryption
   and end to end encryption. The hop by hop mechanisms provide scalable
   privacy services, disable attacks involving traffic analysis, and
   hide all aspects of presence messages. However, they operate based on
   transitivity of trust, and they cause message content to be revealed
   to proxies. The end-to-end mechanisms do not require transitivity of
   trust, and reveal information only to the desired recipient. However,
   end-to-end encryption cannot hide all information, and is susceptible
   to traffic analysis. Strong end to end authentication and encryption
   also requires that both participants have public keys, which is not
   generally the case. Thus, both mechanisms combined are needed for
   complete privacy services.

   SIP allows any hop by hop encryption scheme. It is RECOMMENDED that
   TLS [15] be used between elements to provide this function.  The
   presence server can determine whether TLS is supported by the
   receiving client based on the transport parameter in the Contact
   header of its registration. If there is a registered Contact with a
   URL that contains a transport parameter with value "tls", it implies
   that the PUA supports TLS.

   SIP encryption MAY be used end to end for the transmission of both
   SUBSCRIBE and NOTIFY requests.

7.3 Message integrity and authenticity




Rosenberg et al.                                             [Page 16]

Internet Draft                  presence               November 21, 2001


   It is important for the message recipient to ensure that the message
   contents are actually what was sent by the originator, and that the
   recipient of the message be able to determine who the originator
   really is. This applies to both requests and responses of SUBSCRIBE
   and NOTIFY. This is supported in SIP through end to end
   authentication and message integrity. SIP provides http basic and
   digest authentication. HTTP Basic is NOT RECOMMENDED.

7.4 Outbound authentication

   When local proxies are used for transmission of outbound messages,
   proxy authentication is RECOMMENDED. This is useful to verify the
   identity of the originator, and prevent spoofing and spamming at the
   originating network.

7.5 Replay prevention

   To prevent the replay of old subscriptions and notifications, all
   signed SUBSCRIBE and NOTIFY requests and responses MUST contain a
   Date header covered by the message signature. Any message with a date
   older than several minutes in the past, or more than several minutes
   into the future, SHOULD be discarded.

   Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a
   Call-ID and CSeq header covered by the message signature. A user
   agent or presence server MAY store a list of Call-ID values, and for
   each, the higest CSeq seen within that Call-ID. Any message that
   arrives for a Call-ID that exists, whose CSeq is lower than the
   highest seen so far, is discarded.

   Finally, challenge-response authentication MAY be used to prevent
   replay attacks.

7.6 Denial of service attacks

   Denial of service attacks are a critical problem for an open, inter-
   domain, presence protocol. Here, we discuss several possible attacks,
   and the steps we have taken to prevent them.

7.6.1 Smurf attacks through false contacts

   Unfortunately, presence is a good candidate for smurfing attacks
   because of its amplification properties. A single SUBSCRIBE message
   could generate a nearly unending stream of notifications, so long as
   a suitably dynamic source of presence data can be found. Thus, a
   simple way to launch an attack is to send subscriptions to a large
   number of users, and in the Contact header (which is where
   notifications are sent), place the address of the target.



Rosenberg et al.                                             [Page 17]

Internet Draft                  presence               November 21, 2001


   The only reliable way to prevent these attacks is through
   authentication and authorization. End users will hopefully not accept
   subscriptions from random unrecognized users. Also, the presence
   client software could be programmed to warn the user when the Contact
   header in a SUBSCRIBE is from a domain which does not match that of
   the From field (which identifies the subscriber).

   Also, note that as described in [3], if a NOTIFY is not acknowledged
   or was not wanted, the subscription that generated it is removed.
   This eliminates the amplification properties of providing false
   Contact addresses.

8 Example message flows

   The following subsections exhibit example message flows, to further
   clarify behavior of the protocol. When the value of the Content-
   Length header is "..." this means that the value should be whatever
   the computed length of the body is.

8.1 Client to Client Subscription with Presentity State Changes

   This call flow illustrates subscriptions and notifications that do
   not involve a presence server.

   The watcher subscribes to the presentity, and the subscription is
   authorized, resulting in a 200 OK response. The presentity
   subsequently changes state (is on the phone), resulting in a new
   notification. The flow finishes with the watcher terminating the
   subscription.




               Watcher                       Presentity
               -------                       -----------
                  |      F1 SUBSCRIBE             |
                  | ----------------------------->|
                  |      F2 200 OK                |
                  |<------------------------------|
                  |      F3 NOTIFY                |
                  |<------------------------------|
                  |      F4 200 OK                |
                  |------------------------------>|
                  |      F5 NOTIFY                |
                  |<------------------------------|
                  |      F6 200 OK                |
                  |------------------------------>|
                  |      F7 SUBSCRIBE (unsub)     |



Rosenberg et al.                                             [Page 18]

Internet Draft                  presence               November 21, 2001


                  |------------------------------>|
                  |      F8 200 OK                |
                  |<------------------------------|
                  |      F9 NOTIFY                |
                  |<------------------------------|
                  |      F10 200 OK               |
                  |------------------------------>|



   Message Details



     F1 SUBSCRIBE watcher -> presentity

        SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
        Via: SIP/2.0/UDP  watcherhost.example.com:5060
        From: User <sip:user@example.com>;tag=9988
        To: Resource <sip:presentity@example.com>
        Call-ID: 3248543@watcherhost.example.com
        CSeq : 1 SUBSCRIBE
        Expires: 600
        Accept: application/cpim-pidf+xml
        Event: presence
        Contact: sip:user@watcherhost.example.com
        Content-Length: 0





     F2 200 OK presentity->watcher

        SIP/2.0 200 OK
        Via: SIP/2.0/UDP watcherhost.example.com:5060
        From: User <sip:user@example.com>;tag=9988
        To: Resource <sip:presentity@example.com>;tag=88a7s
        Call-ID: 3248543@watcherhost.example.com
        Cseq: 1 SUBSCRIBE
        Event: presence
        Expires: 600
        Contact: sip:presentity@pres.example.com
        Content-Length: 0







Rosenberg et al.                                             [Page 19]

Internet Draft                  presence               November 21, 2001


     F3 NOTIFY Presentity->watcher

        NOTIFY sip:user@watcherhost.example.com SIP/2.0
        Via: SIP/2.0/UDP pres.example.com:5060
        From: Resource <sip:presentity@example.com>;tag=88a7s
        To: User <sip:user@example.com>;tag=9988
        Call-ID: 3248543@watcherhost.example.com
        CSeq: 1 NOTIFY
        Event: presence
        Content-Type: application/cpim-pidf+xml
        Content-Length: ...

     <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
        <tuple name="ph-1">
          <status>
            <value>open</value>
            <detail type="phone"
             schema="http://www.ietf.org/dtd/im-type-phone.dtd">on-hook</detail>
          </status>
          <contact priority="2">sip:user@example.com</contact>
        </tuple>
      </presence>





     F4 200 OK watcher->presentity

        SIP/2.0 200 OK
        Via: SIP/2.0/UDP pres.example.com:5060
        From: Resource <sip:presentity@example.com>;tag=88a7s
        To: User <sip:user@example.com>;tag=9988
        Call-ID: 3248543@watcherhost.example.com
        CSeq: 1 NOTIFY
        Content-Length: 0





     F5 NOTIFY Presentity->watcher

        NOTIFY sip:user@watcherhost.example.com SIP/2.0
        Via: SIP/2.0/UDP pres.example.com:5060
        From: Resource <sip:presentity@example.com>;tag=88a7s
        To: User <sip:user@example.com>;tag=9988
        Call-ID: 3248543@watcherhost.example.com



Rosenberg et al.                                             [Page 20]

Internet Draft                  presence               November 21, 2001


        CSeq: 2 NOTIFY
        Event: presence
        Content-Type: application/cpim-pidf+xml
        Content-Length: ...

     <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
        <tuple name="ph-1">
          <status>
            <value>closed</value>
            <detail type="phone"
             schema="http://www.ietf.org/dtd/im-type-phone.dtd">off-hook</detail>
          </status>
          <contact priority="2">sip:user@example.com</contact>
        </tuple>
      </presence>





     F6 200 OK watcher->presentity

        SIP/2.0 200 OK
        Via: SIP/2.0/UDP pres.example.com:5060
        From: Resource <sip:presentity@example.com>;tag=88a7s
        To: User <sip:user@example.com>;tag=9988
        Call-ID: 3248543@watcherhost.example.com
        CSeq: 2 NOTIFY
        Content-Length: 0





     F7 SUBSCRIBE watcher -> presentity

        SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
        Via: SIP/2.0/UDP  watcherhost.example.com:5060
        Call-ID: 3248543@watcherhost.example.com
        To: Resource <sip:presentity@example.com>;tag=88a7s
        From: User <sip:user@example.com>;tag=9988
        Event: presence
        CSeq : 2 SUBSCRIBE
        Expires: 0
        Accept: application/cpim-pidf+xml
        Contact: sip:user@watcherhost.example.com
        Content-Length: 0




Rosenberg et al.                                             [Page 21]

Internet Draft                  presence               November 21, 2001


     F8 200 OK presentity->watcher

        SIP/2.0 200 OK
        Via: SIP/2.0/UDP watcherhost.example.com:5060
        Call-ID: 3248543@watcherhost.example.com
        To: Resource <sip:presentity@example.com>;tag=88a7s
        From: User <sip:user@example.com>;tag=9988
        Event: presence
        Cseq: 2 SUBSCRIBE
        Expires:0
        Contact: sip:presentity@pres.example.com
        Content-Length: 0






     F9 NOTIFY Presentity->watcher

        NOTIFY sip:user@watcherhost.example.com SIP/2.0
        Via: SIP/2.0/UDP pres.example.com:5060
        From: Resource <sip:presentity@example.com>;tag=88a7s
        To: User <sip:user@example.com>;tag=9988
        Call-ID: 3248543@watcherhost.example.com
        CSeq: 3 NOTIFY
        Event: presence
        Content-Type: application/cpim-pidf+xml
        Content-Length: ...

     <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
        <tuple name="ph-1">
          <status>
            <value>closed</value>
            <detail type="phone"
             schema="http://www.ietf.org/dtd/im-type-phone.dtd">off-hook</detail>
          </status>
          <contact priority="2">sip:user@example.com</contact>
        </tuple>
      </presence>





     F10 200 OK watcher->presentity

        SIP/2.0 200 OK



Rosenberg et al.                                             [Page 22]

Internet Draft                  presence               November 21, 2001


        Via: SIP/2.0/UDP pres.example.com:5060
        From: Resource <sip:presentity@example.com>;tag=88a7s
        To: User <sip:user@example.com>;tag=9988
        Call-ID: 3248543@watcherhost.example.com
        CSeq: 3 NOTIFY
        Content-Length: 0



8.2 Presence Server with Client Notifications

   This call flow shows the involvement of a presence server in the
   handling of subscriptions. In this scenario, the client has indicated
   that it will handle subscriptions and thus notifications. The message
   flow shows a change of presence state by the client and a
   cancellation of the subscription by the watcher.





                              Presence
       Watcher                 Server                  PUA
          |                      |  F1 REGISTER         |
          |                      |<---------------------|
          |                      |  F2 200 OK           |
          |                      |--------------------->|
          |  F3 SUBSCRIBE        |                      |
          |--------------------->|                      |
          |                      |  F4 SUBSCRIBE        |
          |                      |--------------------->|
          |                      |  F5 200              |
          |                      |<---------------------|
          |  F6 200              |                      |
          |<---------------------|                      |
          |  F7 NOTIFY           |                      |
          |<--------------------------------------------+
          |  F8  200 OK          |                      |
          |-------------------------------------------->|
          |                      |  F9 REGISTER         |
          |                      |<---------------------|
          |                      |  F10 200 OK          |
          |                      |--------------------->|
          |  F11 NOTIFY          |                      |
          |<--------------------------------------------+
          |  F12 200 OK          |                      |
          |-------------------------------------------->|




Rosenberg et al.                                             [Page 23]

Internet Draft                  presence               November 21, 2001


   Message Details



     F1  REGISTER  PUA->server

       REGISTER sip:example.com SIP/2.0
       Via: SIP/2.0/UDP pua.example.com:5060
       To: <sip:resource@example.com>
       From: <sip:resource@example.com>
       Call-ID: 2818@pua.example.com
       CSeq: 1 REGISTER
       Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
       Expires: 600
       Content-Length: 0






     F2  200 OK    server->PUA

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP pua.example.com:5060
       To: <sip:resource@example.com>
       From: <sip:resource@example.com>
       Call-ID: 2818@pua.example.com
       CSeq: 1 REGISTER
       Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
       Expires: 600
       Content-Length: 0







     F3  SUBSCRIBE watcher->server

       SUBSCRIBE sip:resource@example.com SIP/2.0
       Via: SIP/2.0/UDP  watcherhost.example.com:5060
       From: User <sip:user@example.com>;tag=ggf8
       To: Resource <sip:resource@example.com>
       Call-ID: 32485@watcherhost.example.com
       CSeq : 1 SUBSCRIBE
       Expires: 600



Rosenberg et al.                                             [Page 24]

Internet Draft                  presence               November 21, 2001


       Event: presence
       Accept: application/cpim-pidf+xml
       Contact: sip:user@watcherhost.example.com
       Content-Length: 0







     F4  SUBSCRIBE server->PUA

       SUBSCRIBE sip:id@pua.example.com SIP/2.0
       Via: SIP/2.0/UDP server.example.com:5060
       Via: SIP/2.0/UDP watcherhost.example.com:5060
       From: User <sip:user@example.com>;tag=ggf8
       To: Resource <sip:resource@example.com>
       Call-ID: 32485@watcherhost.example.com
       CSeq : 1 SUBSCRIBE
       Event: presence
       Expires: 600
       Accept: application/cpim-pidf+xml
       Contact: sip:user@watcherhost.example.com
       Content-Length: 0






     F5  200 OK    PUA->server

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP server.example.com:5060
       Via: SIP/2.0/UDP watcherhost.example.com:5060
       From: User <sip:user@example.com>;tag=ggf8
       To: Resource <sip:resource@example.com>;tag=ffd2
       Call-ID: 32485@watcherhost.example.com
       CSeq : 1 SUBSCRIBE
       Event: presence
       Expires: 600
       Contact: sip:id@pua.example.com
       Content-Length: 0







Rosenberg et al.                                             [Page 25]

Internet Draft                  presence               November 21, 2001


     F6  200 OK    server->watcher

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP watcherhost.example.com:5060
       From: User <sip:user@example.com>;tag=ggf8
       To: Resource <sip:resource@example.com>;tag=ffd2
       Call-ID: 32485@watcherhost.example.com
       CSeq : 1 SUBSCRIBE
       Event: presence
       Expires: 600
       Contact: sip:id@pua.example.com
       Content-Length: 0






     F7  NOTIFY    PUA->watcher

       NOTIFY sip:user@watcherhost.example.com SIP/2.0
       Via: SIP/2.0/UDP pua.example.com:5060
       To: User <sip:user@example.com>;tag=ggf8
       From: Resource <sip:resource@example.com>;tag=ffd2
       Call-ID: 32485@watcherhost.example.com
       CSeq : 1 NOTIFY
       Event: presence
       Content-Type: application/cpim-pidf+xml
       Content-Length: ...

     <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
        <tuple name="im-1">
          <status>
            <value>open</value>
            <detail type="im"
             schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
          </status>
          <contact priority="2">im:user@example.com</contact>
        </tuple>
      </presence>







     F8 200 OK    watcher->PUA



Rosenberg et al.                                             [Page 26]

Internet Draft                  presence               November 21, 2001


       SIP/2.0 200 OK
       Via: SIP/2.0/UDP pua.example.com:5060
       To: User <sip:user@example.com>;tag=ggf8
       From: Resource <sip:resource@example.com>;tag=ffd2
       Call-ID: 32485@watcherhost.example.com
       CSeq : 1 NOTIFY
       Content-Length: 0






     F9  REGISTER  PUA->server

       REGISTER sip:example.com SIP/2.0
       Via: SIP/2.0/UDP pua.example.com:5060
       To: <sip:resource@example.com>
       From: <sip:resource@example.com>
       Call-ID: 2818@pua.example.com
       CSeq: 2 REGISTER
       Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBCSRIBE"
                 ;q=0.0
       Expires: 600
       Content-Length: 0







     F10  200 OK    server->PUA

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP pua.example.com:5060
       To: <sip:resource@example.com>
       From: <sip:resource@example.com>
       Call-ID: 2818@pua.example.com
       CSeq: 2 REGISTER
       Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
                 ;q=0.0
       Expires: 600
       Content-Length: 0







Rosenberg et al.                                             [Page 27]

Internet Draft                  presence               November 21, 2001


     F11  NOTIFY    PUA->watcher

       NOTIFY sip:user@watcherhost.example.com SIP/2.0
       Via: SIP/2.0/UDP pua.example.com:5060
       To: User <sip:user@example.com>;tag=ggf8
       From: Resource <sip:resource@example.com>;tag=ffd2
       Call-ID: 32485@watcherhost.example.com
       CSeq : 2 NOTIFY
       Event: presence
       Content-Type: application/cpim-pidf+xml
       Content-Length: ...

     <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
        <tuple name="im-1">
          <status>
            <value>open</value>
            <detail type="im"
             schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
          </status>
          <contact priority="2">im:user@example.com</contact>
        </tuple>
      </presence>







     F12 200 OK    watcher->PUA

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP pua.example.com:5060
       To: User <sip:user@example.com> ;tag=ggf8
       From: Resource <sip:resource@example.com>;tag=ffd2
       Call-ID: 32485@watcherhost.example.com
       CSeq : 2 NOTIFY
       Content-Length: 0




8.3 Presence Server Notifications

   This message flow illustrates how the presence server can be the
   responsible for sending notifications for a presentity. This flow
   assumes that the watcher has previously been authorized to subscribe
   to this resource at the server.



Rosenberg et al.                                             [Page 28]

Internet Draft                  presence               November 21, 2001


   In this flow, the PUA informs the server about the updated presence
   information though some non-SIP means.




   Watcher             Server                 PUA
      | F1 SUBSCRIBE      |                    |
      |------------------>|                    |
      | F2 200 OK         |                    |
      |<------------------|                    |
      | F3 NOTIFY         |                    |
      |<------------------|                    |
      | F4 200 OK         |                    |
      |------------------>|                    |
      |                   |                    |
      |                   |   Update presence  |
      |                   |<------------------ |
      |                   |                    |
      | F5 NOTIFY         |                    |
      |<------------------|                    |
      | F6 200 OK         |                    |
      |------------------>|                    |



   Message Details



   F1 SUBSCRIBE   watcher->server

      SUBSCRIBE sip:resource@example.com SIP/2.0
      Via: SIP/2.0/UDP watcherhost.example.com:5060
      To: <sip:resource@example.com>
      From: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 1 SUBSCRIBE
      Event: presence
      Accept: application/cpim-pidf+xml
      Contact: <sip:user@watcherhost.example.com>
      Expires: 600
      Content-Length: 0








Rosenberg et al.                                             [Page 29]

Internet Draft                  presence               November 21, 2001


   F2 202 OK   server->watcher

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP watcherhost.example.com:5060
      To: <sip:resource@example.com>;tag=ffd2
      From: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 1 SUBSCRIBE
      Event: presence
      Expires: 600
      Contact: sip:example.com
      Content-Length: 0





   F3 NOTIFY  server-> watcher

      NOTIFY sip:user@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/UDP server.example.com:5060
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      Event: presence
      CSeq: 1 NOTIFY
      Content-Type: application/cpim-pidf+xml
      Content-Length: ..

     <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
        <tuple name="im-1">
          <status>
            <value>open</value>
            <detail type="im"
             schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
          </status>
          <contact priority="2">im:user@example.com</contact>
        </tuple>
      </presence>






   F4 200 OK

      SIP/2.0 200 OK



Rosenberg et al.                                             [Page 30]

Internet Draft                  presence               November 21, 2001


      Via: SIP/2.0/UDP server.example.com:5060
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 1 NOTIFY
      Content-Length: 0





   F5 NOTIFY

      NOTIFY sip:user@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/UDP server.example.com:5060
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 2 NOTIFY
      Event: presence
      Content-Type: application/cpim-pidf+xml
      Content-Length: ...

     <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
        <tuple name="im-1">
          <status>
            <value>closed</value>
            <detail type="im"
             schema="http://www.ietf.org/dtd/im-type-im.dtd">busy</detail>
          </status>
          <contact priority="2">im:user@example.com</contact>
        </tuple>
      </presence>







   F6 200 OK

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP server.example.com:5060
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 2 NOTIFY



Rosenberg et al.                                             [Page 31]

Internet Draft                  presence               November 21, 2001


      Content-Length: 0




9 Changes from draft-ietf-simple-presence-03

        o When migrating subscriptions, a PA SHOULD rate limit its
          notifications in order to avoid a flood of simultaneous re-
          subscriptions.

        o Clarified that there can be multiple PAs for a presentity.

        o Fixed last of 2xx/200/202 confusions.

        o Added text to handle the case where a PUA receives
          subscriptions for Event packages it doesn't understand,
          because it registered support for the SUBSCRIBE method.

        o Alignment with events-01

        o Migration recommended only if PA is not generating presence
          documents composed from multiple sources.

10 Changes from draft-ietf-simple-presence-02

        o No longer calling this document an extension, since its not.
          Its an Event Package.

        o Clarified migration section so that applies equally well to PS
          to PUA, and PUA to PS. Previous text assumed PS to PUA only.

        o Changed the default filter to "no filter".

        o Removed Section 6.4 on "Call State Subscription" since it is
          informational but may confused those not familiar with the
          referenced work.

        o Removed PGP references since these have been deprecated from
          SIP.

        o We now allow a proxy to migrate a subscription even if there
          are multiple registered contacts supporting SUBSCRIBE. The
          text has clarified that a PUA should only register support for
          SUBSCRIBE if it has complete state about the presentity.

11 Changes from draft-ietf-simple-presence-01




Rosenberg et al.                                             [Page 32]

Internet Draft                  presence               November 21, 2001


        o Complete alignment with draft-ietf-sip-events.

        o Removal of non-confirming mode. Instead, just mention that
          polite blocking is possible, and how it is done is
          implementation specific.

        o Removed CPIM sections to a separate specification.

        o Added reference to privacy specification for transitive
          authentication scenarios.

        o Implementation of caller preferneces by presence servers is
          now a SHOULD.

        o Clarification on the process of subscription migration.

        o For subscription migration, the specification now mentions the
          Subscription-Expires header as the means for a PA to inform
          subscribers that their subscription has expired. This header
          has yet to appear in draft-ietf-sip-events.

        o Updated section of usage of presence URLs based on consensus
          of the IMPP group at IETF 51.

        o Construction of presence documents based on REGISTER is now
          defined as implementation dependent. If a UA wants to
          manipulate its presence, it should upload a presence document
          fragment instead.

        o Removed bit about recreating subscriptions when a 481 is
          received to a SUBSCRIBE request. This should be in draft-
          ietf-sip-events instead.

        o Removed references to draft-lennox-sip-reg-payload and much of
          that discussion. Now, the section talks more generally about
          uploading and aggregation of presence documents, and simply
          states that the means for such upload is outside the scope of
          this spec.

        o Updated example flows. Consistent use of From tags,
          elimination of pres URL, usage of application/cpim-pidf+xml
          types. Fixed caller preferences usage bug.

12 Changes from draft-ietf-simple-presence-00

        o Clarified that user presence can be obtained in many ways, not
          just SIP.




Rosenberg et al.                                             [Page 33]

Internet Draft                  presence               November 21, 2001


        o Defined the default notification content when a filter is not
          provided in the body of a SUBSCRIBE.

        o Removed text about the inability of a PA to increase a
          subscription expiration time (this needs to be reconciled with
          draft-ietf-sip-events.

        o Removed requirement that authentication be end-to-end only,
          and not transitive. This is not practical at all, and
          transitive trust is likely to be the only deployable mechanism
          initially.

        o Removed the Appendix on the watcher info mechanism for
          triggering authorization decisions; draft-ietf-simple-winfo-
          package is now referenced.

        o Defined confirming and non-confirming modes for revealing
          authorization information.

        o Strengthened the section about how a PA obtains information
          about the presentity.

        o Updated section on migrating PA function.

        o Added requirement that a subscriber generate a new
          subscription when a refresh fails with a 481.

        o Removed transport mode ESP as the reccommended inter-server
          transport. TLS is now consistently recommended.

        o Removed insertion of tls transport parameter into Contact
          header in 200 OK response to SUBSCRIBE. This is because this
          parameter needs to be UDP for interoperability.

13 Changes from draft-rosenberg-impp-presence-01

   Renamed to draft-ietf-simple-presence-00.

14 Changes from draft-rosenberg-impp-presence-00

   The document has been completely rewritten, to reflect the change
   from a sales pitch and educational document, to a more formal
   protocol specification. It has also been changed to align with the
   SIP event architecture and with CPIM. The specific protocol changes
   resulting from this rewrite are:

        o The Event header must now be used in the SUBSCRIBE and NOTIFY
          requests.



Rosenberg et al.                                             [Page 34]

Internet Draft                  presence               November 21, 2001


        o The SUBSCRIBE message can only have a single Contact header.
          -00 allowed for more than one.

        o The From and To headers can contain presence URIs.

        o The Request-URI can contain a presence URI.

        o Subscriptions are responded to with a 202 if they are pending
          or accepted.

        o Presence documents are not returned in the body of the
          SUBSCRIBE response. Rather, they are sent in a separate
          NOTIFY. This more cleanly separates subscription and
          notification, and is mandated by alignment with CPIM.

        o Authentication is now mandatory at the PA. Authorization is
          now mandatory at the PA.

        o Fake NOTIFY is sent for pending or rejected subscriptions.

        o A rate limit on notifications was introduced.

        o Merging of presence data has been removed.

        o The subscriber rejects notifications received with tags that
          don't match those in the 202 response to the SUBSCRIBE. This
          means that only one PA will hold subscription state for a
          particular subscriber for a particular presentity.

        o IM URLs allowed in Contacts in register

        o CPIM mappings defined.

        o Persistent connections recommended for firewall traversal.

15 Acknowledgements

   We would like to thank the following people for their support and
   comments on this draft:


   Rick Workman     Nortel
   Adam Roach       Ericsson
   Sean Olson       Ericsson
   Billy Biggs      University of Waterloo
   Stuart Barkley   UUNet
   Mauricio Arango  SUN
   Richard Shockey  Shockey Consulting LLC



Rosenberg et al.                                             [Page 35]

Internet Draft                  presence               November 21, 2001


   Jorgen Bjorkner  Hotsip
   Henry Sinnreich  MCI Worldcom
   Ronald Akers     Motorola


16 Authors Addresses



   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com

   Dean Willis
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   email: dwillis@dynamicsoft.com

   Robert Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   email: rsparks@dynamicsoft.com

   Ben Campbell
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   email: bcampbell@dynamicsoft.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu

   Jonathan Lennox
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003



Rosenberg et al.                                             [Page 36]

Internet Draft                  presence               November 21, 2001


   email: lennox@cs.columbia.edu

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   email: huitema@microsoft.com

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   email: bernarda@microsoft.com

   David Gurle
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   email: dgurle@microsoft.com

   David Oran
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA 95134
   email: oran@cisco.com




17 Bibliography

   [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
   instant messaging," Request for Comments 2778, Internet Engineering
   Task Force, Feb.  2000.

   [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [3] A. Roach, "SIP-specific event notification," Internet Draft,
   Internet Engineering Task Force, Nov. 2001.  Work in progress.

   [4] D. Crocker et al.  , "A common profile for instant messaging
   (CPIM)," Internet Draft, Internet Engineering Task Force, Feb. 2001.
   Work in progress.

   [5] A. Roach, "Event notification in SIP," Internet Draft, Internet
   Engineering Task Force, Feb. 2001.  Work in progress.



Rosenberg et al.                                             [Page 37]

Internet Draft                  presence               November 21, 2001


   [6] H. Sugano and S. Fujimoto, "CPIM presence information data
   format," Internet Draft, Internet Engineering Task Force, Aug. 2001.
   Work in progress.

   [7] B. Marshall et al.  , "SIP extensions for caller identity and
   privacy," Internet Draft, Internet Engineering Task Force, Mar. 2001.
   Work in progress.

   [8] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, and G.
   Zorn, "Diameter base protocol," Internet Draft, Internet Engineering
   Task Force, July 2001.  Work in progress.

   [9] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote
   authentication dial in user service (RADIUS)," Request for Comments
   2865, Internet Engineering Task Force, June 2000.

   [10] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A.
   Sastry, "The COPS (common open policy service) protocol," Request for
   Comments 2748, Internet Engineering Task Force, Jan. 2000.

   [11] J. Rosenberg, "A SIP event sub-package for watcher information,"
   Internet Draft, Internet Engineering Task Force, July 2001.  Work in
   progress.

   [12] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
   / presence protocol requirements," Request for Comments 2779,
   Internet Engineering Task Force, Feb. 2000.

   [13] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
   callee capabilities," Internet Draft, Internet Engineering Task
   Force, Nov. 2000.  Work in progress.

   [14] J. Rosenberg, J. Weinberger, and H. Schulzrinne, "SIP extensions
   for NAT traversal," Internet Draft, Internet Engineering Task Force,
   Aug. 2001.  Work in progress.

   [15] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
   for Comments 2246, Internet Engineering Task Force, Jan. 1999.





                           Table of Contents



   1          Introduction ........................................    1



Rosenberg et al.                                             [Page 38]

Internet Draft                  presence               November 21, 2001


   2          Definitions .........................................    2
   3          Overview of Operation ...............................    3
   4          Usage of Presence URLs ..............................    4
   5          Presence Event Package ..............................    5
   5.1        Package Name ........................................    5
   5.2        Event Package Parameters ............................    5
   5.3        SUBSCRIBE bodies ....................................    5
   5.4        Subscription Duration ...............................    6
   5.5        NOTIFY Bodies .......................................    6
   5.6        Subscriber Generation of SUBSCRIBE Requests .........    6
   5.7        Notifier Processing of SUBSCRIBE Requests ...........    7
   5.8        Notifier Generation of NOTIFY Requests ..............    9
   5.9        Subscriber Processing of NOTIFY Requests ............   11
   5.10       Handling of Forked Requests .........................   11
   5.11       Rate of Notifications ...............................   12
   5.12       State Agents and Notifier Migration .................   12
   6          Publication .........................................   14
   6.1        Co-location .........................................   14
   6.2        REGISTER ............................................   14
   6.3        Uploading Presence Documents ........................   15
   7          Security considerations .............................   15
   7.1        Firewall and NAT Traversal ..........................   15
   7.2        Privacy .............................................   16
   7.3        Message integrity and authenticity ..................   16
   7.4        Outbound authentication .............................   17
   7.5        Replay prevention ...................................   17
   7.6        Denial of service attacks ...........................   17
   7.6.1      Smurf attacks through false contacts ................   17
   8          Example message flows ...............................   18
   8.1        Client to Client Subscription with Presentity
   State Changes ..................................................   18
   8.2        Presence Server with Client Notifications ...........   23
   8.3        Presence Server Notifications .......................   28
   9          Changes from draft-ietf-simple-presence-03 ..........   32
   10         Changes from draft-ietf-simple-presence-02 ..........   32
   11         Changes from draft-ietf-simple-presence-01 ..........   32
   12         Changes from draft-ietf-simple-presence-00 ..........   33
   13         Changes from draft-rosenberg-impp-presence-01 .......   34
   14         Changes from draft-rosenberg-impp-presence-00 .......   34
   15         Acknowledgements ....................................   35
   16         Authors Addresses ...................................   36
   17         Bibliography ........................................   37









Rosenberg et al.                                             [Page 39]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/