[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Transport                                                 P. Koskelainen
Internet-Draft                                              H. Khartabil
Expires: December 19, 2003                                         Nokia
                                                           June 20, 2003

   An Extensible Markup Language (XML) Configuration Access Protocol
            (XCAP) Usage for Conference Policy Manipulation

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 working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents 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 "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 19, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.


   This document describes conference policy data elements and the
   mechanisms to manipulate them at a server via Conference Policy
   Control Protocol (CPCP). Extensible Markup Language (XML)
   Configuration Access Protocol (XCAP) is used to implement CPCP. This
   document specifies an XML Schema and XCAP application usage that are
   needed to implement CPCP.

Koskelainen & Khartabil    Expires December 19, 2003            [Page 1]

Internet-Draft                 XCAP CPCP                       June 2003

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
   3.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.   Application Unique ID  . . . . . . . . . . . . . . . . . . .   6
   5.   Computed Data  . . . . . . . . . . . . . . . . . . . . . . .   7
   6.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   8
   7.   Conference Creation and Termination  . . . . . . . . . . . .   9
   8.   User Additions and Expels  . . . . . . . . . . . . . . . . .  10
   9.   Naming Conventions . . . . . . . . . . . . . . . . . . . . .  11
   10.  Structure of a Conference Policy document  . . . . . . . . .  12
   11.  Structure of XML Document  . . . . . . . . . . . . . . . . .  13
   11.1 <Conference-URI> element . . . . . . . . . . . . . . . . . .  13
   11.2 <Conference-info> element  . . . . . . . . . . . . . . . . .  13
   11.3 <Conference-time> element  . . . . . . . . . . . . . . . . .  14
   11.4 <PCL> (Privilege Control List) element . . . . . . . . . . .  15
   11.5 <SC> (Security Control) element  . . . . . . . . . . . . . .  16
   11.6 <DL> (Dial-Out List) element . . . . . . . . . . . . . . . .  18
   11.7 <ACL> (Access Control List) element  . . . . . . . . . . . .  18
   11.8 <Floor-control> element  . . . . . . . . . . . . . . . . . .  20
   11.9 <Media-Policy> element . . . . . . . . . . . . . . . . . . .  20
   12.  Additional Constraints . . . . . . . . . . . . . . . . . . .  21
   13.  Authorization Policies . . . . . . . . . . . . . . . . . . .  22
   14.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . .  23
   15.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  28
   16.  Security Considerations  . . . . . . . . . . . . . . . . . .  31
   17.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  32
   17.1 XCAP Application Usage ID  . . . . . . . . . . . . . . . . .  32
   17.2 application/conference-policy+xml mime TYPE  . . . . . . . .  32
   17.3 URN Sub-Namespace Registration for
        urn:ietf:params:xml:ns:conference-policy . . . . . . . . . .  33
   18.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .  34
   19.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  35
        Normative References . . . . . . . . . . . . . . . . . . . .  36
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  37
        Intellectual Property and Copyright Statements . . . . . . .  38

Koskelainen & Khartabil    Expires December 19, 2003            [Page 2]

Internet-Draft                 XCAP CPCP                       June 2003

1. Introduction

   SIP conferencing framework [10] defines the mechanisms for
   multi-party centralized conferencing in SIP environment. Existing SIP
   mechanisms allow users e.g. to join and leave a conference.
   Centralized server (called focus) can expel and invite users, and
   have proprietary access control lists and privilege definitions.
   However, in many cases it is useful to have standardized conference
   policy elements (such as access control lists) and the standardized
   protocol means to manipulate them as defined in conference policy
   control protocol requirements [7] (CPCP) document. This document
   provides both standardized conference policy elements and XCAP usage
   to manipulate them.

   Other mechanisms, such as web page or voice response system can also
   be used to manipulate conference policy data. However, these
   solutions are not appropriate due to lack of interoperability. This
   document provides an XCAP [8] application usage to solve these

   XCAP is a HTTP 1.1 based protocol that allows clients to read, write,
   modify and delete application elements at a server. One application
   area which has already adopted XCAP is the manipulation of presence
   lists [9].

   XCAP has many advantages to be used for conference policy control
   protocol. First, it is very simple which is important e.g. in
   wireless environments. It is already in use for presence list
   manipulation and it is expected that clients supports both
   applications. Now they can use same protocol for these purposes.

Koskelainen & Khartabil    Expires December 19, 2003            [Page 3]

Internet-Draft                 XCAP CPCP                       June 2003

2. Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

Koskelainen & Khartabil    Expires December 19, 2003            [Page 4]

Internet-Draft                 XCAP CPCP                       June 2003

3. Terminology


         Access control list (ACL) defines users who can join to a
         conference. Users may have allow, blocked or pending status in
         the list. Each conference has its own ACL.


         Conference Policy Server. See [10]

      Conference participant

         Conference participant is a user who has on-going session (e.g.
         SIP dialog) with the conference focus.

      Floor control

         Floor control is a mechanism that enables applications or users
         to gain safe and mutually exclusive or non-exclusive access to
         the shared object or resource in a conference.

      Dial-Out List (DL)

         Dial-out list (DL) is a list of users who the focus needs to
         invite to the conference.


         Privilege control control (PCL) defines privileges for a user.
         Each user in a conference may have different list of privileges
         and each conference has its own PCL.

Koskelainen & Khartabil    Expires December 19, 2003            [Page 5]

Internet-Draft                 XCAP CPCP                       June 2003

4. Application Unique ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the IETF tree or a vendor tree. This
   specification defines the "conference-policy" AUID within the IETF
   tree, via the IANA registration in Section 17.

Koskelainen & Khartabil    Expires December 19, 2003            [Page 6]

Internet-Draft                 XCAP CPCP                       June 2003

5. Computed Data

   Conference server must fill the conference URI and return it in the
   response when the conference is created, if the conference URI was
   not proposed by the client.

Koskelainen & Khartabil    Expires December 19, 2003            [Page 7]

Internet-Draft                 XCAP CPCP                       June 2003

6. Overview of Operation

   This document assumes that the user knows the location (URI) of
   conference policy server, the details of that discovery are beyond
   the scope of this document.

   CPCP is implemented as an XCAP application usage, similarly to
   presence list manipulation which is also using XCAP.

   CPCP allows clients to manipulate the conference policy at conference
   policy server (CPS). CPS is able to inform the focus, if necessary.
   For example, if new users are added to the dial-out list, then
   conference policy server informs the focus which makes the invites as

   Some assumptions about the conferencing architecture are made.
   Clients always connect to the conference policy server (CPS) when
   they perform XCAP operations. It is assumed that CPS informs other
   conferencing entities, such as focus, floor control server and mixer
   directly or via focus. For example, when user expels another user via
   XCAP based CPCP, then it must first manipulate policy data in CPS
   which then asks the focus to perform the operation. The communication
   between different (logical) conferencing elements are beyond the
   scope of this document. It can be expected that in most cases CPS
   performs also those logical functions.

   OPEN ISSUE: Does focus ever need to update conference policy? (maybe
   in some cases)

   Conference factory applications may also use CPCP to create the
   conference, receive the conference URI, then redirect the conference
   creator to the conference URI.

   Ad-hoc conferences may also became CPCP-controlled. In this case, the
   creator of the original ad-hoc conference (the one who sent initial
   INVITE) has all privileges.

   OPEN ISSUE: Is this needed? (ad-hoc conf becames CPCP-controlled)

Koskelainen & Khartabil    Expires December 19, 2003            [Page 8]

Internet-Draft                 XCAP CPCP                       June 2003

7. Conference Creation and Termination

   Conference is identied by a conference URI which is hosted by the
   server (CPS).

   A user may create a new conference at the CPS by using HTTP POST.
   Depending on server policy and user privileges, CPS may accept the

   Conference (and its resources) can be deleted permanently using HTTP
   DELETE. When the user deletes a conference, CPS MUST also delete all
   its subconferences ("sidebars") at a server.

   Conference sidebars are separate (independent) URIs at the server.

Koskelainen & Khartabil    Expires December 19, 2003            [Page 9]

Internet-Draft                 XCAP CPCP                       June 2003

8. User Additions and Expels

   User with sufficient privileges (users with
   RIGHT_TO_DO_USER_MANAGEMENT privilege) is allowed to perform user
   management operations, such as adding (deleting) user to (from) the
   conference. These commands are sent to the conference policy server.
   After ensuring that the manipulation command came from the privileged
   user, conference policy server asks the focus to perform the
   indicated operation (SIP INVITE or SIP BYE).

   Invite operation is achieved with HTTP POST. This modifies Dial-Out
   List and CPS triggers the focus to send the SIP INVITE(s) as needed.
   Expel operation uses POST as well, as user is put to ACL list with
   Blocked action. Similarly to Invite, this trigger CPS to inform the
   focus about the need to issue a SIP BYE.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 10]

