Internet Engineering Task Force SIMPLE WG Internet Draft J.Rosenberg,B.Campbell draft-rosenberg-simple-buddylist-package-00.txt dynamicsoft November 14, 2001 Expires: May 2002 A SIP Event Package for Buddylist Presence STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document presents a SIP event package for subscribing to a buddy list. A buddy list is a collection of presentities that a subscriber is interested in learning presence state for. Instead of the subscriber sending a SUBSCRIBE to each buddy individually, the subscriber can subscribe to their buddy list as a whole, and then receive notifications when the state of any of their buddies changes. 1 Introduction The SIP for presence specification [1] allows a user (the subscriber) to request to be notified of changes in the presence state of a particular user (the presentity). This is accomplished by having the subscriber generate a SUBSCRIBE request for the presentity, which is processed at a presence agent in the domain of the presentity. J.Rosenberg,B.Campbell [Page 1] Internet Draft Buddy list package November 14, 2001 Typically, a subscriber has a collection of presentities they are interested in. This collection is called a buddy list, and typically has anywhere from a few to even a hundred members. For environments where banwidth is more limited, such as a wireless network, having a user SUBSCRIBE to each buddy individually is problematic. The specific problems are: o It generates substantial message traffic, in the form of the initial SUBSCRIBE requests for each buddy, and the refreshes of each individual subscription. o The presence agent in the remote domain may insist on low refresh intervals, in order to avoid long lived subscription state. This means that the subscriber may need to generate subscriptions faster than it would like to, or has the capacity to. o The presence agent in the remote domain may generate NOTIFY requests more rapidly than the subscriber desires, causing NOTIFY traffic at a greater volume than is desired by the subscriber. o The SUBSCRIBE request may fork, resulting in multiple subscriptions being established, each of which may need to be refreshed independently (this is being debated at this time). It may also require the subscriber to aggregate presence documents for each subscription that is generated. This will generate additional traffic and processing requirements on the subscriber. o If a system has only intermittent connectivity, and generally polls for presence rather than simply subscribing, the latency to obtain the presence state of the entire buddy list can be large. The messaging required for each poll can also be substantial. Our solution to these problems is a simple one. We define an element, called a "buddy list subscription server", or BLSS, which is nothing more than a presence agent for the buddy list itself. The subscriber has a direct relationship with the BLSS. The BLSS need not be in the same domain as the subscriber (it can be run by some third party application provider, for example), but the BLSS exists to serve the specific needs of the subscriber. The user subscribes to their buddy list, which resides in the BLSS, and the BLSS generates a subscription for each user in the buddy list. The BLSS forwards the notifications for each buddy towards the subscriber, potentially performing rate limiting or other aggregation functions as needed. J.Rosenberg,B.Campbell [Page 2] Internet Draft Buddy list package November 14, 2001 The first section provides more detail on the operation of the BLSS, and the second section defines the event package for buddy list subscriptions. 2 BLSS Operation The BLSS has access to the buddy list of the subscriber. How the buddy list gets to the BLSS is outside the scope of this document. It could be uploaded through some kind of publication mechanism, it could be entered in a web page, or it could be established through some voice interaction with the subscriber. When the subscriber comes online, they generate a subscription to the buddylist itself, using the event package for buddy lists. This SUBSCRIBE might look like: SUBSCRIBE sip:joes-buddylist@buddylistserversrus.com SIP/2.0 From: sip:joe@foo.com To: sip:joes-buddylist@buddylistserversrus.com Event: buddylist Call-ID: 989asdh@1.2.3.4 Contact: sip:1.2.3.4 CSeq: 87769 SUBSCRIBE Via: SIP/2.0/UDP 1.2.3.4 The BLSS would receive this, authenticate the SUBSCRIBE (which is easily done since it is assumed that the subscriber has a relationship with the BLSS provider), and if authenticated, authorize. If authorized, the subscription is accepted and a 200 OK is sent. The BLSS generates an immediate, empty NOTIFY as required by [2], and then obtains the presence state of the users on the buddy list. It can do this any way it likes, but typically it will act as a subscriber itself, generating a SUBSCRIBE request for each user in joes-buddylist. As notifications with presence data are received, they can be passed onwards towards the subscriber. As an example, consider a buddy list with two buddies, sip:userA@a.com and sip:userB@b.com. A typical flow for a subscription to this buddy list is shown in Figure 1. 3 Event Package for "buddylist" The following subsections formally define the buddylist event package, following the requirements defined by the SIP events J.Rosenberg,B.Campbell [Page 3] Internet Draft Buddy list package November 14, 2001 Joe BLSS User A user B | | | | |(1) SUBSCRIBE | | | | buddylist | | | |---------------->| | | |(2) 200 OK | | | |<----------------| | | |(3) NOTIFY | | | |<----------------| | | |(4) 200 OK | | | |---------------->| | | | |(5) SUBSCRIBE a | | | |---------------->| | | |(6) SUBSCRIBE b | | | |---------------------------------->| | |(7) 200 OK | | | |<----------------| | | |(8) 200 OK | | | |<----------------------------------| | |(9) NOTIFY | | | |<----------------| | | |(10) 200 OK | | | |---------------->| | |(11) NOTIFY | | | | a's state | | | |<----------------| | | |(12) 200 OK | | | |---------------->| | | | |(13) NOTIFY | | | |<----------------------------------| | |(14) 200 OK | | | |---------------------------------->| |(15) NOTIFY | | | | b's state | | | |<----------------| | | |(16) 200 OK | | | |---------------->| | | Figure 1: Typical BLSS Usage framework [2]. 3.1 Event Package Name J.Rosenberg,B.Campbell [Page 4] Internet Draft Buddy list package November 14, 2001 The name of this event package is "buddylist". The following is the information needed to register this event package with IANA: Package Name: buddylist Type: package Contact: Jonathan Rosenberg, jdrosen@dynamicsoft.com Reference: draft-rosenberg-simple-buddylist-package-00.txt 3.2 Event Package Parameters This specification does not define any parameters in the Event header for this package. 3.3 SUBSCRIBE Bodies The SUBSCRIBE message MAY contain a body whose purpose is to defined filters on the operation of the buddylist. These filters would include any rate limitation desired for the notifications, any aggregation that is desired, and so on. There is no default or mandatory body type defined for this purpose. 3.4 Subscription Duration Since the primary benefit of the buddy list server is to reduce the overall messaging volume to a handset, it is RECOMMENDED that the subscription duration to a buddylist be reasonably long, with a default of two hours. That reduces the need to refresh too frequently. Of course, the standard techniques [2] can be used to increase or reduce this amount. 3.5 NOTIFY Bodies The only mandatory-to-implement body type in notifications is application/cpim-pidf+xml, which is the default body type for the presence event package [3]. Since the cpim-pidf+xml type contains the identity of the presentity within it, it is clear for which buddy the presence data applies. Having this as the default and mandatory-to- implement type simplifies the transition from using a buddylist subscription to using direct subscriptions, as the types in either case are the same. All implementors of this package MUST support this type. It is possible for a BLSS to act as an aggregation point, collecting J.Rosenberg,B.Campbell [Page 5] Internet Draft Buddy list package November 14, 2001 notifications from the bodies and grouping them together into a single NOTIFY. In this case, there are two possibilities. The first is to use multipart/mixed as described in [3]. In this case, each NOTIFY contains the set of presence documents from each presentity being aggregated in the NOTIFY. A subscriber MAY support multipart/mixed, and a notifier MAY support it. The second possibility for aggregation is to use a single body type explicitly designed to support lists of presence data. This format, ????.... This list format is TBD. The absence of an Accept header in the SUBSCRIBE indicates support for only application/cpim-pidf+xml. Any other types supported by the client MUST be included in an Accept header in the SUBSCRIBE request. 3.6 Notifier Processing of SUBSCRIBE Requests All subscriptions for buddy lists SHOULD be authenticated. The use of the SIP HTTP Digest mechanism [4]is RECOMMENDED. Additionally the usage of TLS between the client and the BLSS, with SIP HTTP Digest for client authentication, MAY be used when integrity and privacy services are needed. Once authenticated, the subscription is authorized. Typically, each buddy list is associated with a particular user, and only that user will be allowed to subscribe. Of course, there may be exceptions to this rule, and a notifier MAY use any authorization policy it chooses. One authorized, the SUBSCRIBE is responded with a 200 OK and an immediate, empty NOTIFY. The notifier can then use any means at its disposal to determine the presence state of the members on the buddylist, including acting as a subscriber itself and subscribing to them. 3.7 Notifier Generation of NOTIFY Requests This specification leaves the choice about how and when to generate NOTIFY requests at the discretion of the implementor. One of the value propositions of the BLSS is the means by which it aggregates, rate limits, or optimizes the way in which notifications are generated. As a baseline behavior, if the BLSS acts as a subscriber to determine the state of the presentities on the buddy list, it MAY generate a J.Rosenberg,B.Campbell [Page 6] Internet Draft Buddy list package November 14, 2001 NOTIFY to the BLSS subscriber whenever it receives a NOTIFY from the presentity. The body of the NOTIFY from the presentity, assuming its application/cpim-pidf+xml, would merely be copied from that NOTIFY into the NOTIFY sent by the BLSS to the subscriber. If a subscription to a presentity is refused, the BLSS MAY generate a new presence document for that presentity, setting its status to "subscription refused", and then pass that NOTIFY to the subscriber. This would give the subscriber a visual clue that its subscription was refused, and that the presentity should probably be removed from the buddy list. 3.8 Subscriber Processing of NOTIFY Requests When a subscriber receives a NOTIFY, it MAY authenticate it. Once authenticated, the subscriber verifies that the NOTIFY comes from an existing subscription. Assuming that is the case, the body of the NOTIFY is examined. It will contain the presence state for some subset of the presentities in the buddy list. The presence state for each of those presentities is updated to whatever presence data is conveyed in the NOTIFY. 3.9 Handling of Forked Requests Forking makes little sense with this event package, since the whole idea is a centralization of the source of notifications. Therefore, a subscriber to a buddy list SHOULD generate a 481 on receipt of any NOTIFY requests which do not match the 200 response returned to the SUBSCRIBE. 3.10 Rate of Notifications One potential role of the BLSS is to perform rate limitations on behalf of the subscriber. As such, this specification does not mandate any particular rate limitation, and rather leaves that to the discretion of the implementation. 3.11 State Agents Effectively, a buddy list server is nothing more than a state agent for the presence event type. A separate event package is needed because of the differing body types which can be used in NOTIFY, and the differing semantics of the application/cpim+pidf type (in this package, the subscriber needs to look at the presentity identity, and verify its on their buddy list. For regular presence, the presentity identity in the NOTIFY body will always be the same as the presentity that was subscribed to). Furthermore, there are differing values of the subscription interval, differing recommendations on rate limitation, and so on. J.Rosenberg,B.Campbell [Page 7] Internet Draft Buddy list package November 14, 2001 The usage of the BLSS server does introduce some security considerations. The end user is no longer the direct subscriber to the presence state of the presentity. If the PA for the presentity demands end-to-end authentication, the BLSS will need to be provided the shared secrets for those presentities (assuming Digest is used). This requires a certain level of trust between the user and their BLSS. This specification does not describe any particular means of uploading the shared secret for a particular subscriber to the BLSS. However, that upload mechanism MUST ensure privacy of the key data; using HTTPS to fill out a form is a reasonable method. If the PA for the presentity is using a transitive chain of trust to validate the subscriber, then this works well with the BLSS concept. THe BLSS would authenticate the subscriber, and then MAY use the SIP extensions for privacy [5] to provide an authenticated identity to the PA, over a secure transport such as TLS or IPSec. In the case of the PA authenticating the subscriber based on PKI, the usage of a BLSS is problematic. Since the BLSS will not typically have the private key of the subscriber, the PA will not be able to authenticate the subscriber directly. Some kind of delegation mechanism using certificate chaining may be possible, but requires further consideration. 4 Security Considerations The BLSS does introduce some security considerations, most of which are discussed in Section 3.11. 5 Open Issues 1. The concept here can be generalized into a sub-package. Effectively, it could be the "aggregation" sub-package for any package, and allow for subscriptions to a list of elements of the parent package type. The default body of the sub-package would be the same as the parent package, but also allow for multipart/mixed and possibly a type specific to the parent package. Therefore, instead of "buddylist", we would have "presence.aggregate". 6 Author's Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 J.Rosenberg,B.Campbell [Page 8] Internet Draft Buddy list package November 14, 2001 email: jdrosen@dynamicsoft.com Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 email: bcampbell@dynamicsoft.com 7 Bibliography [1] J. Rosenberg, "SIP extensions for presence," Internet Draft, Internet Engineering Task Force, Sept. 2001. Work in progress. [2] A. Roach, "SIP-specific event notification," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [3] H. Sugano and S. Fujimoto, "CPIM presence information data format," Internet Draft, Internet Engineering Task Force, Aug. 2001. Work in progress. [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [5] B. Marshall et al. , "SIP extensions for caller identity and privacy," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. Table of Contents 1 Introduction ........................................ 1 2 BLSS Operation ...................................... 3 3 Event Package for "buddylist" ....................... 3 3.1 Event Package Name .................................. 4 3.2 Event Package Parameters ............................ 5 3.3 SUBSCRIBE Bodies .................................... 5 3.4 Subscription Duration ............................... 5 3.5 NOTIFY Bodies ....................................... 5 J.Rosenberg,B.Campbell [Page 9] Internet Draft Buddy list package November 14, 2001 3.6 Notifier Processing of SUBSCRIBE Requests ........... 6 3.7 Notifier Generation of NOTIFY Requests .............. 6 3.8 Subscriber Processing of NOTIFY Requests ............ 7 3.9 Handling of Forked Requests ......................... 7 3.10 Rate of Notifications ............................... 7 3.11 State Agents ........................................ 7 4 Security Considerations ............................. 8 5 Open Issues ......................................... 8 6 Author's Addresses .................................. 8 7 Bibliography ........................................ 9 J.Rosenberg,B.Campbell [Page 10]