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