idnits 2.17.1 draft-koskelainen-sipping-conf-policy-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 24, 2003) is 7725 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft Petri Koskelainen 4 Nokia 5 draft-koskelainen-sipping-conf-policy-req-00.txt 6 February 24, 2003 7 Expires: August 2003 9 Requirements for conference policy data 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The conference participants may communicate with the conference 35 policy server, using a conference policy control protocol (CPCP) 36 which is a strictly client-server transactional protocol. This 37 document describes the requirements for conference policy data. Media 38 policy related requirements are beyond the scope of this document. 39 CPCP protocol is not mandatory and the only mechanism to manipulate 40 conference policy data in a conference. For example, web interface 41 can be used as well to perform conference policy manipulation. 42 However, for automata a protocol is needed. 44 1 Introduction 46 The conferencing framework document [1] describes the overall 47 architecture, terminology, and protocol components needed for multi- 48 party conferencing. It defines a logical function called a conference 49 policy server which can store and manipulate rules associated with 50 participation in a conference. These rules include directives on the 51 lifespan of the conference, who can and cannot join the conference, 52 definitions of roles available in the conference and the 53 responsibilities associated with those roles, and policies on who is 54 allowed to request which roles. 56 The conference policy control protocol (CPCP) is a client-server 57 protocol that can be used by the participant to manipulate the rules 58 associated with the conference. 60 The conference policy is represented by a URI. There is a unique 61 conference policy for each conference. The conference policy URI 62 points to a conference policy server which can manipulate that 63 conference policy. 65 Conferencing framework describes also conference notification service 66 that is a logical function provided by the focus. It means that the 67 focus can act as a notifier, accepting subscriptions to the 68 conference state. 70 Note that CPCP is not the only mechanism to manipulate conference 71 policy, but other mechanisms exists as well, such as Web interface. 73 This document can be used with other documents, such as Conferencing 74 framework document [1], and SIP call control - conferencing for user 75 agents [2]. 77 Moreover, [4], [5], [6] give useful background information about 78 conferencing and floor control. 80 1.1 Conventions of This Document 82 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 83 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 84 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. 86 2 Terminology 88 This document uses the definitions from [1]. 90 Additional definitions: 92 ACL: Access Control List. Defines which users are eligible to 93 join a conference. Each conference has its own ACL. 95 Moderator: A special (privileged) role for a user that is 96 allowed to manipulate conference policy and override policy 97 decisions made by other users. 99 Privilege: A privilege is a right to perform a manipulation 100 operation for a conference. It is user permission such as 101 "MODIFY ACL", "TERMINATE CONFERENCE", "INVITE USERS", 102 "EJECT USERS", "MODIFY FLOOR POLICY", "MODIFY MEDIA 103 POLICY", "HAND OFF A PRIVILEGE TO ANOTHER USER", "FLOOR 104 CONTROL CHAIR". (assuming that privileges are individual 105 instead of group based e.g. senior-members have all 106 privileges) 108 3 Integration with Floor Control 110 Floor control is an optional feature often used by conferencing 111 applications. It enables applications or users to gain safe and 112 mutually exclusive or non-exclusive input access to a shared object 113 or resource. We define a floor as the temporary permission for a 114 conference participant to access or manipulate a specific shared 115 resource or group of resources. 117 We assume that the ability of users to create floors is governed by 118 the conference policy. Privileged conference user may use floor 119 control protocol (see [7], [8]) to create floors. 121 The conference policy defines who is allowed to create, change, and 122 remove floors using the floor control protocol. 124 Floor chair is also appointed using the floor control protocol when 125 the floor is created. Typically, only conference moderators are 126 allowed to use these commands. 128 The conference moderator can remove the floor at any time using floor 129 control protocol (so that the resources are no longer floor- 130 controlled), or change the floor chair or the floor parameters. 132 The floor chair just controls the access to the floor, according to 133 the floor policy, defined at a time when the floor is created. 135 4 Conference Policy Data Model 137 Conference policy data is relative static. It is not updated 138 frequently as e.g. participant list is not part of conference policy. 139 Users with sufficient privileges are able to manipulate conference 140 policy. For example, a user with sufficient privileges may 141 manipulate conference's access control list by adding a user into the 142 ACL white list. 144 It is also assumed that the policy data server does not necessarily 145 have a clock. Therefore, conference policy data does not have any 146 time-related policy attributes. 148 5 Conference Policy Requirements 150 This section describes conference policy requirements. 152 5.1 Conference creation, termination and joining 154 (Requirements A1-A7 apply better to CPCP rather than to policy data) 156 REQ-A1: It MUST be possible to create a new conference at focus, 157 resulting in a URI. 159 REQ-A2: It MUST be possible to associate policy attributes to a 160 conference URI. 162 REQ-A3: It MUST be possible to reserve a conference URI from the 163 focus for future use with or without associating policy 164 attributes to it. 166 REQ-A4: It MUST be possible for an user to fetch some or all 167 components of conference policy from the focus (from the 168 conference URI), during and before joining the conference. 170 REQ-A5: It MUST be possible to delete the existing conference 171 URI and release all resources associated with it. 173 REQ-A6: It MUST be possible to terminate the conference instance 174 but keep the conference URI and all policy attributes 175 reserved. 177 REQ-A7: It SHOULD be possible to join anonymously to the 178 conference and still be able to send and receive data and 179 private 1-to-1 SIP messages anonymously. 181 5.2 Manipulating general conference attributes 183 REQ-B2: It MUST be possible to set and modify conference Subject 184 that can be seen e.g. in web page, SDP s line or SIP 185 Subject header. 187 REQ-B3: It MUST be possible to set, modify and delete conference 188 URI display name. 190 REQ-B4: It MUST be possible to set, modify and delete conference 191 creator information (as is seen e.g. in SDP o line). 193 REQ-B5: It MUST be possible to set, modify and delete conference 194 URI link for more information (as used e.g. in SDP u line). 196 REQ-B6: It MUST be possible to set, modify and delete conference 197 host contact information (as used e.g. in SDP e and p 198 lines). 200 REQ-B7: It MUST be possible to set, modify and delete short 201 conference session description (as used e.g. in SDP i 202 line). This can be per session or per media. 204 REQ-B8: It MUST be possible to set, modify and delete max number 205 of conference participants. This defines how many users at 206 max can be present at the same time. 208 REQ-B9: It MUST be possible to set whether the conference is 209 public or hidden (if hidden, focus does not return 210 description to outsiders for OPTIONS or other requests). 212 REQ-B10: Conference policy MUST have an attribute that defines 213 whether the conference is active or inactive. (If active, 214 users can join etc). [This is needed because start/end 215 times are not used here] 217 REQ-B11: It MUST be possible to give the list of invited users 218 into the conference (dial-out case). 220 5.3 Authentication and Security 222 REQ-C1: It MUST be possible to define the authentication 223 mechanism, and passwords for user joins. 225 REQ-C2: It MUST be possible to use sips: scheme as a conference 226 URI. 228 REQ-C3: It MUST be possible to define encryption keys for media 229 data. [OPEN ISSUE: Does this belong to media policy?] 231 5.4 Application and media manipulation 233 REQ-D1: It MUST be possible to assign and de-assign the users 234 who are allowed to manipulate media policy. 236 5.5 ACL manipulation 238 REQ-E1: It MUST be possible to add and delete users into and 239 from ACL white list (allowed to join) and ACL black list 240 (not allowed to join). 242 REQ-E2: ACL conflicts MUST be solved in a well-defined way (e.g. 243 what if user appears both in black list and in white list) 244 e.g. by mandating the order in which ACL definitions are 245 evaluated (e.g. most specific expression first). 247 REQ-E3: It MUST be possible to use wildcards in ACL (such as 248 *.company.com in white list). 250 REQ-E4: It MUST be possible to allow and disallow anonymous and 251 hidden joins to the conference. 253 5.6 Floor control 255 REQ-F1: It MUST be possible to assign and de-assign the users 256 who are allowed to manipulate floor policy. (Floor policy 257 is manipulated by the floor control protocol itself). 259 5.7 Inviting and ejecting users 261 REQ-G1: It MUST be possible to invite one or more users into the 262 conference (including so called "mass invitation" 263 operation). 265 REQ-G2: It MUST be possible eject one or more users from the 266 conference (including so called "mass ejection" operation). 268 5.8 User Privileges 270 REQ-H1: It MUST be possible to give a privilege to a user. (A 271 privilege may be operation, such as right to expel, right 272 to modify conference ACL, right to hand off all or some 273 privileges to another user). 275 REQ-H2: It MUST be possible to remove a privilege from a user. 277 REQ-H3: It MAY be possible to support user privilege groups 278 (e.g. senior-members) and to group privileges together, 279 such as senior-members can eject users and manipulate ACL. 281 REQ-H4: It MAY be possible that default privileges (e.g. only 282 the creator can delete conference) are defined by the 283 Conference Policy Control Protocol that can be changed by 284 the conference policy. 286 REQ-H5: It MUST be possible to authorize users who have the 287 right to subscribe to specific events, such as ACL changes. 289 REQ-H6: It MAY be possible request new privileges from the 290 conference policy server via CPCP. 292 REQ-H7: It SHOULD be possible to define who is allowed to 293 subscribe to conference related events. 295 REQ It MAY be possible that default privileges are defined for 296 new conference, such as conference creator has all 297 privileges available and others do not have have any of 298 them. 300 6 Notifications and Subscriptions 302 New SIP event packages may be needed. For example, conference owner 303 (or a user with sufficient privileges) may subscribe to the 304 conference management event, and get notified when there is a need to 305 do policy manipulation, such as ACL manipulation for on-going join 306 attempt. 308 7 Possible Solutions 310 This document is primarily a requirements document, and does not aim 311 to provide a protocol or policy data format for meeting the 312 requirements defined here. Solutions such as SOAP, XML/RPC and ACAP 313 can be utilized. Moreover, the use of encoding formats such as SDP, 314 SDP-NG, iCal, and vCard can be investigated. 316 8 Open Issues 318 o Whether time-related policy data attributes are needed, e.g. 319 for conference start/end times. Even if absolute times are not 320 needed, it may be useful to have relative times (e.g. max time 321 2 hours). Conference may be created in advance, put to 322 inactive state and activated when needed. This needs more 323 thinking. 325 o Should conferece policy include any bandwidth related 326 attributes (e.g. per media, per user or per conference)? 328 9 Changes from previous version 330 CPCP requirements section [This section may be later extracted to 331 separate internet-draft "Requirements for policy control protocol"] 332 REQ-CP-1: Protocol behaviour: CPCP protocol SHOULD be a 333 reliable client-server protocol. Hence, it SHOULD have a 334 positive response indicating that the request has been 335 received, or error response if an error has occurred. The 336 sending UA takes care of retransmission in the case of 337 packet loss. 339 REQ-CP-2: Manipulations of the policy collection MUST exhibit 340 the ACID property; that is, they MUST be atomic, be 341 consistent, durable, and operate independently. 343 REQ-CP-3: It MAY be possible for the client to batch multiple 344 operations (such as add a user to ACL black list, or remove 345 a user from ACL white list) into a single request that is 346 processed atomically. 348 REQ-CP-4: It MUST be possible for the server to authenticate the 349 client. 351 REQ-CP-5: It MUST be possible for the client to authenticate the 352 server. 354 REQ-CP-6: It MUST be possible for message integrity to be 355 ensured between the client and the server. 357 REQ-CP-7: It MUST be possible for privacy to be ensured between 358 the client and server. 360 10 Acknowledgements 362 The author would like to thank Rohan Mahy, Jonathan Rosenberg, Roni 363 Even, Orit Levin, Alan Johnston, Joerg Ott and others for their 364 comments. 366 11 Authors' Addresses 368 Petri Koskelainen 369 Nokia 370 Visiokatu 1, 371 33720 Tampere, 372 Finland 373 e-mail: petri.koskelainen@nokia.com 375 12 Normative References 377 [1] J. Rosenberg, "A framework for conferencing with the session 378 initiation protocol," internet draft, Internet Engineering Task 379 Force, Feb. 2003. Work in progress. 381 [2] A. Johnston,O. Levin, "Session Initiation Protocol Call Control - 382 Conferencing for User Agents", internet draft, Internet Engineering 383 Task Force, Feb. 2003. Work in progress. 385 [3] S. Bradner, "Key words for use in rfcs to indicate requirement 386 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 388 13 Informative References 390 [4] C. Bormann, D. Kutscher, J. Ott, and D. Trossen, "Simple 391 conference control protocol service specification," internet draft, 392 Internet Engineering Task Force, Mar. 2001. Work in progress. 394 [5] P. Koskelainen, H. Schulzrinne, and X. Wu, "Additional 395 requirements to conferencing," internet draft, Internet Engineering 396 Task Force, Apr. 2002. Work in progress. 398 [6] H. Schulzrinne. P. Koskelainen and X. Wu, "A sip-based conference 399 control framework," in NOSSDAV, (Miami, Florida), May 2002. 401 [7] P. Koskelainen, H. Schulzrinne, and J. Ott, "Requirements for 402 floor control," internet draft, Internet Engineering Task Force, Nov. 403 2002. Work in progress. 405 [8] X. Wu et al., "Use of session initiation protocol (SIP) and 406 simple object access protocol (SOAP) for conference floor control," 407 internet draft, Internet Engineering Task Force, Jan. 2003. Work in 408 progress. 410 Intellectual Property Statement 412 The IETF takes no position regarding the validity or scope of any 413 intellectual property or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; neither does it represent that it 417 has made any effort to identify any such rights. Information on the 418 IETF's procedures with respect to rights in standards-track and 419 standards-related documentation can be found in BCP-11. Copies of 420 claims of rights made available for publication and any assurances of 421 licenses to be made available, or the result of an attempt made to 422 obtain a general license or permission for the use of such 423 proprietary rights by implementors or users of this specification can 424 be obtained from the IETF Secretariat. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights which may cover technology that may be required to practice 429 this standard. Please address the information to the IETF Executive 430 Director. 432 Full Copyright Statement 434 Copyright (c) The Internet Society (2003). All Rights Reserved. 436 This document and translations of it may be copied and furnished to 437 others, and derivative works that comment on or otherwise explain it 438 or assist in its implementation may be prepared, copied, published 439 and distributed, in whole or in part, without restriction of any 440 kind, provided that the above copyright notice and this paragraph are 441 included on all such copies and derivative works. However, this 442 document itself may not be modified in any way, such as by removing 443 the copyright notice or references to the Internet Society or other 444 Internet organizations, except as needed for the purpose of 445 developing Internet standards in which case the procedures for 446 copyrights defined in the Internet Standards process must be 447 followed, or as required to translate it into languages other than 448 English. 450 The limited permissions granted above are perpetual and will not be 451 revoked by the Internet Society or its successors or assigns. 453 This document and the information contained herein is provided on an 454 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 455 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 456 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 457 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 458 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Table of Contents 462 1 Introduction ........................................ 2 463 1.1 Conventions of This Document ........................ 2 464 2 Terminology ......................................... 2 465 3 Integration with Floor Control ...................... 3 466 4 Conference Policy Data Model ........................ 3 467 5 Conference Policy Requirements ...................... 4 468 5.1 Conference creation, termination and joining ........ 4 469 5.2 Manipulating general conference attributes .......... 4 470 5.3 Authentication and Security ......................... 5 471 5.4 Application and media manipulation .................. 5 472 5.5 ACL manipulation .................................... 6 473 5.6 Floor control ....................................... 6 474 5.7 Inviting and ejecting users ......................... 6 475 5.8 User Privileges ..................................... 6 476 6 Notifications and Subscriptions ..................... 7 477 7 Possible Solutions .................................. 7 478 8 Open Issues ......................................... 7 479 9 Changes from previous version ....................... 7 480 10 Acknowledgements .................................... 8 481 11 Authors' Addresses .................................. 8 482 12 Normative References ................................ 8 483 13 Informative References .............................. 9