idnits 2.17.1 draft-koskelainen-xcon-floor-control-req-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 (June 2003) is 7622 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 266, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 279, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 282, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-02) exists of draft-koskelainen-xcon-xcap-cpcp-usage-01 == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sccp-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area H. Schulzrinne 3 Internet-Draft X. Wu 4 Expires: November 30, 2003 Columbia University 5 P. Koskelainen 6 Nokia 7 J. Ott 8 Uni Bremen TZI 9 June 2003 11 Requirements for Floor Control Protocol 12 draft-koskelainen-xcon-floor-control-req-01 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 30, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document defines the requirements for floor control in a 43 multi-party conference environment. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 49 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 5. Integration with Conferencing . . . . . . . . . . . . . . . . 7 52 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 54 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 55 Normative References . . . . . . . . . . . . . . . . . . . . . 12 56 Informative References . . . . . . . . . . . . . . . . . . . . 13 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 58 Intellectual Property and Copyright Statements . . . . . . . . 15 60 1. Introduction 62 Conference applications often have shared resources such as the right 63 to talk, input access to a limited-bandwidth video channel, or a 64 pointer or input focus in a shared application. 66 In many cases, it is desirable to be able to control who can provide 67 input (send/write/control, depending on the application) to the 68 shared resource. 70 Floor control enables applications or users to gain safe and mutually 71 exclusive or non-exclusive input access to the shared object or 72 resource. The floor is an individual temporary access or manipulation 73 permission for a specific shared resource (or group of resources) 74 [7]. 76 Floor control is an optional feature for conferencing applications. 77 SIP [2] conferencing applications may also decide not to support this 78 feature at all. Two-party applications may use floor control outside 79 conferencing, although the usefulness of this kind of scenario is 80 limited. Floor control may be used together with conference policy 81 control protocol (CPCP) [8], or it may be used as standalone separate 82 protocol, e.g. with SIP but without CPCP. 84 Floor control has been studied extensively over the years, (e.g. [9], 85 [7], [6]) therefore earlier work can be utilized here. 87 This document can be used with other documents, such as Conferencing 88 framework document [3]. 90 2. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119. 96 3. Terminology 98 This document uses the definitions from [3]. 100 Additional definitions: 102 Floor: A permission to temporarily access or manipulate a specific 103 shared resource or set of resources. 105 Conference owner: A privileged user who controls the conference, 106 creates floors and assigns and deassigns floor chairs. The 107 conference owner does not have to be a member in a conference. 109 Floor chair: A user (or an entity) who manages one floor (grants, 110 denies or revokes a floor). The floor chair does not have to be a 111 member in a conference. 113 Floor control: A mechanism that enables applications or users to gain 114 safe and mutually exclusive or non-exclusive input access to the 115 shared object or resource. 117 4. Model 119 A floor control protocol is used to convey the floor control messages 120 among the floor chairs (moderators) of the conference, the floor 121 control server and the participants of the conference. A centralized 122 architecture is assumed in which all messages go via one point. 124 The centralized conference server controls the floors at least in the 125 signaling level. Controlling also the actual (physical) media 126 resources (e.g. audio mixer) is highly recommended, but beyond the 127 scope of this document. 129 Note that the floor is a concept coupled with one or more media 130 streams. The creation of the media session itself is defined 131 elsewhere. A participant with appropriate privileges may create a 132 floor by defining that one or more existing media sessions are now 133 floor- controlled, and apppoint a floor chair. 135 5. Integration with Conferencing 137 Floor control itself does not support privileges such as handing over 138 chair privileges to another users (or taking them away). Instead, 139 some external mechanism, such as conference management (e.g. CPCP or 140 internal web-interface for policy manipulation) is used for that. 142 The conference policy (and conference owner or creator) defines 143 whether floor control is in use or not. Actually enforcing conference 144 media distribution in line with the respective media's floor status 145 (e.g. controlling an audio bridge) is beyond the scope of this 146 document. Floor control itself does not define media enforcement. It 147 is also the conference policy that defiens which media streams may be 148 used in a conference and which ones are floor controlled. 150 Typically, the conference owner creates the floor(s) using conference 151 policy control protocol (or some other mechanism) and appoints the 152 floor chair. The conference owner can remove the floor anytime (so 153 that a media session is not floor-controlled anymore) or change floor 154 chair or floor parameters. 156 The floor chair just controls the access to the floor(s), according 157 to the conference policy. 159 A floor control server is a separate logical entity, typically 160 co-located with focus and conference policy server. Therefore, 161 communication mechanisms between floor control server and other 162 central conferencing entities are not defined at this point. 164 6. Requirements 166 REQ-1: It MUST be possible to announce to participants that a 167 particular media session (or group of media sessions) is 168 floor-controlled and where requests for the floor should be addressed 169 to. 171 (This is a requirement for session protocol, i.e. SIP. SDP's "a" line 172 offers one possible indication.) 174 REQ-2: It MUST be possible to group several media sessions together 175 so that one floor applies to the group. 177 (The SDP "fid" extension may serve this purpose.) 179 REQ-3: It MUST be possible to define who is allowed to create, change 180 and remove a floor in a conference. We assume that the conference 181 owner always has this privilege and may also authorize other 182 entities, via the conference policy. 184 REQ-4: It MUST be possible to use a chair-controlled floor policy in 185 which the floor controller notifies the floor chair and waits for the 186 chair to make a decision. This enables the chair to fully control who 187 has the floor. The server MAY forward all requests immediately to 188 chair, or it may do filtering and send only occasional notifications 189 to the chair. 191 REQ-5: Participants MUST be able to request (claim) a floor and give 192 additional information about the request, such as the topic of the 193 question for an audio floor. 195 REQ-6: A floor holder MUST be able to release a floor. 197 REQ-7: The chair or controller MUST be able to revoke a floor from 198 its current holder. 200 REQ-8: It MUST be possible to grant a floor to a participant. 202 REQ-9: It MUST be possible to get and set at least the following 203 floor parameters: 205 - who is floor control chair (this does not have to be the conference 206 owner); 208 - whether "no floor control" is applied (free for all policy) 210 - what is the floor control policy (such as chair-controlled, first- 211 come first-served, random); 212 - the number of simultaneous floor holders. 214 REQ-10: Floor policies MAY support time limits that automatically 215 pass the floor (e.g. to the next-in-line) or revoke the floor after a 216 preset time interval. 218 REQ-11: It MUST be possible for a user with appropriate conference 219 privileges to change the chair for a floor. 221 REQ-12: Bandwidth and terminal limitations SHOULD be taken into 222 account in order to ensure that floor control can be efficiently used 223 in mobile environments. 225 REQ-13: Conference members and the chair MUST have the capability to 226 learn who has the floor and who has requested the floor. (Note: 227 Conference policy may prevent members seeing this.) 229 REQ-14: It MUST be possible to notify conference members and chair 230 about the floorholder changes and when a new floor request is being 231 made. (Note: Conference policy may prevent members seeing this.) 233 7. Open Issues 235 - support for privacy, e.g. the following: floor claimer must be able 236 to indicate privacy preference, and the ability to hide floor chair's 237 identity 239 Preliminary proposal: 241 RRQ-a: It MUST be possible for the floor requester to indicate her 242 privacy preference. The privacy preferences MUST include the 243 following options: 245 anonymous: the participants (including the floor chair) cannot see 246 the floor requester's identity. The floor chair grant the floor based 247 on the claim id and the topic of the claim. 249 known to the floor chair: only the floor chair is able to see the 250 floor requester's identity; all other participants do not obtain this 251 information. 253 public: all the participants can see the floor requester's identity. 255 RRQ-b: It MUST be possible to hide the identity of a floor chair from 256 a subset or all participants of a conference. 258 8. Acknowledgements 260 The authors would like to thank IETF conferencing design team and 261 Sanjoy Sen, Eric Burger, Brian Rosen, and Nermeen Ismail for their 262 feedback. 264 Normative References 266 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 267 Levels", RFC 2119, BCD 14, March 1997. 269 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 270 3261, June 2002. 272 [3] Rosenberg, J., "A Framework for Conferencing with the Session 273 Initiation Protocol", 274 draft-rosenberg-sipping-conferencing-framework-01 (work in 275 progress), February 2003. 277 Informative References 279 [4] Koskelainen, P., Schulzrinne, H. and X. Wu, "Additional 280 Requirements to Conferencing", October 2002. 282 [5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP 283 for conference floor control", January 2003. 285 [6] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 286 conference control framework", Nossdav'2002 Miami Beach, May 287 2002. 289 [7] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for 290 activity coordination in networked multimedia applications", 291 Proc. of 2nd Asian-pacific Conference on Communications APPC, 292 Osaka Japan, June 1995. 294 [8] Koskelainen, P. and H. Khartabil, "An Extensible Markup Language 295 (XML) Configuration Access Protocol (XCAP) Usage for Conference 296 Policy Manipulation", draft-koskelainen-xcon-xcap-cpcp-usage-01 297 (work in progress), October 2003. 299 [9] Borman, C., Kutchner, D., Ott, J. and D. Trossen, "Simple 300 conference control protocol service specification", 301 draft-ietf-mmusic-sccp-00 (work in progress), March 2001. 303 Authors' Addresses 305 Henning Schulzrinne 306 Columbia University 307 1214 Amsterdam Avenue 308 New York 10027 309 USA 311 EMail: hgs@cs.columbia.edu 313 Xiaotao Wu 314 Columbia University 315 1214 Amsterdam Avenue 316 New York 10027 317 USA 319 EMail: xiaotaow@cs.columbia.edu 320 Petri Koskelainen 321 Nokia 322 P.O. Box 100 (Visiokatu 1) 323 Tampere FIN-33721 324 Finland 326 EMail: petri.koskelainen@nokia.com 328 Joerg Ott 329 Uni Bremen TZI 331 Germany 333 EMail: jo@tzi.uni-bremen.de 335 Intellectual Property Statement 337 The IETF takes no position regarding the validity or scope of any 338 intellectual property or other rights that might be claimed to 339 pertain to the implementation or use of the technology described in 340 this document or the extent to which any license under such rights 341 might or might not be available; neither does it represent that it 342 has made any effort to identify any such rights. Information on the 343 IETF's procedures with respect to rights in standards-track and 344 standards-related documentation can be found in BCP-11. Copies of 345 claims of rights made available for publication and any assurances of 346 licenses to be made available, or the result of an attempt made to 347 obtain a general license or permission for the use of such 348 proprietary rights by implementors or users of this specification can 349 be obtained from the IETF Secretariat. 351 The IETF invites any interested party to bring to its attention any 352 copyrights, patents or patent applications, or other proprietary 353 rights which may cover technology that may be required to practice 354 this standard. Please address the information to the IETF Executive 355 Director. 357 Full Copyright Statement 359 Copyright (C) The Internet Society (2003). All Rights Reserved. 361 This document and translations of it may be copied and furnished to 362 others, and derivative works that comment on or otherwise explain it 363 or assist in its implementation may be prepared, copied, published 364 and distributed, in whole or in part, without restriction of any 365 kind, provided that the above copyright notice and this paragraph are 366 included on all such copies and derivative works. However, this 367 document itself may not be modified in any way, such as by removing 368 the copyright notice or references to the Internet Society or other 369 Internet organizations, except as needed for the purpose of 370 developing Internet standards in which case the procedures for 371 copyrights defined in the Internet Standards process must be 372 followed, or as required to translate it into languages other than 373 English. 375 The limited permissions granted above are perpetual and will not be 376 revoked by the Internet Society or its successors or assignees. 378 This document and the information contained herein is provided on an 379 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 380 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 381 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 382 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 383 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 385 Acknowledgement 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society.