idnits 2.17.1 draft-ietf-xcon-cpcp-reqs-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: ---------------------------------------------------------------------------- == 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 (January 29, 2004) is 7392 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 414, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 417, 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. -------------------------------------------------------------------------------- 1 XCON WG P. Koskelainen 2 Internet-Draft H. Khartabil 3 Expires: July 29, 2004 Nokia 4 January 29, 2004 6 Requirements for Conference Policy Control Protocol 7 draft-ietf-xcon-cpcp-reqs-02 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on July 29, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 The conference policy server allows clients to manipulate and 38 interact with the conference policy. One mechanism to manipulate the 39 policy is to use conference policy control protocol (CPCP). This 40 document gives the requirements for CPCP. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 46 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 47 4. Integration with Floor Control . . . . . . . . . . . . . . . . 6 48 5. Conference Policy Data Model . . . . . . . . . . . . . . . . . 7 49 6. CPCP Requirements . . . . . . . . . . . . . . . . . . . . . . 8 50 6.1 Conference creation, termination and joining . . . . . . . . . 8 51 6.2 Manipulating general conference attributes . . . . . . . . . . 8 52 6.3 Authentication and Security . . . . . . . . . . . . . . . . . 9 53 6.4 Application and media manipulation . . . . . . . . . . . . . . 9 54 6.5 ACL manipulation . . . . . . . . . . . . . . . . . . . . . . . 9 55 6.6 Floor control . . . . . . . . . . . . . . . . . . . . . . . . 10 56 6.7 Inviting and ejecting users . . . . . . . . . . . . . . . . . 11 57 6.8 User Privileges . . . . . . . . . . . . . . . . . . . . . . . 11 58 6.9 General Protocol Requirements . . . . . . . . . . . . . . . . 12 59 7. Changes since draft-ietf-xcon-cpcp-reqs-01 . . . . . . . . . . 13 60 8. Changes since draft-ietf-xcon-cpcp-reqs-00 . . . . . . . . . . 14 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 62 Normative References . . . . . . . . . . . . . . . . . . . . . 16 63 Informative References . . . . . . . . . . . . . . . . . . . . 17 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 65 Intellectual Property and Copyright Statements . . . . . . . . 18 67 1. Introduction 69 The conferencing framework document [3] describes the overall 70 architecture, terminology, and protocol components needed for multi- 71 party conferencing. It defines a logical function called a conference 72 policy server (CPS) which can store and manipulate rules associated 73 with participation in a conference. These rules include directives 74 on the lifespan of the conference, who can and cannot join the 75 conference, definitions of roles available in the conference and the 76 responsibilities associated with those 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 a 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. Conference user may use floor control protocol 146 (see e.g. [6]) or some other mechanism to request floors. 148 The conference policy also defines the floor control policy (e.g. 149 moderator-controlled or server grants the floor randomly) and the 150 floor moderator, if the floor policy is moderator-controlled. 152 The privileged user in a conference (such as the creator) can remove 153 the floor at any time by modifying the conference policy (so that the 154 resources are no longer floor- controlled), or change the floor 155 chair. 157 The floor moderator just controls the access to the floor, according 158 to the floor policy, defined by the conference policy at a time when 159 the floor is created. 161 5. Conference Policy Data Model 163 Conference policy data is relatively static. It is not updated 164 frequently as e.g. participant list is not part of the conference 165 policy. Users with sufficient privileges are able to manipulate 166 conference policy. For example, a user with sufficient privileges 167 may manipulate conference's access control list by adding a user into 168 the ACL allowed list. 170 6. CPCP Requirements 172 This section describes requirements for the conference policy control 173 protocol (CPCP). 175 6.1 Conference creation, termination and joining 177 REQ-A1: It MUST be possible to create a new conference addressable by 178 a URI. 180 REQ-A2: It MUST be possible to associate policy attributes to a 181 conference URI. 183 REQ-A3: It MUST be possible to reserve a conference URI for future 184 use with or without associating policy attributes to it. 186 REQ-A4: It MUST be possible for a privileged user to read conference 187 policy for a given conference URI, during and before joining the 188 conference. 190 REQ-A5: It MUST be possible to delete existing conference policy. 191 This results in terminating the conference, deleting conference URI 192 and releasing all resources associated with it. 194 REQ-A6: It MUST be possible to anonymously participate in a 195 conference. 197 REQ-A7: It MUST NOT be possible for a user to authenticate himself as 198 an anonymous user. 200 Note: A conference focus must not accept users to authenticate 201 themselves with a username "anonymous" (like in Digest 202 authentication). 204 REQ-A8: It MUST be possible to assign multiple conference URIs to a 205 conference, one for each session signaling protocol scheme that the 206 conference server supports. 208 REQ-A9: It MUST be possible to define the start and stop times for 209 the conference. 211 6.2 Manipulating general conference attributes 213 REQ-B1: It MUST be possible to set, modify and delete a conference 214 Subject. 216 REQ-B2: It MUST be possible to set, modify and delete conference URI 217 display name. 219 REQ-B3: It MUST be possible to set, modify and delete conference 220 creator information (as is seen e.g. in SDP o line). 222 REQ-B4: It MUST be possible to set, modify and delete conference URI 223 link for more information (as used e.g. in SDP u line). 225 REQ-B5: It MUST be possible to set, modify and delete conference host 226 contact information (as used e.g. in SDP e and p lines). 228 REQ-B6: It MUST be possible to set, modify and delete short 229 conference session description (as used e.g. in SDP i line). This 230 can be per session or per media. 232 REQ-B7: It MUST be possible to set, modify and delete the parameter 233 for max number of conference participants. This defines the maximum 234 number of participants present at the same time. 236 REQ-B8: It MUST be possible to hide conference related information 237 from non-privileged users. 239 Note: This defines the level of visibility of the basic conference 240 information (e.g. visible only to participants). This feature may be 241 needed e.g. in search operations. 243 REQ-B9: It MUST be possible to set, modify and delete conference 244 Keywords. 246 Note: (This may be useful e.g. for search engines). 248 6.3 Authentication and Security 250 REQ-C1: It MUST be possible to define appropriate authentication for 251 joining users. 253 6.4 Application and media manipulation 255 REQ-D1: It MAY be possible to define media policy within conference 256 policy. 258 REQ-D2: It MUST be possible to define the media types for the 259 conference. 261 Note: This means MIME main types, such as audio and video. The 262 conference server can use this information e.g when placing m lines 263 in SIP/SDP dial-outs. 265 6.5 ACL manipulation 266 REQ-E1: It MUST be possible to define which users are not allowed to 267 join the conference. 269 REQ-E2: It MUST be possible to define which users are not allowed to 270 join a conference in a single operation. 272 REQ-E3: It MUST be possible to define which users are allowed to join 273 the conference. 275 REQ-E4: It MUST be possible to define which users are allowed to join 276 a conference in a single operation. 278 REQ-E5: It MUST be possible to define which users are places into 279 pending list, waiting for further approval e.g. from moderator. 281 REQ-E6: It MUST be possible to use wildcards in ACL (such as 282 sip:*@example.com is allowed to join). 284 REQ-E7: ACL conflicts MUST be solved in a well-defined way (e.g. what 285 if user appears both in blocked list and in allowed list) e.g. by 286 mandating the order in which ACL definitions are evaluated (e.g. most 287 specific expression first). 289 REQ-E8: Conference MUST have default policy for those users that no 290 matching rule is found in ACL. 292 REQ-E9: It MUST be possible to allow and disallow anonymous 293 membership in a conference. 295 6.6 Floor control 297 REQ-F1: It MUST be possible to define whether floor control is in use 298 or not. 300 REQ-F2: It MUST be possible to define the algorithm to be used in 301 granting the floor. 303 Note: Example algorithms might be e.g. moderator-controlled, FCFS, 304 random. 306 REQ-F3: It MUST be possible to define how many users can have the 307 floor at the same time. 309 REQ-F4: It MUST be possible to have one floor for one or more media 310 types. 312 REQ-F5: It MUST be possible to have multiple floors in a conference. 314 REQ-F6: It MUST be possible to define whether a floor is 315 moderator-controlled or not. 317 REQ-F7: If the floor is moderator-controlled, it MUST be possible to 318 assign and replace the floor moderator. 320 6.7 Inviting and ejecting users 322 REQ-G1: It MUST be possible to define a dial-out list of users that 323 the conference focus invites. 325 REQ-G2: It MUST be possible to set a dial-out list in a single 326 operation. 328 REQ-G3: It MUST be possible to expel users from a currently occurring 329 conference. 331 REQ-G4: It MUST be possible to expel many users in a single 332 operation. 334 REQ-G5: It MUST be possible to define list of users who the focus 335 should refer to the conference (so that the referred users will dial 336 in the conference). 338 REQ-G6: It MUST be possible to set the list of referred users in a 339 single operation. 341 6.8 User Privileges 343 REQ-H1: It MUST be possible to give a privilege to a user. 345 REQ-H2: It MUST be possible to give privileges to many users in a 346 single operation. 348 REQ-H3: It MUST be possible to remove a privilege from a user. 350 REQ-H4: It MUST be possible to remove privileges from many users in a 351 single operation. 353 REQ-H5: It MUST be possible to define users who are allowed to 354 subscribe to the conference event package [4] 356 REQ-H6: It MUST be only be possible for a users with sufficient 357 privileges to manipulate conference policy. 359 Note: For example, the creator of the conference may manipulate 360 conference policy. 362 6.9 General Protocol Requirements 364 REQ-CP-1: Protocol behaviour: CPCP protocol MUST be a reliable 365 client-server protocol. Hence, it MUST have a positive response 366 indicating that the request has been received, or error response if 367 an error has occurred. 369 REQ-CP-2: Manipulations of the policy collection MUST exhibit the 370 ACID property; that is, they MUST be atomic, be consistent, durable, 371 and operate independently. 373 REQ-CP-3: It MAY be possible for the client to batch multiple 374 operations (such as add a user to ACL blocked list, or remove a user 375 from ACL allowed list) into a single request that is processed 376 atomically. 378 REQ-CP-4: It MUST be possible for the server to authenticate the 379 client. 381 REQ-CP-5: It MUST be possible for the client to authenticate the 382 server. 384 REQ-CP-6: It MUST be possible for message integrity to be ensured 385 between the client and the server. 387 REQ-CP-7: It MUST be possible for privacy to be ensured between the 388 client and server. 390 7. Changes since draft-ietf-xcon-cpcp-reqs-01 392 - time definition changed: only start/stop times required 394 8. Changes since draft-ietf-xcon-cpcp-reqs-00 396 - floor control aligned with floor control requirements document 398 - removed the concept of hidden user 400 - anonymous membership modified 402 - removed "inactive" 404 - added media type requirement (e.g. audio, video) 406 9. Acknowledgements 408 The authors would like to thank Eric Burger, Keith Drage, Brian 409 Rosen, Xiaotao Wu, Henning Schulzrinne, Simo Veikkolainen and IETF 410 conferencing design team for their feedback. 412 Normative References 414 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 415 Levels", RFC 2119, BCD 14, March 1997. 417 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 418 3261, June 2002. 420 [3] Rosenberg, J., "A Framework for Conferencing with the Session 421 Initiation Protocol", 422 draft-rosenberg-sipping-conferencing-framework-01 (work in 423 progress), February 2003. 425 [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 426 Package for Conference State", 427 draft-ietf-sipping-conference-package-01 (work in progress), 428 June 2003. 430 Informative References 432 [5] Koskelainen, P., Schulzrinne, H. and X. Wu, "Additional 433 Requirements to Conferencing", October 2002. 435 [6] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP 436 for conference floor control", January 2003. 438 [7] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 439 conference control framework", Nossdav'2002 Miami Beach, May 440 2002. 442 Authors' Addresses 444 Petri Koskelainen 445 Nokia 446 P.O. Box 100 (Visiokatu 1) 447 Tampere FIN-33721 448 Finland 450 EMail: petri.koskelainen@nokia.com 452 Hisham Khartabil 453 Nokia 454 P.O. Box 321 455 Helsinki FIN-00045 456 Finland 458 EMail: hisham.khartabil@nokia.com 460 Intellectual Property Statement 462 The IETF takes no position regarding the validity or scope of any 463 intellectual property or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; neither does it represent that it 467 has made any effort to identify any such rights. Information on the 468 IETF's procedures with respect to rights in standards-track and 469 standards-related documentation can be found in BCP-11. Copies of 470 claims of rights made available for publication and any assurances of 471 licenses to be made available, or the result of an attempt made to 472 obtain a general license or permission for the use of such 473 proprietary rights by implementors or users of this specification can 474 be obtained from the IETF Secretariat. 476 The IETF invites any interested party to bring to its attention any 477 copyrights, patents or patent applications, or other proprietary 478 rights which may cover technology that may be required to practice 479 this standard. Please address the information to the IETF Executive 480 Director. 482 Full Copyright Statement 484 Copyright (C) The Internet Society (2004). All Rights Reserved. 486 This document and translations of it may be copied and furnished to 487 others, and derivative works that comment on or otherwise explain it 488 or assist in its implementation may be prepared, copied, published 489 and distributed, in whole or in part, without restriction of any 490 kind, provided that the above copyright notice and this paragraph are 491 included on all such copies and derivative works. However, this 492 document itself may not be modified in any way, such as by removing 493 the copyright notice or references to the Internet Society or other 494 Internet organizations, except as needed for the purpose of 495 developing Internet standards in which case the procedures for 496 copyrights defined in the Internet Standards process must be 497 followed, or as required to translate it into languages other than 498 English. 500 The limited permissions granted above are perpetual and will not be 501 revoked by the Internet Society or its successors or assignees. 503 This document and the information contained herein is provided on an 504 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 505 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 506 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 507 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 508 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 510 Acknowledgement 512 Funding for the RFC Editor function is currently provided by the 513 Internet Society.