idnits 2.17.1 draft-ietf-simple-data-req-02.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.) ** 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 220: '... REQ PC-1: It MUST be possible for ...' RFC 2119 keyword, line 223: '... REQ PC-2: It MUST be possible for ...' RFC 2119 keyword, line 226: '... example), it MUST be possible to i...' RFC 2119 keyword, line 229: '... REQ PC-3: It MUST be possible for ...' RFC 2119 keyword, line 233: '... REQ PC-4: It MUST be possible to a...' (68 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (April 16, 2003) is 7679 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) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '6') (Obsoleted by RFC 6665) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 4 dynamicsoft 5 M. Isomaki 6 Nokia 7 draft-ietf-simple-data-req-02.txt 8 April 16, 2003 9 Expires: October 2003 11 Requirements for Manipulation of Data Elements in Session 12 Initiation Protocol (SIP) for Instant Messaging and Presence 13 Leveraging Extensions (SIMPLE) Systems 15 STATUS OF THIS MEMO 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 To view the list Internet-Draft Shadow Directories, see 34 http://www.ietf.org/shadow.html. 36 Abstract 38 In any presence application, it is frequently necessary for the user 39 to configure a number of pieces of information. Users will need to 40 manipulate their presentity list, adding and removing presentities, 41 and manipulate their authorization lists, which specify the set of 42 users that can subscribe to their presence. In this document, we 43 provide a framework and requirements for such data manipulations. 45 Table of Contents 47 1 Introduction ........................................ 3 48 2 Terminology ......................................... 3 49 3 Framework ........................................... 4 50 4 Presentity Collection Manipulation Requirements ..... 6 51 5 Authorization Policy Manipulation ................... 9 52 5.1 Acceptance Policy Requirements ...................... 9 53 5.2 Notification Requirements ........................... 10 54 5.3 Content Requirements ................................ 10 55 5.4 General Requirements ................................ 11 56 6 Security Considerations ............................. 12 57 7 To Do ............................................... 12 58 8 Acknowledgements .................................... 13 59 9 Authors Addresses ................................... 13 60 10 Normative References ................................ 13 61 11 Informative References .............................. 13 63 1 Introduction 65 Consumer-based instant messaging and presence applications typically 66 provide a rich set of features. In addition to being able to 67 subscribe to, and get notified of, changes in presence, users can 68 also configure the operation of the application. 70 Most systems allow the user to add or remove users from their "buddy 71 list", which we refer to here as a presentity collection. The 72 presentity collection is the set of presentities [1] that a user is 73 subscribed to. This list is frequently stored on the server, allowing 74 the user to generate a single subscription to the entire list. The 75 server then "fans out" that subscription too all the presentities on 76 the list. Subscription to presentity collections is supported through 77 the SIP event notification extension for collections [2]. However, no 78 automated means is currently defined to create these lists, add users 79 to them, remove users from them, or query for the set of users on the 80 list. 82 Similarly, most systems support user-defined authorization policies. 83 A user can specify which watchers are (or are not) allowed to 84 subscribe to their presence, and furthermore, what aspects of their 85 presence a watcher is able to see. While SIMPLE [3] systems can 86 support such authorization policies, besides human-driven techniques, 87 such as web or voice response, there is no automated way to specify 88 these policies. 90 In this document, we propose a framework and a set of requirements 91 for manipulation of presentity collections and authorization 92 policies. 94 2 Terminology 96 This document uses the following terminology: 98 Presentity Collection: A presentity collection is a set of 99 presentities, each of which is identified by a URI. The 100 collection itself is identified by a URI (for example, 101 sip:myfriends@example.com). Using the SIP event extension 102 for collections [2], a watcher can subscribe to the 103 presentity collection and learn about the presence state of 104 all the presentities in the set. 106 Presence Authorization Policy: Presence authorization policy 107 refers to the set of directives given to a presence agent 108 on what subscriptions to accept, when to generate 109 notifications for a subscription, and what information 110 should be placed in those notifications. 112 Acceptance Policy: The component of presence authorization 113 policy that determines whether or not to accept a 114 subscription from a watcher. 116 Notification Policy: The component of presence authorization 117 policy that determines when a notification should be sent 118 to a watcher. 120 Content Policy: The component of presence authorization that 121 determines the content of the information provided to a 122 watcher in a notification. 124 SIMPLE Data Elements: SIMPLE data elements are user specified 125 data that determine the behavior of a presence agent. This 126 includes presentity collections and presence authorization 127 policy. 129 Data Manipulation Client: A data manipulation client is a 130 protocol agent that reads, writes, and receives 131 notifications of changes in SIMPLE data elements. 133 Data Manipulation Server: A data manipulation server is a 134 protocol agent that receives reads, writes, and sends 135 notifications of changes in SIMPLE data elements. The 136 server is responsible for the storage of the SIMPLE data 137 elements. 139 3 Framework 141 The framework for the the usage and manipulation of SIMPLE data 142 elements is shown in Figure 1. 144 The data manipulation client (just referred to as the client) uses 145 some protocol, whose requirements are specified here, to interact 146 with the data manipulation server. Those interactions include 147 requests to read a SIMPLE data element, write one, or receive 148 notifications in changes to one. The data manipulation server (just 149 referred to as the server) mananges a persistent store of the SIMPLE 150 data elements, and interacts with the client. 152 When a Presence Agent (PA) receives a SIP SUBSCRIBE request [3], it 153 may require access to SIMPLE data elements in order to process the 154 request. For example, if the subscription is for a presentity 155 collection, the PA will need to determine that this is the case, and 156 secondly, "expand" the collection, obtaining the list of URIs for 157 that collection. 159 SUBSCRIBE +--------+ 160 --------------->| | Read 161 | PA |<--+ //----\\ 162 <---------------| | | || || 163 NOTIFY +--------+ +--- \\----//| 164 | | 165 | Storage| 166 | | 167 +--------+ | | 168 | Server |<-----> | | 169 | | Read/ \ / 170 | | Write \------/ 171 +--------+ 172 ^ | 173 | | 174 | | PC/Auth 175 | | Manipulations 176 | | 177 | | 178 | V 179 +--------+ 180 | Client | 181 | | 182 | | 183 +--------+ 185 Figure 1: Framework for Data Manipulation 187 If the SUBSCRIBE request is for a presentity, the PA will need to 188 obtain the presence authorization policy of that presentity in order 189 to process the SUBSCRIBE request. 191 In both cases, the PA requires only read access to the data. As a 192 result, it obtains it directly from the data store, rather than 193 interacting with the server. This, of course, is just a model of the 194 system; a real implementation might involve interaction with the 195 server before reading the data. 197 Between the presentity collection and presence authorization policy, 198 the presence authorization policy is a far more complicated piece of 199 data. The authorization policy can be reasonably split into three 200 separate pieces. The first, which we call the acceptance policy, 201 determines whether or not to grant a subscription to the subscriber. 202 This policy results in a binary decision. The second piece, which we 203 call the notification policy, determines when that particular 204 subscriber should receive notifications. For example, a subscriber 205 might only be permitted to see when I log in or log out of IM, but 206 not receive notifications when my phone goes on hook. This is closely 207 related to the third piece, which we call the content policy. This 208 policy specifies the content of the information present in a 209 notification that is sent to a subscriber. 211 All of these policies are data that is manipulated by the data 212 manipulation protocol. 214 4 Presentity Collection Manipulation Requirements 216 The following are the set of requirements for the protocol between 217 the client and the server for the purposes of manipulation presentity 218 collections. 220 REQ PC-1: It MUST be possible for the client to create a 221 presentity collection and associate it with a URI. 223 REQ PC-2: It MUST be possible for the user to specify the URI 224 for the presentity collection when one is created. If the 225 name cannot be allocated (because it already exists, for 226 example), it MUST be possible to inform the client of the 227 failure, and the reason for it. 229 REQ PC-3: It MUST be possible for the server to provide the 230 client a URI for the list when one is created, in the case 231 where the client does not provide it. 233 REQ PC-4: It MUST be possible to add an entry to the presentity 234 collection. Each entry MUST consist of at least a URI, and 235 MAY include a display name. It MUST be possible for the 236 entry to be any URI that is meaningful in the context of a 237 presentity collection. Examples would include a SIP URI or 238 pres URI [4]. 240 REQ PC-5: It MUST be possible for a presentity collection to 241 contain entries which are themselves presentity 242 collections. It MUST be possible for the client to 243 determine whether the entry is a presentity or anoter 244 presentity collection. 246 REQ PC-6: It MUST be possible to remove an entry from the 247 presentity collection. If the entry does not exist, it MUST 248 be possible for the server to inform the client of this 249 fact. 251 REQ PC-7: It MUST be possible to clear all entries from a 252 presentity collection. 254 REQ PC-8: It MUST be possible to delete a presentity collection. 255 In this context, deleted means that the name of the 256 presentity collection is no longer defined, so that 257 subscriptions to the list would fail. 259 REQ PC-9: It MUST be possible to query for the set of URIs in a 260 particular presentity collection, by providing the URI for 261 the presentity collection. 263 REQ PC-10: It MUST be possible for the presentity collection to 264 be associated with a list of authorized users. Those 265 authorized users are the only ones permitted to manipulate 266 the presentity collection. 268 REQ PC-11: It MUST be possible for the presentity collection to 269 be associated with a list of users that are authorized to 270 subscribe to the list. 272 REQ PC-12: It MUST be possible for a client to store a cached 273 copy of the list. This implies that it MUST be possible for 274 the server to notify the client of a change in the list. It 275 MUST be possible for the client to manipulate the local 276 cached copy even when there is no connectivity to the 277 server. It MUST be possible to synchronize the cached copy 278 with the master copy on the server, when connectivity is 279 re-established. 281 This particular requirement is crucial for wireless 282 systems, where a copy of the list resides ont he handset. 283 Without this requirement, a user would not be able to view 284 the list, or add a user to it, when they go out of 285 coverage. 287 REQ PC-13: It MUST be possible for there to be multiple clients 288 with cached copies of the list. 290 REQ PC-14: Manipulations of the presentity collection MUST 291 exhibit the ACID property; that is, they MUST be atomic, be 292 consistent, durable, and operate independently. 294 REQ PC-15: It MAY be possible for the client to batch multiple 295 operations (add a presentity, remove a presentity) into a 296 single request that is processed atomically. 298 REQ PC-16: It MUST be possible for the server to authenticate 299 the client. 301 REQ PC-17: It MUST be possible to use the same database of 302 client credentials used with SIP and SIMPLE, with the data 303 manipulation protocol. 305 REQ PC-18: It MUST be possible for the client to authenticate 306 the server. 308 REQ PC-19: It MUST be possible for message integrity to be 309 insured between the client and the server. 311 REQ PC-20: It MUST be possible for confidentiality to be ensured 312 between the client and server. As a motivating example, an 313 eavesdropper on the protocol could ascertain the set of 314 people in my presentity collection, resulting in divulging 315 private information. 317 REQ PC-21: It MUST be possible for the protocol to operate 318 through an intermediary, such as a proxy. 320 REQ PC-22: It MUST be possible to modify an entry in the 321 presentity collection. 323 REQ PC-23: It MUST be possible for the protocol to operate with 324 devices with intermittent and low bandwidth connectivity, 325 such as wireless data devices. 327 REQ PC-24: It MUST be possible for the presence collection to be 328 integrated with a network resident address book. This means 329 that there should be no duplication of data between the 330 two, and only a single transaction should be needed to add 331 or remove an entry from both. 333 REQ PC-25: It MUST be possible for a user to retrieve the list 334 of collections that they have created. 336 REQ PC-26: It MUST be possible to associate a display name with 337 a collection. 339 REQ PC-27: It MUST be possible to extend the set of information 340 associated with entries in the collection. 342 5 Authorization Policy Manipulation 344 The following are the set of requirements for the protocol between 345 the client and the server for the purposes of manipulating presence 346 authorization policy. The requirements are divided between acceptance 347 policy, notification policy, and content policy. 349 5.1 Acceptance Policy Requirements 351 REQ AP-1: It MUST be possible for the acceptance policy to 352 support rejection of the subscription if the watcher is 353 present on a specified list of "blocked watchers". When a 354 list is checked in this fashion, its referred to as a 355 blocked list. 357 REQ AP-2: It MUST be possible for the acceptance policy to 358 support rejection of the subscription if the watcher is not 359 present on a specified list of "allowed watchers". 361 REQ AP-3: It MUST be possible for the acceptance policy to 362 support making a subscription pending if the watcher is 363 present on neither an explicit allowed or blocked list. In 364 that case, the watcherinfo package [5] can be used for 365 reactive authorization. 367 REQ AP-4: It MUST be possible for the acceptance policy to check 368 multiple blocked and allowed lists. 370 REQ AP-5: It SHOULD be possible for the policy to be based on 371 the means by which the authenticated identity of the 372 watcher was determined (digest vs. s/mime, for example). 374 REQ AP-6: It SHOULD be possible for the policy to be based on 375 whether notifications can be sent encrypted to the 376 subscriber. 378 REQ AP-7: It MUST be possible for a subscription to be accepted 379 or rejected based on whether the subscriber is on the 380 presentity's own buddy list. 382 REQ AP-8: It MUST be possible for the user to manipulate any 383 lists that are checked by by the authorization policy (for 384 example, the allowed and denied lists). Manipulate means to 385 add, remove, modify, read, clear and create and delete. 387 REQ AP-9: It MUST be possible for the acceptance policies to be 388 applied to subscriptions for SIP event packages [6] besides 389 presence. 391 5.2 Notification Requirements 393 REQ N-1: It MUST be possible for the user to specify that 394 notifications are to be sent only when the value of a 395 particular status type changes. 397 REQ N-2: It MUST be possible for the user to specify that the 398 notifications are to be sent only when a particular status 399 type changes to a specified value or set of values. 401 REQ N-3: It MUST be possible for the user to specify that the 402 notifications are to be sent only when a particular status 403 type changes from a specified value to a specified value 404 (i.e., from open to closed). 406 REQ N-4: It MUST be possible for the user to specify that the 407 notifications are to be sent only when the value of the 408 contact address changes. 410 REQ N-5: It SHOULD be possible for the user to specify that the 411 notifications are not, or should be sent on changes in the 412 state of the subscription (as opposed to the state of the 413 presentity). 415 5.3 Content Requirements 417 REQ C-1: It MUST be possible for the user to specify that the 418 notification should or should not contain a contact 419 address. 421 REQ C-2: It MUST be possible for the user to specify that the 422 notification should contain only specific status types 423 (such as basic). 425 REQ C-3: The user MUST be able to specify the specific values of 426 a specific status type that the notification should or 427 should not contain. Values not permitted must result in the 428 omission of that status type. If all status is omitted, the 429 tuple must be omitted as well. As an example, a user can 430 specify that the notification should include tuples with 431 OPEN status, but suppress those with only CLOSED status. 433 REQ C-4: The user MUST be able to specify that the notification 434 should only contain information for particular tuples. 436 REQ C-5: It SHOULD be possible for the user to specify that the 437 value of a status should be modified for a particular 438 subscriber (i.e., the user wants to lie). 440 REQ C-6: It SHOULD be possible for the user to specify the 441 specific presence document to send to a watcher. 443 REQ C-7: It SHOULD be possible for the user to specify that the 444 notifications should be encrypted using S/MIME. 446 5.4 General Requirements 448 These requirements apply to all of the three components of the 449 authorization policy. 451 REQ G-1: It MUST be possible for a client to store a cached copy 452 of the policies. This implies that it MUST be possible for 453 the server to notify the client of a change in these data. 454 It MUST be possible for the client to manipulate the local 455 cached copy even when there is no connectivity to the 456 server. It MUST be possible to synchronize the cached copy 457 with the master copy on the server, when connectivity is 458 re-established. 460 REQ G-2: It MUST be possible for there to be multiple clients 461 with cached copies of the data. 463 REQ G-3: Manipulations of the data MUST exhibit the ACID 464 property; that is, they MUST be atomic, be consistent, 465 durable, and operate independently. 467 REQ G-4: It MAY be possible for the client to batch multiple 468 operations (add a user to a list, set a display name) into 469 a single request that is processed atomically. 471 REQ G-5: It MUST be possible for the server to authenticate the 472 client. 474 REQ G-6: It MUST be possible to use the same database of client 475 credentials used with SIP and SIMPLE, with the data 476 manipulation protocol. 478 REQ G-7: It MUST be possible for the client to authenticate the 479 server. 481 REQ G-8: It MUST be possible for message integrity to be ensured 482 between the client and the server. 484 REQ G-9: It MUST be possible for confidentiality to be ensured 485 between the client and server. As a motivating example, an 486 eavesdropper on the protocol could ascertain the set of 487 people in my allowed list collection, resulting in 488 divulging private information. 490 REQ G-10: It MUST be possible for the protocol to operate with 491 devices with intermittent and low bandwidth connectivity, 492 such as wireless data devices. 494 REQ G-11: It MUST be possible to extend the authorization 495 policies with new rules. 497 REQ G-12: It MUST be possible for a client to discover the types 498 of authorization policies the server can handle. 500 6 Security Considerations 502 There are many security considerations associated with the protocol 503 whose requirements are defined here. 505 The protocol is used to manipulate data that has a signficiant impact 506 on the operation of a service provided to a user. In particular, if 507 the data is manipulated by an attacker, the attacker can: 509 o convey information to subscribers that the presentity wishes 510 to keep private; 512 o launch denial of service attacks by flooding a subscriber with 513 more presence information than they expected; 515 o deny service to subscribers or to presentities. 517 To prevent these attacks, the protocol has to ensure than only 518 authorized users can manipulate the data. Requirements for 519 authentication and authorization are defined above. 521 Information conveyed in the protocol represents sensitive data. It 522 can include the content of presentity collections and lists of 523 blocked users, both of which reveal personal preferences of a user 524 that they do not wish to convey. As a result, it is necessary that 525 the client authenticate the server, to be sure it is passing this 526 information to a trusted entity. It is also necessary for the 527 protocol to provide encryption services, so that eavesdroppers cannot 528 inspect the data as it passes by. 530 7 To Do 531 o Align this with the ongoing filter work 533 o Make sure the requirements are consistent with the final 534 protocol mechanism. 536 8 Acknowledgements 538 The authors would like to thank Paul Kyzivat for his input. 540 9 Authors Addresses 542 Jonathan Rosenberg 543 dynamicsoft 544 72 Eagle Rock Avenue 545 First Floor 546 East Hanover, NJ 07936 547 email: jdrosen@dynamicsoft.com 549 Markus Isomaki 550 Nokia 551 Nokia House 552 Keilalahti, Espoo 553 Finland 554 email: markus.isomaki@nokia.com 556 10 Normative References 558 11 Informative References 560 [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and 561 instant messaging," RFC 2778, Internet Engineering Task Force, Feb. 562 2000. 564 [2] A. B. Roach, J. Rosenberg, and B. Campbell, "A session initiation 565 protocol (SIP) event notification extension for collections," 566 internet draft, Internet Engineering Task Force, Mar. 2003. Work in 567 progress. 569 [3] J. Rosenberg, "A presence event package for the session 570 initiation protocol (SIP)," internet draft, Internet Engineering Task 571 Force, Jan. 2003. Work in progress. 573 [4] D. H. Crocker and J. L. Peterson, "Common profile for presence 574 (CPP)," internet draft, Internet Engineering Task Force, Mar. 2003. 575 Work in progress. 577 [5] J. Rosenberg, "A watcher information event template-package for 578 the session initiation protocol (SIP)," internet draft, Internet 579 Engineering Task Force, Jan. 2003. Work in progress. 581 [6] A. B. Roach, "Session initiation protocol (sip)-specific event 582 notification," RFC 3265, Internet Engineering Task Force, June 2002. 584 Intellectual Property Statement 586 The IETF takes no position regarding the validity or scope of any 587 intellectual property or other rights that might be claimed to 588 pertain to the implementation or use of the technology described in 589 this document or the extent to which any license under such rights 590 might or might not be available; neither does it represent that it 591 has made any effort to identify any such rights. Information on the 592 IETF's procedures with respect to rights in standards-track and 593 standards-related documentation can be found in BCP-11. Copies of 594 claims of rights made available for publication and any assurances of 595 licenses to be made available, or the result of an attempt made to 596 obtain a general license or permission for the use of such 597 proprietary rights by implementors or users of this specification can 598 be obtained from the IETF Secretariat. 600 The IETF invites any interested party to bring to its attention any 601 copyrights, patents or patent applications, or other proprietary 602 rights which may cover technology that may be required to practice 603 this standard. Please address the information to the IETF Executive 604 Director. 606 Full Copyright Statement 608 Copyright (c) The Internet Society (2003). All Rights Reserved. 610 This document and translations of it may be copied and furnished to 611 others, and derivative works that comment on or otherwise explain it 612 or assist in its implementation may be prepared, copied, published 613 and distributed, in whole or in part, without restriction of any 614 kind, provided that the above copyright notice and this paragraph are 615 included on all such copies and derivative works. However, this 616 document itself may not be modified in any way, such as by removing 617 the copyright notice or references to the Internet Society or other 618 Internet organizations, except as needed for the purpose of 619 developing Internet standards in which case the procedures for 620 copyrights defined in the Internet Standards process must be 621 followed, or as required to translate it into languages other than 622 English. 624 The limited permissions granted above are perpetual and will not be 625 revoked by the Internet Society or its successors or assigns. 627 This document and the information contained herein is provided on an 628 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 629 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 630 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 631 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 632 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.