[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


   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-

   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

   To view the list Internet-Draft Shadow Directories, see


   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

        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

        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

   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

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@
   Contact: sip:
   CSeq: 87769 SUBSCRIBE
   Via: SIP/2.0/UDP

   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

   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

   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

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

   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

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

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
   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
   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]

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