Internet-Draft                 XCAP CPCP                       June 2003

9. Naming Conventions

   There are no naming conventions that need to be defined for this
   application usage.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 11]

Internet-Draft                 XCAP CPCP                       June 2003

10. Structure of a Conference Policy document

   Conference policy document is an XML [5] document that MUST be
   well-formed and SHOULD be valid. Conference policy documents MUST be
   based on XML 1.0 and MUST be encoded using UTF-8. This specification
   makes use of XML namespaces for identifying conference policy
   documents and document fragments. The namespace URI for elements
   defined by this specification is a URN [2], using the namespace
   identifier 'ietf' defined by [3] and extended by [11]. This URN is:


   A conference policy document begins with the root element tag
   ``conference-policy''.  It consists of one mandatory element
   "conference." Other elements from different namespaces MAY be present
   for the purposes of extensibility; elements or attributes from
   unknown namespaces MUST be ignored. Conference element includes
   following sub-elements:

      Conference-info: This mandatory sub-element includes informational attributes
        describing the conference, e.g. for search purposes and to be included
           into dial-out session descriptions.
      Conference-time: This mandatory sub-element includes information related
        to conference duration.
      ACL: This is mandatory sub-element for access control list.
      PCL: This is mandatory sub-element for privilege control list.
      DL: This is mandatory sub-element for dial-out list.
      SC: This is mandatory sub-element for security control.
      Conference-media-policy: This is mandatory sub-element for conference media policy.

   The attributes are described in more detail in forthcoming sections.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 12]

