idnits 2.17.1 draft-koskelainen-xcon-cpcp-reqs-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: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 16, 2003) is 7497 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) == Unused Reference: '1' is defined on line 360, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 363, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area P. Koskelainen 3 Internet-Draft H. Khartabil 4 Expires: April 15, 2004 Nokia 5 October 16, 2003 7 Requirements for Conference Policy Control Protocol 8 draft-koskelainen-xcon-cpcp-reqs-01 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 other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 15, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The conference policy server allows clients to manipulate and 39 interact with the conference policy. One mechanism to manipulate the 40 policy is to use conference policy control protocol (CPCP). This 41 document gives the requirements for CPCP. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 47 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 4. Integration with Floor Control . . . . . . . . . . . . . . . . 6 49 5. Conference Policy Data Model . . . . . . . . . . . . . . . . . 7 50 6. CPCP Requirements . . . . . . . . . . . . . . . . . . . . . . 8 51 6.1 Conference creation, termination and joining . . . . . . . . . 8 52 6.2 Manipulating general conference attributes . . . . . . . . . . 8 53 6.3 Authentication and Security . . . . . . . . . . . . . . . . . 9 54 6.4 Application and media manipulation . . . . . . . . . . . . . . 9 55 6.5 ACL manipulation . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.6 Floor control . . . . . . . . . . . . . . . . . . . . . . . . 10 57 6.7 Inviting and ejecting users . . . . . . . . . . . . . . . . . 10 58 6.8 User Privileges . . . . . . . . . . . . . . . . . . . . . . . 10 59 6.9 General Protocol Requirements . . . . . . . . . . . . . . . . 11 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 61 Normative References . . . . . . . . . . . . . . . . . . . . . 13 62 Informative References . . . . . . . . . . . . . . . . . . . . 14 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 64 Intellectual Property and Copyright Statements . . . . . . . . 15 66 1. Introduction 68 The conferencing framework document [3] describes the overall 69 architecture, terminology, and protocol components needed for multi- 70 party conferencing. It defines a logical function called a conference 71 policy server (CPS) which can store and manipulate rules associated 72 with participation in a conference. These rules include directives 73 on the lifespan of the conference, who can and cannot join the 74 conference, definitions of roles available in the conference and the 75 responsibilities associated with those roles, and policies on who is 76 allowed to request which roles. 78 The conference policy control protocol (CPCP) is a client-server 79 protocol that can be used by users to manipulate the rules associated 80 with the conference. 82 The conference policy is represented by a URI. There is a unique 83 conference policy for each conference. The conference policy URI 84 points to a conference policy server which can manipulate that 85 conference policy. 87 Conferencing framework describes also conference notification service 88 that is a logical function provided by the focus. It means that the 89 focus can act as a notifier, accepting subscriptions to the 90 conference state. 92 Note that CPCP is not the only mechanism to manipulate conference 93 policy, but other mechanisms exists as well, such as Web interface. 95 This document can be used with other documents, such as Conferencing 96 framework document [3]. Moreover, [5] and [7] give useful background 97 information about conferencing and floor control. 99 2. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119. 105 3. Terminology 107 This document uses the definitions from [3]. 109 Additional definitions: 111 ACL 113 Access control list (ACL) defines users who can join a 114 conference. Users may have allow, blocked or pending status in 115 the list. Each conference has its own ACL. 117 Moderator 119 A special (privileged) role for a user that is allowed to 120 manipulate conference policy and override policy decisions made 121 by other users. 123 Floor control 125 Floor control is a mechanism that enables applications or users 126 to gain safe and mutually exclusive or non-exclusive access to 127 the shared object or resource in a conference. 129 Privilege 131 A privilege is a right to perform a manipulation operation in a 132 conference. It is user permission such as the right to modify 133 ACL or expel users. 135 4. Integration with Floor Control 137 Floor control is an optional feature often used by conferencing 138 applications. It enables applications or users to gain safe and 139 mutually exclusive or non-exclusive input access to a shared object 140 or resource. We define a floor as the temporary permission for a 141 conference participant to access or manipulate a specific shared 142 resource or group of resources. 144 We assume that the ability of users to create floors is governed by 145 the conference policy. Privileged conference user may use floor 146 control protocol (see e.g. [6]) or some other mechanism to create 147 floors. 149 The conference policy defines who is allowed to create, change, and 150 remove floors using the floor control protocol. 152 Floor chair is also appointed using the floor control protocol when 153 the floor is created. Typically, only conference moderators are 154 allowed to use these commands. 156 The conference moderator can remove the floor at any time using floor 157 control protocol (so that the resources are no longer floor- 158 controlled), or change the floor chair or the floor parameters. 160 The floor chair just controls the access to the floor, according to 161 the floor policy, defined at a time when the floor is created. 163 5. Conference Policy Data Model 165 Conference policy data is relatively static. It is not updated 166 frequently as e.g. participant list is not part of conference policy. 167 Users with sufficient privileges are able to manipulate conference 168 policy. For example, a user with sufficient privileges may 169 manipulate conference's access control list by adding a user into the 170 ACL allowed list. 172 6. CPCP Requirements 174 This section describes requirements for the conference policy 175 protocol. 177 6.1 Conference creation, termination and joining 179 REQ-A1: It MUST be possible to create a new conference addressable 180 with a URI. 182 REQ-A2: It MUST be possible to associate policy attributes to a 183 conference URI. 185 REQ-A3: It MUST be possible to reserve a conference URI for future 186 use with or without associating policy attributes to it. 188 REQ-A4: It SHOULD be possible for a privileged user to read 189 conference policy for a given conference URI, during and before 190 joining the conference. 192 REQ-A5: It MUST be possible to delete existing conference policy. 193 This results in terminating the conference, deleting conference URI 194 and releasing all resources associated with it. 196 REQ-A6: It SHOULD be possible to anonymously participate in a 197 conference. 199 REQ-A7: It SHOULD be possible to participate in a conference as a 200 hidden user. Hidden user is present in a conference, but his presense 201 is not revealed. 203 6.2 Manipulating general conference attributes 205 REQ-B1: It MUST be possible to set, modify and delete a conference 206 Subject. 208 REQ-B2: It MUST be possible to set, modify and delete conference URI 209 display name. 211 REQ-B3: It MUST be possible to set, modify and delete conference 212 creator information (as is seen e.g. in SDP o line). 214 REQ-B4: It MUST be possible to set, modify and delete conference URI 215 link for more information (as used e.g. in SDP u line). 217 REQ-B5: It MUST be possible to set, modify and delete conference host 218 contact information (as used e.g. in SDP e and p lines). 220 REQ-B6: It MUST be possible to set, modify and delete short 221 conference session description (as used e.g. in SDP i line). This 222 can be per session or per media. 224 REQ-B7: It SHOULD be possible to set, modify and delete the parameter 225 for max number of conference participants. This defines how many 226 users at max can be present at the same time. 228 REQ-B8: It MUST be possible to hide conference related information 229 from non-privileged users. 231 REQ-B9: It MUST be possible to inactive a conference for defined 232 period of time. 234 REQ-B10: It SHOULD be possible to set, modify and delete conference 235 Keywords. (This may be useful e.g. for search engines). 237 6.3 Authentication and Security 239 REQ-C1: It MUST be possible to define appropriate authentication for 240 joining users. 242 REQ-C2: It MUST be possible to use sips: scheme as a conference URI. 244 6.4 Application and media manipulation 246 REQ-D1: It MAY be possible to define media policy within conference 247 policy. 249 6.5 ACL manipulation 251 REQ-E1: It MUST be possible to define which users are not allowed to 252 join the conference. 254 REQ-E2: It MUST be possible to define which users are not allowed to 255 join a conference in a single operation. 257 REQ-E3: It MUST be possible to define which users are allowed to join 258 the conference. 260 REQ-E4: It MUST be possible to define which users are allowed to join 261 a conference in a single operation. 263 REQ-E5: It MUST be possible to define which users are places into 264 pending list, waiting for further approval e.g. from moderator. 266 REQ-E6: It MUST be possible to use wildcards in ACL (such as 267 sip:*@example.com is allowed to join). 269 REQ-E7: ACL conflicts MUST be solved in a well-defined way (e.g. what 270 if user appears both in blocked list and in allowed list) e.g. by 271 mandating the order in which ACL definitions are evaluated (e.g. most 272 specific expression first). 274 REQ-E8: Conference MUST have default policy for those users that no 275 matching rule is found in ACL. 277 REQ-E9: It MUST be possible to allow and disallow anonymous 278 membership in a conference. 280 REQ-E10: It MUST be possible to allow and disallow hidden membership 281 in a conference. 283 6.6 Floor control 285 REQ-F1: It MUST be possible to assign and de-assign the users who are 286 allowed to manipulate floor policy. 288 6.7 Inviting and ejecting users 290 REQ-G1: It MUST be possible to define a dial-out list of users that 291 the conference focus invites. 293 REQ-G2: It MUST be possible to set a dial-out list in a single 294 operation. 296 REQ-G3: It MUST be possible to expel users from a currently occurring 297 conference. 299 REQ-G4: It MUST be possible to expel many users in a single 300 operation. 302 REQ-G5: It SHOULD be possible to define list of users who the focus 303 should refer to the conference (so that the referred users will dial 304 in the conference). 306 REQ-G6: It SHOULD be possible to set the list of referred users in a 307 single operation. 309 6.8 User Privileges 311 REQ-H1: It MUST be possible to give a privilege to a user. 313 REQ-H2: It MUST be possible to give privileges to many users in a 314 single operation. 316 REQ-H3: It MUST be possible to remove a privilege from a user. 318 REQ-H4: It MUST be possible to remove privileges from many users in a 319 single operation. 321 REQ-H5: It SHOULD be possible to define users who are allowed to 322 subscribe to conference event package [4] 324 6.9 General Protocol Requirements 326 REQ-CP-1: Protocol behaviour: CPCP protocol MUST be a reliable 327 client-server protocol. Hence, it MUST have a positive response 328 indicating that the request has been received, or error response if 329 an error has occurred. 331 REQ-CP-2: Manipulations of the policy collection MUST exhibit the 332 ACID property; that is, they MUST be atomic, be consistent, durable, 333 and operate independently. 335 REQ-CP-3: It MAY be possible for the client to batch multiple 336 operations (such as add a user to ACL blocked list, or remove a user 337 from ACL allowed list) into a single request that is processed 338 atomically. 340 REQ-CP-4: It MUST be possible for the server to authenticate the 341 client. 343 REQ-CP-5: It MUST be possible for the client to authenticate the 344 server. 346 REQ-CP-6: It MUST be possible for message integrity to be ensured 347 between the client and the server. 349 REQ-CP-7: It MUST be possible for privacy to be ensured between the 350 client and server. 352 7. Acknowledgements 354 The author would like to thank Eric Burger, Xiaotao Wu, Henning 355 Schulzrinne, Simo Veikkolainen and IETF conferencing design team for 356 their feedback. 358 Normative References 360 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 361 Levels", RFC 2119, BCD 14, March 1997. 363 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 364 3261, June 2002. 366 [3] Rosenberg, J., "A Framework for Conferencing with the Session 367 Initiation Protocol", 368 draft-rosenberg-sipping-conferencing-framework-01 (work in 369 progress), February 2003. 371 [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 372 Package for Conference State", 373 draft-ietf-sipping-conference-package-01 (work in progress), 374 June 2003. 376 Informative References 378 [5] Koskelainen, P., Schulzrinne, H. and X. Wu, "Additional 379 Requirements to Conferencing", October 2002. 381 [6] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP 382 for conference floor control", January 2003. 384 [7] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 385 conference control framework", Nossdav'2002 Miami Beach, May 386 2002. 388 Authors' Addresses 390 Petri Koskelainen 391 Nokia 392 P.O. Box 100 (Visiokatu 1) 393 Tampere FIN-33721 394 Finland 396 EMail: petri.koskelainen@nokia.com 398 Hisham Khartabil 399 Nokia 400 P.O. Box 321 401 Helsinki FIN-00045 402 Finland 404 EMail: hisham.khartabil@nokia.com 406 Intellectual Property Statement 408 The IETF takes no position regarding the validity or scope of any 409 intellectual property or other rights that might be claimed to 410 pertain to the implementation or use of the technology described in 411 this document or the extent to which any license under such rights 412 might or might not be available; neither does it represent that it 413 has made any effort to identify any such rights. Information on the 414 IETF's procedures with respect to rights in standards-track and 415 standards-related documentation can be found in BCP-11. Copies of 416 claims of rights made available for publication and any assurances of 417 licenses to be made available, or the result of an attempt made to 418 obtain a general license or permission for the use of such 419 proprietary rights by implementors or users of this specification can 420 be obtained from the IETF Secretariat. 422 The IETF invites any interested party to bring to its attention any 423 copyrights, patents or patent applications, or other proprietary 424 rights which may cover technology that may be required to practice 425 this standard. Please address the information to the IETF Executive 426 Director. 428 Full Copyright Statement 430 Copyright (C) The Internet Society (2003). All Rights Reserved. 432 This document and translations of it may be copied and furnished to 433 others, and derivative works that comment on or otherwise explain it 434 or assist in its implementation may be prepared, copied, published 435 and distributed, in whole or in part, without restriction of any 436 kind, provided that the above copyright notice and this paragraph are 437 included on all such copies and derivative works. However, this 438 document itself may not be modified in any way, such as by removing 439 the copyright notice or references to the Internet Society or other 440 Internet organizations, except as needed for the purpose of 441 developing Internet standards in which case the procedures for 442 copyrights defined in the Internet Standards process must be 443 followed, or as required to translate it into languages other than 444 English. 446 The limited permissions granted above are perpetual and will not be 447 revoked by the Internet Society or its successors or assignees. 449 This document and the information contained herein is provided on an 450 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 451 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 452 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 453 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 454 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 456 Acknowledgement 458 Funding for the RFC Editor function is currently provided by the 459 Internet Society.