Internet Draft Eunsook Kim Internet Engineering Task Force Jong-Hwa Yi draft-ekim-xcon-cpcp-bb-00.txt ETRI October 2003 Expires April 2004 Conference Policy Control Protocol Building Blocks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notices Copyright (c) The Internet Society (2003). All Rights Reserved. Abstract In a tightly coupled conference, conference participants can communicate with the conference policy server using a conference policy control protocol (CPCP). This document generally describes how to use CPCP to efficiently provide and augment interaction between clients and conference policy server. This document describes what information is needed for conference policy control, and what operation is needed to manipulate and interact with the policy information. It is noted that the purpose of this draft is not to suggest a new mechanism of CPCP, but to suggest building block approach to CPCP work. EKim, et al Expires April 2004 [Page 1] INTERNET DRAFT CPCP Building Block October 2003 Table of Contents 1. Introduction 2. Terminology 3. Overall Architecture 4. Overview of CPCP operations 5. Body of CPCP Messages 6. Conference Policy Information 7. CPCP Operations 8. Requirements from other functions 9. Security Considerations 10. IANA Considerations 11. References Acknowledgements Authors' Addresses Full Copyright Statement 1. Introduction The conferencing framework document [2], which describes overall architectures, terminology, and protocol components needed for multi-party conferencing, defines a conference policy server where conference users can store and manipulate the conference policy. There is a unique conference policy for each conference, and the conference policy is represented by a URI. The URI points to a conference policy server. The framework document also describes the major conferencing operations, and many of them can be performed by the conference policy control protocol (CPCP): creating conferences, adding participants, conditional joins, removing participants, approving policy changes, destroying conferences, obtaining membership information, adding and removing media. The conference policy is also used by focus to make authorization decisions and guide its overall behavior. This document defines general operations of the conference policy control based on the framework and the conference policy requirements documents [3,4]. The clients send conference policy control requests to the conference policy server to manipulate and interact with the conference policy. Then the server responds the requests with corresponding results. The protocol specification is out of the scope of this document. This document is intended to continue a discussion to explore standard operations for conference policy control. Please send comments to the mailing list ekim, et al Expires April 2004 [Page 2] INTERNET DRAFT CPCP Building Block October 2003 1.1 Conventions of This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Terminology ACL: Access Control List Chair groups: a group of participants who charge in a conference and have certain privileges to manipulate the otherÆs privileges CPS: Conference Policy Server participants: conference clients who join a conference users: the same with participants 3. Overall Architecture +----------------+ + CPS + +----------+ +----------------+----+policy DB + + xcap/soap/etc. + +----------+ +----------------+ + HTTP / others + +--------+ /+----------------+ +--------+ + / | +--------+ + + /CPCP | + conf. + + / | + client +--/ | +--------+ \ | \SIP | \ | \+------------+ +-------+ + Conference + + + + Server +---+ mixer + + (Focus) + + + +------------+ +-------+ Conference clients can request to CPS to create a conference, destroy a conference, modify a conference policy data, get membership information, add participants, remove participants, change/add/remove privileges from certain participants by CPCP. ekim, et al Expires April 2004 [Page 3] INTERNET DRAFT CPCP Building Block October 2003 CPCP is an independent protocol from signaling like SIP or H.323. Each request and response MUST contain XML body, and it can carry on XCAP, SOAP, or other standardized mechanism. (note. if XCON decides a standardized mechanism among them, the architecture will be changed.) In SIP based conferencing system, CPS should invoke a focus when there is a request to create a conference. It also SHOULD notify focus of a request asking to invite or eject participants. Focus MAY ask to CPS of authentication of participants. 4. Overview of CPCP Operations The CPCP operations can categorize by conference management, participant management, privilege management, floor control management and media policy management. Each operation contains XML body that includes a unique request id in order to CPS to recognize whether the request is a duplicated one or not. Clients send a request operation with the request id to CPS, and the CPS send a corresponding response operation to the clients with returning the same request id. The operations can categorize conference management, participant management, privilege management, floor management, and media management. The operations about Conference management perform creation and destruction of a main conference and a sidebar. To create a conference, to terminate a conference, to manipulate conference information, to read conference information, to create a sidebar, and to terminate a sidebar will be included. The operations about participant management carry out manipulation of ACL, Char group, or sidebar users. To add users into ACL, to delete users from ACL, to add sidebar participants, to delete sidebar participants, to invite users, to eject users, to add chair group, to delete a chair, to read ACL information, and to read sidebar user information will be performed. The CPS SHOULD notify the conference application server (focus) of invite users and eject users operations, and corresponding call signaling should be followed. To give privileges and to withdraw privileges are the operations about privilege management. Each participant has its own privileges and has different role according to the privileges. In an initial state, only a head chair or chair groups have the privilege of giving privileges to other participants. Some special privileges ekim, et al Expires April 2004 [Page 4] INTERNET DRAFT CPCP Building Block October 2003 like conference destroying or ejecting participants also are recommended to share only within chair groups. Floor control and Media policy managements in CPCP are only related to who have the privileges to manipulate the information. When it uses XCAP [9] to carry and process the operations, HTTP commands will deliver requesting XML document. If it uses SOAP to come up with the operation, SOAP commands defined by mapping CPCP will be used. The detail binding behaviors will be described in protocol specification documents. The use of XCAP for CPCP is describing in [8]. 5. Body of CPCP messages XML document is used for the conference policy control message body. It MUST be based on XML 1.0 and MUST be encoded using UTF-8. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is: urn:ietf:params:xml:ns:conference-policy A conference policy document begins with the root element tag, æconference-policyÆ. General conference information, participants list and information, privileges list, floor control or media policy data will be included in the body. Each operation can use a single element or multiple elements. 6. Conference Policy information This chapter describes the detail elements of the conference policy information. A conference is described as a 'conference-policy' element. The corresponding XML schema is described as following: ekim, et al Expires April 2004 [Page 5] INTERNET DRAFT CPCP Building Block October 2003 6.1 General conference information The element of general conference information will be used for the operations of conference management - create or terminate a conference, or create or terminate a sidebar. Participants authenticated also can request to read the conference information. It contains conference URI, conference display name, Subject, Keyword, language, conference type, security policy, conference time, maximum number of participants, media information, and chair information. Other features MAY be extended. The conference display name and conference subject stand for the name and the subject of the conference, respectively. The optional element, conference type describes the type of the conference model: 'open', 'closed static', 'closed dynamic'. Each value contains the following meaning: * open conference: everyone can join a conference without restriction * closed conference: only pre-determined, pre-announced users determined during runtime can join a session - static model: the group of participants does not change during runtime of the session. - dynamic model: the group of participants might change during In security policy, it is announced which security mechanism is used. 'TLS', 'SMIME', 'authentication mechanism', and 'password' can be listed. 'authentication mechanism' may have three types: 'string', 'digest', and 'none'. The element of conference time is for reporting runtime of the session. It can be expressed with 'start time' and 'end time' describing when the conference will be started and terminated. Maximum number of Participants defines how many users can take part in the conference at the same time. It would be set by consideration of capacity of video handling. The element of media information has the type 'mideaType', consisted of audio, video, wb, and text. It defines which media will be used in the conference. ekim, et al Expires April 2004 [Page 6] INTERNET DRAFT CPCP Building Block October 2003 The chair information defines who charge the conference. It describes a user or user group having special privileges to access conference policy information. Depends on conference policy, only chair group may change conference policy data or privileges of the other users, and eject other participants. 6.2 Participants information Conference participants consist of ACL (Access Control List), Chair group, and sidebar users. Each user MUST be identified with a unique URI, and MAY have display name. It has certain privileges by user type. 6.2.1 privileges information Privileges to manipulate the conference policy data are listed as following: Right to destroy the ongoing conference Right to modify the conference policy Right to read the conference policy information Right to add a user in ACL Right to expel a user from the conference Right to modify chair group information Right to add a user to the chair group Right to expel a chair from the chair group Right to award privileges to others Right to withdraw privileges from others Right to manage media policy Right to manage floor control policy Right to control sidebars They are assigned to the conference participants. It can be modified during the conference. 6.4 floor-control information The information is not about operations of floor-control, but those who have privileges of floor control. TBD 6.5 media-control information The information is not about operations of media-control, but media server information and those who have privileges of media control. ekim, et al Expires April 2004 [Page 7] INTERNET DRAFT CPCP Building Block October 2003 TBD 7. CPCP Operations The clients send conference control requests to the CPS to manipulate and interact with the conference policy. Then the server responds the requests with corresponding results. The major conferencing operations can categorize by conference management, membership management, media management and floor management operations. Operations performed for conference management can include creating and destroying conferences, approving policy changes, creating and destroying sidebar, creating and destroying cascading conference, and notifying for cascading conference. Membership management operations can cover of adding, removing, blocking or ejecting participants, of requesting conditional joins, and obtaining membership information. Manipulating user privileges is also included in the membership management operations. Media management operations are about adding and removing media, granting media change, and changing media policy. Floor management operations handle requesting and granting floor, and manipulating floor controller. About clients' requests from the above operations, the server MUST response the results with the corresponding return value such as a new conference URI for a request of creating a conference. When it fails, it will return error code with reason of user terminated, media connection failure, internal error, registration failure, authorization failure, no resources, bad or missing parameter, no permission, or not found the requested XML. 7.1 Operations of conference management 7.1.1 Create conference Every user who is authenticated by the CPS can issue this operation. The operation contains an XML instance derived from the defined XML schema explained in chapter 5. For a conference, 'conf-URI' MUST be unique, and it MUST be a valid SIP or SIPS URI. ekim, et al Expires April 2004 [Page 8] INTERNET DRAFT CPCP Building Block October 2003 When a client sends the operation, CPS creates a 'conf-URI' and sends the client the URI, indicating a focus address. The CPS initiates the focus, as well. Clients MAY request the operation with a 'conf-URI', which they eager to use. If the requested URI has no error or causes any conflict, CPS MAY accept the requested URI. 7.1.2 Destroy conference When a conference is destroyed, the conference and media policies associated with it are destroyed. If there are still participants in the conference, only authorized chair group MUST issue this operation. The destroy conference command takes one mandatory element, 'conf- URI' and an optional element, 'conf-name'. The response of the command is indicating whether the conference has been successfully destroyed or not. 7.1.3 Read conference policy information This operation is for obtaining the conference policy information, such as the general information of the conference, access control list, the current member list, or the chair group list in a conference, etc. The corresponding response will be returned containing in a XML body. 7.2 Operations of membership management 7.2.1 Add users in ACL This operation is for adding one or more users in the access control list (ACL) in a conference. An authorized client can specify any SIP URI that is to be added, if it is not already in the participants list. The XML body contains the 'conf-URI' identifying the conference, and the target 'SIP-URI' identifying the will-be-added user. The response of the operation is indicating whether the users has been successfully added or not to the ACL. The CPS SHOULD inform of this request to the focus in order to trigger INVITE message to the targeted user. 7.2.2 Eject Users from a conference ekim, et al Expires April 2004 [Page 9] INTERNET DRAFT CPCP Building Block October 2003 The authorized chair group members only allow executing this operation. The XML body contains the 'conf-URI' identifying the conference, and the target 'SIP-URI' identifying the will-be-expelled user. The response of the operation is indicating whether the users has been successfully ejected or not from the ACL. The CPS SHOULD inform of this request to the focus in order to trigger BYE message to the targeted user. 7.2.3 Award user privileges This operation is executed to changes the privileges of the specified users. Only authorized members can issue this operation. It carry the 'target-user' indicating one ore more target users who will get the privileges and 'privilege types', defining the type of privileges. The response of the command is indicating whether the requested changes have been successfully performed or not. TBD 7.2.4 Withdraw user privileges This operation requests to hand off the privileges of the specified users. Only authorized members can issue this command. The parameters and usage of this operation are the same with the operation of awarding user privileges. The only difference is that it is used for take away the privileges from the 'target-user'. The response of the command is indicating whether the privileges have been successfully deprived or not. TBD 7.3 Operations of media management TBD 7.5 Operations of floor management TBD 8. Security Considerations ekim, et al Expires April 2004 [Page 10] INTERNET DRAFT CPCP Building Block October 2003 Conference policy servers MUST use appropriate authentication to ensure the commands to manipulate or interact the conference policy data originated from trusted parties. Other SIP considerations apply [1]. The further concerned security issues will be identified as the further works go on. 9. IANA considerations The following URN sub-namespace should be registered. URI: urn:ietf:params:xml:ns:conference-policy 10. References [1] J. Rosenberg, H. Schulzrinne, et al, "SIP: Session Initiation Protocol, " RFC3261, Internet Engineering Task Force, Jun. 2002. [2] J. Rosenberg, "A framework for conferencing with the session initiation protocol," Internet Draft, Internet Engineering Task Force, Feb. 2003. Work in progress. [3] P. Koskelainen, "Requirements for conference policy protocol," Internet Draft, Internet Engineering Task Force, June 2003. Work in progress. [4] O. Levin, "Conference Policy Control Protocol for Centralized Conferencing," Internet Draft, Internet Engineering Task Force, June 2003. Work in progress. [5] R. Moats, "URN syntax, " RFC2141, Internet Engineering Task Force, May 1997. [6] R. Moats, "A URN namespace for IETF documents, " RFC2648, Internet Engineering Task Force, Aug. 1999. [7] M. Mealling, "The IETF XML registry, " Internet Draft, Internet Engineering Task Force, Jul. 2002. Work in progress. [8] P. Koskelainen, H. Khartabil, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy Manipulation, " Internet Draft, Internet Engineering Task Force, June. 2003. Work in progress. [9] J. Rosenburg, "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP), " IETF Internet Draft, Jun. 2003. Work in progress. ekim, et al Expires April 2004 [Page 11] INTERNET DRAFT CPCP Building Block October 2003 Acknowledgement The CPCP draft by O. Levin, and the CPCP requirement by P. Koskelainen give good motivation and information to write this draft. Authors' Addresses Eunsook Kim eunah@etri.re.kr 361 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea Jong-Hwa Yi jhyiee@etri.re.kr 361 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. ekim, et al Expires April 2004 [Page 12] INTERNET DRAFT CPCP Building Block October 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ekim, et al Expires April 2004 [Page 13]