Internet-Draft                 XCAP CPCP                       June 2003

11. Structure of XML Document

11.1 <Conference-URI> element

   Conference is identified by the conference URI, which is allocated by
   the conference policy server and returned to the client. It is also
   possible that client proposes a new name by itself (e.g.
   sip:discussion-on-dogs@example.com) as it may be useful to have
   human-friendly name in some cases. Server still decides whether it
   gives the name proposed by the client. Conference URI can be SIP,
   SIPS, or TEL URI. Conference policy server creates the focus for the
   conference when the conference instance starts.

   <Conference-URI> is a mandatory element and it cannot be changed
   during the conference lifetime.

   Conference may be deleted so that conference URI and policy are
   deleted permanently (using HTTP DELETE). Conference instance may also
   be terminated temporarily, e.g. so that conference URI and policy
   remain at the server but conference is no longer active (modifying
   conference end-time).

11.2 <Conference-info> element

   <Conference-Info> element includes informative conference paramaters
   which may be helpful describing the purpose of conference, e.g. for
   search purposes or providing contact information for the host.

   Each conference has an optional <Subject> element, which describes
   the current topic in a conference. The optional <Display-Name>
   element is the display name of the conference, which usually does not
   change over time.

   <Free-Text> and <Keywords> are optional elements. They provide
   additional textual information about the conference. This information
   can be made available to the conference participants or to everyone
   interested by means not specified here. Examples of usage could be
   searching for a conference based on some keywords, providing
   additional information to tentative conference participants etc.

   Optional <Host-Info> element contains several sub-elements. It gives
   additional information about the user who is hosting the conference.
   This information can be be included into SDP fields in SIP INVITEs
   sent by the focus. <SIP-uri> element is mandatory, while <TEL-uri>,
   <Web-page> and <E-mail> are optional. Note that the conference host
   is not necessarily the same as the conference moderator.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 13]

Internet-Draft                 XCAP CPCP                       June 2003

11.3 <Conference-time> element

   OPEN ISSUE: Do we need times, maybe just relative time and whether it
   can be extended or not. If there is separate scheduling application
   for future conference reservations, how it is controlled?

   The information related to conference time and lifetime is contained
   in the <Conference-Time> element. The conference may occur only once
   for a limited period of time (i.e. it has a limited lifetime), the
   conference may be non-bounded (i.e. it does not have a specified end
   time), or the conference may be permanent. Bounded conferences may be
   repeated after some time interval (e.g. on weekly basis).

   <Conference-Time> contains one or more <Conference-Occurrences each
   defining the time information of a single conference occurrence.
   Multiple <Conference-Occurrence> elements MAY be used if a conference
   is active at multiple irregularly spaced times; each additional
   <Conference-Occurrence> element contains time information for a
   specific occurrence.

   For each occurrence, the <Start-time> and <Stop-time> specify start
   and stop times for when a conference is active. For example, for a
   conference that is to be repeated once on a different time, one
   <Conference-Occurrence> could define the conference to be active at
   10am on Monday until 11am on Monday, while the second
   <Conference-Occurence> defines the conference to active at 11am on
   Tuesday until 1pm on Tuesday.

   If the conference is active at regular times, a <Repeat> element
   should be used in addition to and following <Start-time> and
   <Stop-time> elements - in which case the <Start-time> and <Stop-time>
   elements specify the start and stop times of the repeat sequence.

   If the <Stop-time> is set to zero, then the session is not bounded,
   though it will not become active until after the <Start-time>.  If
   the <Start-time> is also zero, the session is regarded as permanent.

   <Repeat-interval> element specifies repeat times for a conference.
   For example, if a conference is active at 10am on Monday and 11am on
   Tuesday for one hour each week for three months, then the
   <Start-time> would be 10am on the first Monday, the <Repeat-interval>
   would be 1 week, the <Active-duration> would be 1 hour, and the
   offsets <Offsets-from-start-time> would be zero and 25 hours. The
   corresponding <Stop-time> would be the end of the last session three
   months later. In this example, the information is contained within a
   single <Conference-Occurrence element>.

   By default all repeat attributes are in seconds.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 14]

Internet-Draft                 XCAP CPCP                       June 2003

