Internet Draft
Internet Engineering Task Force                                  IMPP WG
Internet Draft                                        Jonathan Rosenberg
                                                             Dean Willis
                                                           Robert Sparks
                                                            Ben Campbell
                                                             dynamicsoft

                                                     Henning Schulzrinne
                                                         Jonathan Lennox
                                                             Columbia U.

                                                           Bernard Aboba
                                                       Christian Huitema
                                                             David Gurle
                                                               Microsoft

                                                               Dave Oran
                                                                   Cisco
draft-rosenberg-impp-presence-00.txt
June 15, 2000
Expires: December, 2000


                      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

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document proposes an extension to SIP for subscriptions and
   notifications of user presence. Traditional SIP clients already make
   use of the REGISTER method to upload presence state to network
   servers, in order to enable call establishment. This extension allows
   that data to be published to subscribers. This is accomplished by
   defining two new SIP methods - SUBSCRIBE and NOTIFY, and by defining
   a new logical entity, the presence agent (PA), which handles
   subscriptions and notifications.


1 Introduction

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



Rosenberg et al.                                              [Page 1]

Internet Draft                  presence                   June 15, 2000


   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 an extension to the Session Initiation
   Protocol (SIP) [2] for presence. Baseline SIP is used primarily for
   initiation of interactive sessions, such as voice, video, and games.
   The process of session initiation requires a system which uses the
   communications means, communications addresses, and communications
   status of a user in order to determine the host where initiation
   requests can be delivered. A presence system is one where this
   information is pushed to subscribers through notification requests,
   as opposed to being pulled by proxy and redirect servers when session
   establishment is desired. In a sense, this makes presence and session
   initiation "duals" - one is synchronous (presence systems push data
   the instant it changes) and the other is asynchronous (servers access
   presence data for a user at the point where a call is initiated to
   that user). The similarities between presence and communications
   establishment is one reason why we chose to base the presence
   protocol on SIP. Section 2 explains this in greater detail.

   The extension defined here has, as its objectives, scalability,
   security, flexibility, and extensibility. To provide scale, our
   protocol (1) pushes intelligence to the periphery wherever possible,
   as we believe this to be the primary tool for achieving this goal,
   (2) allows the global namespace to be divided into a hierarchy, and
   (3) allows presence state to be distributed along this hierarchy.
   Many of the capabilities of this extension for providing scale are
   simply inherited from SIP, which was engineered to handle highly
   scalable communications establishment. This extension also makes
   communications between differing administrative domains possible. The
   scale objectives and mechanisms for achieving it are outlined in
   detail in section 9.

   Presence deals with highly sensitive data regarding people, and we
   can envision future applications which deal with information like the
   physical location of individuals, which is even more sensitive. To
   handle this, privacy of the information distributed, and
   authentication of relevant parties in the system is provided by the
   system.

   Finally, flexibility is important. It is likely that a protocol for
   subscription and notification of events related to communications
   will be applied to other applications. Even within the general area
   of communications, subscription and notification services are needed
   for features like auto callback and message waiting indication. While
   these are not directly addressed by this extension, we have
   engineered in sufficient flexibility to enable them in a systematic



Rosenberg et al.                                              [Page 2]

Internet Draft                  presence                   June 15, 2000


   fashion. This is accomplished by separating the protocol operation
   from the underlying transport (UDP, TCP, or anything else can be
   used), and by separating the transfer of subscriptions and
   notifications from their content. The extension is also flexible in
   that it can support client to client subscriptions and notifications
   with no server at all (serverless operation), support a single server
   for intra-domain operation, multiple servers for intra-domain
   operation, and inter-domain operation with a server in one domain,
   the other, or both.

2 Why use SIP as a base protocol for presence?

   We have chosen the Session Initiation Protocol (SIP) as a starting
   point for developing a presence protocol. This is for many reasons.
   Overall, our aim is to reuse infrastructure and components which help
   solve the problem. We have found that SIP solves a very similar
   problem, with the result that minimal work is required to extend it
   to solve the problem at hand.

   SIPs primary function is to initiate interactive multiparty
   communications sessions. The challenge in doing this is to allow a
   caller to take a location independent identifier, such as
   joe@example.com, and use it to discover the location of the user
   (where location in this context refers to a host on the Internet
   where the user can be reached), so that the invitation to join a
   session can be delivered. The problem is challenging because users
   move around, have dynamically assigned IP addresses, may be reachable
   at numerous locations and via multiple devices, and may have varying
   capabilities at those locations. SIP operates by allowing users to
   send communications reachability state to the network, and this
   information is used by the network to "rendezvous" the caller with
   the called party. Within baseline SIP, this communications
   reachability state consists primarily of communications addresses.
   However, an extension, caller preferences and callee capabilities
   [3], extends this state to include status and capabilities. This
   enables a much more powerful form of rendezvous. For example, a
   caller can dial a generic number for the called party, specify in the
   call establishment request that communications is desired with a
   mobile phone, and the call will be preferentially routed to the users
   cell phone.

   We observed that the information used by network elements within SIP
   to rendezvous callers with called users is the *same* information
   distributed by a presence protocol. The only difference is in the
   application of this information. In SIP, this information is not
   distributed to interested parties when it changes, but rather used on
   demand to set up a call. In essence, SIP makes use of this state
   (uploaded to the network in REGISTER requests) for asynchronously



Rosenberg et al.                                              [Page 3]

Internet Draft                  presence                   June 15, 2000


   initiated queries for communications, while presence distributes it
   synchronously when it changes. Effectively, session initiation and
   presence are "duals" of each other, relying on the same information.
   Because of this, extension of SIP to satisfy the needs of a presence
   protocol seems very sensible - a re-use of "information".

   There is also significant reuse of protocol machinery, and more
   importantly, reuse of deployed components, infrastructure, and data.
   Conceptually, using the same infrastructure for initiation of
   communications, and for distribution of communications state, seems
   natural. It means that the same system provides both components of
   interactive communications services, working seamlessly and
   efficiently. Reuse of the same infrastructure means a big reduction
   in management and infrastructure costs for providers. Perhaps most
   importantly, using the same underlying protocols and infrastructures
   makes it easy to provide new services which integrate voice/video and
   presence.

   Furthermore, we anticipate that many systems will offer both
   communications establishment and presence on the same device, such as
   a wireless handset. Therefore, using the same underlying protocol
   components for both is a substantial practical advantage in terms of
   code reuse and memory footprint reduction, both of which are very
   important for wireless handsets. Real SIP implementations exist with
   memory footprints well under 100k. As only a subset of SIP is needed
   for presence, this number will be even lower for presence-only
   systems.

   The abstract arguments made in the previous paragraph manifest
   themselves through a common set of requirements for both presence and
   session initiation. As a result, there are many capabilities already
   present in SIP which are directly applicable to presence. In
   particular:

        Scale: SIP must scale to support initiation of communications
             sessions among the global Internet populace. This presents
             demanding scale requirements. To meet them, SIP allows for
             the global namespace of users to be divided up
             hierarchically, with dynamic communications state stored
             only in the leaves of the hierarchy. Network elements
             (called proxies) within the hierarchy can be stateless,
             handling routing of requests downward in the hierarchy, and
             responses upwards, without storing any information. This
             simulaneously provides both scale and fault tolerance.


        Rendezvous: SIP must allow a caller to have an initiation
             request routed to the server which has authoritative



Rosenberg et al.                                              [Page 4]

Internet Draft                  presence                   June 15, 2000


             information about the location and communications
             capabilities of the called user. For presence, a mechanism
             is needed to route subscription requests to the server
             which has authoritative information about the location and
             communications capabilities of the subscribed-to user.
             Clearly, these are the same exact problem, and SIPs
             existing rendezvous and routing capabilities are directly
             applicable for presence.


        Identity of Participants: In SIP, it is critical to be able to
             identify the initiator of the request, and the target of
             the communications. In presence, messages need to identify
             the initiator of the subscription, and its target. These
             are the same parties. The SIP mechanisms for identification
             of entities are therefore directly usable for presence.


        Authentication of Initiator: In SIP, it is essential that the
             called party be able to verify the identity of the caller,
             in order to prevent calls from unwanted parties. In
             presence, it is essential that the presentity be able to
             verify the identity of the subscriber, in order to prevent
             subscriptions from unwanted parties. Both are the same
             problem, and readily accomplished with end to end
             authentication mechanisms. SIP currently provides three
             such mechanisms, one of which is public key based (PGP),
             and the other two of which are based on a shared secret
             (http basic and digest). The protocol is extensible to
             support additional mechanisms. Furthermore, SIP provides
             proxy-signed requests, so that the presentity can verify
             the domain of the originator.


        End-to-end privacy of Data: In SIP, the bodies, and several of
             the headers of the request and response messages can be
             encrypted, using PGP. This allows for privacy of sessions
             users are being invited to. For presence, there is a need
             for end to end privacy of the presence state users convey,
             which is also encapsulated in bodies. Thus, the SIP
             encryption mechanisms can provide privacy for presence.


        Hop-by-Hop Encryption: End to end encryption is important, but
             requires deployment of a PKI with end user keys. As none
             really exists, a secondary level of privacy can be provided
             when a transitive trust relationship exists between users
             and network elements of multiple administrative domains.



Rosenberg et al.                                              [Page 5]

Internet Draft                  presence                   June 15, 2000


             This is through hop by hop encryption between users and
             proxies and proxies and proxies. SIP allows hop by hop
             encryption based on any number of mechanisms, and this
             concept can be reused for privacy of presence as well.


        Content: SIP uses MIME to carry content in its messages.
             Normally, this content is the Session Description Protocol
             (SDP) [4] which defines sessions, but other content is
             allowed. Subscription requests need to carry documents that
             describe details of the subscription, and notification
             requests carry documents that describe the state of the
             presentity. We propose that MIME is also used for this
             purpose. This provides important extensibility
             capabilities. As these capabilities are already provided by
             SIP, no additional work is needed to support them in
             presence.


        Transport Independence: SIP is used to establish communications
             sessions. A widely varying set of devices is likely to make
             use of such services, including PCs, wireless PDAs (in
             fact, the 3GPP wireless standards body has already chosen
             SIP as the signaling platform for third generation wireless
             devices), standalone phones, cell phones, laptops, and even
             Internet appliances. In recognition of the diverse
             connectivity these devices have, SIP is transport neutral,
             and can run over any protocol, including TCP and UDP. It
             can also be run over the newer SCTP [5], and a process for
             doing so is defined in a companion document [6].


        Soft State: In SIP, the communications state pushed into the
             network must be periodically refreshed in order for it to
             remain present. This soft state mechanism provides
             robustness against system crashes. The period of refresh
             can be negotiated through a simple two phase mechanism. In
             presence, this mechanism is not only needed for
             communications state, but also for subscriptions, which
             represent a new piece of state in the system. SIPs existing
             refresh mechanisms can be reused for this purpose.

   These similarities mean that the majority of SIPs mechanisms are
   directly applicable for presence. SIP proxies can route presence
   requests with no change. Section 12 details those components of SIP
   which are, and are not, needed for presence.

3 Definitions



Rosenberg et al.                                              [Page 6]

Internet Draft                  presence                   June 15, 2000


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

        User Agent (UA): A SIP User Agent. A UA is capable of sending
             and receiving SIP requests.

        User Agent Server (UAS): A UAS is the component of a UA which
             receives requests, and responds to them.

        User Agent Client (UAC): A UAC is the component of a UA which
             sends requests, and receives responses.

        Registrar: A registrar is a SIP server which can receive and
             process REGISTER requests. These requests are used to
             construct address bindings.

        Proxy: A proxy is a SIP proxy. A SIP proxy receives a SIP
             request, modifies some of the headers, and forwards the
             request to a next-hop server, which can be another proxy,
             or possibly a user agent.

        Presence User Agent (PUA): A Presence User Agent manipulates
             presence information for a presentity. In SIP terms, this
             means that a PUA generates REGISTER requests, conveying
             some kind of information about the presentity. 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 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 complete knowledge of the
             presence state of a presentity. Typically, this is
             accomplished by co-locating the PA with the
             proxy/registrar, or the presence user agent of the
             presentity. A PA is always addressable with a SIP URL.

        Presence Server: A presence server is a presence agent that is
             colocated with a proxy/registrar. 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.




