idnits 2.17.1 draft-ietf-xcon-cpcp-reqs-03.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 (April 26, 2004) is 7298 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 455, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 458, 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-03 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON WG P. Koskelainen 3 Internet-Draft H. Khartabil 4 Expires: October 25, 2004 Nokia 5 April 26, 2004 7 Requirements for Conference Policy Control Protocol 8 draft-ietf-xcon-cpcp-reqs-03 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 October 25, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . 9 53 6.3 Authentication and Security . . . . . . . . . . . . . . . . . 10 54 6.4 Application and media manipulation . . . . . . . . . . . . . . 10 55 6.5 ACL manipulation . . . . . . . . . . . . . . . . . . . . . . . 10 56 6.6 Floor control . . . . . . . . . . . . . . . . . . . . . . . . 11 57 6.7 Inviting and ejecting users . . . . . . . . . . . . . . . . . 11 58 6.8 User Privileges . . . . . . . . . . . . . . . . . . . . . . . 12 59 6.9 General Protocol Requirements . . . . . . . . . . . . . . . . 12 60 7. Changes since draft-ietf-xcon-cpcp-reqs-02 . . . . . . . . . . 14 61 8. Changes since draft-ietf-xcon-cpcp-reqs-01 . . . . . . . . . . 15 62 9. Changes since draft-ietf-xcon-cpcp-reqs-00 . . . . . . . . . . 16 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 64 Normative References . . . . . . . . . . . . . . . . . . . . . 18 65 Informative References . . . . . . . . . . . . . . . . . . . . 19 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 67 Intellectual Property and Copyright Statements . . . . . . . . 20 69 1. Introduction 71 The conferencing framework document [3] describes the overall 72 architecture, terminology, and protocol components needed for multi- 73 party conferencing. It defines a logical function called a conference 74 policy server which can store and manipulate rules associated with 75 participation in a conference. These rules include directives on the 76 lifespan of the conference, who can and cannot join the conference, 77 definitions of roles available in the conference and the 78 responsibilities associated with those roles. 80 The conference policy control protocol (CPCP) is a client-server 81 protocol that can be used by users to manipulate the rules associated 82 with the conference. 84 The conference policy is represented by a URI. There is a unique 85 conference policy for each conference. The conference policy URI 86 points to a conference policy server which can manipulate that 87 conference policy. 89 Conferencing framework describes also conference notification service 90 that is a logical function provided by the focus. It means that the 91 focus can act as a notifier, accepting subscriptions to the 92 conference state. 94 Note that CPCP is not the only mechanism to manipulate conference 95 policy, but other mechanisms exists as well, such as a Web interface. 97 This document can be used with other documents, such as Conferencing 98 framework document [3]. Moreover, [5] and [7] give useful background 99 information about conferencing and floor control. 101 2. Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119. 107 3. Terminology 109 This document uses the definitions from [3]. 111 Additional definitions: 113 ACL 115 Access control list (ACL) defines users who can join a 116 conference. Users may have allow, blocked or pending status in 117 the list. Each conference has its own ACL. 119 Floor control 121 Floor control is a mechanism that enables applications or users 122 to gain safe and mutually exclusive or non-exclusive access to 123 the shared object or resource in a conference. 125 Privilege 127 A privilege is a right to perform a manipulation operation in a 128 conference. It is user permission such as the right to modify 129 ACL or expel users. 131 4. Integration with Floor Control 133 Floor control is an optional feature often used by conferencing 134 applications. It enables applications or users to gain safe and 135 mutually exclusive or non-exclusive input access to a shared object 136 or resource. We define a floor as the temporary permission for a 137 conference participant to access or manipulate a specific shared 138 resource or group of resources. 140 We assume that the ability of users to create floors is governed by 141 the conference policy. Conference user may use floor control protocol 142 (see e.g. [6]) or some other mechanism to request floors. 144 The conference policy also defines the floor control policy (e.g. 145 moderator-controlled or server grants the floor randomly) and the 146 floor moderator, if the floor policy is moderator-controlled. 148 The privileged user in a conference (such as the creator) can remove 149 the floor at any time by modifying the conference policy (so that the 150 resources are no longer floor- controlled), or change the floor 151 chair. 153 The floor moderator just controls the access to the floor, according 154 to the floor policy, defined by the conference policy at a time when 155 the floor is created. 157 5. Conference Policy Data Model 159 Conference policy data is relatively static. It is not updated 160 frequently as e.g. participant list is not part of the conference 161 policy. Users with sufficient privileges are able to manipulate 162 conference policy. For example, a user with sufficient privileges 163 may manipulate conference's access control list by adding a user into 164 the ACL allowed list. 166 6. CPCP Requirements 168 This section describes requirements for the conference policy control 169 protocol (CPCP). 171 6.1 Conference creation, termination and joining 173 REQ-A1: It MUST be possible to create a new conference addressable by 174 a URI. 176 REQ-A2: It MUST be possible to associate policy attributes to a 177 conference URI. 179 REQ-A3: It MUST be possible to reserve a conference URI for future 180 use with or without associating policy attributes to it. 182 REQ-A4: It MUST be possible for a privileged user to read conference 183 policy for a given conference URI, during and before joining the 184 conference. 186 REQ-A5: It MUST be possible to delete existing conference policy. 187 This results in terminating the conference, deleting conference URI 188 and releasing all resources associated with it. 190 REQ-A6: It MUST be possible to anonymously participate in a 191 conference. 193 REQ-A7: It MUST NOT be possible for a user to authenticate himself as 194 an anonymous user. 196 Note: A conference focus must not accept users to authenticate 197 themselves with a username "anonymous" (like in Digest 198 authentication). 200 REQ-A8: It MUST be possible to assign multiple conference URIs to a 201 conference, one for each session signaling protocol scheme that the 202 conference server supports. 204 REQ-A9: It MUST be possible to define the time when media mixing may 205 start ("don't-mix-before-time") and stop ("cannot-continue-after") 206 operating in the conference. 208 REQ-A10: It MUST be possible to define the time after which users are 209 allowed to join the conference. 211 REQ-A11: It MUST be possible to define the time after which new users 212 are not allowed to join the conference anymore. 214 REQ-A12: It MUST be possible to define the time when users or 215 resources on the dial-out list are invited to join the conference. 217 REQ-A13: It MUST be possible define whether the conference can be 218 extended. Note: This does not guarantee that resources are available. 220 REQ-A14: It MUST be possible to indicate key participants. 222 REQ-A15a: It MUST be possible to define when media mixing starts 223 based on the latter of the mixing start time, and the time the first 224 participant arrives. 226 REQ X15b: It MUST be possible to define when media mixing starts 227 based on the latter of the mixing start time, and the time the first 228 key participant arrives. 230 REQ-A16a: It MUST be possible to define when media mixing stops based 231 on the earlier of the mixing stop time, and the time the last 232 participant leaves the conference. 234 REQ-A16b: It MUST be possible to define when media mixing stops based 235 on the earlier of the mixing stop time, and the time the last key 236 participant leaves. 238 REQ-A16c: It MUST be possible to define when media mixing stops based 239 on the time only. 241 REQ-A17: It MUST be possible to define that the users and resources 242 on the dial-out list are invited only after first key participant has 243 joined. 245 Note: This parameter, if set, overrides the time defined by REQ-A12. 247 6.2 Manipulating general conference attributes 249 REQ-B1: It MUST be possible to set, modify and delete a conference 250 Subject. 252 REQ-B2: It MUST be possible to set, modify and delete conference URI 253 display name. 255 REQ-B3: It MUST be possible to set, modify and delete conference 256 creator information (as is seen e.g. in SDP o line). 258 REQ-B4: It MUST be possible to set, modify and delete conference URI 259 link for more information (as used e.g. in SDP u line). 261 REQ-B5: It MUST be possible to set, modify and delete conference host 262 contact information (as used e.g. in SDP e and p lines). 264 REQ-B6: It MUST be possible to set, modify and delete short 265 conference session description (as used e.g. in SDP i line). This 266 can be per session or per media. 268 REQ-B7: It MUST be possible to set, modify and delete the parameter 269 for max number of conference participants. This defines the maximum 270 number of participants present at the same time. 272 REQ-B8: It MUST be possible to hide conference related information 273 from non-privileged users. 275 Note: This defines the level of visibility of the basic conference 276 information (e.g. visible only to participants). This feature may be 277 needed e.g. in search operations. 279 REQ-B9: It MUST be possible to set, modify and delete conference 280 Keywords. 282 Note: (This may be useful e.g. for search engines). 284 6.3 Authentication and Security 286 REQ-C1: It MUST be possible to define appropriate authentication for 287 joining users. 289 6.4 Application and media manipulation 291 REQ-D1: It MAY be possible to define media policy within conference 292 policy. 294 REQ-D2: It MUST be possible to define the media types for the 295 conference. 297 Note: This means MIME main types, such as audio and video. The 298 conference server can use this information e.g when placing m lines 299 in SIP/SDP dial-outs. 301 6.5 ACL manipulation 303 REQ-E1: It MUST be possible to define which users are not allowed to 304 join the conference. 306 REQ-E2: It MUST be possible to define which users are not allowed to 307 join a conference in a single operation. 309 REQ-E3: It MUST be possible to define which users are allowed to join 310 the conference. 312 REQ-E4: It MUST be possible to define which users are allowed to join 313 a conference in a single operation. 315 REQ-E5: It MUST be possible to define which users are places into 316 pending list, waiting for further approval e.g. from moderator. 318 REQ-E6: It MUST be possible to use wildcards in ACL. 320 REQ-E7: ACL conflicts MUST be solved in a well-defined way (e.g. what 321 if user appears both in blocked list and in allowed list) e.g. by 322 mandating the order in which ACL definitions are evaluated (e.g. most 323 specific expression first). 325 REQ-E8: Conference MUST have default policy for those users that no 326 matching rule is found in ACL. 328 REQ-E9: It MUST be possible to allow and disallow anonymous 329 membership in a conference. 331 6.6 Floor control 333 REQ-F1: It MUST be possible to define whether floor control is in use 334 or not. 336 REQ-F2: It MUST be possible to define the algorithm to be used in 337 granting the floor. 339 Note: Example algorithms might be e.g. moderator-controlled, FCFS, 340 random. 342 REQ-F3: It MUST be possible to define how many users can have the 343 floor at the same time. 345 REQ-F4: It MUST be possible to have one floor for one or more media 346 types. 348 REQ-F5: It MUST be possible to have multiple floors in a conference. 350 REQ-F6: It MUST be possible to define whether a floor is 351 moderator-controlled or not. 353 REQ-F7: If the floor is moderator-controlled, it MUST be possible to 354 assign and replace the floor moderator. 356 6.7 Inviting and ejecting users 357 REQ-G1: It MUST be possible to define a dial-out list of users that 358 the conference focus invites. 360 REQ-G2: It MUST be possible to set a dial-out list in a single 361 operation. 363 REQ-G3: It MUST be possible to expel users from a currently occurring 364 conference. 366 REQ-G4: It MUST be possible to expel many users in a single 367 operation. 369 REQ-G5: It MUST be possible to define list of users who the focus 370 should refer to the conference (so that the referred users will dial 371 in the conference). 373 REQ-G6: It MUST be possible to set the list of referred users in a 374 single operation. 376 6.8 User Privileges 378 REQ-H1: It MUST be possible to give a privilege to a user. 380 REQ-H2: It MUST be possible to give privileges to many users in a 381 single operation. 383 REQ-H3: It MUST be possible to remove a privilege from a user. 385 REQ-H4: It MUST be possible to remove privileges from many users in a 386 single operation. 388 REQ-H5: It MUST be possible to define users who are allowed to 389 subscribe to the conference event package [4] 391 REQ-H6: It MUST be only be possible for a users with sufficient 392 privileges to manipulate conference policy. 394 Note: For example, the creator of the conference may manipulate 395 conference policy. 397 6.9 General Protocol Requirements 399 REQ-CP-1: Protocol behaviour: CPCP protocol MUST be a reliable 400 client-server protocol. Hence, it MUST have a positive response 401 indicating that the request has been received, or error response if 402 an error has occurred. 404 REQ-CP-2: Manipulations of the policy collection MUST exhibit the 405 ACID property; that is, they MUST be atomic, be consistent, durable, 406 and operate independently. 408 REQ-CP-3: It MUST be possible for the server to authenticate the 409 client. 411 REQ-CP-4: It MUST be possible for the client to authenticate the 412 server. 414 REQ-CP-5: It MUST be possible for message integrity to be ensured 415 between the client and the server. 417 REQ-CP-6: It MUST be possible for privacy to be ensured between the 418 client and server. 420 7. Changes since draft-ietf-xcon-cpcp-reqs-02 422 - start/stop time-related requirements clarified (requirements 423 A9-A17) 425 - removal of CP-3 (batching multiple operations) since it is 426 overlapping with other requirements e.g. H2 428 - removal of "moderator" in terminology (conflicts with floor 429 moderator) 431 8. Changes since draft-ietf-xcon-cpcp-reqs-01 433 - time definition changed: only start/stop times required 435 9. Changes since draft-ietf-xcon-cpcp-reqs-00 437 - floor control aligned with floor control requirements document 439 - removed the concept of hidden user 441 - anonymous membership modified 443 - removed "inactive" 445 - added media type requirement (e.g. audio, video) 447 10. Acknowledgements 449 The authors would like to thank Eric Burger, Keith Drage, Brian 450 Rosen, Xiaotao Wu, Henning Schulzrinne, Simo Veikkolainen and IETF 451 conferencing design team for their feedback. 453 Normative References 455 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 456 Levels", RFC 2119, BCD 14, March 1997. 458 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 459 3261, June 2002. 461 [3] Rosenberg, J., "A Framework for Conferencing with the Session 462 Initiation Protocol", 463 draft-rosenberg-sipping-conferencing-framework-01 (work in 464 progress), February 2003. 466 [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 467 Package for Conference State", 468 draft-ietf-sipping-conference-package-03 (work in progress), 469 February 2004. 471 Informative References 473 [5] Koskelainen, P., Schulzrinne, H. and X. Wu, "Additional 474 Requirements to Conferencing", October 2002. 476 [6] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP 477 for conference floor control", January 2003. 479 [7] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 480 conference control framework", Nossdav'2002 Miami Beach, May 481 2002. 483 Authors' Addresses 485 Petri Koskelainen 486 Nokia 487 P.O. Box 100 (Visiokatu 1) 488 Tampere FIN-33721 489 Finland 491 EMail: petri.koskelainen@nokia.com 493 Hisham Khartabil 494 Nokia 495 P.O. Box 321 496 Helsinki FIN-00045 497 Finland 499 EMail: hisham.khartabil@nokia.com 501 Intellectual Property Statement 503 The IETF takes no position regarding the validity or scope of any 504 intellectual property or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; neither does it represent that it 508 has made any effort to identify any such rights. Information on the 509 IETF's procedures with respect to rights in standards-track and 510 standards-related documentation can be found in BCP-11. Copies of 511 claims of rights made available for publication and any assurances of 512 licenses to be made available, or the result of an attempt made to 513 obtain a general license or permission for the use of such 514 proprietary rights by implementors or users of this specification can 515 be obtained from the IETF Secretariat. 517 The IETF invites any interested party to bring to its attention any 518 copyrights, patents or patent applications, or other proprietary 519 rights which may cover technology that may be required to practice 520 this standard. Please address the information to the IETF Executive 521 Director. 523 Full Copyright Statement 525 Copyright (C) The Internet Society (2004). All Rights Reserved. 527 This document and translations of it may be copied and furnished to 528 others, and derivative works that comment on or otherwise explain it 529 or assist in its implementation may be prepared, copied, published 530 and distributed, in whole or in part, without restriction of any 531 kind, provided that the above copyright notice and this paragraph are 532 included on all such copies and derivative works. However, this 533 document itself may not be modified in any way, such as by removing 534 the copyright notice or references to the Internet Society or other 535 Internet organizations, except as needed for the purpose of 536 developing Internet standards in which case the procedures for 537 copyrights defined in the Internet Standards process must be 538 followed, or as required to translate it into languages other than 539 English. 541 The limited permissions granted above are perpetual and will not be 542 revoked by the Internet Society or its successors or assignees. 544 This document and the information contained herein is provided on an 545 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 546 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 547 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 548 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 549 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 551 Acknowledgement 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.