11.4 <PCL> (Privilege Control List) element

   Many kind of operations can be performed in a conference so there
   must be a mechanism that controls who are allowed to perform which
   operation. In the simplest case, one user - often called as a
   moderator - has the right to perform any operation available. In
   other cases, it may be useful to define e.g. that some users are
   allowed to expel users but not perform any other operations.
   Therefore, conferencing framework supports the idea of privileges.
   Privilege is a temporary user right to perform an operation.
   Conference may have at least the following privileges:



   RIGHT_TO_CREATE_CONFERENCE: Users with this privilege can create a
   new conference at a server.

   RIGHT_TO_TERMINATE_CONFERENCE: Users who have this privilege may
   terminate (delete) current conference by using CPCP.

   RIGHT_TO_MANIPULATE_GENERAL_PARAMETERS: Users who have this privilege
   can manipulate general parameters, e.g. conference time, Subject etc.

   RIGHT_TO_DO_USER_MANAGEMENT: Users who have this privilege are
   allowed to ask the focus to invite and expel users.

   RIGHT_TO_MANIPULATE_MEDIA_POLICY: Users who have this privilege may
   manipulate the media part of conference policy by using CPCP.

   RIGHT_TO_MANIPULATE_OWN_MEDIA_POLICY: User who have this privilege is
   allowed to manipulate his or her own media policy.

   RIGHT_TO_MANIPULATE_PRIVILEGES: Users who have this privilege may
   give (or take away) a privilege to another user by using CPCP. After

Koskelainen & Khartabil    Expires December 19, 2003           [Page 15]

Internet-Draft                 XCAP CPCP                       June 2003

   succesful completion of this command, conference policy has the new
   information. It is up to the conference focus to send a notification
   and inform the user who got the new privilege.

   RIGHT_TO_MANIPULATE_FLOOR_POLICY: Users who have this privilege are
   allowed to create floors and assign floor moderators (using floor
   control protocol) for all media sessions within the conference.

   Initial privileges are defined when the conference is originally
   created. Privileges may be handed over to other users and they can be
   taken away. Also users outside of conference may hold a privilege.
   Problematic situations might be possible, such as nobody in a
   conference has any privileges. These kind of situations are
   impossible to completely avoid. However, as a backup mechanism, the
   conference creator or at least one user has always the
   RIGHT_TO_GIVE_PRIVILEGE privilege. Moreover, conference service (or
   server) may have server-specific backup rules, e.g. server
   administrator may be manually involved, if necessary.

   It is necessary to control the information which users have
   privileges. Therefore, ACL-like Privilege Control List (PCL) is
   introduced as a policy data element. It includes target URI (possibly
   wildcarded) followed by the list of privileges.

   Example PCL looks like this:

   sip:*@example.com: RIGHT_TO_EXPEL
   sip:alice@company.com: RIGHT_TO_TERMINATE_CONFERENCE

   User can fetch the PCL from the conference policy server by using
   HTTP GET as it is part of conference policy.

   New privileges can be added to a user by using a HTTP POST operation
   for a given subtree and privilege can be taken away using HTTP
   DELETE. These commands can be succesfully performed only by those
   users who themselves have the required privilege

11.5 <SC> (Security Control) element

   The conference security encompasses three aspects: controlling the
   visibility of a conference, securing the SIP messages, and performing
   authentication for individual users.

   The mandatory <Visibility> element controls whether the conference is
   visible to others than users participating in a conference. This
   element may have two values: "Visible" and "Invisible". If

Koskelainen & Khartabil    Expires December 19, 2003           [Page 16]

Internet-Draft                 XCAP CPCP                       June 2003

   <Visibility> is set to "Invisible" then the conference policy server
   should not reveal any information about the conference to others than

   We define two mechanisms for securing the signalling dialogs between
   users and the conference policy server: TLS and S/MIME.

   TLS is used to provide transport layer security on a hop-by-hop
   basis. According to SIP [6], using SIPS URI scheme in a request
   signifies that TLS must be used to secure each hop over which the
   request is forwarded until the request reaches the SIP entity
   responsible for the domain portion of the Request-URI.

   When the mandatory <Security-Mechanism> in the conference policy has
   a value "TLS=true" (thus implying the use of SIPS URI scheme), it is
   required that TLS is used end-to-end. In other words, TLS must be
   used also on the last hop between the entity responsible for the
   domain portion of the Request-URI and the conference policy server.

   If end-to-end confidentiality of entire SIP messages is not required
   in the conference policy, but it is required that the message bodies
   within SIP are encrypted, the <Security-Policy> element must have a
   value "S/MIME=true".

   TLS and S/MIME may be required independent of each other. In other
   words, it may be requred to use neither, one, or both depending on
   the settings of these parameters.

   The conference creator may optionally define the authentication
   policy for individual participants. Mechanisms used for this are
   defined in the <Authorization-mechanism> element. The only defined
   authorization mechanism in this document is HTTP Digest.

   The value of the <Authorization-mechanism> element may be either
   "Digest" indicating HTTP Digest authentication, or "none" indicating
   that no authentication is required. The password associated with each
   user in the Digest authentication is included in the optional
   <Password> attribute. This attribute is ignored if authentication is
   set to "none".

   Each target URI in the SC list is also associated with a <Visibility>
   element that defines whether the participant is visible to other
   users. The relationship of this attribute and the the <Visibility>
   element affecting the whole conference is as follows:

   - Conference visible, participant visible: participant is visible to everyone
   - Conference visible, participant invisible: participant is invisible to everyone