Rosenberg et al.                                              [Page 7]

Internet Draft                  presence                   June 15, 2000


        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.

4 Overview of Operation

   In this section, we present an overview of the operation of this
   extension. It defines two new methods, SUBSCRIBE (for subscribing to
   changes in state), and NOTIFY (for notifying subscribers of changes
   in state).

4.1 Architecture

   We define a new type of SIP user agent, called a Presence Agent, or
   PA. A PA is a logical function, and is usually co-located with either
   a proxy/registrar, or a PUA. A PA is capable of storing subscriptions
   and generating notifications. Since a PA can reside either in either
   a proxy/registrar or within the PUA, the system allows both "network"
   and "client" generated notifications and management of subscriptions.
   In fact, the role of PA is defined on a subscription by subscription
   basis, and can change during the lifetime of the subscription. This
   allows for the PA function to migrate from PUA to presence server and
   back, depending on the connectivity of the PUA.

   PAs generate notifications. These notifications can be delivered
   directly to the subscriber, or proxies on the subscription path can
   elect to receive the notifications as well. Such flexibility allows
   each administrative domain to make its own decision regarding the
   tradeoffs between security, scalability, and provision of services.
   This flexibility is inherited from SIP.

   The architecture is depicted in Figure 1.


4.2 Message Flow

   A subscriber, acting as a User Agent Client (in SIP, an end system
   which sends requests is called a User Agent Client, or UAC) wishing
   to subscribe to some presentity constructs a SIP SUBSCRIBE request
   message. The request URI of this request is a normal SIP URL
   identifying the address of the presentity. This request URI is
   rewritten by SIP proxies (which are very similar to HTTP proxies) as
   the request travels towards the recipient. For example, a request for
   sip:joe@example.com will arrive at the example.com server, which
   looks up Joe in some corporate database, and then determines that Joe
   can be reached internally at sip:joe@engineering.example.com. This
   new address is placed in the request URI of the outgoing request, and



Rosenberg et al.                                              [Page 8]

Internet Draft                  presence                   June 15, 2000




                                                                          
                                                                          
                                                                          
                                                                          
                            +-------+                                     
                            |       |                                     
                          /\| Proxy |\                                    
                         /  |       | \ SUB                               
                    SUB /   +-------+  \                                  
                       /                \                                 
                      /                  \/                               
              +-------+                 +-------+                         
              |       |                 |       |                         
              | Proxy |                 | Proxy |                         
              |       |                 |       |                         
              +-------+                 +-------+                         
               /                             \                            
         / \  /                               \ SUB                       
        /   \                                  \                          
       /     \   <----                          \/                        
      / Sub-  \       --------                +----------+                
     /  scriber\              --------        |          |                
    /-----------\          NOTIFY     -----   |Proxy/    |                
                                              |Registrar/|                
                                              |PA        |                
                                              |          |                
                                              +----------+                
                                                /                         
                                        SUB   //    /\    ^               
                                      NOTIFY /     /      |               
                                           //     /       |REGISTER       
                                          /      /        |               
                                        //      /         |               
                                  / \  /      / \        / \              
                                 /PA+\       /   \      /   \             
                                / PUA \     / PUA \    / PUA \            
                                -------     -------    -------            
                                                                          


   Figure 1: Architecture of Presence System


   sent to the server for engineering.example.com. Since the request URI
   is rewritten by proxies, some means is needed to convey the identity
   of the original desired recipient. Thus, the sender also places the



Rosenberg et al.                                              [Page 9]

