Internet DRAFT - draft-ekim-xcon-cpcp-bb
draft-ekim-xcon-cpcp-bb
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
<draft-ekim-xcon-cpcp-bb-00.txt>
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 <xcon@ietf.org>
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:
<xs:element name="conference-policy">
<xs:complexType name="conference">
<xs:sequence>
<xs:element name="conference-management" minOccurs="0"/>
<xs:element name="participant-management" minOccurs="0"/>
<xs:element name="sidebar-management" minOccurs="0"/>
<xs:element name="floor-manangement" minOccurs="0"/>
<xs:element name="media-management" minOccurs="0"/>
</xs:sequence>
ekim, et al Expires April 2004 [Page 5]
INTERNET DRAFT CPCP Building Block October 2003
<xs:attribute name="conf-id" type="xs:nonNegativeInteger"
use="required"/>
</xs:complexType>
</xs:element>
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]
