idnits 2.17.1 draft-ietf-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 (January 19, 2004) is 7403 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 407, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 410, 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 19, 2004 Nokia 4 January 19, 2004 6 Requirements for Conference Policy Control Protocol 7 draft-ietf-xcon-cpcp-reqs-01 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 19, 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 . . . . . . . . . . . . . . . . 11 59 7. Changes since draft-ietf-xcon-cpcp-reqs-00 . . . . . . . . . . 13 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 61 Normative References . . . . . . . . . . . . . . . . . . . . . 15 62 Informative References . . . . . . . . . . . . . . . . . . . . 16 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 64 Intellectual Property and Copyright Statements . . . . . . . . 17 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. 77 The conference policy control protocol (CPCP) is a client-server 78 protocol that can be used by users to manipulate the rules associated 79 with the conference. 81 The conference policy is represented by a URI. There is a unique 82 conference policy for each conference. The conference policy URI 83 points to a conference policy server which can manipulate that 84 conference policy. 86 Conferencing framework describes also conference notification service 87 that is a logical function provided by the focus. It means that the 88 focus can act as a notifier, accepting subscriptions to the 89 conference state. 91 Note that CPCP is not the only mechanism to manipulate conference 92 policy, but other mechanisms exists as well, such as Web interface. 94 This document can be used with other documents, such as Conferencing 95 framework document [3]. Moreover, [5] and [7] give useful background 96 information about conferencing and floor control. 98 2. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119. 104 3. Terminology 106 This document uses the definitions from [3]. 108 Additional definitions: 110 ACL 112 Access control list (ACL) defines users who can join a 113 conference. Users may have allow, blocked or pending status in 114 the list. Each conference has its own ACL. 116 Moderator 118 A special (privileged) role for a user that is allowed to 119 manipulate conference policy and override policy decisions made 120 by other users. 122 Floor control 124 Floor control is a mechanism that enables applications or users 125 to gain safe and mutually exclusive or non-exclusive access to 126 the shared object or resource in a conference. 128 Privilege 130 A privilege is a right to perform a manipulation operation in a 131 conference. It is user permission such as the right to modify 132 ACL or expel users. 134 4. Integration with Floor Control 136 Floor control is an optional feature often used by conferencing 137 applications. It enables applications or users to gain safe and 138 mutually exclusive or non-exclusive input access to a shared object 139 or resource. We define a floor as the temporary permission for a 140 conference participant to access or manipulate a specific shared 141 resource or group of resources. 143 We assume that the ability of users to create floors is governed by 144 the conference policy. Conference user may use floor control protocol 145 (see e.g. [6]) or some other mechanism to request floors. 147 The conference policy also defines the floor control policy (e.g. 148 moderator-controlled or server grants the floor randomly) and the 149 floor moderator, if the floor policy is moderator-controlled. 151 The privileged user in a conference (such as the creator) can remove 152 the floor at any time by modifying the conference policy (so that the 153 resources are no longer floor- controlled), or change the floor 154 chair. 156 The floor moderator just controls the access to the floor, according 157 to the floor policy, defined by the conference policy at a time when 158 the floor is created. 160 5. Conference Policy Data Model 162 Conference policy data is relatively static. It is not updated 163 frequently as e.g. participant list is not part of conference policy. 164 Users with sufficient privileges are able to manipulate conference 165 policy. For example, a user with sufficient privileges may 166 manipulate conference's access control list by adding a user into the 167 ACL allowed list. 169 6. CPCP Requirements 171 This section describes requirements for the conference policy control 172 protocol (CPCP). 174 6.1 Conference creation, termination and joining 176 REQ-A1: It MUST be possible to create a new conference addressable by 177 a URI. 179 REQ-A2: It MUST be possible to associate policy attributes to a 180 conference URI. 182 REQ-A3: It MUST be possible to reserve a conference URI for future 183 use with or without associating policy attributes to it. 185 REQ-A4: It MUST be possible for a privileged user to read conference 186 policy for a given conference URI, during and before joining the 187 conference. 189 REQ-A5: It MUST be possible to delete existing conference policy. 190 This results in terminating the conference, deleting conference URI 191 and releasing all resources associated with it. 193 REQ-A6: It MUST be possible to anonymously participate in a 194 conference. 196 REQ-A7: It MUST NOT be possible for a user to authenticate himself as 197 an anonymous user. 199 Note: A conference focus must not accept users to authenticate 200 themselves with a username "anonymous" (like in Digest 201 authentication). 203 REQ-A8: It MUST be possible to assign multiple conference URIs to a 204 conference, one for each session signaling protocol scheme that the 205 conference server supports. 207 6.2 Manipulating general conference attributes 209 REQ-B1: It MUST be possible to set, modify and delete a conference 210 Subject. 212 REQ-B2: It MUST be possible to set, modify and delete conference URI 213 display name. 215 REQ-B3: It MUST be possible to set, modify and delete conference 216 creator information (as is seen e.g. in SDP o line). 218 REQ-B4: It MUST be possible to set, modify and delete conference URI 219 link for more information (as used e.g. in SDP u line). 221 REQ-B5: It MUST be possible to set, modify and delete conference host 222 contact information (as used e.g. in SDP e and p lines). 224 REQ-B6: It MUST be possible to set, modify and delete short 225 conference session description (as used e.g. in SDP i line). This 226 can be per session or per media. 228 REQ-B7: It MUST be possible to set, modify and delete the parameter 229 for max number of conference participants. This defines the maximum 230 number of participants present at the same time. 232 REQ-B8: It MUST be possible to hide conference related information 233 from non-privileged users. 235 Note: This defines the level of visibility of the basic conference 236 information (e.g. visible only to participants). This feature may be 237 needed e.g. in search operations. 239 REQ-B9: It MUST be possible to set, modify and delete conference 240 Keywords. 242 Note: (This may be useful e.g. for search engines). 244 6.3 Authentication and Security 246 REQ-C1: It MUST be possible to define appropriate authentication for 247 joining users. 249 6.4 Application and media manipulation 251 REQ-D1: It MAY be possible to define media policy within conference 252 policy. 254 REQ-D2: It MUST be possible to define the media types for the 255 conference. 257 Note: This means MIME main types, such as audio and video. The 258 conference server can use this information e.g when placing m lines 259 in SIP/SDP dial-outs. 261 6.5 ACL manipulation 263 REQ-E1: It MUST be possible to define which users are not allowed to 264 join the conference. 266 REQ-E2: It MUST be possible to define which users are not allowed to 267 join a conference in a single operation. 269 REQ-E3: It MUST be possible to define which users are allowed to join 270 the conference. 272 REQ-E4: It MUST be possible to define which users are allowed to join 273 a conference in a single operation. 275 REQ-E5: It MUST be possible to define which users are places into 276 pending list, waiting for further approval e.g. from moderator. 278 REQ-E6: It MUST be possible to use wildcards in ACL (such as 279 sip:*@example.com is allowed to join). 281 REQ-E7: ACL conflicts MUST be solved in a well-defined way (e.g. what 282 if user appears both in blocked list and in allowed list) e.g. by 283 mandating the order in which ACL definitions are evaluated (e.g. most 284 specific expression first). 286 REQ-E8: Conference MUST have default policy for those users that no 287 matching rule is found in ACL. 289 REQ-E9: It MUST be possible to allow and disallow anonymous 290 membership in a conference. 292 6.6 Floor control 294 REQ-F1: It MUST be possible to define whether floor control is in use 295 or not. 297 REQ-F2: It MUST be possible to define the algorithm to be used in 298 granting the floor. 300 Note: Example algorithms might be e.g. moderator-controlled, FCFS, 301 random. 303 REQ-F3: It MUST be possible to define how many users can have the 304 floor at the same time. 306 REQ-F4: It MUST be possible to have one floor for one or more media 307 types. 309 REQ-F5: It MUST be possible to have multiple floors in a conference. 311 REQ-F6: It MUST be possible to define whether a floor is 312 moderator-controlled or not. 314 REQ-F7: If the floor is moderator-controlled, it MUST be possible to 315 assign and replace the floor moderator. 317 6.7 Inviting and ejecting users 319 REQ-G1: It MUST be possible to define a dial-out list of users that 320 the conference focus invites. 322 REQ-G2: It MUST be possible to set a dial-out list in a single 323 operation. 325 REQ-G3: It MUST be possible to expel users from a currently occurring 326 conference. 328 REQ-G4: It MUST be possible to expel many users in a single 329 operation. 331 REQ-G5: It MUST be possible to define list of users who the focus 332 should refer to the conference (so that the referred users will dial 333 in the conference). 335 REQ-G6: It MUST be possible to set the list of referred users in a 336 single operation. 338 6.8 User Privileges 340 REQ-H1: It MUST be possible to give a privilege to a user. 342 REQ-H2: It MUST be possible to give privileges to many users in a 343 single operation. 345 REQ-H3: It MUST be possible to remove a privilege from a user. 347 REQ-H4: It MUST be possible to remove privileges from many users in a 348 single operation. 350 REQ-H5: It MUST be possible to define users who are allowed to 351 subscribe to the conference event package [4] 353 REQ-H6: It MUST be only be possible for a users with sufficient 354 privileges to manipulate conference policy. 356 Note: For example, the creator of the conference may manipulate 357 conference policy. 359 6.9 General Protocol Requirements 361 REQ-CP-1: Protocol behaviour: CPCP protocol MUST be a reliable 362 client-server protocol. Hence, it MUST have a positive response 363 indicating that the request has been received, or error response if 364 an error has occurred. 366 REQ-CP-2: Manipulations of the policy collection MUST exhibit the 367 ACID property; that is, they MUST be atomic, be consistent, durable, 368 and operate independently. 370 REQ-CP-3: It MAY be possible for the client to batch multiple 371 operations (such as add a user to ACL blocked list, or remove a user 372 from ACL allowed list) into a single request that is processed 373 atomically. 375 REQ-CP-4: It MUST be possible for the server to authenticate the 376 client. 378 REQ-CP-5: It MUST be possible for the client to authenticate the 379 server. 381 REQ-CP-6: It MUST be possible for message integrity to be ensured 382 between the client and the server. 384 REQ-CP-7: It MUST be possible for privacy to be ensured between the 385 client and server. 387 7. Changes since draft-ietf-xcon-cpcp-reqs-00 389 - floor control aligned with floor control requirements document 391 - removed the concept of hidden user 393 - anonymous membership modified 395 - removed "inactive" 397 - added media type requirement (e.g. audio, video) 399 8. Acknowledgements 401 The authors would like to thank Eric Burger, Keith Drage, Brian 402 Rosen, Xiaotao Wu, Henning Schulzrinne, Simo Veikkolainen and IETF 403 conferencing design team for their feedback. 405 Normative References 407 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 408 Levels", RFC 2119, BCD 14, March 1997. 410 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 411 3261, June 2002. 413 [3] Rosenberg, J., "A Framework for Conferencing with the Session 414 Initiation Protocol", 415 draft-rosenberg-sipping-conferencing-framework-01 (work in 416 progress), February 2003. 418 [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 419 Package for Conference State", 420 draft-ietf-sipping-conference-package-01 (work in progress), 421 June 2003. 423 Informative References 425 [5] Koskelainen, P., Schulzrinne, H. and X. Wu, "Additional 426 Requirements to Conferencing", October 2002. 428 [6] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP 429 for conference floor control", January 2003. 431 [7] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 432 conference control framework", Nossdav'2002 Miami Beach, May 433 2002. 435 Authors' Addresses 437 Petri Koskelainen 438 Nokia 439 P.O. Box 100 (Visiokatu 1) 440 Tampere FIN-33721 441 Finland 443 EMail: petri.koskelainen@nokia.com 445 Hisham Khartabil 446 Nokia 447 P.O. Box 321 448 Helsinki FIN-00045 449 Finland 451 EMail: hisham.khartabil@nokia.com 453 Intellectual Property Statement 455 The IETF takes no position regarding the validity or scope of any 456 intellectual property or other rights that might be claimed to 457 pertain to the implementation or use of the technology described in 458 this document or the extent to which any license under such rights 459 might or might not be available; neither does it represent that it 460 has made any effort to identify any such rights. Information on the 461 IETF's procedures with respect to rights in standards-track and 462 standards-related documentation can be found in BCP-11. Copies of 463 claims of rights made available for publication and any assurances of 464 licenses to be made available, or the result of an attempt made to 465 obtain a general license or permission for the use of such 466 proprietary rights by implementors or users of this specification can 467 be obtained from the IETF Secretariat. 469 The IETF invites any interested party to bring to its attention any 470 copyrights, patents or patent applications, or other proprietary 471 rights which may cover technology that may be required to practice 472 this standard. Please address the information to the IETF Executive 473 Director. 475 Full Copyright Statement 477 Copyright (C) The Internet Society (2004). All Rights Reserved. 479 This document and translations of it may be copied and furnished to 480 others, and derivative works that comment on or otherwise explain it 481 or assist in its implementation may be prepared, copied, published 482 and distributed, in whole or in part, without restriction of any 483 kind, provided that the above copyright notice and this paragraph are 484 included on all such copies and derivative works. However, this 485 document itself may not be modified in any way, such as by removing 486 the copyright notice or references to the Internet Society or other 487 Internet organizations, except as needed for the purpose of 488 developing Internet standards in which case the procedures for 489 copyrights defined in the Internet Standards process must be 490 followed, or as required to translate it into languages other than 491 English. 493 The limited permissions granted above are perpetual and will not be 494 revoked by the Internet Society or its successors or assignees. 496 This document and the information contained herein is provided on an 497 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 498 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 499 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 500 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 501 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 503 Acknowledgement 505 Funding for the RFC Editor function is currently provided by the 506 Internet Society.