Internet Draft                  presence                   June 15, 2000


   URL for the desired recipient in the mandatory To field. The From
   field identifies the originator of the message. The message must also
   contain a Call-ID. In SIP, the Call-ID is used to associate a group
   of requests with the same session. Here, the usage is the same; the
   session in this case is initiated by a SUBSCRIBE. All SUBSCRIBE
   messages that refresh the subscription, and all NOTIFY messages
   generated for that subscription, are part of the same session, and
   thus share the same Call-ID value. Call-ID has no meaning beyond
   being a common identifier.

   Each SUBSCRIBE also carries a CSeq, which is a sequence number plus
   the name of the method of the request (the method name is there to
   support SIP features not required for presence). The CSeq uniquely
   identifies each SUBSCRIBE and NOTIFY in the session, and increases
   for each subsequent request in the same direction. Each SIP request
   also carries a Via header. Via headers contain a trace of the IP
   addresses or FQDNs of the systems that the request traversed. As a
   request travels from proxy to proxy towards the recipient, each adds
   its address, "pushing" them into a header, much like the operation of
   a stack. The stack of addresses is reflected in the response, and
   each proxy "pops" the top address off, and uses that to determine
   where to send the response. This allows proxies to forward UDP
   requests statelessly, so that they need not even remember where the
   request came from to forward the response. Finally, clients using
   this extension MUST insert a Contact header into the request (Contact
   is used for routing of requests in the reverse direction, from the
   target of the original message to the initiator of the original
   message).

   The SUBSCRIBE request MAY contain a body. The body contains
   additional information that describes the subscription. SIP uses the
   standard MIME headers (Content-Type, Content-Length, and Content-
   Encoding) to identify the content.

   An example subscription request looks like:

   SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0
   Via: SIP/2.0/UDP userpc.example.com
   To: sip:jdrosen@dynamicsoft.com
   From: sip:user@example.com
   Contact: sip:user@userpc.example.com
   Call-ID: knsd08alas9dy@3.4.5.6
   CSeq: 1 SUBSCRIBE
   Content-Length: 0



   The request MAY be sent using UDP or TCP (SIP supports both UDP and



Rosenberg et al.                                             [Page 10]

Internet Draft                  presence                   June 15, 2000


   TCP (and even SCTP [6] transport; reliability is guaranteed over UDP
   and congestion control is provided through a simple retransmission
   scheme with exponential backoff).

   The request MAY be sent to a local outbound proxy (a local outbound
   proxy is a device similar to an http proxy; it receives requests
   which are not destined for itself, and then forwards them towards the
   final destination), or MAY be sent directly to the server in the
   domain specified in the request URI. This is identical to baseline
   SIP. Local outbound proxies are RECOMMENDED in order to provide
   domain-based third party signatures (i.e., resign the request with a
   key for the entire domain). These proxies SHOULD perform proxy
   authentication, verifying the identity of the originator, before
   resigning.

   Proxies forward the message according to configured routing logic
   combined with DNS SRV record procedures. Pre-established security
   associations MAY be used, or SAs MAY be established on demand. The
   SAs themselves SHOULD be based on IPSec ESP in transport mode [7] to
   provide privacy services for instant messages. Keys for ESP MAY be
   established administratively. If administrative keys are not
   available, IKE is used for key exchange [8]. If a proxy receives a
   request that does not arrive over a SA, it MAY reject the request.
   This decision is based on the local security policy of the proxy.

   Each proxy adds its address to the Via header as it forwards the
   request. Proxies MAY also record route; this means that they can
   request to receive all subsequent messages for the same Call-ID. By
   not record-routing, proxies will see only the initial request they
   forward; all subsequent requests in the same session will bypass the
   proxy, and go on a more direct path between the end systems. Record-
   routing is done by inserting a header into the forwarded request
   (called Record-Route) which contains the address of the proxy. Like
   the Via headers, Record-Route has a "stack" property, since proxies
   "push" values into the message. The entire Record-Route stack is
   reflected in the response to the SUBCRIBE, but unlike Via, no
   addresses are "popped" in the response. In this fashion, both sender
   and recipient of the SUBSCRIBE have a list of the message path for
   subsequent requests. This path list is built into a Route header by
   the end systems, and placed in subsequent requests. The Route header
   is like a loose source route in IP, and specifies the path that the
   request should take. Record-routing gives each proxy the capability
   to independently decide the right trade off of scale (achieved by not
   record routing) and services (generally achieved by record routing).
   Proxies which are aware that they are behind a firewall, for example,
   can record-route, ensuring that messages from inside to outside
   always come from the proxy.




Rosenberg et al.                                             [Page 11]

Internet Draft                  presence                   June 15, 2000


   Eventually, the SUBSCRIBE request is forwarded to a proxy which is
   co-located with a registrar. A registrar is an entity in SIP that has
   dynamic application layer routing information. When a client starts
   up, they send the registrar a REGISTER request that binds an address
   in the domain of the registrar to the address of the machine they are
   residing on. Continuing with the example above, the proxy for
   engineering.example.com receives the request for Joe. Joe had
   formerly registered a binding from sip:joe@engineering.example.com to
   sip:joe@mypc.engineering.example.com, which contains the FQDN of the
   host Joe is using. In fact, the binding established by a REGISTER can
   be one to many, so that a user can indicate the ability to be
   contacted at multiple hosts (laptop, PDA, cell phone). This
   information is fundamentally presence. For that reason, the
   proxy/registrar can elect to act as a PA for this subscription. A
   proxy/registrar which can act as a PA is known as a presence server.

   Before accepting the subscription, the presence server will generally
   need to obtain authorization from the principal. This extension does
   not specify how the presence server would obtain authorization from
   the principal. Authorization can be provided ahead of time through
   web configuration, for example. Another approach is to obtain
   authorization at the time of the subscription. One approach for such
   authorization is defined in a separate document [9]. If authorization
   cannot be obtained at the time of subscription, the presence server
   can return a 202 (Accepted) response, which indicates that the
   subscription might have been accepted. When authorization is finally
   obtained (because the principal becomes online and is queried once
   again for authorization), the presence server can then enable the
   subscription and begin generation of notifications for it.

   Instead of acting as a PA, the presence server can act as a proxy for
   a subscription, and forward it to a presence client. A presence
   client makes itself known to the presence server by registering
   (using SIP REGISTER) a Contact address that includes the methods tag
   of "SUBSCRIBE". The tag is defined in the caller preferences
   specification [3]. This specification allows, among other things, for
   clients to indicate in a REGISTER that they would prefer to receive
   messages with specific methods. Proxies receiving requests with a
   particular method forward it to the contact address which has
   indicated it can handle that method. This allows for a user with a
   single SIP address to use separate user agents for presence and for
   other communications. Alternatively, users can use the same user
   agents for both.

   An example registration using this tag looks like:


   REGISTER sip:dynamicsoft.com SIP/2.0



Rosenberg et al.                                             [Page 12]

Internet Draft                  presence                   June 15, 2000


   Via: SIP/2.0/UDP mypc.dynamicsoft.com
   To: sip:jdrosen@dynamicsoft.com
   From: sip:jdrosen@dynamicsoft.com
   Call-ID: asidhasd@1.2.3.4
   CSeq: 39 REGISTER
   Contact: sip:jdrosen@pua-pc.dynamicsoft.com;methods="SUBSCRIBE"
   Contact: http://www.cs.columbia.edu/~jdrosen
   Content-Length: 0



   One of the Contact headers contains the SUBSCRIBE value in the
   methods tag. The presence server can therefore forward the request to
   that address. If there are no registrations with the methods tag of
   "SUBSCRIBE", there are no presence clients, and the presence server
   SHOULD assume the role of PA.

   In fact, it is possible that two different presence clients register
   for the same presentity. In this case, the presence server, acting as
   a proxy, may fork the SUBSCRIBE, which means it sends multiple copies
   of the request, one to each presence client. Each client will
   presumably query its principal about whether the subscription is
   acceptable. In the common case where a principal has left their
   presence tool running at work, and then gone home and started the
   tool there, the principal will accept the subscription at home. This
   causes a success response to be generated, and forwarded to the
   presence server (which is acting as a proxy), and then back to the
   subscriber. The presence tool at home then assumes responsibility for
   that subsription. The tool at work can continue to support
   subscriptions it received previously.

   Independently of whether the PA resides in the presence server or
   presence client, if a SUBSCRIBE request arrives and is acceptable, a
   200 OK response is generated, and the PA stores state for the
   subscription. The 200 OK response contains a copy of the current
   presence state of the presentity. The 200 OK response to the
   SUBSCRIBE listed above might look like:


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP presenceserver.dynamicsoft.com
   Via: SIP/2.0/UDP userpc.example.com
   To: sip:jdrosen@dynamicsoft.com
   From: sip:user@example.com
   Contact: sip:user@userpc.example.com
   Record-Route: sip:jdrosen@example.com;maddr=presenceserver.dynamicsoft.com
   Expires: 3600
   Call-ID: knsd08alas9dy@3.4.5.6



Rosenberg et al.                                             [Page 13]

Internet Draft                  presence                   June 15, 2000


   CSeq: 1 SUBSCRIBE
   Content-Type: application/xpidf+xml
   Content-Length: 287

   
   
   
    
     
      
Notice that the response has mirrored many fields from the request, including the To, From, Call-ID, CSeq, and Via headers. The PA has also added a Contact header, providing an address where it can be reached. The response also contains a Record-Route header. This header was presumably inserted by the proxy (the address in the maddr header is that of a presence server acting as a proxy), and is reflected in the 200 OK response. The response also contains a presence document for the presentity, and a Contact header. The Contact headers in a response to SUBSCRIBE list all the current addresses which have been subscribed. A subscription is uniquely defined by the combination of the Call-ID, To, and From header fields in the SUBSCRIBE. Subscriptions are soft- state; they must be refreshed periodically by the subscriber in order to remain active. The Expires header in the 200 OK response is used to indicate the lifetime of the subscription; the subscriber must resend the subscription before then, or it is deleted from the PA. When the presence information for the presentity changes, the PA generates a NOTIFY request for each subscriber. Recall that a PA is assumed to know about all changes in the presence information for a presentity; it will know this either because it is co-located with the PUA, otherwise it is co-located with the registrar, and will learn about changes in presence information from REGISTER requests. The NOTIFY request is routed using the Record-Route and Contact headers obtained from the subscription, as is done in baseline SIP. For example, the PA will generate a NOTIFY that looks like this: Rosenberg et al. [Page 14] Internet Draft presence June 15, 2000 NOTIFY sip:user@userpc.example.com Via: SIP/2.0/UDP pua-pc.dynamicsoft.com To: sip:user@example.com From: sip:jdrosen@dynamicsoft.com Contact: sip:jdrosen@pua-pc.dynamicsoft.com Route: sip:user@userpc.example.com;maddr=userpc.example.com Call-ID: knsd08alas9dy@3.4.5.6 CSeq: 1 NOTIFY Content-Type: application/xpidf+xml Content-Length: 290
This NOTIFY is sent to the presence server (presenceserver.dynamicsoft.com) because of the maddr parameter in the Record-Route. The presence server receives this, and sees the Route header. It removes the Route header, places the URI sip:user@userpc.example.com into the Request URI, and sends it to the IP address corresponding to the maddr parameter, in this case, also userpc.example.com. In this way, the NOTIFY takes the same path as the SUBSCRIBE took. As an optimization, notifications do not need to be sent if the subscriber is not actually online. This improves scalability. When a client wishes to fetch the current communications state of a user, it generates a SUBSCRIBE request, with an Expires header with time 0 (that is, a subscription which immediately expires). Once it hits the PA, a 200 OK response is generated (assuming authorization exists) containing the current presence state. The subscription is then immediately expired. The result is a fetch of presence information without generation of a subscription. Note that since fetch is accomplished using SUBSCRIBE, the same security mechanisms and authorization requirements are used for both. Rosenberg et al. [Page 15] Internet Draft presence June 15, 2000 5 Subscriptions This section defines detailed syntax and semantics associated with subscriptions. 5.1 Generating subscriptions Subscription is accomplished using the new SUBSCRIBE method, defined below. Subscribe = "SUBSCRIBE" Like all SIP method names, the SUBSCRIBE method name is case sensitive. SUBSCRIBE is used when a subscriber wishes to receive asynchronous notifications about events generated by some object. These events can be changes in the state of the object, or any other type of event. The address of the object is placed by the subscriber in the To header and also the request URI. The body of the SUBSCRIBE method MAY contain information to limit the set of events for which notifications are sent, or otherwise provide modifiers to the subscription. If no body is present, all events generated by the object cause notifications. In its application to presence of people, the object is actually a presentity, and its address is the SIP URL for the presentity. Tables 1 and 2 extend tables 4 and 5 of SIP with two additional columns, defining the headers that can be used in the SUBSCRIBE and NOTIFY requests and responses. Subscriptions are soft-state, and must be periodically refreshed. The refresh interval is suggested by the client in the SUBSCRIBE request (using the Expires header) and the actual value returned in the SUBSCRIBE response in the Expires header; see Section 6.20 of SIP. If no value is present, the default is one hour. The response to the subscription MUST contain an Expires header indicating the actual expiration of the subscription. This time will never be later than the time offered in the request, if it is offered. The subscription SHOULD be refreshed before this expiration of the client still desires the subscription to be valid. A SUBSCRIBE request MUST contain a To header, identifying the logical identity of the user or object who is being subcribed to (i.e., the Rosenberg et al. [Page 16] Internet Draft presence June 15, 2000 where enc. e-e SUBSCRIBE NOTIFY ___________________________________________________ Accept R e o o Accept 415 e o o Accept-Encoding R e o o Accept-Encoding 415 e o o Accept-Language R e o o Accept-Language 415 e o o Allow 200 e o o Allow 405 e m m Authorization R e o o Authorization r e o o Call-ID gc n e m m Contact R e m o Contact 2xx e m o Contact 3xx e o o Contact 485 e o o Content-Encoding e e o o Content-Length e e m m Content-Type e e * * CSeq gc n e m m Date g e o o Encryption g n e o o Expires g e o o From gc n e m m Hide R n h o o Max-Forwards R n e o o Organization g c h o o Table 1: Summary of header fields, A--O address of the presentity). A SUBSCRIBE request, of course, MUST contain a Request-URI. For requests generated by a UAC, this SHOULD be identical to the To field. As the SUBSCRIBE request traverses proxy servers, the Request-URI is rewritten to the address of the subscribed-to entity as known in the next-hop server. A SUBSCRIBE request MUST contain a Call-ID header (simply an opaque identifier) and a From header. The From header contains logical identity of the user requesting the subscription. Generally, this is a SIP URL, although it need not be. Note that as a logical identifier, it will generally not contain a complete hostname, such as sip:user@pc10.engineering.example.com, but rather contain a logical name, such as sip:user@example.com. Rosenberg et al. [Page 17] Internet Draft presence June 15, 2000 where enc. e-e SUB NOTIFY __________________________________________________________ Priority R c e - - Proxy-Authenticate 407 n h o o Proxy-Authorization R n h o o Proxy-Require R n h o o Record-Route R h o o Record-Route 2xx,401,484 h o o Require R e o o Retry-After R c e - - Retry-After 404,413,480,486 c e o o 500,503 c e o o 600,603 c e o o Response-Key R c e o o Route R h o o Server r c e o o Subject R c e - - Timestamp g e o o To gc(1) n e m m Unsupported 420 e o o User-Agent g c e o o Via gc(2) n e m m Warning r e o o WWW-Authenticate R c e o o WWW-Authenticate 401 c e o o Table 2: Summary of header fields, P--Z; (1): copied with possible addition of tag; (2): UAS removes first Via header field A subscription is uniquely identified by the combination of the To, Call-ID and the From field in the SUBSCRIBE request. Refreshes of subscriptions SHOULD reuse the same Call-ID if possible, since subscriptions are uniquely identified at presence servers using the Call-ID. Two subscriptions from the same user, for the same user, but with different Call-IDs, are considered different subscriptions. We anticipate that reuse of the same Call-ID will not be possible through reboot cycles. This is acceptable, however. The soft-state nature of subscriptions will cause the old one to expire. Note this is exactly the same as usage of Call-ID in registrations. A SUBSCRIBE request MUST contain a CSeq header. As specified in [2], The CSeq header MUST increment for each subsequent request for the same To, From, and Call-ID field (thus, the CSeq in each refresh MUST increase). The CSeq header uniquely identifies and orders each refresh of a particular subscription. Rosenberg et al. [Page 18] Internet Draft presence June 15, 2000 A SUBSCRIBE request MUST contain a Via header, formatted as defined in RFC 2543 [2]. Via headers are used to properly forward the response to the SUBSCRIBE. A SUBSCRIBE request MUST contain a Contact header. This indicates the address(es) (as a SIP URL) to which the client would like to receive notifications. This MUST be be one or more SIP addresses, containing the fully qualified domain names for the host generating the subscription, or the IP address of the host generating the subscription. Other addresses are possible, supporting third party subscriptions. If it contains multiple addresses, notifications will be sent to each address. If no Contact header is present, no notifications will be sent. The SUBSCRIBE request MAY contain a body, and when present, the Content-Length, Content-Type, and Content-Encoding are used as specified in [2]. There are many applications for bodies within a SUBSCRIBE request - for example, providing more detailed information about what the subscription is for. Derivation of semantics of the purpose of the body is based on the Content-Type and Content- Disposition headers. A SUBSCRIBE request MAY contain an Accept header, indicating the allowed presence description formats which may be returned in a notification. When not present, the server assumes only the lightweight presence format [10] is supported. This extension does NOT neccessitate the use of either Require or Proxy-Require. These headers SHOULD NOT be present unless some other extensions are needed beyond this one. Usage of the other headers specified as optional in Tables 1 and 2 is defined in [2]. 5.2 Sending subscriptions The SUBSCRIBE request MAY be sent directly to the server identified in the Request URI. Alternatively, it can be sent to a local outbound proxy server. Usage of local outbound proxies is RECOMMENDED with presence in order to provide security features. An example subscription message looks like: SUBSCRIBE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP myhost.example.com From: Professor Smith To: Joe User Rosenberg et al. [Page 19] Internet Draft presence June 15, 2000 Contact: sip:professor@mypc.university.edu Call-ID: 986sdo909y66555@12.33.4.5 CSeq: 4937872 SUBSCRIBE Accept: text/uri-list, text/xml-presence 5.3 Proxying subscriptions Proxies forward SUBSCRIBE requests as they would any other request. The result is that the SUBSCRIBE eventually arrives at a server where the user is registered. Section 5.4 outlines processing in these servers. 5.4 Presence server processing of SUBSCRIBE This section outlines the processing of a new subscription request for a presentity served by a presence server. When a SUBSCRIBE request arrives, the presence server SHOULD send a 100 Trying response. The next job of the presence server is to determine if it will act as a proxy for this subscription, or as a PA. Once this determination is made, processing follows Section 5.3 in the case of a proxy, and Section 5.5 in the case of a PA. If the presentity identified in the request URI has at least one registered Contact that indicates support of the SUBSCRIBE method, the presence server MAY proxy the request, or MAY act as a PA. If no Contacts are registered for the presentity, or if there are Contacts, but none indicate support for the SUBSCRIBE method, the presence server SHOULD assume the role of PA. If there was more than one Contact which indicated support of the SUBSCRIBE method, the proxy MAY fork the request (that is, send the subscription to more than one PA). Standard SIP processing, as defined in Section 12.4 of RFC2543 [2], is used to collect responses and send a single response upstream, towards the subscriber. Basically, the algorithm specified will result in a 200 OK being forwarded upstream if any of the presence clients responded with a 200 OK. If more than one presence client responded with a 200 OK, only one of them is forwarded upstream. Note that this may cause multiple PAs to generate notifications for the same presentity. This is acceptable; each PA is generating the same information. The redundant information is discarded at the subscriber [11]. If the presence server was formerly acting as a PA for a subscription Rosenberg et al. [Page 20] Internet Draft presence June 15, 2000 (in other words, the presence server was a PA for a subscription with the same Call-ID, To, and From field, but different CSeq), but is now a proxy, the presence server MUST cease acting as PA for this subscription if the proxied request generates a final response, unless that final response is 405 (Method not Allowed) (which means the presence client isn't actually a presence client, since it doesn't support SUBSCRIBE). It is possible for the role of PA to migrate from presence server to presence client dynamically. Consider first the case of a presence server acting as a PA, because there were no presence clients available. At some point, the presence client comes online (known to the presence server through a registration). When the subscription is next refreshed, the presence server can act as a proxy instead of a PA, and forward the subscription to the presence client. This terminates the subscription on the server, and allows it to become active on the presence client. By transferring subscriptions on refreshes, handling of subscriptions to gradually transition from a presence server to a presence client. The role of presence server migrates back in much the same way. When the presence client goes offline (by unregistering the Contact address with the methods="SUBSCRIBE" tag), subscription refreshes will now terminate at the presence server, causing the presence server to act as a PA for those subscriptions. This will cause the subscriptions to gradually become active at the presence server. As an optimization, the presence server can cache the active subscriptions at the client. This is done by observing the SUBSCRIBE requests, and the 200 OK responses, which pass by the presence server (which is acting as a proxy). When the presence client goes offline, the presence server can simply instantiate the cached subscriptions immediately. Note that caching of subscriptions imposes a security risk unless the presence server can authenticate and verify the integrity of SUBSCRIBE requests and their responses. 5.5 Presence agent processing of SUBSCRIBE The presence agent MAY authenticate the request (using a 401 response, NOT 407, since the PA is a user agent in SIP terminology). Once authenticated, the PA determines if this is a subscription refresh, or a new subscription. If the Call-ID, To, and From field match that of an existing subscription, the subscription is a refresh. Otherwise, it is a new subscription. 5.5.1 Refreshes Rosenberg et al. [Page 21] Internet Draft presence June 15, 2000 A PA MAY reject a refresh if it determines that the subscription is no longer acceptable (for example, if the subscription was permitted on a timed basis). In this case, the subscription is removed from the system, and a 6xx class response is sent. Note that a 4xx or 5xx error response MUST NOT cause the subscription to be removed from the system. The remainder of the discussion on refreshes assumes that the subscription is still acceptable. Each notification address (as indicated in the Contact header), is independently refreshed. This allows different expiration times for different notification addresses. Differing expiration times can be indicated using the expires parameter of the Contact header, just as is done for registrations [2]. When a presence agent receives a subscription refresh, it updates the expiration time of each notification address in the subscription. As with the initial subscription, the server MAY lower the amount of time until expiration, but MUST NOT increase it. The final expiration time is placed in the Expires header in the response, or into the expires parameters of the Contact headers in the response. The 200 OK response SHOULD also contain a copy of the current presence state of the presentity, in a format listed in the Accept header of the SUBSCRIBE, else the Light Presence Information Data Format (LPIDF) [10] if no Accept header is present. If the Accept header was present but empty, no presence information is placed in the response. If no refresh for a notification address is received before its expiration time, that address is removed from the list of addresses. If all notification addresses are removed, the entire subscription is deleted. 5.5.2 New subscriptions The presence server first determines if the subscriber is authorized. How such authorization is determined is outside the scope of this document. Authorizations may have been pre-granted by the presentity or the system administrator. Alternatively, when the subscription arrives, the PA may query the user to determine if authorization is permitted. Such querying is straightforward in the case of a PA co- resident with a PUA (in which case a screen pop or something else can be used). In the case of a PA co-resident with a proxy/registrar, a remote authorization protocol, such as [9], or even the Common Open Policy Service (COPS) [12] can be used. If authorization was refused, the request SHOULD be rejected with a 600 class response. If authorization could not be obtained (for Rosenberg et al. [Page 22] Internet Draft presence June 15, 2000 example, because the principal was offline or not available), the PA SHOULD generate a 202 response. This response tells the subscriber that the subscription is pending. The PA may reattempt authorization at a later time, possibly when the principal comes back online. See [9], which describes a SIP extension that can be used for authorization of users. The subscriber SHOULD refresh the subscription as per a 200 response. The subscriber knows the subscription is accepted when either (1) a NOTIFY for that subscription appears, or (2) a refresh generates a 200 response. If authorization has been granted, the PA MUST respond to SUBSCRIBE with a 200 OK response. The response MUST contain an indication of expiration time for each notification address in the SUBSCRIBE. The 200 OK response SHOULD also contain a copy of the current presence state of the presentity, in a format listed in the Accept header of the SUBSCRIBE, else the Light Presence Information data Format (LPIDF) [10] if no Accept header is present. If the Accept header was present but empty, no presence information is placed in the response. The PA MAY sign the 200 OK response. The PA also instantiates a subscription for the subscriber. The subscription is indexed by the Call-ID in the SUBSCRIBE and the URI in the From field (including the tag). The PA generates Route headers (using the Contact and Record-Route headers from the request) to be used for sending notifications. These Route headers are constructed exactly as if the SUBSCRIBE request were an INVITE. The Route headers are stored for use in subsequent notifications. 5.6 Subscriber processing of SUBSCRIBE response The subscriber will receive a single final response to the SUBSCRIBE request. If this response is a 600 class response, the subscription request has been denied. If the response is a 200 class response, the subscription has been accepted. The response may contain the current presence state of the presentity. The 200 OK response will contain expiration information (either in an Expires header, and/or in the expires parameter of Contact headers in the 200 OK response) indicating when the subscription expires. The subscriber MUST refresh the subscription before an expiration time if it wishes to continue to receive notifications to the address with that expiration. The SUBSCRIBE response will also contain Record-Route headers; these are used to build a Route header set for use in subsequent subscription refreshes. The construction of the Route headers follows those for a 200 OK response to INVITE as documented in RFC2543 [2], except that Contact headers are not included in the processing. Rosenberg et al. [Page 23] Internet Draft presence June 15, 2000 SUBSCRIBE is like REGISTER, in that the Contact headers don't refer to signaling addresses, but rather notification addresses. Unlike REGISTER, a Route needs to be built for SUBSCRIBE, and this Route should not include the Contact headers. To refresh the subscription, the subscriber contructs a new SUBSCRIBE request. The Call-ID, To, and From in this request MUST match those of the previous SUBSCRIBE request. The CSeq header MUST be higher than that of the previous SUBSCRIBE request. The Via header is constructed as described in 5.2. The request MUST contain the Route header constructed from the response to the initial SUBSCRIBE. The request MAY contain Accept, Content-Length, Content-Type, and Content-Encoding headers as described in Section 5.2. The request URI is constructed from the Route headers, as defined in RFC2543 [2]. The request is then sent to the server in the request URI. As long as the subscription remains active, the subscriber will receive notifications of presence state from the PA. 5.7 Unsubscribing A subscriber may unsubscribe by sending a SUBSCRIBE request with an Expires header of 0. The Contact header indicates the particular address that is being unsubscribed. This MAY be a *, indicating that all Contacts for that particular subscription (as identified by the Call-ID, To, and From) are to be removed. If all Contacts are removed, the PA deletes the subscription. 5.8 Fetching Fetching is similar to a subscribing, in that it returns the current presence state. However, no notifications are sent for future changes in the presence state. Rather than inventing a new method for this, it is readily accomplished with a SUBSCRIBE along with an Expires: 0 header and no Contact header. The absence of any Contact header is what distinguishes it from the similar operation of unsubscribing. The advantage of using SUBSCRIBE is that the server can simply process the request independently of whether its a fetch or longer lived subscription; the authorization and processing steps are identical. The only difference is whether an actual subscription is instantiated for the user or not. This parallels how fetching of registrations is done in SIP. Note that fetching has no effect on existing subscriptions. 6 Publication Rosenberg et al. [Page 24] Internet Draft presence June 15, 2000 Publication is the process by which presence information is uploaded from the presence user agents to the presence agent. The information uploaded through publications is the content used to formulate presence documents distributed through notifications. Publication can be done using any number of means, including proprietary protocols. There are many cases where this is both necessary and desirable. However, we define a standard mechanism for publication of presence information from a PUA to a presence server. This mechanism is entirely based on the existing SIP registration and caller preferences specifications [3]. Simply put, the Contact headers placed in registrations are the presence information published by the presence user agents. The caller preferences extension provides a large set of parameters which can be used to provide additional information, beyond location, which provided by SIP REGISTER. Usage of REGISTER to publish presence information has several important features: o It supports communications means represented by any URL scheme, including HTTP and SMTP. o It supports distributed presence information, whereby multiple PUAs can independently update state for different communications addresses for the same presentity. o It supports third party updates, so that one entity can update presence state for another. o Caller preferences allows for relative weights to be assigned to the addresses. o Caller preferences allows for arbitrary characteristics to be assigned to the addresses. o Caller preferences allows for descriptions to contain arbitrary text that can be used for notes. We also allow REGISTER requests to contain presence documents, so that the PUAs can publish more complex information. Note that we do not provide for locking mechanisms, which would allow a client to lock presence state, fetch it, and update it atomically. We believe that this is not neeeded for the majority of use cases, and introduces substantial complexity. Most presence operations do not require get-before-set, since the SIP register mechanism works in Rosenberg et al. [Page 25] Internet Draft presence June 15, 2000 such a way that data can be updated without a get. 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. 7 Notification Notification is the process of transmitting presence state to subscribers. It is done by a PA. 7.1 When to send Notifications are sent when the state of the presentity changes, and that state change is one for which a notification is desired. Notifications SHOULD be sent in a timely fashion after the state has changed. Description of the cases in which state changes should trigger notifications is handled by subscription documents transmitted in SUBSCRIBE requests. If no such document was present, the PA SHOULD assume that all state changes are reported. Similarly, the subscription document describes the subscribers preferences for the detailed content present in the notification. The actual data sent would be computed through the intersection requested content, and the content authorized by the subscribed party in their access controls. In the absense of a subscription document, it is assumed that the subscriber wants all data. As an important optimization, a PA MAY elect not to send a notify to a subscriber if it knows that the subscriber is not available to receive notifications. This can be known by having the PA subscribe to the subscriber. In particular, the ability to receive notifications represents another piece of presence state which can be uploaded in a REGISTER, and discovered through a SUBSCRIBE. For example, if userA subscribes to userB, userA would include, in its registrations, an address that indicates its ability to receive NOTIFY requests: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP userApc.example.com To: sip:userA@example.com From: sip:userA@example.com Call-ID: 8ynllz9a6ajsda009@9.8.7.6 CSeq: 1 REGISTER Contact: sip:userA@userApc.example.com;methods=NOTIFY Content-Length: 0 Rosenberg et al. [Page 26] Internet Draft presence June 15, 2000 If userB also subscribes to userA, userB would be aware of this communications address for notifications. It could then match it against the notification addresses in the subscription from userA, and determine whether a notification address was currently active. We anticipate that most subscriptions will be symmetric, that is, A subscribes to B and B subscribes to A. In this case, no extra subscriptions are required for this optimization. Note that this optimization is likely to work only when notifications are sent by clients. This is because presence servers are not likely to be privy to presence state of the subscribers. 7.2 Formatting of NOTIFY The generation of notifications is relatively straightforward. The presence data is constructed based on rules outside of the scope of this document. Note that the entity generating a notification MUST use a presence format listed among those in the Accept header in the SUBSCRIBE request. If not present, the Lightweight Presence Information Data Format (LPIDF) [10] type is assumed. The NOTIFY MUST contain the same Call-ID as the SUBSCRIBE for which it is acting as a notification. The From field MUST match the To field in the SUBSCRIBE, and the To field MUST match the From field in the SUBSCRIBE. The From field MUST contain a tag, which allows for notifications from presence server and PUA to be distinguished, as far as SIP transaction processing are concerned. For SIP experts - this represents a slightly different operation than for INVITE. When a user sends an INVITE, they will receive a 200 OK with a tag. Requests in the reverse direction then contain that tag, and that tag only, in the From field. Here, the response to SUBSCRIBE may contain a tag in the To field, and a NOTIFY will contain a tag in the From field. However, the UA may receive NOTIFY requests with tags in the From field that do not match the tag in the 200 OK received to the initial SUBSCRIBE. This is because only a single 200 OK is returned to a SUBSCRIBE request, as opposed to multiple 200 OK for INVITE. Thus, the UA MUST be prepared to receive NOTIFYs with many different tags, each from a different PUA. The CSeq MUST be formatted as described in SIP [2]. In particular, note that the CSeq space is different in the direction of notifier to subscriber and subscriber to notifier, and is from a different space for presence clients and presence servers. NOTIFY SHOULD NOT contain Rosenberg et al. [Page 27] Internet Draft presence June 15, 2000 a Contact header. If the SUBSCRIBE request contained Record-Route and/or Contact headers, the Route header for NOTIFY is computed as per [2], as if the SUBSCRIBE were an INVITE, and the NOTIFY were a BYE. The request-URI is also computed as per [2]. NOTIFY requests SHOULD be authenticated, using any of the end to end SIP authentication mechanisms. Note that the shared secret mechanisms are likely to only work for presence client generated notifications, since shared secrets will exist only between end users, not between servers and end users. When presence servers are generating the notifications, public key based authentication is RECOMMENDED. 7.3 Responding to NOTIFY The subscriber SHOULD be prepared to receive notifications from different sources for the same presentity. The mechanisms for combining these notifications to the overall presentity state is outside the scope of this document, but is described in [11]. If a NOTIFY is received by a UA for a subscription which does not exist, the UA SHOULD respond with a 481 (Unknown Call Leg). It is RECOMMENDED that the UA also send a SUBSCRIBE method, with the To field copied from the From of the NOTIFY, the From copied from the To of the NOTIFY, Expires equal to zero, and Contact wildcarded (*). This will request that the subscription which generated the unwanted notification be removed. If the NOTIFY is properly formed and desired, the UA MUST respond with a 200 OK. Notification responses will not normally contain bodies. They MAY if the request contained an Accept header listing acceptable bodies in the response. If the notification generates no final response at all, and times out, or if the notification generates a 481 response, the entity generating the notification should invalidate that notification address in the subscription. If invalidation of the address results in no notification addresses remaining in the subscription, the entire subscription is deleted. This prevents notifications from being generated to users that have gone offline, or to those users who were mistakenly subscribed but have no presence client at all. The soft state nature of subscriptions will ensure that valid subscriptions will be refreshed if accidentally deleted. 8 Access controls Access controls are mechanisms which allow the user controlling a Rosenberg et al. [Page 28] Internet Draft presence June 15, 2000 presentity to define rules about who is allowed to subscribe, what data they see, and when. Access controls are a critical component of a presence solution, but are ideally separated from the underlying presence protocol. This is because access controls are fundamentally a mechanism for influencing policy decisions made by presence servers; policy can be controlled in numerous ways, and for maximum flexibility and modularity, should be kept separate. Some possibilities for access controls include: Web Based: A user can go to a secure web page, enter in access controls, and have the data pushed to the presence server through proprietary means (the presence server itself may run a web server). This provides the opportunity for substantial differentiation in access control services, without interoperability issues. However, it is not suitable for automated control over access controls. CPL Based: The call processing language (CPL) [13] is used to define call processing rules (i.e., policy) for call setup requests. We observe that the same policies will likely make sense for subscriptions as well. Therefore, CPL, possibly with some extensions, can be used for access controls for presence. These access controls can be uploaded in a SIP REGISTER request [14]. COPS: The Common Open Policy Service (COPS) [12] protocol allows for general purpose outsourced policy decisions. It could easily be used by presence servers to define processing of subscriptions. Some of the things access controls can be used for are: o Pre-authorizing subscribers, so that their subscriptions are automatically accepted. o Blocking subscribers, so that their subscription requests are automatically rejected o Specifying that only subsets of presence information are reported to selected subscribers o Specifying that false presence information can be given to selected subscribers 9 Providing scalability This section briefly overviews the mechanisms in this extension which Rosenberg et al. [Page 29] Internet Draft presence June 15, 2000 provide scalability, a critical goal for any presence protocol. We have observed that scalability is limited by the messaging and processing load at presence servers. As the processing load is proportional to the message load, we can consider just the message load to determine the scale bottlenecks at a presence server. This load is equal to: load = (presentities * subscribers per presentity * notifications per presentity) + (presentities * subscribers per presentity) The first term represents the notification load, and the second, the subscription load. The dominant factor is the notification load. We address this load by providing three mechanisms - one for the reduction of each of these terms. 9.1 Partitioning of the namespace The load on an individual server can be reduced by partitioning the namespace, so that a single presence server handles only a small number of presentities. This is accomplished through proxy servers, which can receive a subscription, determine the subdomain which owns the presence for that user, and forward the subscription to that subdomain. The subdomain itself may have proxies which do this. The result is that the presence namespace can be divided hierarchically, with proxies providing routing towards the leafs, which handle the actual presence servers. As an example, a subscription request to sip:joe@example.com reaches the main proxy server for example.com. This server does nothing but look up users in a directory server, mapping them to subdomains. This particular user is in engineering, so the proxy maps the request URI to sip:joe@engineering.example.com, and forwards it to the engineering.example.com server. A different user may have been forwarded to the marketing.example.com server. These servers, in turn, can rely on databases or other configuration to map these addresses into further subdomains. For example, the engineering server might map sip:joe@engineering.example.com to sip:joe@electrical.engineering.example.com. As these proxies are generally stateless, they can be easily clustered, with load balancing provided through DNS SRV records. Use of SRV records also Rosenberg et al. [Page 30] Internet Draft presence June 15, 2000 provides for fault tolerance among the cluster. SIP proxy servers can be stateless; assisting only in the routing of requests, and not maintaining any state at all. Furthermore, through SIPs Record-Routing mechanisms, proxies can assist in routing the first SUBSCRIBE request; refreshes can bypass the proxies to improve scale. 9.2 Client notifications The load can also be reduced by completely eliminating notifications from the presence server. This is accomplished through the mechanisms described in this extension that allow, by default, a presence client to generate notifications for a subscriber. This follows the well known Internet scalability principle of pushing intelligence to the periphery. 9.3 Distributed subscription state All the subscriptions from one domain to another can be aggregated by co-locating a PA with a local outbound proxy. This is shown in Figure 2. In the figure, domain X has two subscribers for a single presentity in domain Y. Both subscribers use a local outbound proxy, so that the SUBSCRIBE messages pass through a single proxy. When the proxy sees a subscription for a user in an outside domain, it acts as a PA, and accepts the subscription itself. Since a PA must be aware of the complete presence state of the presentity, the presence server itself subscribes to the presentity the first time it gets a subscription for that presentity. Subsequent subscriptions from inside domain X for the same presentity do not need to trigger additional subscriptions outside. A single subscription from domain X is used. So, in the figure, the first subscription request, SUBSCRIBE 1, might look like: SUBSCRIBE sip:presentity@domainy.com SIP/2.0 Via: SIP/2.0/UDP subscriberA-pc.domainx.com From: sip:subscriberA@domainx.com To: sip:presentity@domainy.com Call-ID: uobhasd97@7.3.4.2 CSeq: 1 SUBSCRIBE Contact: sip:subscriberA@subscriberA-pc.domainX.com Content-Length: 0 Rosenberg et al. [Page 31] Internet Draft presence June 15, 2000 ++++++++++ ++++++++ +++++ +++ +++ ++ ++++++++++++ + ++ + ++ +---------+ + + +---------+ | +----+ | +SUBSCRIBE 3 | | | | | |-------------------> | | | | PA | | ++ + | Proxy | | +----+ | +++++ + | | | Outbound| ++ + | | | Proxy | + + | | +---------+ ++ + +---------+ SUBSCRIBE ^ ^ + ++ \ 1 / \ + ++ \ / \ SUBSCRIBE + ++++ \ SUBSCRIBE 3 //-----\\ \ 2 ++ ++++++ \ // \\ \ ++ ++ \ | Subscriber | \ ++ +++ > \\ A // \ ++ ++ +---------+ \\-----// \ + ++ | | //------\\ ++ + | Presence| |/ \| + + | Server | | Subscriber | + ++ | | |\ B /| + + | | \\------// + + +---------+ + ++ + + ++ + DOMAIN X + + /\ + + / \ ++++ + /PUA \ +++++ ++ /------\ ++++++ + ++ DOMAIN Y ++ ++ ++ +++++++++++++++++++ Figure 2: Distributing Subscription State When this is received at the outbound proxy/PA for domain X, the PA itself generates a subscription for presentity, SUBSCRIBE 3: Rosenberg et al. [Page 32] Internet Draft presence June 15, 2000 Via: SIP/2.0/UDP outboundproxy.domainx.com From: sip:domainx.com To: sip:presentity@domainy.com Call-ID: gghhjjoo@0.1.2.3 CSeq: 77 SUBSCRIBE Contact: sip:outboundproxy.domainX.com Content-Length: 0 Note that this subscription lists the outbound proxy/PA as the originating host (in the Via and Contact fields), and sip:domainx.com as the identity of the subscriber. This subcription is forwarded to the PA for presentity in domain Y. If it is willing to accept a domain wide subscription (after authenticating the request, of course, as coming from the owner of the domain), a 200 OK is generated. Once this arrives at the outbound proxy, it can accept the subscription from subscriber 1. When subscriber 2 subscribes, using SUBSCRIBE 2: SUBSCRIBE sip:presentity@domainy.com SIP/2.0 Via: SIP/2.0/UDP subscriberB-pc.domainx.com From: sip:subscriberB@domainx.com To: sip:presentity@domainy.com Call-ID: qwertyuiop@11.22.33.44 CSeq: 12 SUBSCRIBE Contact: sip:subscriberB@subscriberB-pc.domainX.com Content-Length: 0 this subscription is accepted by the outbound proxy/PA. No subscriptions are generated or forwarded to domain Y. This process results in the subscription state being distributed throughout the network, with each domain holding the subscriptions from users within its own domain. In fact, the process can take place recursively, resulting in distribution of presence state over a tree of domains. That achieves scale; a presentity that might get millions of subscribers would be readily served by such an architecture. The important concept to note here is that this aggregation process is a matter of local optimization in domain X; as far as domain Y is concerned, there is a single subscription, and processing that subscription is no different than processing any other subscription. This is possible because we have defined presence operations to be Rosenberg et al. [Page 33] Internet Draft presence June 15, 2000 invoked on logical entities, PAs, which can dynamically be instantiated on a subscription by subscription basis in any device which can somehow determine the complete presence state of a presentity. In the case here, the outbound proxy is instantiating the PA, and it is allowing the PA to know the presence state of a presentity through another subscription. The drawback of this optimization is that it introduces security issues. The subscription from domainX is now domain wide; the presentity cannot authenticate the identity of every subscriber within the domain. It is forced into a trust relationship with that domain, such that domain Y trusts that domain X is authenticating each subscriber. Furthermore, the ability of the presentity to authorize some subscribers from domain X, but not others, is lost, unless there is some means to convey access control across domains. As a result, the decision about whether to accept such domain wide subscriptions is up to the security policy of the presence server. Clearly, such subscriptions might be accepted for certain presentities (ones with many subscribers), but not others. 10 Security considerations There are numerous security considerations for presence. Many are outlined above; this section considers them issue by issue. 10.1 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 Rosenberg et al. [Page 34] Internet Draft presence June 15, 2000 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 between network servers (proxies to proxies, proxies to redirect servers), transport mode ESP [7] is used to encrypt the entire message. Between a UAC and its local proxy, TLS [15] is RECOMMENDED. Similarly, TLS SHOULD be used between a presence server and the PUA. 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 that registration contains the token "tls" as transport, it implies that the PUA supports TLS. Furthermore, we allow for the Contact header in the SUBSCRIBE request to contain TLS as a transport. The Contact header is used to route subsequent messages between a pair of entities. It defines the address and transport used to communicate with the user agent. Even though TLS might be used between the subscriber and its local proxy, placing this parameter in the Contact header means that TLS can also be used end to end for generation of notifications after the initial SUBSCRIBE message has been successfully routed. This would provide end to end privacy and authentication services with low proxy overheads. SIP encryption MAY be used end to end for the transmission of both SUBSCRIBE and NOTIFY requests. SIP supports PGP based encryption, which does not require the establishment of a session key for encryption of messages within a given subscription (basically, a new session key is established for each message as part of the PGP encryption). Work has recently begun on the application of S/MIME [16] for SIP. Tunneling of TLS over SIP, for the purposes of establishment of an end to end private key for encryption, is also under investigation. 10.2 Message integrity and authenticity 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 PGP based authentication and integrity (both challenge-response and public key signatures), and http basic and digest authentication. 10.3 Outbound authentication When local proxies are used for transmission of outbound messages, Rosenberg et al. [Page 35] Internet Draft presence June 15, 2000 proxy authentication is RECOMMENDED. This is useful to verify the identity of the originator, and prevent spoofing and spamming at the originating network. 10.4 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 (http basic, digest, of PGP) MAY be used to prevent replay attacks. 10.5 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. 10.5.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. 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 Section 7.3, if a notify is not acknowledged or was not wanted, the subscription that generated it is removed. This eliminates some of the amplification properties of Rosenberg et al. [Page 36] Internet Draft presence June 15, 2000 providing false Contact addresses. 10.5.2 Annoyance subscriptions A user can attempt to "annoy" another by subscribing, and on rejection, subscribe again. If subscriptions cause screen pops, this can result in a DoS attack whereby screen pops are constantly pushed onto the subscribed parties machine. To avoid this attack, PUAs SHOULD cache rejected subscriptions and automatically reject subsequent ones (of course, the UA will want a way for the subscriber to remove the negative cached entries if they change their mind). In addition, the PUA SHOULD use access control mechanisms to block those subscriptions at the presence server as well. 10.6 Firewall traversal The extension defined here is firewall and NAT friendly, in that it can be configured in such a way as to traverse any device which allows outgoing TCP connections to an external server. Consider the configuration in Figure 3: The key to enabling traversal of the firewall is to ensure that all SUBSCRIBE requests, their responses, and subsequent notifications and their responses, all traverse a long lived connection opened from the proxy inside the firewall (on the left) out towards the proxy or presence server in the remote domain. SIP supports long lived connections, but what is needed here is a means for the proxy inside the firewall to request to the presence entity on the far side that (1) the connection be kept open, and (2) the presence entity record-route, so that notifications pass over the same connection. These are accomplished with a simple extension [17]. In this environment, the proxy would need to be aware it is behind a firewall, so that it can request the persistent connection, and use TCP in the first place. Note that a subscriber could also do this, allowing for firewall traversal even in the absence of a proxy inside the firewall. Since usage of these persistent connections is not mandatory, it can be used when needed, but for non-firewalled networks, end to end notifications can be used instead, increasing scalability. 11 Addressing Transport SIP, and this protocol based on it, is very flexible in its usage of Rosenberg et al. [Page 37] Internet Draft presence June 15, 2000 | | | | INSIDE | OUTSIDE | | | | +--------+ | +--------+ | | | | | | | | |Presence| | Proxy | --------------+--------- | Entity | | | | | | | | | | | +--------+ | +--------+ | | | | | | | | | | | | | | /------\ | // \\ | | Subscriber | | | | | \\ // \------/ Firewall Figure 3: Architecture of Presence System transport protocols. Both TCP and UDP operation are defined; SIP is reliable over any transport and provides its own application layer congestion control, reliability and sequencing. New transports can be used, such as the Stream Control Transmission Protocol (SCTP) [5], which may prove useful for presence messages [6], or TLS. SIPs ability to run over UDP may provide useful for an eventual application of multicast to presence information. Notifications, in particular, might be very amenable to multicast distribution. This flexibility is needed because, simply put, one size does not fit Rosenberg et al. [Page 38] Internet Draft presence June 15, 2000 all. UDP is beneficial in that it can be used in stateless proxy servers, improving scale and performance. It is also faster, as no explicit connection setup is required. It may also be appropriate for small devices, such as wireless handsets, which may not readily support persistent connections. However, TCP is advantageous in many cases for liveness determination, congestion control, and its superior segmentation and reassembly capabilities. 12 Required SIP features SIP contains many components and capabilities, only some of which are needed to support presence. It is a common misconception to believe that SIP is only good for initiating phone calls. Since SIP separates the definition of a session to other protocols, such as the Session Description Protocol (SDP) [4], SIP is best viewed as a real-time rendezvous system, which allows content to be delivered from one user, to the current location(s) where another user, the desired target, is located. This rendezvous system can be used to deliver invitations to sessions, as is accomplished with the INVITE method, but other data, such as subscriptions and notifications, can be delivered. As such, most of the generic components of SIP as they relate to message routing are useful and needed for this extension, and most of those related specifically to INVITE, BYE, ACK, and CANCEL processing are not needed. This section outlines those components needed, and those not needed, for presence. 12.1 Needed components The following are the SIP components needed in a PA, PUA, or subscriber (all three are classified as user agents in SIP terminology) to support this extension: o Basic SIP parser, capable of generating To, From, Call-ID, CSeq, To, Via, Route, Accept, Allow, Require, Record-Route, Expires, Contact, Content-Length, and Content-Type headers, in addition to the request and response line. o UDP transmission mechanisms for non-INVITE requests, which is nothing more than a periodic retransmit of a request with exponential backoff. o Implementation of the client and server state machine for non-INVITE requests (used for reliable transport), documented in Section 10.4.1 of SIP [2]. Rosenberg et al. [Page 39] Internet Draft presence June 15, 2000 o The ability to send SIP REGISTER requests, and process responses, and refresh those registrations. o Construction and usage of Route headers. o Support the Require mechanism for protocol extension, as defined in Section 6.30 of RFC 2543. o Reject requests with unknown methods, returning an Allow header in the response. o Reject requests with unknown bodies, returning an Accept header in the response. o Send and process SIP responses based solely on the 100s digit. o Send responses based on the Via header processing rules of Section 6.40 If a UA wishes to implement security, it needs to support the security mechanisms defined in RFC 2543. A presence server must additionally act as a proxy, and therefore must additionally be able to: o Parse and generate SIP messages, understanding the To, From, Call-ID, CSeq, Via, Route, Record-Route, and Proxy-Require headers, in addition to the request and response line. o If co-located with a registrar, process SIP REGISTER requests and generate responses o Perform the proxying functions described in Section 12 of RFC 2543; these rules mainly concern connection management, Via processing, loop detection, and transport. 12.2 Components not needed User agents supporting presence do not need to support the following SIP capabilities: o Processing of INVITE, ACK, CANCEL, BYE requests o Support for the INVITE reliability mechanisms and state machines o multiple 200 OK responses Rosenberg et al. [Page 40] Internet Draft presence June 15, 2000 o SDP processing o re-INVITEs Elimination of INVITE processing alone results in a substantial reduction in required features. 13 Example message flows THe following subsections exhibit example message flows, to further clarify behavior of the protocol. 13.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 presentity includes its current state in the 200 OK response message. The presentity subsequently changes state (is on the phone), resulting in a new notification. The flow finishes with the watcher canceling the subscription. Watcher Presentity ------- ----------- | F1 SUBSCRIBE | | ----------------------------->| | F2 200 OK | |<------------------------------| | F3 NOTIFY | |<------------------------------| | F4 200 OK | |------------------------------>| | F5 NOTIFY | |<------------------------------| | F6 200 OK | |------------------------------>| | F7 SUBSCRIBE (unsub) | |------------------------------>| | F8 200 OK | |<------------------------------| Message Details Rosenberg et al. [Page 41] Internet Draft presence June 15, 2000 F1 SUBSCRIBE watcher -> presentity SUBSCRIBE sip:presentity@pres.example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248543@watcherhost.example.com CSeq : 1 SUBSCRIBE Expires: 600 Accept: application/xpidf+xml, text/lpidf Contact: sip:user@watcherhost.example.com F2 200 OK presentity->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248543@watcherhost.example.com Cseq: 1 SUBSCRIBE Expires: 600 Content-Type: application/xpidf+xml Content-Length: 351
F3 NOTIFY Presentity->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pres.example.com:5060 From: Resource Rosenberg et al. [Page 42] Internet Draft presence June 15, 2000 To: User Call-ID: 3248543@watcherhost.example.com CSeq: 1 NOTIFY Content-Type: application/xpidf+xml Content-Length: 352
F4 200 OK watcher->presentity SIP/2.0 200 OK Via: SIP/2.0/UDP pres.example.com:5060 From: Resource To: User Call-ID: 3248543@watcherhost.example.com CSeq: 1 NOTIFY F5 NOTIFY Presentity->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pres.example.com:5060 From: Resource To: User Call-ID: 3248543@watcherhost.example.com CSeq: 2 NOTIFY Content-Type: application/xpidf+xml Content-Length: 351 Rosenberg et al. [Page 43] Internet Draft presence June 15, 2000
F6 200 OK watcher->presentity SIP/2.0 200 OK Via: SIP/2.0/UDP pres.example.com:5060 From: Resource To: User Call-ID: 3248543@watcherhost.example.com CSeq: 2 NOTIFY F7 SUBSCRIBE watcher -> presentity SUBSCRIBE sip:presentity@pres.example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248543@watcherhost.example.com CSeq : 2 SUBSCRIBE Expires: 0 Accept: application/xpidf+xml, text/lpidf Contact: sip:user@watcherhost.example.com F8 200 OK presentity->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248543@watcherhost.example.com Cseq: 2 SUBSCRIBE Expires:0 Content-Type: text/lpidf Rosenberg et al. [Page 44] Internet Draft presence June 15, 2000 Content-Length: 113 To: sip:presentity@pres.example.com Contact: sip:presentity@pres.example.com;method=INVITE; description="open" 13.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 OK | | |<---------------------| | F6 200 OK | | |<---------------------| | | | F7 REGISTER | | |<---------------------| | | F8 200 OK | | |--------------------->| | F9 NOTIFY | | |<--------------------------------------------+ | F10 200 OK | | |-------------------------------------------->| | F11 SUBSCRIBE | | |--------------------->| | | | F12 SUBSCRIBE | | |--------------------->| | | F13 200 OK | | |<---------------------| | F14 200 OK | | Rosenberg et al. [Page 45] Internet Draft presence June 15, 2000 |<---------------------| | Message Details F1 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2818@pua.example.com CSeq: 1 REGISTER Contact: ;description="open" Contact: Expires: 600 F2 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2818@pua.example.com CSeq: 1 REGISTER Contact: ;description="open" Contact: Expires: 600 F3 SUBSCRIBE watcher->server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Rosenberg et al. [Page 46] Internet Draft presence June 15, 2000 Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Expires: 600 Contact: sip:user@watcherhost.example.com 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 To: Resource Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Expires: 600 Contact: sip:user@watcherhost.example.com 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 To: Resource Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Expires: 600 Content-Type: text/lpidf Content-Length: 115 To: sip:resource@example.com Contact: ;description="open" F6 200 OK server->watcher Rosenberg et al. [Page 47] Internet Draft presence June 15, 2000 SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Expires: 600 Content-Type: text/lpidf Content-Length: 115 To: sip:resource@example.com Contact: ;description="open" F7 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2818@pua.example.com CSeq: 2 REGISTER Contact: ;description="inuse" Expires: 600 F8 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2818@pua.example.com CSeq: 2 REGISTER Contact: ;description="inuse"; expires=600 Contact: ; expires=210 Rosenberg et al. [Page 48] Internet Draft presence June 15, 2000 F9 NOTIFY PUA->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: User From: Resource Call-ID: 32485@watcherhost.example.com CSeq : 1 NOTIFY Content-Type: text/lpidf Content-Length: 116 To: sip:resource@example.com Contact: ;description="inuse" F10 200 OK watcher->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: User From: Resource Call-ID: 32485@watcherhost.example.com CSeq : 1 NOTIFY F11 SUBSCRIBE watcher->server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 32485@watcherhost.example.com CSeq : 2 SUBSCRIBE Expires: 0 Contact: sip:user@watcherhost.example.com F12 SUBSCRIBE server->PUA Rosenberg et al. [Page 49] Internet Draft presence June 15, 2000 SUBSCRIBE sip:resource@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 To: Resource Call-ID: 32485@watcherhost.example.com CSeq : 2 SUBSCRIBE Expires: 0 Contact: sip:user@watcherhost.example.com F13 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 To: Resource Call-ID: 32485@watcherhost.example.com CSeq : 2 SUBSCRIBE Content-Type: text/lpidf Content-Length: 115 To: sip:resource@example.com Contact: ; description="open" F14 200 OK server->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 32485@watcherhost.example.com CSeq : 2 SUBSCRIBE Content-Type: text/lpidf Content-Length: 115 To: sip:resource@example.com Contact: ; description="open" Rosenberg et al. [Page 50] Internet Draft presence June 15, 2000 13.3 Presence Server Notifications This message flow illustrates how the presence server can be the responsible for sending notifications for a presentity. The presence server will do this if the presentity has not sent a registration indicating an interest in handling subscriptions. This flow assumes that the watcher has previously been authorized to subscribe to this resource at the server. Watcher Server PUA | F1 SUBSCRIBE | | |------------------>| | | F2 200 OK | | |<------------------| | | | F3 REGISTER | | |<-------------------| | | F4 200 OK | | |------------------->| | F5 NOTIFY | | |<------------------| | | F6 200 OK | | |------------------>| | | | F7 REGISTER | | |<-------------------| | | F8 200 OK | | |------------------->| | F9 NOTIFY | | |<------------------| | | F10 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: From: Call-ID: 2010@watcherhost.example.com CSeq: 1 SUBSCRIBE Contact: Expires: 600 Rosenberg et al. [Page 51] Internet Draft presence June 15, 2000 F2 200 OK server->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 To: From: Call-ID: 2010@watcherhost.example.com CSeq: 1 SUBSCRIBE Expires: 600 Content-Type: text/lpidf Content-Length: 114 To: sip:resource@example.com Contact: ;description="closed" F3 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 110@pua.example.com CSeq: 1 REGISTER Contact: ;description="open" Expires: 600 F4 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 110@pua.example.com CSeq: 1 REGISTER Contact: ; description="open"; expires=600 Rosenberg et al. [Page 52] Internet Draft presence June 15, 2000 F5 NOTIFY server-> watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 2010@watcherhost.example.com CSeq: 1 NOTIFY Content-Type: text/lpidf Content-Length: 111 To: sip:resource@example.com Contact: ; description="open" F6 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 2010@watcherhost.example.com CSeq: 1 NOTIFY F7 REGISTER REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 110@pua.example.com CSeq: 2 REGISTER Contact: ;description="Away from keyboard" Expires: 600 F8 200 OK Rosenberg et al. [Page 53] Internet Draft presence June 15, 2000 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 110@pua.example.com CSeq: 2 REGISTER Contact: ; description="Away from keyboard" ; expires=600 F9 NOTIFY NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 2010@watcherhost.example.com CSeq: 2 NOTIFY Content-Type: text/lpidf Content-Length: 125 To: sip:resource@example.com Contact: ; description="Away from keyboard" F10 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 2010@watcherhost.example.com CSeq: 2 NOTIFY 13.4 Presence Server Notifications with Client Authorization of Subscription This call flow expands on the call flow in 13.3 by showing how the Rosenberg et al. [Page 54] Internet Draft presence June 15, 2000 Presence Server gets authorization for a new subscription from the client. The authorization is done using the QAUTH method defined in [9]. Presence Watcher Server PUA | | F1 REGISTER | | |<---------------------| | | F2 200 OK | | |--------------------->| | F3 SUBSCRIBE | | |--------------------->| | | F4 202 Accepted | | |<---------------------| | | | F5 QAUTH | | |--------------------->| | | F6 200 OK | | |<---------------------| | F7 NOTIFY | | |<---------------------| | | F8 200 OK | | |--------------------->| | | | F9 REGISTER | | |<---------------------| | | F10 200 OK | | |--------------------->| | F11 NOTIFY | | |<---------------------| | | F12 200 OK | | |--------------------->| | | F13 SUBSCRIBE | | |--------------------->| | | F14 200 OK | | |<---------------------| | Message Details: F1 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Rosenberg et al. [Page 55] Internet Draft presence June 15, 2000 Call-ID: 12@pua.example.com CSeq: 1 REGISTER Contact: ;description="open" Contact: Expires: 600 F2 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 12@pua.example.com CSeq: 1 REGISTER Contact: ;description="open" Contact: Expires: 600 F3 SUBSCRIBE watcher->server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248546@watcherhost.example.com CSeq: 1 SUBSCRIBE Expires: 600 Contact: sip:user@watcherhost.example.com F4 202 Accepted server->watcher SIP/2.0 202 Accepted Rosenberg et al. [Page 56] Internet Draft presence June 15, 2000 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248546@watcherhost.example.com CSeq: 1 SUBSCRIBE Expires: 600 F5 QAUTH server->PUA QAUTH sip:id@pua.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: User To: Resource Call-ID: 2874@server.example.com CSeq: 1 QAUTH Expires: Sun, 14 Jun 2036 00:00:00 GMT Contact: sip:server.example.com F6 200 OK PUA->server SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: User To: Resource Call-ID: 2874@server.example.com CSeq: 1 QAUTH Expires: Sun, 14 Jun 2036 00:00:00 GMT F7 NOTIFY server->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 3248546@watcherhost.example.com CSeq: 1 NOTIFY Rosenberg et al. [Page 57] Internet Draft presence June 15, 2000 Content-Type: text/lpidf Content-Length: 111 To: sip:resource@example.com Contact: ; description="open" F8 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 3248546@watcherhost.example.com CSeq: 1 NOTIFY F9 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 12@pua.example.com CSeq: 2 REGISTER Contact: ;description="hiding in storm shelter" Contact: Expires: 600 F10 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: Rosenberg et al. [Page 58] Internet Draft presence June 15, 2000 From: Call-ID: 12@pua.example.com CSeq: 2 REGISTER Contact: ;description="hiding in storm shelter" Contact: Expires: 600 F11 NOTIFY server->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 3248546@watcherhost.example.com CSeq: 2 NOTIFY Content-Type: text/lpidf Content-Length: 131 To: sip:resource@example.com Contact: ; description="hiding in storm shelter" F12 200 OK watcher->server SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: To: Call-ID: 3248546@watcherhost.example.com CSeq: 2 NOTIFY F13 SUBSCRIBE watcher->server Rosenberg et al. [Page 59] Internet Draft presence June 15, 2000 SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248546@watcherhost.example.com CSeq: 2 SUBSCRIBE Expires: 0 Contact: sip:user@watcherhost.example.com F14 200 OK server->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248546@watcherhost.example.com CSeq: 2 SUBSCRIBE Content-Type: text/lpidf Content-Length: 131 To: sip:resource@example.com Contact: ; description="hiding in storm shelter" 13.5 Delayed Subscription Approval The call flow is similar to 13.4 with the difference being that the client is currently offline. A watcher subscribes to a resource for which the server but has not been authorized and a PUA for that resource is not available. The server queues the request until a PUA becomes available. The PUA grants permission, but since the original subscription had expired, the server does not generate a NOTIFY. The watcher subscribes again, after the REGISTER has expired, and has its subscription approved. Note that since there are no contacts registered for the resource at that time, the presence document is vacuous. Rosenberg et al. [Page 60] Internet Draft presence June 15, 2000 watcher server PUA | | | | F1 SUBSCRIBE | | |--------------------->| (PUA not "online") | | F2 202 Accepted | | |<---------------------| | | (subscription expires) | | | F3 REGISTER | | |<--------------------| | | F4 200 OK | | |-------------------->| | | F5 QAUTH | | |-------------------->| | | F6 200 OK | | |<--------------------| | (registration expires)| | F7 SUBSCRIBE | | |--------------------->| | | F8 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 From: User To: Resource Call-ID: 3248543@watcherhost.example.com CSeq: 1 SUBSCRIBE Date: Mon, 12 Jun 2000 16:00:00 GMT Expires: 600 Contact: sip:user@watcherhost.example.com F2 202 Accepted server->watcher SIP/2.0 202 Accepted Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User Rosenberg et al. [Page 61] Internet Draft presence June 15, 2000 To: Resource Call-ID: 3248543@watcherhost.example.com CSeq: 1 SUBSCRIBE Expires: 600 F3 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2001@pua.example.com CSeq: 1 REGISTER Date: Wed, 14 Jun 2000 09:57:16 GMT Contact: Contact: Expires: 600 F4 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2001@pua.example.com CSeq: 1 REGISTER Contact: Contact: Expires: 600 F5 QAUTH server->PUA QAUTH sip:id@pua.example.com SIP/2.0 Rosenberg et al. [Page 62] Internet Draft presence June 15, 2000 Via: SIP/2.0/UDP server.example.com:5060 From: User To: Resource Call-ID: 47774@server.example.com CSeq: 1 QAUTH Expires: Sun, 14 Jun 2036 00:00:00 GMT Contact: sip:server.example.com F6 200 OK PUA->server SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: User To: Resource Call-ID: 47774@server.example.com CSeq: 1 QAUTH Expires: Sun, 14 Jun 2036 00:00:00 GMT F7 SUBSCRIBE watcher->server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Call-ID: 3248544@watcherhost.example.com CSeq: 1 SUBSCRIBE Date: Thu, 15 Jun 2000 07:22:15 GMT Expires: 600 Contact: sip:user@watcherhost.example.com F8 200 OK server->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource Rosenberg et al. [Page 63] Internet Draft presence June 15, 2000 Call-ID: 3248544@watcherhost.example.com CSeq: 1 SUBSCRIBE Expires: 600 Content-Type: text/lpidf Content-Length: 31 To: sip:resource@example.com 14 Checklist of requirements This section examines the requirements for presence, as specified in RFC2779 [18], and indicates how each requirement is addressed by this extension. Only the requirements related to presence are discussed here. Requirements for instant messaging are discussed in [19] and presence data formats in [10,11]. "Requirement 2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available independent of whether an INSTANT MESSAGE SERVICE is available, and vice-versa." Presence and IM are supported by completely separate protocols, and do not depend on each other. "Requirement 2.1.2. The protocols must not assume that an INSTANT INBOX is necessarily reached by the same IDENTIFIER as that of a PRESENTITY. Specifically, the protocols must assume that some INSTANT INBOXes may have no associated PRESENTITIES, and vice versa." The complete separation of IM and presence allows different identifiers to be used for each. "Requirement 2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY." The architecture provided here allows for the IM and presence identifiers to be the same, if so desired. "Requirement 2.1.4. The administration and naming of ENTITIES within a given DOMAIN MUST be able to operate independently of actions in any other DOMAIN." This requirement is met by SIP. SIP uses email-like identifiers which consist of a user name at a domain. Administration of user names is done completely within the domain, and these user names have no Rosenberg et al. [Page 64] Internet Draft presence June 15, 2000 defined rules or organization that needs to be known outside of the domain in order for SIP to operate. "Requirement 2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS within the NAMESPACE." This requirement is met by SIP. SIP uses standard DNS domains, which are not restricted in number. "Requirement 2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate with ENTITIES in another DOMAIN, without the DOMAINS having previously been aware of each other." This requirement is met by SIP, as it is essential for establishing sessions as well. DNS SRV [20] records are used to discover servers for a particular service within a domain. They are a generalization of MX records, used for email routing. SIP defines procedures for usage of DNS records to find servers in another domains, which include SRV lookups. This allows domains to communication without prior setup. "Requirement 2.2.2: The protocol MUST be capable of meeting its other functional and performance requirements even when there are millions of ENTITIES within a single DOMAIN." Whilst it is hard to judge whether this can be met by examining the architecture of a protocol, SIP has numerous mechanisms for achieving large scales of users within a domain. It allows hierarchies of servers, whereby the namespace can be partitioned among servers. Servers near the top of the hierarchy, used solely for routing, can be stateless, providing excellent scale. "Requirement 2.2.3: The protocol MUST be capable of meeting its other functional and performance requirements when there are millions of DOMAINS within the single NAMESPACE." The usage of DNS for dividing the namespace into domains provides the same scale as todays email systems, which support millions of DOMAINS. "Requirement 2.2.4: The protocol MUST be capable of meeting its other functional and performance requirements when every single SUBSCRIBER has SUBSCRIPTIONS to hundreds of PRESENTITIES." Section 9 discusses the means by which our extension provides scale. Rosenberg et al. [Page 65] Internet Draft presence June 15, 2000 "Requirement 2.2.5: The protocol MUST be capable of meeting its other functional and performance requirements when hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to a single PRESENTITY." Section 9 discusses the means by which our extension provides scale. "Requirement 2.2.6: The protocol MUST be capable of meeting its other functional and performance requirements when every single SUBSCRIBER has SUBSCRIPTIONS to PRESENTITIES in hundreds of distinct DOMAINS." Section 9 discusses the means by which our extension provides scale. "Requirement 2.4.1: The protocol MUST allow the creation of a SUBSCRIPTION both directly and via intermediaries, such as PROXIES." SIP supports proxies, but they are optional. User agents can communicate directly. This feature is inherited by this extension. "Requirement 2.4.2: The protocol MUST allow the sending of a NOTIFICATION both directly and via intermediaries, such as PROXIES." The use of Record-Routing described here, and in RFC2543 [2] means that notifications can go directly from presence agent to subscriber, or through proxies, as the policy of each proxy dictates. "Requirement 2.4.4: The protocol proxying facilities and transport practices MUST allow ADMINISTRATORS ways to enable and disable protocol activity through existing and commonly-deployed FIREWALLS. The protocol MUST specify how it can be effectively filtered by such FIREWALLS." Although SIP itself runs on port 5060 by default, any other port can be used. It is simple to specify that presence should run on a different port, if so desired. "Requirement 2.5.1: The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been corrupted or tampered with." SIP provides end to end authentication and message integrity using PGP; other mechanisms can be specified. "Requirement 2.5.2. The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT Rosenberg et al. [Page 66] Internet Draft presence June 15, 2000 MESSAGE) has not been recorded and played back by an adversary." Replay attacks can be prevented through either challenge-response authentication, timestamp based checks, or storage of previously used sequence numbers and transaction identifiers. See Section 10.4. "Requirement 2.5.3: The protocol MUST provide means to ensure that a sent message (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that the sender allows." SIP provides end-to-end encryption using PGP. "Requirement 2.5.4: The protocol MUST allow any client to use the means to ensure non-corruption, non-playback, and privacy, but the protocol MUST NOT require that all clients use these means at all times." SIPs security mechanisms are optional. "Requirement 3.1.1: All ENTITIES MUST produce and consume at least a common base format for PRESENCE INFORMATION." Here, we mandate the Lightweight Presence Information Data Format (LPIDF) [10]. "Requirement 3.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE INFORMATION even when the PRESENTITY is OUT OF CONTACT." The extension described here defines a fetch operation that can be made on a presence server; this server handles subscriptions and fetches when a presence client is not available. "Requirement 3.2.2: A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT OF CONTACT." Subscriptions are handled by a presence server when the presence client is not available. "Requirement 3.2.3: If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER, unless prevented by the PRESENTITY's ACCESS RULES." This is supported as described in Section 7. Rosenberg et al. [Page 67] Internet Draft presence June 15, 2000 "Requirement 3.2.4. The protocol MUST provide a mechanism for detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT." The SIP REGISTER method is used for this purpose. "Requirement 3.2.5: The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER gracefully telling the service that it will no longer be in communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT due to unanticipated failures." Registrations are soft state, and will timeout if not refreshed. "Requirement 3.3.1: The protocol MUST include mechanisms to allow PRESENCE INFORMATION to be cached." Although not explicitly described here, this is easily supported as an implementation improvement. "Requirement 3.3.2: The protocol MUST include mechanisms to allow cached PRESENCE INFORMATION to be updated when the master copy changes." Presence data contains timestamps which indicate its expiration; this forces a fetch to go to the PA after expiration. "Requirement 3.3.3: The protocol caching facilities MUST NOT circumvent established ACCESS RULES or restrict choice of authentication/encryption mechanisms." The protocol does not explicitly circumvent access rules when caching is used; however, if the caching server does not choose to authenticate or authorize subscribers, no protocol in the world can prevent this. "Requirement 3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any SUBSCRIBER to that information MUST be notified of the changed information rapidly, except when such notification is entirely prevented by ACCESS RULES. This requirement is met if each SUBSCRIBER's NOTIFICATION is transported as rapidly as an INSTANT MESSAGE would be transported to an INSTANT INBOX." SIP is engineered for rapid transfer of messages. In fact, SIP (and the presence extension) allows notifications to go directly from presence agent to subscriber. 15 Acknowledgements Rosenberg et al. [Page 68] Internet Draft presence June 15, 2000 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 Jorgen Bjorkner Hotsip Henry Sinnreich MCI Worldcom Ronald Akers Motorola 16 Authors Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Dean Willis dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: dwillis@dynamicsoft.com Robert Sparks dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: rsparks@dynamicsoft.com Ben Campbell dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: bcampbell@dynamicsoft.com Henning Schulzrinne Rosenberg et al. [Page 69] Internet Draft presence June 15, 2000 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 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 Rosenberg et al. [Page 70] Internet Draft presence June 15, 2000 Engineering Task Force, Mar. 1999. [3] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. [4] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments 2327, Internet Engineering Task Force, Apr. 1998. [5] R. Stewart et al. , "Simple control transmission protocol," Internet Draft, Internet Engineering Task Force, Apr. 2000. Work in progress. [6] J. Rosenberg and H. Schulzrinne, "SCTP as a transport for SIP," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [7] S. Kent and R. Atkinson, "IP encapsulating security payload (ESP)," Request for Comments 2406, Internet Engineering Task Force, Nov. 1998. [8] D. Harkins and D. Carrel, "The internet key exchange (IKE)," Request for Comments 2409, Internet Engineering Task Force, Nov. 1998. [9] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for presence authorization," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [10] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A lightweight presence information data format (LPIDF)," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [11] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A data format for presence using XML," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [12] 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. [13] J. Lennox and H. Schulzrinne, "CPL: a language for user control of internet telephony services," Internet Draft, Internet Engineering Task Force, Mar. 1999. Work in progress. Rosenberg et al. [Page 71] Internet Draft presence June 15, 2000 [14] J. Lennox and H. Schulzrinne, "Transporting user control information in sip register payloads," Internet Draft, Internet Engineering Task Force, Mar. 2000. 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. [16] B. Ramsdell and Ed, "S/MIME version 3 message specification," Request for Comments 2633, Internet Engineering Task Force, June 1999. [17] J. Rosenberg and H. Schulzrinne, "SIP extensions for managing persistent connections," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [18] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging / presence protocol requirements," Request for Comments 2779, Internet Engineering Task Force, Feb. 2000. [19] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for instant messaging," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. [20] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)," Request for Comments 2782, Internet Engineering Task Force, Feb. 2000. Table of Contents 1 Introduction ........................................ 1 2 Why use SIP as a base protocol for presence? ....... 3 3 Definitions ......................................... 6 4 Overview of Operation ............................... 8 4.1 Architecture ........................................ 8 4.2 Message Flow ........................................ 8 5 Subscriptions ....................................... 16 5.1 Generating subscriptions ............................ 16 5.2 Sending subscriptions ............................... 19 5.3 Proxying subscriptions .............................. 20 5.4 Presence server processing of SUBSCRIBE ............. 20 5.5 Presence agent processing of SUBSCRIBE .............. 21 Rosenberg et al. [Page 72] Internet Draft presence June 15, 2000 5.5.1 Refreshes ........................................... 21 5.5.2 New subscriptions ................................... 22 5.6 Subscriber processing of SUBSCRIBE response ......... 23 5.7 Unsubscribing ....................................... 24 5.8 Fetching ............................................ 24 6 Publication ......................................... 24 7 Notification ........................................ 26 7.1 When to send ........................................ 26 7.2 Formatting of NOTIFY ................................ 27 7.3 Responding to NOTIFY ................................ 28 8 Access controls ..................................... 28 9 Providing scalability ............................... 29 9.1 Partitioning of the namespace ....................... 30 9.2 Client notifications ................................ 31 9.3 Distributed subscription state ...................... 31 10 Security considerations ............................. 34 10.1 Privacy ............................................. 34 10.2 Message integrity and authenticity .................. 35 10.3 Outbound authentication ............................. 35 10.4 Replay prevention ................................... 36 10.5 Denial of service attacks ........................... 36 10.5.1 Smurf attacks through false contacts ................ 36 10.5.2 Annoyance subscriptions ............................. 37 10.6 Firewall traversal .................................. 37 11 Addressing Transport ................................ 37 12 Required SIP features ............................... 39 12.1 Needed components ................................... 39 12.2 Components not needed ............................... 40 13 Example message flows ............................... 41 13.1 Client to Client Subscription with Presentity State Changes .................................................. 41 13.2 Presence Server with Client Notifications ........... 45 13.3 Presence Server Notifications ....................... 51 13.4 Presence Server Notifications with Client Authorization of Subscription .................................. 54 13.5 Delayed Subscription Approval ....................... 60 14 Checklist of requirements ........................... 64 15 Acknowledgements .................................... 68 16 Authors Addresses ................................... 69 17 Bibliography ........................................ 70 Rosenberg et al. [Page 73]