Koskelainen & Khartabil    Expires December 19, 2003           [Page 17]

Internet-Draft                 XCAP CPCP                       June 2003

   - Conference invisible, participant visible: participant is visible to the conference
   - Conference invisible, participant invisible: participant is invisible to everyone

11.6 <DL> (Dial-Out List) element

   The purpose of a dial-out list (DL) in a conference is to trigger the
   focus to invite users in (e.g. due to charging reasons). This list
   can be updated during the conference lifetime so it can be used for
   mid-conference invites (and mass-invites) as well.

   DL includes list of users (wildcards not allowed) and list of
   parameters for each user. Focus does not update the DL, so the
   existing DL users remain in the DL until they are removed (using

   DL includes two parameters for each user in the list: the repeat time
   (how many times user is called), and the interval between the call
   attempts. Repeat time zero (0) means that call attempts are tried

   OPEN ISSUE: Are repeat/interval parameters needed? (or just let the
   server to decide?)

   Example DCL looks like:
   sip:bob@example.com: 30, 5-minutes
   tel:tim@example2.com: 3, 1-minutes

   Two operations can be performed for DL: Add new entry (URI) using
   HTTP POST, and Delete current entry using HTTP DELETE. The latter
   means that the user is removed from the DL and not called anymore.

11.7 <ACL> (Access Control List) element

   The purpose of Access Control List (ACL) is to control who can join
   the conference. Conference has one ACL consisting the target and the
   action for the target. The target is user URI (or wildcarded user
   URI). Action is one of Allowed/Blocked/Pending. Allowed means that
   the target is allowed to join the conference. Blocked means the
   opposite and pending means that the target is put on hold while
   further processing - such as consulting the moderator - takes places.

   Example ACL would look like this:
                sip:bob@example.com: allowed
                sip:*@example.com: blocked
                sip:*@company.com: pending

Koskelainen & Khartabil    Expires December 19, 2003           [Page 18]

Internet-Draft                 XCAP CPCP                       June 2003

   ACL must have default rule for those targets that no matching rule is
   found (i.e. "pending" action for those targets not found in the

   Wildcards can be used for whole user part only, not parts of it. For
   example, "sip:*@example.com" is a valid target while
   "sip:b*@example.com" is not.

   Sip: and sips: schemes are treated equally for the same person as ACL
   identifies users, not transport methods or authentication

   "Most specific expression wins" policy is used if overlapping rules
   are found. Basically, this means that user specific rule is searched
   first and if it is not found, then most specific wildcard rule is

   OPEN ISSUE: What kind of wildcard policy for domain part? Must be
   limited somehow in order to prevent too complicated and overlapping
   rules. Proposal: Don't allow it at all, or allow it only immediately
   after "@"-sign. For example, "sip:bob@*.com" is a valid target while
   "sip:bob@example.*" is not. A: Don't Allow wildcards in domain part.

   Following operations exist for ACL:

                Allow(list of targets)
                Block(list of targets)
                Pending(list of targets)

   First three commands create a new (or change existing) rule for the
   list of targets (user URIs or wildcarded user URIs). They can also
   remove unnecessary rules, e.g. if bob@example.com and tom@example.com
   are already blocked when new rule defining that *@example.com is
   blocked is performed, user specific rules can be safely removed.

   HTTP POST is used for Allow/Block/Pending operations and HTTP DELETE
   is used for the last operation. HTTP PUT is used to modify ACL for
   the target who already exists in ACL.

   Delete copes with (potential) ACL size problem. If the conference is
   long-lasting it is possible that new rules are added all the time but
   old rules are almost never removed (some of them are rewritten,
   though). This leads easily to the situation in which the ACL includes
   huge amount of unnecessary rules which are not really needed anymore.
   Therefore, there should be a mechanism to delete ACL. Conference
   focus may send a notification which warns that the size of ACL has
   increased local limit.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 19]

Internet-Draft                 XCAP CPCP                       June 2003

   New rule always overrides the old rule. It is server's responsibility
   to ensure this. This guarantees that conflicting rules do not exist
   (e.g. both allowed and blocked action is defined for same target) and
   the order in which ACL is searched is irrelevant.

   Blocking user also expels user from the current conference.

11.8 <Floor-control> element

   Floor control in a conference is performed using Floor Control
   Protocol (FCP). CPCP only controls via privileges who are allowed to
   manipulate floor policy (e.g. create and delete floors). FCP can then
   be used to create floor, and assign and de-assign floor moderator for
   a given floor. For example, in a typical conference the conference
   creator (moderator) first creates a floor for audio plane (using FCP)
   and then names one user - possibly himself -  (using FCP) to act as a
   floor moderator governing the access to the floor. Note that FCP does
   not create media streams (just the virtual floor attached to media),
   as media streams are created using CPCP.

   When the floor has been created and floor moderator has been
   assigned, the floor moderator gets notifications from the focus and
   is able to accept or deny floor requests (using FCP) from the
   conference users. The details of FCP are beyond the scope of this

   User with privilege RIGHT_TO_MANIPULATE_FLOOR_POLICY can create the
   floors and assign floor moderator using FCP.

11.9 <Media-Policy> element

   Media policy is integral part of the conference policy. It defines
   e.g. what kind of media topologies exist in the conference. The
   details of media manipulation are defined elsewhere
   (draft-mahy-sipping-media-policy-control-00.txt). User with
   sufficient privileges (RIGHT_TO_MANIPULATE_MEDIA_POLICY) is allowed
   to create, modify and delete media policy (e.g. add new media

Koskelainen & Khartabil    Expires December 19, 2003           [Page 20]

Internet-Draft                 XCAP CPCP                       June 2003

12. Additional Constraints


Koskelainen & Khartabil    Expires December 19, 2003           [Page 21]

Internet-Draft                 XCAP CPCP                       June 2003

13. Authorization Policies

   If the conference is "visible" (as defined in conference policy) then
   anybody can read the policy using HTTP GET. The policy may also be
   available for search engines etc. If the conference is "invisible",
   then only current participants and users with special privilege (e.g.
   RIGHT_TO_DO_USER_MANAGEMENT) can read the policy.

   OPEN ISSUE: Do we need new privilege which defines whether user is
   allowed to read conference policy? (probably no, current privileges
   are ok)

   OPEN ISSUE: Do we need to define that e.g. ACL is not shown in
   visible conferences

   OPEN ISSUE: Who can subscribe to the event package? (if visible, then
   anybody; if invisible, then only current participants and users with
   special privilege?)

   User with sufficient privileges can modify the relevant parts of the
   document. For example, user with privilege
   RIGHT_TO_MANIPULATE_FLOOR_POLICY can modify floor policy part of the
   conference policy.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 22]

Internet-Draft                 XCAP CPCP                       June 2003

14. XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

        <! Define the visibility as data type with two possible values>
        <xsd:simpleType name="Visibility-type"/>
         <xsd:restriction base="xsd:string">
           <xsd:enumeration value="visible"/>
          <xsd:enumeration value="invisible"/>

        <! Define the privileges as data type with all possible values>
        <xsd:simpleType name="Privileges-values"/>
         <xsd:restriction base="xsd:string">
           <xsd:enumeration value="RIGHT_TO_EXPEL_USER"/>
          <xsd:enumeration value="RIGHT_TO_TERMINATE_CONFERENCE"/>
          <xsd:enumeration value="RIGHT_TO_DO_USER_MANAGEMENT"/>
          <xsd:enumeration value="RIGHT_TO_MANIPULATE_MEDIA_POLICY"/>
          <xsd:enumeration value="RIGHT_TO_GIVE_PRIVILEGE"/>
           <xsd:enumeration value="RIGHT_TO_TAKE_PRIVILEGE_AWAY"/>
          <xsd:enumeration value="RIGHT_TO_MANIPULATE_FLOOR_POLICY"/>

        <! Define the privileges as list in order to include many in >
        <! same declaration>
        <xsd:simpleType name="Privilege-type">
          <xsd:list itemType="Privileges-values"/>

        <! Define the list of keywords>
        <xsd:simpleType name="Keyword-type">
          <xsd:list itemType="xsd:string"/>

        <! Define the list of Offsets values>
        <xsd:simpleType name="Offset-type">
          <xsd:list itemType="xsd:nonNegativeInteger"/>

Koskelainen & Khartabil    Expires December 19, 2003           [Page 23]

Internet-Draft                 XCAP CPCP                       June 2003


        <! Define the types of Access modes>
        <xsd:simpleType name="Access-mode">
           <xsd:restriction base="xsd:string">
              <xsd:enumeration value="Allowed"/>
                <xsd:enumeration value="Blocked"/>
              <xsd:enumeration value="Pending"/>

        <xsd:element name="Conference">
                        <xsd:element name="Conference-URI" use="required"/>
                                 <xsd:element name="SIP-URI" type="xsd:anyURI"
                                 <xsd:element name="TEL-URI"
                        <xsd:element ref="Conference-info" use="required"/>
                        <xsd:element ref="Conference-time" use="required"/>
                        <xsd:element ref="ACL" use="required"/>
                        <xsd:element ref="PCL" use="required"/>
                        <xsd:element ref="DL" use="required"/>
                        <xsd:element ref="SC" use="required"/>
                        <xsd:element ref="Conference-floor-policy"
                        <xsd:element ref="Conference-media-policy"

        <xsd:element name="Conference-info">
                        <xsd:element name="Subject" type="xsd:string"/>
                        <xsd:element name="Display-name" type="xsd:string"/>
                        <xsd:element name="Free-text" type="xsd:string"/>
                        <xsd:element name="Keywords" type="Keyword-type"/>
                        <xsd:element name="Host-info">

Koskelainen & Khartabil    Expires December 19, 2003           [Page 24]

Internet-Draft                 XCAP CPCP                       June 2003

                                        <xsd:element name="SIP-URI"
                                                type="xsd:anyURI" use="required"/>
                                        <xsd:element name="TEL-URI"
                                        <xsd:element name="E-mail"
                                        <xsd:element name="Web-page"

        <xsd:element name="Conference-time">
                <xsd:element name="Conference-occurrence"/>
                           <xsd:element name="Start-time"
                           <xsd:element name="Repeat"/>
                                  <xsd:attribute name="Interval"
                                  <xsd:attribute name="Active-duration"
                                  <xsd:attribute name="Offsets"
                           <xsd:element name="Stop-time"

        <! Access Control List (ACL)>
        <xsd:element name="ACL">
                <xsd:element name="ACL-target-URI" type="xsd:anyURI"

Koskelainen & Khartabil    Expires December 19, 2003           [Page 25]

Internet-Draft                 XCAP CPCP                       June 2003

                        use="required" minOccurs="1" maxOccurs="unbounded"/>
                        <xsd:attribute name="Access-type"

        <! Privilege Control List (PCL)>
        <xsd:element name="PCL">
         <xsd:element name="PCL-target" minOccurs="1"
                  <xsd:element name="PCL-target-URI" type="xsd:anyURI"
                  <xsd:element name="Privileges"

        <! Dial-Out List (DL)>
        <xsd:element name="DL">
         <xsd:element name="DL-target" minOccurs="1"
                  <xsd:element name="DL-target-URI"
                        type="xsd:anyURI"  use="required"/>
                  <xsd:element name="Delay"
                        type="xsd:nonNegativeInteger" use="required"/>
                  <xsd:element name="Repetitions"
                        type="xsd:nonNegativeInteger" use="required"/>
                  <xsd:element name="Repetition-interval"
                        type="xsd:nonNegativeInteger" use="required"/>

Koskelainen & Khartabil    Expires December 19, 2003           [Page 26]

Internet-Draft                 XCAP CPCP                       June 2003

        <! Security Control (SC)>
        <xsd:element name="SC">
                  <xsd:element name="Visibility" type="Visibility-type"
                  <xsd:element name="Security-mechanism">
                                <xsd:attribute value="TLS"
                                        type="xsd:boolean" default="false"/>
                                <xsd:attribute value="S-MIME"
                                        type="xsd:boolean" default="false"/>

                  <xsd:element name="SC-target" minOccurs="1"
                            <xsd:element name="SC-target-URI"
                                        type="xsd:anyURI" use="required"/>
                            <xsd:element name="Visibility"
                                        type="Visibility-type" use="required"/>
                            <xsd:element name="Authorization-mechanism">
                                          <xsd:restriction base="xsd:string">
                                                <xsd:enumeration value="Digest"/>
                                                <xsd:enumeration value="None"/>
                                        <xsd:attribute name="Password"

Koskelainen & Khartabil    Expires December 19, 2003           [Page 27]

Internet-Draft                 XCAP CPCP                       June 2003

15. Examples

   The following is an example of a document compliant to the schema:

   Below is an example how to create a conference:

   Example 1. Creating a Conference

   Alice creates a conference as follows:

      PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml HTTP/1.1

      <?xml version="1.0" encoding="UTF-8"?>
         <Conference xmlns="urn:ietf:params:xml:ns:conference-policy">
               <Subject>What's happening tonight</Subject>
               <Display-name>Party Goer's</Display-name>
               <Free-text>John and Peter will join the conference soon</Free-text>
               <Keywords>party nightclub beer</Keywords>
                  <Repeat interval="604800" Active-duration="3600" offsets="0 90000"/>
               <ACL-target-URI Access-type="Allowed">sip:*@example.com</ACL-target-URI>
               <ACL-target-URI Access-type="Blocked">sip:*@*</ACL-target-URI>

Koskelainen & Khartabil    Expires December 19, 2003           [Page 28]

Internet-Draft                 XCAP CPCP                       June 2003

                  <Privileges>RIGHT_TO_EXPEL_USER RIGHT_TO_DO_USER_MANAGEMENT</Privileges>
               <Security-mechanism TLS="false" S-MIME="true"/>
                  <Authorization-mechanism password="1a2b3c4d">Digest<Athorization-mechanism>

   At exactly 2003-06-16T10:00:00Z, the conference server creates a focus and sends
   SIP INVITE requests to Alice and Sarah. After the focus is created, SIP INVITE
   requests can be accepted from anyone at domain example.com. Any attempts to join
   the conference by users in other domains are rejected.

   Example 2. Expelling a User

   Continuing with the above example: aftar the conference has started, Alice decides

Koskelainen & Khartabil    Expires December 19, 2003           [Page 29]

Internet-Draft                 XCAP CPCP                       June 2003

   to expel Bob who has joined the conference. So she adds him to the ACL list with
   Access-type of value "Blocked".

   OPEN ISSUE: Should there be a attribute defining how long someone should be
   expelled for?

   The XCAP request looks like:

      POST http://xcap.example.com/services/conferences/users/Alice/conference.xml?
         Conference/ACL/ACL-target-URI HTTP/1.1

      <ACL-target-URI Access-type="Blocked">sip:bob@example.com</ACL-target-URI>

   At this point, the focus sends a SIP BYE request to Bob ending Bob's participation
   in the conference. This also guarantees that Bob cannot rejoin the conference since
   he is expilictly blocked until his URI is removed from the ACL blocked list.
   Any attempt Bob makes in rejoining the conference will fail.

   Example 3. Allowing An Expelled Participant To Join Again

   Continuing with the example above, Alice now decides to allow Bob to join again
   after a period of time. She does so by removing his entry in the ACL that identifies
   him as "Blocked

      DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml?
         Conference/ACL/ACL-target-URI/ACL-target-URI="sip:bob@example.com" HTTP/1.1

   Bob can now rejoin the conference by sending a SIP INVITE request.

   Example 4. Removing A Conference

   Alice now decides she no longer wants this conference to exist and therefore
   deletes the conference:

      DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml

   As a result of this action, the focus sends SIP BYE requests to all current
   participants in the conference. The conference server terminates the focus

Koskelainen & Khartabil    Expires December 19, 2003           [Page 30]

Internet-Draft                 XCAP CPCP                       June 2003

16. Security Considerations

   See section Section 11.5.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 31]

