idnits 2.17.1 draft-rosenberg-simple-data-req-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 a Security Considerations section. ** 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 147: '... REQ 1: It MUST be possible for ...' RFC 2119 keyword, line 150: '... REQ 2: It MUST be possible for ...' RFC 2119 keyword, line 152: '... already exists, for example), it MUST...' RFC 2119 keyword, line 156: '... REQ 3: It SHOULD be possible fo...' RFC 2119 keyword, line 160: '... REQ 4: It MUST be possible to a...' (45 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 (June 24, 2002) is 7970 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: 5 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-rosenberg-simple-data-req-00.txt 8 June 24, 2002 9 Expires: December 2002 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 an instant messaging and presence application, it is frequently 37 necessary for the user to configure a number of pieces of 38 information. Users will need to manipulate their buddy list, adding 39 and removing presentities, and manipulate their authorization lists, 40 which specify the set of users that can subscribe to their presence. 41 In this document, we provide a set of requirements for such data 42 manipulations, and provide a framework for viewing them in a common 43 way. 45 Table of Contents 47 1 Introduction ........................................ 3 48 2 Buddy List Manipulation ............................. 3 49 2.1 Model ............................................... 3 50 2.2 Requirements ........................................ 4 51 3 Authorization Policy Manipulation ................... 6 52 3.1 Model ............................................... 6 53 3.2 Requirements ........................................ 8 54 4 Manipulation of Feature Data ........................ 8 55 4.1 Model ............................................... 8 56 4.2 Examples ............................................ 9 57 4.3 Requirements ........................................ 11 58 5 Possible Solutions .................................. 12 59 6 Authors Addresses ................................... 12 60 7 Normative References ................................ 13 61 8 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". The buddy list is the set of presentities [1] that a user is 72 subscribed to. This buddy list is frequently stored on the server, 73 allowing the user to generate a single subscription to the entire 74 list. The server then "fans out" that subscription too all the 75 presentities on the list. Subscription to buddy lists is supported 76 through the buddylist event package defined for SIMPLE [2]. However, 77 no automated means is currently defined to create these lists, add 78 users to them, remove users from them, or query for the set of users 79 on the list. 81 Similarly, most systems support user-defined authorization policies. 82 A user can specify which watchers are (or are not) allowed to 83 subscribe to their presence, and furthermore, what aspects of their 84 presence a watcher is able to see. While SIMPLE [3] systems can 85 support such authorization policies, besides human-driven techniques, 86 such as web or voice response, there is no automated way to specify 87 these policies. 89 In this document, we propose a set of requirements for manipulation 90 of buddy lists and authorization policies. We also provide a 91 generalized framework for these problems, and present requirements 92 for a generalized solution. 94 2 Buddy List Manipulation 96 2.1 Model 98 The model for the the usage and manipulation of a buddy list is shown 99 in Figure 1. 101 A buddy list is defined as a set of presentities (each of which is 102 represented by a URI). The buddy list is itself identified by a URI 103 (for example, sip:myfriends@example.com). The SIP buddy list event 104 package [2] allows a watcher to subscribe to the buddy list. 105 Currently, buddy lists are manipulated through human interaction, 106 such as on a web page or a voice response system. In order to support 107 manipulation of the list by automata, protocol support is needed. 109 We assume that there is some kind of client-server protocol for such 110 SUBSCRIBE +--------+ 111 --------------->| | Read 112 | PA |<--+ //----\\ 113 <---------------| | | || || 114 NOTIFY +--------+ +--- \\----//| 115 | | 116 | Storage| 117 | | 118 +--------+ | | 119 | Server |------> | | 120 | | Write \ / 121 | | \------/ 122 +--------+ 123 ^ | 124 | | 125 | | BL 126 | | Manipulations 127 | | 128 | | 129 | V 130 +--------+ 131 | Client | 132 | | 133 | | 134 +--------+ 136 Figure 1: Model for Buddy List Manipulation 138 manipulation. The server stores the buddy list, and can directly 139 manipulate it based on requests from the client. The presence agent 140 (PA) can fetch the buddy list when it receives a subscribe request 141 for it. 143 2.2 Requirements 145 The following are the set of requirements for such manipulations: 147 REQ 1: It MUST be possible for the client to create a buddylist 148 and associate it with a URI. 150 REQ 2: It MUST be possible for the user to specify the URI for 151 the buddylist when one is created. If the name cannot be 152 allocated (because it already exists, for example), it MUST 153 be possible to inform the client of the failure, and the 154 reason for it. 156 REQ 3: It SHOULD be possible for the server to provide the 157 client a URI for the list when one is created, in the case 158 where the client does not provide it. 160 REQ 4: It MUST be possible to add an entry to the buddylist. It 161 MUST be possible for the entry to be any URI that is 162 meaningful in the context of a buddy list. Examples would 163 include a SIP URI or pres URI [4]. 165 REQ 5: It MUST be possible for a buddy list to contain entries 166 which are themselves buddy lists. 168 REQ 6: It MUST be possible to remove an entry from the 169 buddylist, by providing the URI for the specific entry to 170 be removed. If the entry does not exist, it MUST be 171 possible for the server to inform the client of this fact. 173 REQ 7: It SHOULD be possible to clear all entries from a buddy 174 list. 176 REQ 8: It MUST be possible to delete a buddy list. In this 177 context, deleted means that the name of the buddy list is 178 no longer defined, so that subscriptions to the list would 179 fail. 181 REQ 9: It MUST be possible to query for the set of URIs in a 182 particular buddy list, by providing the URI for the buddy 183 list. 185 REQ 10: It MUST be possible for the buddy list to be associated 186 with a list of authorized users. Those authorized users are 187 the only ones permitted to manipulate the buddy list. 189 REQ 11: It MUST be possible for a client to store a cached copy 190 of the list. This implies that it MUST be possible for the 191 server to notify the client of a change in the list. It 192 MUST be possible for the client to manipulate the local 193 cached copy even when there is no connectivity to the 194 server. It MUST be possible to synchronize the cached copy 195 with the master copy on the server, when connectivity is 196 re-established. 198 This particular requirement is crucial for wireless 199 systems, where a copy of the list resides ont he handset. 200 Without this requirement, a user would not be able to view 201 the list, or add a user to it, when they go out of 202 coverage. 204 REQ 12: It MUST be possible for there to be multiple clients 205 with cached copies of the list. 207 REQ 13: Manipulations of the buddy list MUST exhibit the ACID 208 property; that is, they MUST be atomic, be consistent, 209 durable, and operate independently. 211 REQ 14: It MAY be possible for the client to batch multiple 212 operations (add a buddy, remove a buddy) into a single 213 request that is processed atomically. 215 REQ 15: It MUST be possible for the server to authenticate the 216 client. 218 REQ 16: It MUST be possible for the client to authenticate the 219 server. 221 REQ 17: It MUST be possible for message integrity to be insured 222 between the client and the server. 224 REQ 18: It MUST be possible for privacy to be insured between 225 the client and server. As a motivating example, an 226 eavesdropper on the protocol could ascertain the set of 227 people on my buddy list, resulting in divulging private 228 information. 230 3 Authorization Policy Manipulation 232 3.1 Model 234 When presence agent receives a subscription request, it makes a 235 decision on whether the watcher is allowed to subscribe, and what 236 they are allowed to subscribe to. The presentity can manipulate those 237 policies, in order to support both off-line authorizations, and 238 reactive authorizations (reactive authorizations are ones that are 239 made in response to an attempt by the watcher to subscribe). 241 Similarly, when a proxy receives an IM, the proxy can execute policy 242 which determines whether or not the IM should be forwarded to the 243 user. 245 Generally, there are two aspects to both of these policy systems. One 246 is the logic that guides the policy, and the other is the data (such 247 as lists of users) accessed by that logic. As an example, the logic 248 might dictate that a watcher is checked against an explicit deny 249 list, and if present, their subscription is denied. If they are not 250 on the deny list, they are checked against an explicit allow list, 251 and if present, their subscription is accepted. If they are on 252 neither list, they are marked as pending. This logic makes use of two 253 lists, which represent the data. 255 In this model, the logic can be represented by a script, similar to 256 the operation of a Call Processing Language (CPL) [5] script. The 257 primitives of the scripting language would allow for access to the 258 lists that represent the data. For example, a CPL-like script 259 representing the policy example of the previous paragraph might look 260 like: 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 282 The deny and allow lists are, in this example, represented by SIP 283 URIs. The script itself can also be represented by a URI. In order to 284 activate a policy, a particular script is bound to the authorization 285 function that executes at the PA (or SIP proxy server that would 286 process an IM). 288 The overall architecture is, as a result, the same as is shown in 289 Figure 1. The client manipulates the script and a set of lists at the 290 server. The server stores this data, and it can be read by a presence 291 agent in order to make an authorization decision. 293 3.2 Requirements 295 Based on this model, the following requirements can be specified: 297 REQ 1: It MUST be possible to bind a script defining the logic 298 for processing to a particular authorization function. 300 REQ 2: It MUST be possible for the client to determine the set 301 of supported scripting languages. 303 REQ 3: It MUST be possible for the server to reject the script 304 because it is malformed, too complex, or not acceptable for 305 some other reason. 307 REQ 4: It MUST be possible for the client to fetch the current 308 script. 310 REQ 5: It MUST be possible for the client to indicate what 311 script languages it supports when it fetches the script. In 312 this way, a server could conceivably translate it to a 313 format supported by the client. 315 Almost all of the requirements for buddy list manipulation as 316 specified above also apply to manipulation of the script and of the 317 lists. As such, we do not repeat them. 319 4 Manipulation of Feature Data 321 From a requirements analysis of the manipulation of buddy lists and 322 of authorization policy, it is clear that there is a more general 323 problem here. The problem is the manipulation of user feature data 324 associated with applications. We therefore propose a model for this 325 more general case, and specify requirements for it. 327 4.1 Model 329 In the proposed model, there is an application (also referred to as a 330 feature) that is resident within the network. This application 331 provides a value added service to the user. Sometimes, the user has 332 control over the logic of the application itself. However, in many 333 more cases, the application is "owned" by the service provider, and 334 cannot be arbitrarily manipulated by the user. Rather, it has a well 335 defined set of ways in which it is invoked and interacted with. The 336 application operates on behalf of a user. That user might be the one 337 interacting with it (as in the buddy list application), or might be 338 representing the interests of that user when a different user 339 interacts with it (as in the authorization application). In this 340 model, we assume that an application can always determine the user on 341 whose behalf it is operating for any particular interaction. 343 The application, in order to properly operate, requires a set of data 344 elements that are specific to the user on whose behalf it operates. 345 Each application has a well-defined set of data elements it requires. 346 Each data element is named (for example "buddy list") and is of a 347 well-defined type. Example types include lists, integers, trees, or 348 scripts. 350 In order to provide those data elements, the user can create, 351 destroy, and manipulate objects of various types. It can also bind an 352 instance of an object to a particular named data element. As an 353 example, a user can create a list called "my friends" and bind it to 354 the "buddy list" data element, which accepts lists. 356 This model is shown pictorially in Figure 2. In this model, the 357 application has a number data elements (represented by "holes"), each 358 of which has a name (foo, bar, baz). The shape of the hole represents 359 its type. There is a data storage (which could be the Internet 360 itself) that contains data elements of various types. Authorized 361 users can bind the holes to instances of each shape (type), in order 362 to fully define the operation of the application. There is a default 363 object that would fill in each hole when one has not explicitly been 364 provided. 366 4.2 Examples 368 The model is easily applied to many different applications. 370 A simple example is call-forward no-answer. This application requires 371 a single data element, the call-forwarding number. This data element 372 is a particular data type (phone number). It should be possible for a 373 user to create several phone numbers within the network, associate 374 each with a name, and then bind the actual application to a specific 375 name. 377 Another example is a voicemail application. The application might 378 require a number of data elements - the number of rings until it goes 379 to voicemail (an integer), the prompt played to the caller (an audio 380 file), and the password for accessing the voicemail (a string). 381 Clearly, some of these data elements, like the greeting, cannot be 382 manipulated through a protocol proposed here. However, the binding 383 Example Application 384 +-----------------------------------+ 385 | | 386 | | 387 | baz | 388 | +-+ | 389 | | | | 390 | foo bar | | | 391 | +--+ +----+ | | | 392 | | | | | | | | | 393 +----+ /+------+ | +---+ +---------+ 394 / | | 395 / | | 396 / | | 397 / | | 398 / | | 399 / | | 400 +---------/---------------V-----------------------+ 401 | / +--+ +-+--+ | +-+ | 402 | V |B | | E | | | | | 403 | +--+ +--+ +----+ | | | | 404 | |A | | |G| | 405 | +--+ | | | | 406 | +--+ | +-+ | 407 | |C | V | 408 | +--+ +-+ | 409 | | | | 410 | object +----+ | | | 411 | pool | D | |F| | 412 | +----+ | | | 413 | +-+ | 414 | | 415 +-------------------------------------------------+ 416 Data Storage 418 Figure 2: Data Manipulation Model 420 operations proposed here are applicable. In the example of the 421 voicemail greeting, the greeting could be recorded separately, but 422 assuming it is nothing more than a URI (such as 423 sip:greeting33@example.com) it can be bound to the "greeting" data 424 element of the voicemail application through the protocol whose 425 requirements are discussed here. 427 4.3 Requirements 429 Based on this model, we propose the following general requirements 430 for a protocol to manipulate user feature data: 432 REQ 1: It MUST be possible to create objects that have one of 433 several defined types. The types MUST include, at a 434 minimum, integer, string, list of strings, list of URI, and 435 blob. 437 REQ 2: It MUST be possible for the user to provide a URI that 438 identifies the object that was created. 440 REQ 3: It MUST be possible for the server to provide the client 441 with a URI that identifies the object that was created. 443 REQ 4: It MUST be possible to destroy an object. 445 REQ 5: It MUST be possible to query for the value of a 446 particular object. 448 REQ 6: It MUST be possible to perform type-specific 449 manipulations on the object. In the case of lists, this 450 would include addition and removal of members. 452 REQ 7: It MUST be possible to bind a named data element for a 453 particular named application to a particular object. For 454 example, a client could bind the buddy list data element of 455 the Presence application to the buddy list 456 myfriends@example.com. 458 REQ 8: It MUST be possible to obtain the name of the object 459 bound to a particular data element of a particular 460 application. For example, to determine which buddy list is 461 the current one in use. 463 REQ 9: It MUST be possible for the client to maintain a cached 464 copy of a particular object. 466 REQ 10: It MUST be possible for multiple clients to maintain a 467 cached copy of the same object. 469 REQ 10: It MUST be possible for the client to receive 470 notifications of changes to an object. 472 REQ 11: It MUST be possible for the client to perform type 473 specific manipulations on an object even while not 474 connected to the server. 476 REQ 12: It MUST be possible for an object to be resynchronized 477 to the master copy on a server, once a client reconnects. 479 REQ 13: Manipulations of data objects MUST exhibit the ACID 480 property. 482 REQ 14: It SHOULD be possible for client to learn the set of 483 data elements, and their types, for a particular named 484 application. As an example, a client could query a 485 voicemail application, and learn that it requires an 486 integer called "number of rings" and an audio file called 487 "greeting". 489 REQ 15: It MUST be possible for the server to authorize only 490 specific users to create, destroy, and manipulate objects, 491 and to bind an object to a data element. 493 REQ 16: It MUST be possible for the server to authenticate the 494 client, and for the client to authenticate the server. 496 REQ 17: It MUST be possible for message integrity to be provided 497 for all messages between client and server, and server and 498 client. 500 REQ 18: It MUST be possible to provide privacy for all messages 501 exchanged between client and server. 503 5 Possible Solutions 505 This document is primarily a requirements document, and does not aim 506 to provide a protocol for meeting the requirements defined here. 507 However, there are several protocols already in existence which 508 appear close to meeting the requirements described. One of these is 509 ACAP [6]. Since the protocol is primarily a client-server RPC type of 510 operation, it seems like HTTP and SOAP might also serve as a basis, 511 with a suitably defined set of WSDL. SIP could operate alongside 512 SOAP, to provide the notification aspects of the requirements. SNMP 513 is another possibility for the protocol. 515 6 Authors Addresses 517 Jonathan Rosenberg 518 dynamicsoft 519 72 Eagle Rock Avenue 520 First Floor 521 East Hanover, NJ 07936 522 email: jdrosen@dynamicsoft.com 524 Markus Isomaki 525 Nokia 526 Nokia House 527 Keilalahti, Espoo 528 Finland 529 email: markus.isomaki@nokia.com 531 7 Normative References 533 8 Informative References 535 [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and 536 instant messaging," RFC 2778, Internet Engineering Task Force, Feb. 537 2000. 539 [2] J. Rosenberg, "A SIP event package for buddylist presence," 540 Internet Draft, Internet Engineering Task Force, June 2002. Work in 541 progress. 543 [3] J. Rosenberg, "Session initiation protocol (SIP) extensions for 544 presence," Internet Draft, Internet Engineering Task Force, May 2002. 545 Work in progress. 547 [4] D. Crocker et al. , "A common profile for instant messaging 548 (CPIM)," Internet Draft, Internet Engineering Task Force, Nov. 2001. 549 Work in progress. 551 [5] J. Lennox and H. Schulzrinne, "Call processing language framework 552 and requirements," RFC 2824, Internet Engineering Task Force, May 553 2000. 555 [6] C. Newman and J. G. Myers, "ACAP -- application configuration 556 access protocol," RFC 2244, Internet Engineering Task Force, Nov. 557 1997. 559 Full Copyright Statement 561 Copyright (c) The Internet Society (2002). All Rights Reserved. 563 This document and translations of it may be copied and furnished to 564 others, and derivative works that comment on or otherwise explain it 565 or assist in its implementation may be prepared, copied, published 566 and distributed, in whole or in part, without restriction of any 567 kind, provided that the above copyright notice and this paragraph are 568 included on all such copies and derivative works. However, this 569 document itself may not be modified in any way, such as by removing 570 the copyright notice or references to the Internet Society or other 571 Internet organizations, except as needed for the purpose of 572 developing Internet standards in which case the procedures for 573 copyrights defined in the Internet Standards process must be 574 followed, or as required to translate it into languages other than 575 English. 577 The limited permissions granted above are perpetual and will not be 578 revoked by the Internet Society or its successors or assigns. 580 This document and the information contained herein is provided on an 581 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 582 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 583 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 584 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 585 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.