idnits 2.17.1 draft-ietf-xcon-floor-control-req-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 616. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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 2, 2005) is 7047 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 524, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 540, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-02 == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sccp-00 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area P. Koskelainen 3 Internet-Draft Nokia 4 Expires: July 3, 2005 J. Ott 5 Uni Bremen TZI 6 H. Schulzrinne 7 X. Wu 8 Columbia University 9 January 2, 2005 11 Requirements for Floor Control Protocol 12 draft-ietf-xcon-floor-control-req-03.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 3, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 Floor control is a means to manage joint or exclusive access to 48 shared resource in a (multiparty) conferencing environment. Thereby, 49 floor control complements other functions -- such as conference and 50 media session setup, conference policy manipulation, and media 51 control -- that are realized by other protocols. This document 52 defines the requirements for a floor control protocol for multiparty 53 conferences in the context of an existing framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Integration with Conferencing . . . . . . . . . . . . . . . . 7 62 6. Assumptions about a Conference Policy . . . . . . . . . . . . 8 63 7. Floor Control Protocol Requirements . . . . . . . . . . . . . 10 64 7.1 Communication between Participant and Server . . . . . . . 10 65 7.2 Communicaton between Chair and Server . . . . . . . . . . 11 66 7.3 General Protocol Requirements . . . . . . . . . . . . . . 12 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 71 10.2 Informative References . . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 73 Intellectual Property and Copyright Statements . . . . . . . . 18 75 1. Introduction 77 Conference applications often have shared resources such as the right 78 to talk, input access to a limited-bandwidth video channel, or a 79 pointer or input focus in a shared application. 81 In many cases, it is desirable to be able to control who can provide 82 input (send/write/control, depending on the application) to the 83 shared resource. 85 Floor control enables applications or users to gain safe and mutually 86 exclusive or non-exclusive input access to the shared object or 87 resource. The floor is an individual temporary access or 88 manipulation permission for a specific shared resource (or group of 89 resources) [7]. 91 Floor control is an optional feature for conferencing applications. 92 SIP [2] conferencing applications may also decide not to support this 93 feature at all. Two-party applications may use floor control outside 94 conferencing, although the usefulness of this kind of scenario is 95 limited. Floor control may be used together with conference policy 96 control protocol (CPCP) [8], or it may be used as independent 97 standalone protocol, e.g. with SIP but without CPCP. 99 Floor control has been studied extensively over the years, (e.g. 100 [9], [7], [6]) therefore earlier work can be leveraged here. 102 The present document describes the requirements for a floor control 103 protocol. As a requirements specification, the document makes no 104 assumptions about the later implementation of the respective 105 requirements as parts of one or more protocols and about the entities 106 implementing it/them and their roles. 108 This document may be used in conjunction with other documents, such 109 as the Conferencing framework document [3]. In particular, when 110 speaking about a floor control server, this entity may be identical 111 to or co-located with the focus or a conference policy server defined 112 in the framework document, while participants and floor chairs 113 referred to in this specificiation may be regular participants as 114 introduced in the conferencing framework document. The term "floor 115 control protocol" is used in an abstract sense in this specification 116 and may ultimately be mapped to any of the existing conference 117 control or other signaling protocols (including CPCP and SIP). But 118 defining those relationships is left to a concrete floor control 119 protocol specification. 121 2. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119. 127 3. Terminology 129 This document uses the definitions from [3]. 131 The following additional definitions apply: 133 Floor: A permission to temporarily access or manipulate a specific 134 shared resource or set of resources. 136 Conference owner: A privileged user who controls the conference, 137 creates floors and assigns and deassigns floor chairs. The 138 conference owner does not have to be a member in a conference. 140 Floor chair: A user (or an entity) who manages one floor (grants, 141 denies or revokes a floor). The floor chair does not have to be a 142 member in a conference. 144 Floor control: A mechanism that enables applications or users to gain 145 safe and mutually exclusive or non-exclusive input access to the 146 shared object or resource. 148 Floor control server: A logical entity that maintains the state of 149 the floor(s) including which floors exists, who the floor chairs are, 150 who holds a floor, etc. Requests to manipulate a floor are directed 151 at the floor control server. 153 Floor request set: A logical data structure holding all requests for 154 a particular floor at a given point in time. 156 Floor holder set: A logical data structure identifying all 157 participants who currently hold the floor. 159 4. Model 161 The model for floor control comprises three logical entities: a 162 single floor control server, one or more floor chairs (moderators), 163 and any number of regular conference participants. 165 A floor control protocol is used to convey the floor control messages 166 among the floor chairs (moderators) of the conference, the floor 167 control server, and the participants of the conference. A 168 centralized architecture is assumed in which all messages go via one 169 point, the floor control server. Processing (granting or rejecting) 170 floor control requests is done by the one or more floor chairs or by 171 the server itself, depending on the policy. 173 Floor requests from the participants are received by the floor 174 control server and kept in an -- at the level of the floor control 175 protocol -- floor request set (i.e. are not ordered in any 176 particular fashion). The current floor holders are reflected in a 177 current floor holder set. Floor chairs are capable of manipulating 178 both sets to e.g. grant, revoke, reject, and pass the floor. 180 The order in which requests are processed, whether they are granted 181 or rejected, how many participants obtain a floor simultaneously, is 182 determined by a higher layer application operating on these sets and 183 is not confined by the floor control protocol. 185 A floor is associated with one or more media sessions. The 186 centralized conference server manages the floors and thus controls 187 access to the media sessions. There are two aspects to this: 1) The 188 server maintains and distributes consistent state information about 189 who has a certain floor at a certain point in time and does so 190 following some rule set. This provides all participants with the 191 necessary information about who is allowed to e.g. speak, but relies 192 on a cooperative behavior among all participants. 2) In addition, to 193 prevent individuals from ignoring the "hints" given by the floor 194 control server, the latter may -- e.g. in cooperation with other 195 functional entities -- enforce compliance with floor status, e.g. by 196 blocking media streams from participants not entitled to speak. The 197 floor control server controls the floors at least at the signaling 198 level (1); actively controlling also the actual (physical) media 199 resources (2) is highly recommended, but beyond the scope of this 200 document. 202 As noted in the introduction, an actual protocol specification 203 fulfilling the requirements defined in this memo may map the 204 components of the above model onto the conferencing components 205 defined in the conferencing framework document. Some of these 206 aspects are discussed briefly in the next subsection. 208 5. Integration with Conferencing 210 Floor control itself does not support privileges such as creating 211 floors and appointing floor chairs, handing over chair privileges to 212 other users (or taking them away). Instead, some external mechanism, 213 such as conference management (e.g. CPCP or web interface for policy 214 manipulation) is used for that. 216 The conference policy (and thus the conference owner or creator) 217 defines whether floor control is in use or not. Actually enforcing 218 conference media distribution in line with the respective media's 219 floor status (e.g. controlling an audio bridge) is beyond the scope 220 of this document. Floor control itself does not define media 221 enforcement. It is up to the conference and media policies to define 222 which media streams may be used in a conference and which ones are 223 floor controlled. 225 Typically, the conference owner creates the floor(s) using conference 226 policy control protocol (or some other mechanism) and appoints the 227 floor chair. The conference owner can remove the floor anytime (so 228 that a media session is not floor-controlled anymore) or change floor 229 chair or floor parameters. 231 The floor chair just controls the access to the floor(s), according 232 to the conference policy. 234 A floor control server is a separate logical entity, typically 235 co-located with focus and/or conference policy server. Therefore, 236 the floor control server can interact with focus, conference Policy 237 Server and media servers as needed. Communication mechanisms between 238 floor control server and other central conferencing entities are not 239 within the scope of the floor control protocol requirements described 240 in this document. 242 Conferences may be cascaded and hence a single participant in one 243 conference representing a second conference (called subconference). 244 From a floor control perspective there is no difference between a 245 participant (identified by its URI) representing a single person or 246 another (set of) subconference(s). 248 Note: In the latter case, it is the responsibility of the 249 subconference to internally negotiate floor requests before passing 250 on a request to the conference and to internally assign a floor upon 251 receiving a floor grant. This may be done recursively by employing 252 the floor control protocol with a different floor control server in 253 the subconference. 255 6. Assumptions about a Conference Policy 257 The floor control protocol is supposed to be used to manage access to 258 shared resources in the context of a conference. It is up to this 259 conference -- more precisely: its conference policy [4] -- to define 260 the rules for the operation of the floor control protocol. 261 Furthermore, a conference policy control protocol [4] may define 262 mechanisms to alter those rules during the course of a conference. 263 This section briefly outlines the assumptions made by a floor control 264 protocol about the conference policy and means for its modification. 266 The conference policy is expected to define the rules for floor 267 control -- which particularly implies that it is not the 268 responsibility of the floor control protocol to establish or 269 communicate those rules. 271 In general, it is assumed that the conference policy also defines who 272 is allowed to create, change and remove a floor in a conference. 274 Conference participants and floor chairs should be able to get and 275 set floor-related parameters. The conference policy may restrict who 276 may access or alter which parameters. Note that not all parameters 277 maintained for a floor are also interpreted by the floor control 278 protocol (e.g. floor policy descriptions may be stored associated 279 with a floor but may be interpreted by a higher layer application). 280 Note also that changes to the floor control policy outside the scope 281 of the floor control protocol and e.g. to be carried out by a 282 conference policy control protocol. 284 (For example, it may be useful to see who the floor chair is, what 285 kind of policy is in use, time limits, number of simultanous floor 286 holders and current floor holder.) 288 These following requirements on a conference policy related to floor 289 control are identified in [4]: 291 REQ-F1: It MUST be possible to define whether floor control is in use 292 or not. 294 REQ-F2: It MUST be possible to define the algorithm to be used in 295 granting the floor. (Note: Example algorithms might be e.g. 296 moderator-controlled, FCFS, random.) 298 Note: it must be possible to use an automated floor policy where the 299 floor control server decides autonomously about granting, and 300 rejecting floor requests as well as revoking the floor. It must also 301 be possible to use a chair-controlled floor policy in which the floor 302 control server notifies the floor chair and waits for the chair to 303 make a decision. This enables the chair to fully control who has the 304 floor. The server MAY forward all requests immediately to the floor 305 chair, or it may do filtering and send only occasional notifications 306 to the chair. 308 REQ-F3: It MUST be possible to define how many users can have the 309 floor at the same time. 311 REQ-F4: It MUST be possible to have one floor for one or more media 312 types. 314 REQ-F5: It MUST be possible to have multiple floors in a conference. 316 REQ-F6: It MUST be possible to define whether a floor is 317 moderator-controlled or not. 319 REQ-F7: If the floor is moderator-controlled, it MUST be possible to 320 assign and replace the floor moderator. 322 7. Floor Control Protocol Requirements 324 This section covers the requirements on a floor control protocol. 325 The requirements are grouped as follows: 1) floor control protocol 326 between participant and server; 2) floor control protocol between 327 floor chairs and server; 3) floor control server management, and 4) 328 general protocol requirements. 330 7.1 Communication between Participant and Server 332 REQ-PS-1: Participants MUST be able to request (claim) a floor. 334 REQ-PS-2: It SHOULD be possible for a participant requesting a floor 335 to give additional information about the request, such as the topic 336 of the question for an audio floor. Note: In some scenarios, the 337 floor control server or the floor chair may use this information when 338 granting the floor to the user, or when making manipulation to the 339 floor sets at the server. 341 REQ-PS-3: It MUST be possible for a participant to modify (e.g. 342 cancel) a previously placed floor request. 344 REQ-PS-4: It SHOULD be possible for a participant to initiate a floor 345 control operation (e.g. floor request, release) on behalf of another 346 participant (third-party floor control) provided that he is 347 authorized to do so. 349 REQ-PS-5: A participant MUST be informed that she has been granted 350 the floor. 352 REQ-PS-6: A participant MUST be informed that his floor request has 353 been rejected. 355 REQ-PS-7: A participant MUST be informed that the floor was revoked 356 from her. 358 REQ-PS-8: A participant SHOULD be informed that her floor request is 359 pending and will be processed later. 361 REQ-PS-9: A floor holder MUST be able to release a floor. 363 REQ-PS-10: It MUST be possible to notify conference participants 364 (changes to) the floor holder(s) 366 REQ-PS-11: It MUST be possible to notify conference participants when 367 a new floor request is being made. 369 RRQ-PS-12: It MUST be possible for a floor requester to request 370 privacy for claiming the floor. 372 anonymous: the participants (including the floor chair) cannot see 373 the floor requester's identity. The floor chairs grant the floor 374 based on the claim id and the topic of the claim. 376 known to the floor chair: only the floor chair is able to see the 377 floor requester's identity; all other participants do not obtain this 378 information. 380 public: all the participants can see the floor requester's identity. 382 REQ-PS-13: It MUST be possible for a participant to request privacy 383 for holding the floor along with a floor request. Note that identity 384 information about the particpant may become available to others 385 through different means (e.g. application/media protocols or the 386 mmedia itself such as the voice). 388 7.2 Communicaton between Chair and Server 390 REQ-CS-1: It MUST be possible to inform the floor chairs, if present, 391 about a participant's floor request. 393 It SHOULD be possible to convey additional information the 394 participant may have provided along with her request. 396 It MUST be possible to hide the requesting participant's identity 397 from the chair, i.e. not include this identity information in the 398 floor request. 400 REQ-CS-2: It MUST be possible to grant a floor to a participant. 402 REQ-CS-3: It MUST be possible to reject a participant's floor 403 request. 405 REQ-CS-4: The floor chair MUST be able to revoke a floor from (one 406 of) its current holder(s). Note that the floor chair may also remove 407 pending floor requests from the request set (by rejecting them). 409 REQ-CS-5: It MUST be possible to notify floor chairs about changes to 410 the floor holder(s) 412 REQ-CS-6: There SHOULD be operations to manipulate the request set 413 available for floor chair(s). Such request set SHOULD at least 414 include creating, maintaining, and re-ordering floor requests a queue 415 and clearing the floor control queue. 417 RRQ-CS-7: It MUST be possible to hide the identity of a floor chair 418 from a subset or all participants of a conference. 420 REQ-CS-8: It MUST be possible for a newly assigned floor chair to 421 learn about (e.g. inquire) the existing floor request set. 423 7.3 General Protocol Requirements 425 REQ-GEN-1: Bandwidth and terminal limitations SHOULD be taken into 426 account in order to ensure that floor control can be efficiently used 427 in mobile environments. 429 It should be noted that efficient communication by means of minimal 430 sized messages may contradict the desire to express reasons for 431 requesting a floor along with other information. Therefore, a floor 432 control protocol SHOULD be designed in a way that it allow for 433 expressive as well as minimal messaging, as (negotiable) 434 configuration option and/or selectable on a per-message basis. 436 REQ-GEN-2: The floor control MUST be a reliable client-server 437 protocol. Hence, it MUST provide a positive response indicating that 438 a request has been received or an error response if an error has 439 occurred. 441 REQ-GEN-3: It MUST be possible for the floor control server to 442 authenticate participants and chairs. 444 REQ-GEN-4: It MUST be possible for the participants and chairs to 445 authenticate the server. 447 REQ-GEN-5: It MUST be possible to ensure message integrity between 448 participants and chairs and the floor control server. 450 REQ-GEN-6: It MUST be possible to ensure privacy of messages 451 exchanged between participants and chairs and the floor control 452 server. 454 8. Security Considerations 456 Floor control messages are exchanged on one hand between regular 457 participants and the floor control server and on the other hand 458 between the floor control server and the floor chair(s). 460 If enabled, floor control mechanisms are used to control who may 461 contribute to a conference in arbitrary ways (speak, be seen, write, 462 etc. as supported by the conferencing applications). It is 463 important that floor control messages be protected because otherwise 464 an attacker could prevent participants from being "heard" in the 465 conference (e.g., in scenarios where silence is considered consent) 466 or make participants be heard in a conference without their knowledge 467 (e.g., eavesdropping on the participant's mike). Such considerations 468 are particularly relevant when floor control is used in conjunction 469 with one or more (central) entities (e.g., a media mixer) controlled 470 by the floor control server to enforce floor control decisions which 471 may allow an attacker to completely "mute" a participant. 473 Communications between a conference participant and the floor control 474 server are vulnerable to all kinds of masquerading attacks. If an 475 attacker can spoof the identity of the participant or inject messages 476 on its behalf, it may generate floor requests (e.g. floor release) 477 and prevent proper participation of the participant. If an attacker 478 can inject messages to the participant, it may generate arbitrary 479 responses and false status information. If an attacker can 480 impersonate the floor control server, a participant's requests may 481 never reach the actual floor control server. If an attacker can 482 intercept either side's messages (and hence become a man in the 483 middle) it may suppress, alter, or inject messages and thus 484 manipulate a participant's view of the conference floor status as 485 well as the floor control server's view of a participant. 487 Similar considerations apply to the communications between the floor 488 control server and the floor chair(s). If an attacker can intercept 489 messages from either side, it may defer or prevent responses to floor 490 control requests (from a particular floor chair). If it can inject 491 messages (particularly in the direction from the floor chair to the 492 floor control server), it may steer the assigment of conference 493 floors. If interception and injection is possible (man in the middle 494 scenario), an attacker can create an arbitrary image of the 495 conference for the floor chair. If an attacker can impersonate a 496 floor chair, it may rule the conference floor assignment (if there is 497 only a single chair) or disrupt the conference course by means of 498 arbitrary and potentially conflicting requests/responses/assignments 499 (if there are multiple floor chairs). In the latter case, the amount 500 of damage a single attacker can do depends on the floor control 501 policy. 503 Finally, attackers may eavesdrop on the floor control communications 504 and learn which participants are present, how active they are, who 505 are the floor chairs, etc. 507 To mitigate the above threats, conference participants, floor control 508 servers, and floor chairs SHOULD be authenticated upon initial 509 contact. All floor control messages SHOULD be authenticated and 510 integrity-protected to prevent third-party intervention and MITM 511 attacks. Floor control messages SHOULD be encrypted to prevent 512 eavesdropping. 514 9. Acknowledgements 516 The authors would like to thank IETF conferencing design team and 517 Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, 518 and Nermeen Ismail for their feedback. 520 10. References 522 10.1 Normative References 524 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 525 Levels", RFC 2119, BCD 14, March 1997. 527 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 528 3261, June 2002. 530 10.2 Informative References 532 [3] Rosenberg, J., "A Framework for Conferencing with the Session 533 Initiation Protocol", 534 draft-ietf-sipping-conferencing-framework-02.txt (work in 535 progress), June 2004. 537 [4] Koskelainen, P. and H. Khartabil, "Additional Requirements to 538 Conferencing", August 2004. 540 [5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP 541 for conference floor control", January 2003. 543 [6] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 544 conference control framework", Nossdav'2002 Miami Beach, May 545 2002. 547 [7] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for 548 activity coordination in networked multimedia applications", 549 Proc. of 2nd Asian-pacific Conference on Communications APPC, 550 Osaka Japan, June 1995. 552 [8] Koskelainen, P., Khartabil, H. and A. Niemi, "The Conference 553 Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01.txt 554 (work in progress), October 2004. 556 [9] Borman, C., Kutscher, D., Ott, J. and D. Trossen, "Simple 557 conference control protocol service specification", 558 draft-ietf-mmusic-sccp-00.txt (work in progress), March 2001. 560 Authors' Addresses 562 Petri Koskelainen 563 Nokia 564 5 Wayside Road 565 Burlington 01803 566 USA 568 EMail: petri.koskelainen@nokia.com 570 Joerg Ott 571 Uni Bremen TZI 572 Bibliothekstr. 1 573 Bremen D-28359 574 Germany 576 EMail: jo@tzi.uni-bremen.de 578 Henning Schulzrinne 579 Columbia University 580 1214 Amsterdam Avenue 581 New York 10027 582 USA 584 EMail: hgs@cs.columbia.edu 586 Xiaotao Wu 587 Columbia University 588 1214 Amsterdam Avenue 589 New York 10027 590 USA 592 EMail: xiaotaow@cs.columbia.edu 594 Intellectual Property Statement 596 The IETF takes no position regarding the validity or scope of any 597 Intellectual Property Rights or other rights that might be claimed to 598 pertain to the implementation or use of the technology described in 599 this document or the extent to which any license under such rights 600 might or might not be available; nor does it represent that it has 601 made any independent effort to identify any such rights. Information 602 on the procedures with respect to rights in RFC documents can be 603 found in BCP 78 and BCP 79. 605 Copies of IPR disclosures made to the IETF Secretariat and any 606 assurances of licenses to be made available, or the result of an 607 attempt made to obtain a general license or permission for the use of 608 such proprietary rights by implementers or users of this 609 specification can be obtained from the IETF on-line IPR repository at 610 http://www.ietf.org/ipr. 612 The IETF invites any interested party to bring to its attention any 613 copyrights, patents or patent applications, or other proprietary 614 rights that may cover technology that may be required to implement 615 this standard. Please address the information to the IETF at 616 ietf-ipr@ietf.org. 618 Disclaimer of Validity 620 This document and the information contained herein are provided on an 621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 623 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 624 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 625 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 Copyright Statement 630 Copyright (C) The Internet Society (2005). This document is subject 631 to the rights, licenses and restrictions contained in BCP 78, and 632 except as set forth therein, the authors retain all their rights. 634 Acknowledgment 636 Funding for the RFC Editor function is currently provided by the 637 Internet Society.