Internet-Draft                 XCAP CPCP                       June 2003

17. IANA Considerations

17.1 XCAP Application Usage ID

   This section registers a new XCAP Application Usage ID (AUID)
   according to the IANA procedures defined in..

   Name of the AUID: conference-policy
   Description: Conference policy application manipulates conference
   policy at a server.

17.2 application/conference-policy+xml mime TYPE

   MIME media type: application

   MIME subtype name: conference-policy+xml

   Mandatory parameters: none

   Optional parameters: Same as charset parameter applicatioN/xml as
   specified in RFC 3023 [6].

   Encoding considerations: Same as encoding considerations of
   application/xml as specified in RFC 3023 [6].

   Security considerations: See section 10 of RFC 3023 [6] and section
   Section 17 of this document.

   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type has been
   used to support conference policy manipulation for SIP based

   Additional information:

   Magic number: None

   File extension: .cl or .xml

   Macintosh file type code: "TEXT"

   Personal and email address for further information: Petri Koskelainen

Koskelainen & Khartabil    Expires December 19, 2003           [Page 32]

Internet-Draft                 XCAP CPCP                       June 2003

   Intended Usage: COMMON

   Author/change controller: The IETF

17.3 URN Sub-Namespace Registration for

   This section registers a new XML namespace, as per guidelines in URN
   document [11].

   URI: The URI for this namespace is

   Registrant Contact: IETF, XCON working group, Petri Koskelainen


   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
   <html xmlns="http://www.w3.org/1999/xhtml">
    <meta http-equiv="content-type"
    <title>Conference Policy Namespace</title>
     <h1>Namespace for Conference Policy</h1>
     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>

