idnits 2.17.1 draft-rosenberg-simple-buddylist-package-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 204: '...UBSCRIBE message MAY contain a body wh...' RFC 2119 keyword, line 213: '... a handset, it is RECOMMENDED that the...' RFC 2119 keyword, line 228: '...tors of this package MUST support this...' RFC 2119 keyword, line 236: '...n the NOTIFY. A subscriber MAY support...' RFC 2119 keyword, line 237: '.../mixed, and a notifier MAY support it....' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2001) is 8198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 386 looks like a reference -- Missing reference section? '2' on line 389 looks like a reference -- Missing reference section? '3' on line 392 looks like a reference -- Missing reference section? '5' on line 400 looks like a reference -- Missing reference section? '4' on line 396 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIMPLE WG 3 Internet Draft J.Rosenberg,B.Campbell 4 draft-rosenberg-simple-buddylist-package-00.txt dynamicsoft 5 November 14, 2001 6 Expires: May 2002 8 A SIP Event Package for Buddylist Presence 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document presents a SIP event package for subscribing to a buddy 34 list. A buddy list is a collection of presentities that a subscriber 35 is interested in learning presence state for. Instead of the 36 subscriber sending a SUBSCRIBE to each buddy individually, the 37 subscriber can subscribe to their buddy list as a whole, and then 38 receive notifications when the state of any of their buddies changes. 40 1 Introduction 42 The SIP for presence specification [1] allows a user (the subscriber) 43 to request to be notified of changes in the presence state of a 44 particular user (the presentity). This is accomplished by having the 45 subscriber generate a SUBSCRIBE request for the presentity, which is 46 processed at a presence agent in the domain of the presentity. 48 Typically, a subscriber has a collection of presentities they are 49 interested in. This collection is called a buddy list, and typically 50 has anywhere from a few to even a hundred members. 52 For environments where banwidth is more limited, such as a wireless 53 network, having a user SUBSCRIBE to each buddy individually is 54 problematic. The specific problems are: 56 o It generates substantial message traffic, in the form of the 57 initial SUBSCRIBE requests for each buddy, and the refreshes 58 of each individual subscription. 60 o The presence agent in the remote domain may insist on low 61 refresh intervals, in order to avoid long lived subscription 62 state. This means that the subscriber may need to generate 63 subscriptions faster than it would like to, or has the 64 capacity to. 66 o The presence agent in the remote domain may generate NOTIFY 67 requests more rapidly than the subscriber desires, causing 68 NOTIFY traffic at a greater volume than is desired by the 69 subscriber. 71 o The SUBSCRIBE request may fork, resulting in multiple 72 subscriptions being established, each of which may need to be 73 refreshed independently (this is being debated at this time). 74 It may also require the subscriber to aggregate presence 75 documents for each subscription that is generated. This will 76 generate additional traffic and processing requirements on the 77 subscriber. 79 o If a system has only intermittent connectivity, and generally 80 polls for presence rather than simply subscribing, the latency 81 to obtain the presence state of the entire buddy list can be 82 large. The messaging required for each poll can also be 83 substantial. 85 Our solution to these problems is a simple one. We define an element, 86 called a "buddy list subscription server", or BLSS, which is nothing 87 more than a presence agent for the buddy list itself. The subscriber 88 has a direct relationship with the BLSS. The BLSS need not be in the 89 same domain as the subscriber (it can be run by some third party 90 application provider, for example), but the BLSS exists to serve the 91 specific needs of the subscriber. The user subscribes to their buddy 92 list, which resides in the BLSS, and the BLSS generates a 93 subscription for each user in the buddy list. The BLSS forwards the 94 notifications for each buddy towards the subscriber, potentially 95 performing rate limiting or other aggregation functions as needed. 97 The first section provides more detail on the operation of the BLSS, 98 and the second section defines the event package for buddy list 99 subscriptions. 101 2 BLSS Operation 103 The BLSS has access to the buddy list of the subscriber. How the 104 buddy list gets to the BLSS is outside the scope of this document. It 105 could be uploaded through some kind of publication mechanism, it 106 could be entered in a web page, or it could be established through 107 some voice interaction with the subscriber. 109 When the subscriber comes online, they generate a subscription to the 110 buddylist itself, using the event package for buddy lists. This 111 SUBSCRIBE might look like: 113 SUBSCRIBE sip:joes-buddylist@buddylistserversrus.com SIP/2.0 114 From: sip:joe@foo.com 115 To: sip:joes-buddylist@buddylistserversrus.com 116 Event: buddylist 117 Call-ID: 989asdh@1.2.3.4 118 Contact: sip:1.2.3.4 119 CSeq: 87769 SUBSCRIBE 120 Via: SIP/2.0/UDP 1.2.3.4 122 The BLSS would receive this, authenticate the SUBSCRIBE (which is 123 easily done since it is assumed that the subscriber has a 124 relationship with the BLSS provider), and if authenticated, 125 authorize. If authorized, the subscription is accepted and a 200 OK 126 is sent. The BLSS generates an immediate, empty NOTIFY as required by 127 [2], and then obtains the presence state of the users on the buddy 128 list. It can do this any way it likes, but typically it will act as a 129 subscriber itself, generating a SUBSCRIBE request for each user in 130 joes-buddylist. As notifications with presence data are received, 131 they can be passed onwards towards the subscriber. 133 As an example, consider a buddy list with two buddies, 134 sip:userA@a.com and sip:userB@b.com. A typical flow for a 135 subscription to this buddy list is shown in Figure 1. 137 3 Event Package for "buddylist" 139 The following subsections formally define the buddylist event 140 package, following the requirements defined by the SIP events 141 Joe BLSS User A user B 142 | | | | 143 |(1) SUBSCRIBE | | | 144 | buddylist | | | 145 |---------------->| | | 146 |(2) 200 OK | | | 147 |<----------------| | | 148 |(3) NOTIFY | | | 149 |<----------------| | | 150 |(4) 200 OK | | | 151 |---------------->| | | 152 | |(5) SUBSCRIBE a | | 153 | |---------------->| | 154 | |(6) SUBSCRIBE b | | 155 | |---------------------------------->| 156 | |(7) 200 OK | | 157 | |<----------------| | 158 | |(8) 200 OK | | 159 | |<----------------------------------| 160 | |(9) NOTIFY | | 161 | |<----------------| | 162 | |(10) 200 OK | | 163 | |---------------->| | 164 |(11) NOTIFY | | | 165 | a's state | | | 166 |<----------------| | | 167 |(12) 200 OK | | | 168 |---------------->| | | 169 | |(13) NOTIFY | | 170 | |<----------------------------------| 171 | |(14) 200 OK | | 172 | |---------------------------------->| 173 |(15) NOTIFY | | | 174 | b's state | | | 175 |<----------------| | | 176 |(16) 200 OK | | | 177 |---------------->| | | 179 Figure 1: Typical BLSS Usage 181 framework [2]. 183 3.1 Event Package Name 184 The name of this event package is "buddylist". 186 The following is the information needed to register this event 187 package with IANA: 189 Package Name: buddylist 191 Type: package 193 Contact: Jonathan Rosenberg, jdrosen@dynamicsoft.com 195 Reference: draft-rosenberg-simple-buddylist-package-00.txt 197 3.2 Event Package Parameters 199 This specification does not define any parameters in the Event header 200 for this package. 202 3.3 SUBSCRIBE Bodies 204 The SUBSCRIBE message MAY contain a body whose purpose is to defined 205 filters on the operation of the buddylist. These filters would 206 include any rate limitation desired for the notifications, any 207 aggregation that is desired, and so on. There is no default or 208 mandatory body type defined for this purpose. 210 3.4 Subscription Duration 212 Since the primary benefit of the buddy list server is to reduce the 213 overall messaging volume to a handset, it is RECOMMENDED that the 214 subscription duration to a buddylist be reasonably long, with a 215 default of two hours. That reduces the need to refresh too 216 frequently. Of course, the standard techniques [2] can be used to 217 increase or reduce this amount. 219 3.5 NOTIFY Bodies 221 The only mandatory-to-implement body type in notifications is 222 application/cpim-pidf+xml, which is the default body type for the 223 presence event package [3]. Since the cpim-pidf+xml type contains the 224 identity of the presentity within it, it is clear for which buddy the 225 presence data applies. Having this as the default and mandatory-to- 226 implement type simplifies the transition from using a buddylist 227 subscription to using direct subscriptions, as the types in either 228 case are the same. All implementors of this package MUST support this 229 type. 231 It is possible for a BLSS to act as an aggregation point, collecting 232 notifications from the bodies and grouping them together into a 233 single NOTIFY. In this case, there are two possibilities. The first 234 is to use multipart/mixed as described in [3]. In this case, each 235 NOTIFY contains the set of presence documents from each presentity 236 being aggregated in the NOTIFY. A subscriber MAY support 237 multipart/mixed, and a notifier MAY support it. 239 The second possibility for aggregation is to use a single body type 240 explicitly designed to support lists of presence data. This format, 241 ????.... 243 This list format is TBD. 245 The absence of an Accept header in the SUBSCRIBE indicates support 246 for only application/cpim-pidf+xml. Any other types supported by the 247 client MUST be included in an Accept header in the SUBSCRIBE request. 249 3.6 Notifier Processing of SUBSCRIBE Requests 251 All subscriptions for buddy lists SHOULD be authenticated. The use of 252 the SIP HTTP Digest mechanism [4]is RECOMMENDED. Additionally the 253 usage of TLS between the client and the BLSS, with SIP HTTP Digest 254 for client authentication, MAY be used when integrity and privacy 255 services are needed. 257 Once authenticated, the subscription is authorized. Typically, each 258 buddy list is associated with a particular user, and only that user 259 will be allowed to subscribe. Of course, there may be exceptions to 260 this rule, and a notifier MAY use any authorization policy it 261 chooses. 263 One authorized, the SUBSCRIBE is responded with a 200 OK and an 264 immediate, empty NOTIFY. The notifier can then use any means at its 265 disposal to determine the presence state of the members on the 266 buddylist, including acting as a subscriber itself and subscribing to 267 them. 269 3.7 Notifier Generation of NOTIFY Requests 271 This specification leaves the choice about how and when to generate 272 NOTIFY requests at the discretion of the implementor. One of the 273 value propositions of the BLSS is the means by which it aggregates, 274 rate limits, or optimizes the way in which notifications are 275 generated. 277 As a baseline behavior, if the BLSS acts as a subscriber to determine 278 the state of the presentities on the buddy list, it MAY generate a 279 NOTIFY to the BLSS subscriber whenever it receives a NOTIFY from the 280 presentity. The body of the NOTIFY from the presentity, assuming its 281 application/cpim-pidf+xml, would merely be copied from that NOTIFY 282 into the NOTIFY sent by the BLSS to the subscriber. If a subscription 283 to a presentity is refused, the BLSS MAY generate a new presence 284 document for that presentity, setting its status to "subscription 285 refused", and then pass that NOTIFY to the subscriber. This would 286 give the subscriber a visual clue that its subscription was refused, 287 and that the presentity should probably be removed from the buddy 288 list. 290 3.8 Subscriber Processing of NOTIFY Requests 292 When a subscriber receives a NOTIFY, it MAY authenticate it. Once 293 authenticated, the subscriber verifies that the NOTIFY comes from an 294 existing subscription. Assuming that is the case, the body of the 295 NOTIFY is examined. It will contain the presence state for some 296 subset of the presentities in the buddy list. The presence state for 297 each of those presentities is updated to whatever presence data is 298 conveyed in the NOTIFY. 300 3.9 Handling of Forked Requests 302 Forking makes little sense with this event package, since the whole 303 idea is a centralization of the source of notifications. Therefore, a 304 subscriber to a buddy list SHOULD generate a 481 on receipt of any 305 NOTIFY requests which do not match the 200 response returned to the 306 SUBSCRIBE. 308 3.10 Rate of Notifications 310 One potential role of the BLSS is to perform rate limitations on 311 behalf of the subscriber. As such, this specification does not 312 mandate any particular rate limitation, and rather leaves that to the 313 discretion of the implementation. 315 3.11 State Agents 317 Effectively, a buddy list server is nothing more than a state agent 318 for the presence event type. A separate event package is needed 319 because of the differing body types which can be used in NOTIFY, and 320 the differing semantics of the application/cpim+pidf type (in this 321 package, the subscriber needs to look at the presentity identity, and 322 verify its on their buddy list. For regular presence, the presentity 323 identity in the NOTIFY body will always be the same as the presentity 324 that was subscribed to). Furthermore, there are differing values of 325 the subscription interval, differing recommendations on rate 326 limitation, and so on. 328 The usage of the BLSS server does introduce some security 329 considerations. The end user is no longer the direct subscriber to 330 the presence state of the presentity. If the PA for the presentity 331 demands end-to-end authentication, the BLSS will need to be provided 332 the shared secrets for those presentities (assuming Digest is used). 333 This requires a certain level of trust between the user and their 334 BLSS. This specification does not describe any particular means of 335 uploading the shared secret for a particular subscriber to the BLSS. 336 However, that upload mechanism MUST ensure privacy of the key data; 337 using HTTPS to fill out a form is a reasonable method. 339 If the PA for the presentity is using a transitive chain of trust to 340 validate the subscriber, then this works well with the BLSS concept. 341 THe BLSS would authenticate the subscriber, and then MAY use the SIP 342 extensions for privacy [5] to provide an authenticated identity to 343 the PA, over a secure transport such as TLS or IPSec. 345 In the case of the PA authenticating the subscriber based on PKI, the 346 usage of a BLSS is problematic. Since the BLSS will not typically 347 have the private key of the subscriber, the PA will not be able to 348 authenticate the subscriber directly. Some kind of delegation 349 mechanism using certificate chaining may be possible, but requires 350 further consideration. 352 4 Security Considerations 354 The BLSS does introduce some security considerations, most of which 355 are discussed in Section 3.11. 357 5 Open Issues 359 1. The concept here can be generalized into a sub-package. 360 Effectively, it could be the "aggregation" sub-package for 361 any package, and allow for subscriptions to a list of 362 elements of the parent package type. The default body of 363 the sub-package would be the same as the parent package, 364 but also allow for multipart/mixed and possibly a type 365 specific to the parent package. Therefore, instead of 366 "buddylist", we would have "presence.aggregate". 368 6 Author's Addresses 370 Jonathan Rosenberg 371 dynamicsoft 372 72 Eagle Rock Avenue 373 First Floor 374 East Hanover, NJ 07936 375 email: jdrosen@dynamicsoft.com 377 Ben Campbell 378 dynamicsoft 379 5100 Tennyson Parkway 380 Suite 1200 381 Plano, Texas 75024 382 email: bcampbell@dynamicsoft.com 384 7 Bibliography 386 [1] J. Rosenberg, "SIP extensions for presence," Internet Draft, 387 Internet Engineering Task Force, Sept. 2001. Work in progress. 389 [2] A. Roach, "SIP-specific event notification," Internet Draft, 390 Internet Engineering Task Force, Nov. 2001. Work in progress. 392 [3] H. Sugano and S. Fujimoto, "CPIM presence information data 393 format," Internet Draft, Internet Engineering Task Force, Aug. 2001. 394 Work in progress. 396 [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 397 session initiation protocol," Request for Comments 2543, Internet 398 Engineering Task Force, Mar. 1999. 400 [5] B. Marshall et al. , "SIP extensions for caller identity and 401 privacy," Internet Draft, Internet Engineering Task Force, Mar. 2001. 402 Work in progress. 404 Table of Contents 406 1 Introduction ........................................ 1 407 2 BLSS Operation ...................................... 3 408 3 Event Package for "buddylist" ....................... 3 409 3.1 Event Package Name .................................. 4 410 3.2 Event Package Parameters ............................ 5 411 3.3 SUBSCRIBE Bodies .................................... 5 412 3.4 Subscription Duration ............................... 5 413 3.5 NOTIFY Bodies ....................................... 5 414 3.6 Notifier Processing of SUBSCRIBE Requests ........... 6 415 3.7 Notifier Generation of NOTIFY Requests .............. 6 416 3.8 Subscriber Processing of NOTIFY Requests ............ 7 417 3.9 Handling of Forked Requests ......................... 7 418 3.10 Rate of Notifications ............................... 7 419 3.11 State Agents ........................................ 7 420 4 Security Considerations ............................. 8 421 5 Open Issues ......................................... 8 422 6 Author's Addresses .................................. 8 423 7 Bibliography ........................................ 9