Koskelainen & Khartabil    Expires December 19, 2003           [Page 33]

Internet-Draft                 XCAP CPCP                       June 2003

18. Contributors

   Jose Costa-Requana
   Simo Veikkolainen
   Teemu Jalava

Koskelainen & Khartabil    Expires December 19, 2003           [Page 34]

Internet-Draft                 XCAP CPCP                       June 2003

19. Acknowledgements

   The authors would like to thank Markus Isom„ki and IETF conferencing
   design team for their feedback.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 35]

Internet-Draft                 XCAP CPCP                       June 2003

Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCD 14, March 1997.

   [2]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [3]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [4]   Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC
         3261, June 2002.

   [5]   Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         REC REC-xml-20001006, October 2000.

   [6]   Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC
         3023, January 2001.

   [7]   Koskelainen, P., "Requirements for conference policy control
         protocol", draft-koskelainen-xcon-cpcp-req-00 (work in
         progress), June 2003.

   [8]   Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",
         draft-rosenberg-simple-xcap-00 (work in progress), May 2003.

   [9]   Rosenberg, J., "An Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP) Usage for Presence Lists",
         draft-draft-rosenberg-simple-xcap-list-usage-00 (work in
         progress), May 2003.

   [10]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-rosenberg-sipping-conferencing-framework-01 (work in
         progress), February 2003.

   [11]  Mealling, M., "Forward Error Correction (FEC) Building Block",
         draft-mealling-iana-xmlns-registry-04 (work in progress), July

Koskelainen & Khartabil    Expires December 19, 2003           [Page 36]

Internet-Draft                 XCAP CPCP                       June 2003

Authors' Addresses

   Petri Koskelainen
   P.O. Box 100 (Visiokatu 1)
   Tampere  FIN-33721

   EMail: petri.koskelainen@nokia.com

   Hisham Khartabil
   P.O. Box 321
   Helsinki  FIN-00045

   EMail: hisham.khartabil@nokia.com

Koskelainen & Khartabil    Expires December 19, 2003           [Page 37]

Internet-Draft                 XCAP CPCP                       June 2003

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

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 Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

Koskelainen & Khartabil    Expires December 19, 2003           [Page 38]

Internet-Draft                 XCAP CPCP                       June 2003



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Koskelainen & Khartabil    Expires December 19, 2003           [Page 39]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/