XCON                                                        H. Khartabil
Internet-Draft                                            P. Koskelainen
Expires: October 18, 2004                                          Nokia
                                                          April 19, 2004



             The Conference Policy Control Protocol (CPCP)
                        draft-ietf-xcon-cpcp-00


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://
   www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on October 18, 2004.


Copyright Notice


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


Abstract


   This document describes the Conference Policy Control Protocol
   (CPCP). It specifies an Extensible Markup Language (XML) Schema that
   enumerates the conference policy data elements that enable a user to
   define a conference policy. It also defines an XML Configuration
   Access Protocol (XCAP) application usage that is needed to store and
   manipulate a conference policy.










Khartabil & Koskelainen    Expires October 18, 2004             [Page 1]
Internet-Draft                    CPCP                        April 2004



Table of Contents


   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
   2.     Conventions Used in This Document  . . . . . . . . . . . .   3
   3.     Terminology  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.     Structure of a Conference Policy document  . . . . . . . .   4
   4.1    MIME Type for CPCP XML Document  . . . . . . . . . . . . .   6
   4.2    XML Document Description . . . . . . . . . . . . . . . . .   6
   4.2.1  <Conference-settings> element  . . . . . . . . . . . . . .   6
   4.2.2  <Conference-info> element  . . . . . . . . . . . . . . . .   6
   4.2.3  <Conference-time> element  . . . . . . . . . . . . . . . .   7
   4.2.4  <ACL> (Access Control List) element  . . . . . . . . . . .   8
   4.2.5  <PCL> (Privilege Control List) element . . . . . . . . . .   9
   4.2.6  <DL> (Dial-Out List) element . . . . . . . . . . . . . . .  10
   4.2.7  <SC> (Security Control) element  . . . . . . . . . . . . .  10
   4.2.8  <Conference-floor-policy> element  . . . . . . . . . . . .  11
   4.2.9  <Conference-media-Policy> element  . . . . . . . . . . . .  12
   4.3    XML Schema . . . . . . . . . . . . . . . . . . . . . . . .  12
   5.     Floor Control Policy vs. Floor Control Protocol  . . . . .  19
   6.     An XCAP Usage for Conference Policy Manipulation . . . . .  19
   6.1    Application Unique ID  . . . . . . . . . . . . . . . . . .  19
   6.2    Resource Interdependencies . . . . . . . . . . . . . . . .  19
   6.3    Additional Constraints . . . . . . . . . . . . . . . . . .  20
   6.4    Naming Conventions . . . . . . . . . . . . . . . . . . . .  20
   6.5    Authorization Policies . . . . . . . . . . . . . . . . . .  20
   6.6    MIME Type for CPCP XML Document  . . . . . . . . . . . . .  20
   6.7    Overview of Operation  . . . . . . . . . . . . . . . . . .  20
   6.8    Communication Between Conference Entities  . . . . . . . .  21
   6.9    Conference Creation and Termination  . . . . . . . . . . .  21
   6.10   Manipulating the Participant Lists . . . . . . . . . . . .  21
   6.10.1 Expelling a Participant  . . . . . . . . . . . . . . . . .  22
   6.11   Privileges: Who can modify the conference policy . . . . .  22
   6.12   Conference URI(s)  . . . . . . . . . . . . . . . . . . . .  23
   7.     Examples . . . . . . . . . . . . . . . . . . . . . . . . .  23
   8.     Security Considerations  . . . . . . . . . . . . . . . . .  26
   9.     IANA Considerations  . . . . . . . . . . . . . . . . . . .  26
   9.1    XCAP Application Usage ID  . . . . . . . . . . . . . . . .  26
   9.2    application/conference-policy+xml mime TYPE  . . . . . . .  26
   9.3    URN Sub-Namespace Registration for
          urn:ietf:params:xml:ns:conference-policy . . . . . . . . .  27
   10.    Contributors . . . . . . . . . . . . . . . . . . . . . . .  28
   11.    Acknowledgements . . . . . . . . . . . . . . . . . . . . .  28
          Normative References . . . . . . . . . . . . . . . . . . .  28
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  29
          Intellectual Property and Copyright Statements . . . . . .  31







Khartabil & Koskelainen    Expires October 18, 2004             [Page 2]
Internet-Draft                    CPCP                        April 2004



1. Introduction


   SIP conferencing framework [11] defines the mechanisms for
   multi-party centralized conferencing in a SIP environment. Existing
   SIP mechanisms allow users, for example, to join and leave a
   conference. A centralized serve, called focus, can expel and invite
   users, and may have proprietary access control lists and user
   privilege definitions. However, in many cases it is useful to have a
   standardised conference policy elements such as access control lists
   and a standardised protocol means to manipulate them. The
   requirements for such protocol are defined in [7]. This document
   provides an XML Schema Section 4.3 that enumerates the conference
   policy data elements that enable a user to define a conference
   policy. It also defines an XML Configuration Access Protocol (XCAP)
   [8] application usage that is needed to store and manipulate a
   conference policy.


   Other mechanisms, such as web page or voice response system can also
   be used to manipulate conference policy data.


   XCAP has many advantages in its use for conference policy control
   protocol. It is a HTTP 1.1 based protocol that allows clients to
   read, write, modify and delete application data stored in XML format
   at a server. XCAP maps XML document elements and attributes to HTTP
   URIs that can be directly accessed by HTTP. One application area
   which has already adopted XCAP is the manipulation of event lists
   [9].


2. Conventions Used in 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.


3. Terminology


   This document uses terminology from [11]. Some additional definitions
   are introduced here.


      ACL


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


      CPS


         Conference Policy Server. See [11]




Khartabil & Koskelainen    Expires October 18, 2004             [Page 3]
Internet-Draft                    CPCP                        April 2004



      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.


      PCL


         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.


      Privileged user


         In this document, a privileged user is the creator. Defining
         privileges to modify certain parts of a conference policy is
         outside the scope of this document.


      CPS XCAP URI


         The URI of the XCAP server that is used to create the
         conference. The URI contsruction is specified in [8]. It is
         refered to in XCAP as the host part.


      Conference Policy URI


         The URI of conference policy. In XCAP, it is the CPS XCAP URI
         along with the abs_path. It identifies the XML document. The
         URI contsruction is specified in [8].



4. Structure of a Conference Policy document


   The conference policy document is an XML [5] document that MUST be
   well-formed and MUST 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




Khartabil & Koskelainen    Expires October 18, 2004             [Page 4]
Internet-Draft                    CPCP                        April 2004



   defined by this specification is a URN [2], using the namespace
   identifier 'ietf' defined by [3] and extended by [13]. This URN is:


   urn:ietf:params:xml:ns:conference-policy


   A conference policy document begins with the root element tag
   "conference-policy". Other elements from different namespaces MAY be
   present for the purposes of extensibility. Elements or attributes
   from unknown namespaces MUST be ignored. The conference policy is
   build up using multiple namespaces:


   o  "urn:ietf:params:xml:ns:conference-settings": This namespace
      defines elements for conference setting. The inclusion of this
      namespace is optional. It contains the mandatory element
      <Conference-settings>. This element contains the conference URI(s)
      and maximum number of participants. It can occur only once in the
      document.


   o  "urn:ietf:params:xml:ns:conference-info": This namespace defines
      elements to carry conference information. The inclusion of this
      namespace is optional. It contains the mandatory element
      <Conference-info>. This element includes informational describing
      the conference, e.g. for search purposes. This information can
      also be used in the session description when the focus is sending
      invitations. It can occur only once in the document.


   o  "urn:ietf:params:xml:ns:conference-time": This optional namespace
      defines conference time information. It defines the mandatory
      <Conference-time> element that includes elements defining start
      and stop times for a conference.


   o  "urn:ietf:params:xml:ns:conference-acl": This optional namespace
      is for the access control list. It defines the mandatory <ACL>
      element that contains URIs for users who can dial into the
      conference, users who are blocked from dialling in, and expelled
      users.


   o  "urn:ietf:params:xml:ns:conference-pcl": This optional namespace
      is for the privilege control list. It defines the mandatory <PCL>
      element that contains privileges and URIs for users who have those
      privileges.


   o  "urn:ietf:params:xml:ns:conference-dl": This optional namespace is
      for the dial-out list. It defines the mandatory <DL> element that
      contains URIs for users that the focus will invite to the
      conference.


   o  "urn:ietf:params:xml:ns:conference-sc": This optional namespace is




Khartabil & Koskelainen    Expires October 18, 2004             [Page 5]
Internet-Draft                    CPCP                        April 2004



      for security control. It defines the <SC> element that contains
      conference security level and passwords.


   o  "urn:ietf:params:xml:ns:conference-mp": This optional namespace is
      for the media policy for a conference. It defines the
      <Conference-media-policy> element that contains the media types to
      be used in the conference.


   o  "urn:ietf:params:xml:ns:conference-fp": This optional namespace is
      for the floor control policy. It defines the
      <Conference-floor-policy> element.


   The elements are described in more detail in the forthcoming
   sections.


4.1 MIME Type for CPCP XML Document


   The MIME type for the CPCP XML document is "application/
   conference-policy+xml".


4.2 XML Document Description


4.2.1 <Conference-settings> element


   The mandatory <Conference-settings> element contains 2 sub-elements;
   the <Conference-URI> element and the <Max-participant-count> element.


   <Conference-URI> is an optional element. It can occur more than once
   to accommodate multiple signaling protocols. Once a conference URI is
   set, it MUST         NOT be changed or removed for the duration of the
   conference. Only one URI per protocol MUST be set. URIs can be added
   at any time.


   This is in its own XML namespace, so it is separated from other
   elements and hence relevant modification rights (privileges) can be
   given more easily to other   namespaces.


   <Max-participant-count> is an optional. It carries the maximum number
   of participants allowed in the conference. When the maximum number of
   participants         threshold is reached, no new users are not allowed to
   join until the number of participants decreases again. If using SIP,
   the server can reject a request to join      (INVITE) with a "480
   Temporarily Unavailable" response. Alternatively, the sever may
   implement a waiting queue.


4.2.2 <Conference-info> element


   Mandatory <Conference-info> element has its own namespace and it can




Khartabil & Koskelainen    Expires October 18, 2004             [Page 6]
Internet-Draft                    CPCP                        April 2004



   occur only once in a document. It includes informative conference
   parameters which may be helpful describing the purpose of a
   conference, e.g. for search purposes or for providing host contact
   information. The <Conference-info element MUST have a special
   attribute 'xml:lang' to specify the language used in the contents of
   this element as defined Section 2.12 of [5].


   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 potential conference participants by means
   outside the scope of this document. Examples of usage could be
   searching for a conference based on some keywords. The optional
   <Web-page> element points to a URI where additional information about
   the conference can be found.


   The optional <Host-info> element contains several elements. It gives
   additional information about the user hosting the conference. This
   information can, for example, be included into the SDP fields of the
   SIP INVITEs sent by the focus. The <URI> element is optional and can
   occur more than once.


4.2.3 <Conference-time> element


   The information related to conference time and lifetime is contained
   in the <Conference-time> element. The conference may occur for a
   limited period of time (i.e. bounded), or the conference may be
   unbounded (i.e. it does not have a specified end time). Bounded
   conferences may occur multiple times(e.g. on weekly basis).


   <Conference-Time> has its own XML namespace. It contains one or more
   <Conference-occurrence> elements 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> element specifies when a
   conference starts. the <Stop-time> element specifies the time a
   conference stops. If the <Start-time> element is not present, it
   indicates that the conference starts immediately. If the <Stop-time>
   is set to zero, then conference occurrence is not bounded, i.e.
   permanent, though it will not become active until the <Start-time>.
   If the <Stop-time> element is not present, it indicates that the




Khartabil & Koskelainen    Expires October 18, 2004             [Page 7]
Internet-Draft                    CPCP                        April 2004



   conference terminates as soon as the last participant leaves the
   conference. The focus might wait a small period of time before
   terminating the conference, in case a participant joins straight
   after the last participant leaves.


   When saying that a conference starts, or becomes active (start-time),
   it means that the mixing starts.  A focus will most likely allow
   participants to connect shortly before start time, but may put them
   on hold until the start time. Participants on the Dial out list may
   also be dialled to shortly before start time.


   A conference terminates with stop-time. The creator is free to set
   the stop-time to be the time s/he leaves (and therefore the
   conference terminates when s/he leaves), terminate the conference as
   s/he leaves (modifying stop-time), or leave before the stop-time and
   therefore the conference continues. The stop-time can be changed by
   the conference creator, during the conference, to allow the extension
   of the conference based on best effort. A conference always
   terminates when the conference policy is removed, regardless of the
   stop time.


   The absence of this conference time information indicates that a
   conference starts immediately and terminates when the conference
   policy is removed. See Section 6.9 for more details


4.2.4 <ACL> (Access Control List) element


   ACL has its own XML namespace.


   The purpose of Access Control List (ACL) is to control who can join
   the conference.A conference has one <ACL> consisting of one or more
   <ACL-target-URI> elements and the <Access-type> parameter for those
   URIs. Access-Types are one of Allowed/Blocked/Pending/Expelled.
   Allowed means that the       target is allowed to join the conference.
   Blocked means that the target is not allowed to join the conference.
   This can be used in the where the allowed URIs are wild-carded and
   the user wants to explicitly block one potential participant, whose
   URI falls within the wildcarded URIs, from joining. The other way
   around is also possible where the blocked URIs are wildcarded and
   the user wants to explicitly allow one potential participant, whose
   URI falls within the wildcarded URIs, to join. Pending means that
   authorisation for the target is not granted and while further
   processing is required - such as consulting the moderator. Expelled
   means        that user is expelled from current conference and is not
   allowed to join or be dialled-out (even if dial-out list includes
   user's URI).


   Wildcards are allowed in ACL as follows. The domain part is allowed




Khartabil & Koskelainen    Expires October 18, 2004             [Page 8]
Internet-Draft                    CPCP                        April 2004



   to be wildcard only if the username is a wildcard. Wildcard in the
   domain part MUST be immediately after the @-sign. A wildcard in the
   domain is interpreted as multiple zones. For example:
   sip:*@*.example.com includes sip:*@engineering.example.com as well as
   sip:*@tester.engineering.example.com. The use of wildcarding has been
   restricted to avoid ambiguous entries in the access control list.


   Examples of allowed wildcards are -  sip:*@example.com, *@*.com, *@*.


   Examples are not allowed wildcards are -  sip:bob@example.*,
   sip:bob@*.com, sip:*@example.*.com.


   "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
   utilized.


   There is a need for the ACL to contain an entry that defines the
   default access types for users not explicitly allowed nor blocked
   from joining the conference, i.e. everybody else. For example:
   "Pending" action for *@*. If that entry is missing, the focus local
   policy dictates the behaviour.


   Sip: and sips: schemes are treated as equivalent in the ACL since it
   defines users and not the security used by users.


   It is also possible to ask the focus to refer users to the
   conference. An optional Boolean attribute "refer" exists in the
   <ACL-target-URI> that indicates to the server that the creator of the
   conference wishes for the focus to refer the identified potential
   participants to the conference when a conference occurrence has
   started.  In SIP, this is achieved by the focus sending a REFER
   request to those potential participants. The default value for the
   "refer" attribute is "false".


4.2.5 <PCL> (Privilege Control List) element


   Advanced privilege models can be applied in conferencing context
   (e.g. who is allowed to modify ACL, who is allowed to expel users
   etc). This document defines only one privilege and leaves the
   definition of additional privileges (e.g. who can modify ACL) as a
   separate standardisation effort.


   The <PCL> element is mandatory and has its own XML namespace. It
   defines which users has what privileges. The <PCL> element may
   contain one or more <PCL-target> elements. The <PCL-target> element
   carries 2 pieces of information: the target URI, <PCL-target-URI> and
   the privileges for that URI, <Privileges>. All mandatory elements.




Khartabil & Koskelainen    Expires October 18, 2004             [Page 9]
Internet-Draft                    CPCP                        April 2004



   The target URI can be wildcarded as described for the ACL in Section
   4.2.4.


   Example URIs are:


      sip:bob@company.com


      sip:*@example.com


   The only privilege defined in this document is
   RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE. It defines which users are
   allowed to   subscribe to the conference state event package [12]and
   be notified.


4.2.6 <DL> (Dial-Out List) element


   The dial-out list (DL)  is a list of user URIs that the focus uses to
   learn who to invite to join a conference. This list can be updated
   during the conference lifetime so it can be used for mid-conference
   invites (and mass-invites) as well.


   DL has its own XML namespace.


   The <DL> element includes a mandatory <DL-target> element. The
   <DL-target> element includes the mandatory <DL-target-URI> element.
   This elements carries the URI of the user to be invited.


4.2.7 <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.


   This element has its own XML namespace.


   The conference security settings start with the mandatory >SC>
   element. It contains the mandatory <Visibility> element. This element
   can hold one of      two values: visible or invisible. The <Visibility>
   element controls whether information in the <Conference-URI>,
   <Conference-time> and <Conference-info> elements may be made
   available publicly. For example, an application at a conference
   server might list the ongoing conferences on web page, or it may
   allow searching for conferences based on the keywords listed in the
   <Conference-info> element. Setting <Visibility> to "invisible"
   instructs the application not to reveal any such information.
   However, information in other elements, such as <ACL>, should not be
   seen by anyone else other than a privileged user, even with the
   <Visibility> element set to "visible".




Khartabil & Koskelainen    Expires October 18, 2004            [Page 10]
Internet-Draft                    CPCP                        April 2004



   We define two mechanisms for securing the signaling between users and
   the focus: 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.


   The <Security-mechanism>element inside the <SC> element has 2 boolean
   parameter: TLS and S/MIME. When in TLS parameter is set to "true"
   (thus implying the use of SIPS URI scheme, if SIP is used as the
   signaling protocol), 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
   by the conference policy, but it is required that the message bodies
   within SIP are encrypted, the S/MIME attribute must have a value
   "true".


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


   The conference creator can define an authentication policy for the
   participants. This is done with the optional <SC-target> element.


   If the <SC-target> element is present, then at least one
   <SC-target-URI> inside the <SC-target> element must be present, each
   identifies a user or a set of users for which the authentication
   mechanism apply. The target URI can be wildcarded as described for
   the ACL in Section 4.2.4.


   The authentication policy defined in the optional
   <Authorization-mechanism> element defines how the participants should
   be authenticated. Two authentication mechanisms are defined in this
   document: Digest and Digest-AKA. The authentication policy can also
   be set to none. 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".


4.2.8 <Conference-floor-policy> element


   This element has its own XML namespace. The absence of this namespace
   and its elements from an XML document indicates that the conference
   does not have a floor.


   The <Conference-floor-policy> is mandatory and contains the required




Khartabil & Koskelainen    Expires October 18, 2004            [Page 11]
Internet-Draft                    CPCP                        April 2004



   boolean attribute that indicates if the floor is moderator controlled
   or not. One or more <Floor> elements can appear in the
   <Conference-floor-policy> element. The number of those elements
   indicates how many floors the conference can         have. A floor can be
   used for one or more media types; the mandatory <Media-types> element
   can contain zero or more of the <Video>, <Audio>, <Application>,
   <Data> ,<Control>, <Message>, and <text> elements indicating the
   media of the floor. One type of media can only appear        once. Other
   media types can be defined by extensions.


   A floor can be controlled using many algorithms; the mandatory
   <Algorithm> element MUST contain one and only of the
   <Moderator-controlled>, <FCFS>, and <Random> elements indicating the
   algorithm.


   The <Max-floor-users> element in the <Floor> element is optional and,
   if present, dictates the maximum number of users who can have the
   floor at one time. The optional <Moderator-URI> indicates the URI of
   the moderator. It MUST be set if the attribute moderator-controlled
   is set to "true".


4.2.9 <Conference-media-Policy> element


   Media policy is an integral part of the conference policy. It defines
   e.g. what kind of media topologies exist in the conference. This
   document defines a very basic media policy that states the media
   types a conference has. This is used by the focus to know what media
   types to invite users with and what media types it should accept from
   dialling in users. The details of media manipulation are defined
   elsewhere. User with sufficient privileges is allowed to create,
   modify and delete the media policy (e.g. add new media types).


   This element has its own XML namespace.


   The definition starts with the mandatory <Conference-media-policy>
   element. This element contains a mandatory <Media-types> element that
   lists the media types allowed for this conference. The format of this
   mirrors that of the same element in floor policy.


4.3 XML Schema





   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                        targetNamespace="urn:ietf:params:xml:ns:conference-policy"
                        xmlns:conference-mp="urn:ietf:params:xml:ns:conference-mp"




Khartabil & Koskelainen    Expires October 18, 2004            [Page 12]
Internet-Draft                    CPCP                        April 2004



                        xmlns:conference-fp="urn:ietf:params:xml:ns:conference-fp"
                        xmlns:conference-sc="urn:ietf:params:xml:ns:conference-sc"
                        xmlns:conference-dl="urn:ietf:params:xml:ns:conference-dl"
                        xmlns:conference-pcl="urn:ietf:params:xml:ns:conference-pcl"
                        xmlns:conference-acl="urn:ietf:params:xml:ns:conference-acl"
                        xmlns:conference-time="urn:ietf:params:xml:ns:conference-time"
                         xmlns:conference-info="urn:ietf:params:xml:ns:conference-info"
                         xmlns:conference-settings="urn:ietf:params:xml:ns:conference-settings"
                         elementFormDefault="qualified">
        <xs:import namespace="urn:ietf:params:xml:ns:conference-settings" schemaLocation="conference-settings.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-info" schemaLocation="conference-info.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-time" schemaLocation="conference-time.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-acl" schemaLocation="conference-acl.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-pcl" schemaLocation="conference-pcl.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-dl" schemaLocation="conference-dl.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-sc" schemaLocation="conference-sc.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-fp" schemaLocation="conference-fp.xsd"/>
        <xs:import namespace="urn:ietf:params:xml:ns:conference-mp" schemaLocation="conference-mp.xsd"/>
        <xs:element name="Conference">
                <xs:complexType>
                        <xs:sequence>
                                <xs:element name="Conference-Settings" type="conference-settings:conference-settings"/>
                                <xs:element name="Conference-Info" type="conference-info:Conference-Info"/>
                                <xs:element name="Conference-Time" type="conference-time:Conference-Time"/>
                                <xs:element name="ACL" type="conference-acl:Conference-ACL"/>
                                <xs:element name="PCL" type="conference-pcl:Conference-PCL"/>
                                <xs:element name="DL" type="conference-dl:Conference-DL"/>
                                <xs:element name="SC" type="conference-sc:Conference-SC"/>
                                <xs:element name="Conference-floor-policy" type="conference-fp:Conference-Floor-Policy"/>
                                <xs:element name="Conference-media-policy" type="conference-mp:Conference-Media-Policy"/>
                        </xs:sequence>
                </xs:complexType>
        </xs:element>
   </xs:schema>



   <!-- Conference settings -->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-settings"
                         xmlns="urn:ietf:params:xml:ns:conference-settings"
                         xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:complexType name="Conference-settings">
                <xs:sequence>
                        <xs:element name="Conference-uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="Max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/>
                </xs:sequence>
        </xs:complexType>




Khartabil & Koskelainen    Expires October 18, 2004            [Page 13]
Internet-Draft                    CPCP                        April 2004



   </xs:schema>



   <!-- Conference Info -->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-info"
                        xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">


             <!-- This import brings in the XML language attribute xml:lang-->
        <xs:import namespace="http://www.w3.org/XML/1998/namespace"
          schemaLocation="http://www.w3.org/2001/xml.xsd"/>


        <xs:complexType name="Conference-info">
                <xs:sequence>
                        <xs:element name="Subject" type="xs:string" minOccurs="0"/>
                        <xs:element name="Display-name" type="xs:string" minOccurs="0"/>
                        <xs:element name="Free-text" type="xs:string" minOccurs="0"/>
                        <xs:element name="Keywords" minOccurs="0">
                                <xs:simpleType>
                                        <xs:list itemType="xs:string"/>
                                </xs:simpleType>
                        </xs:element>
                        <xs:element name="Web-page" type="xs:anyURI" minOccurs="0"/>
                        <xs:element name="Host-info" minOccurs="0">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="URI" type="xs:anyURI" minOccurs="0"/>
                                                <xs:element name="E-mail" type="xs:anyURI" minOccurs="0"/>
                                                <xs:element name="Web-page" type="xs:anyURI" minOccurs="0"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
                <xs:attribute ref="xml:lang"/>
        </xs:complexType>
   </xs:schema>



   <!-- Conference time -->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-time"
                        xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:complexType name="Conference-Time">
                <xs:sequence>
                        <xs:element name="Conference-occurrence" minOccurs="0" maxOccurs="unbounded">
                                <xs:complexType>




Khartabil & Koskelainen    Expires October 18, 2004            [Page 14]
Internet-Draft                    CPCP                        April 2004



                                        <xs:sequence>
                                                <xs:element name="Start-time" type="xs:dateTime" minOccurs="0"/>
                                                <xs:element name="Stop-time" type="xs:dateTime" minOccurs="0"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>



   <!-- Access Control List ACL -->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-acl"
                        xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:complexType name="Conference-ACL">
                <xs:sequence>
                        <xs:element name="ACL-target-URI" maxOccurs="unbounded">
                                <xs:complexType>
                                        <xs:simpleContent>
                                                <xs:extension base="xs:anyURI">
                                                        <xs:attribute name="Refer" type="xs:boolean" default="false"/>
                                                        <xs:attribute name="Access-type" use="required">
                                                                <xs:simpleType>
                                                                        <xs:restriction base="xs:string">
                                                                                <xs:enumeration value="Allowed"/>
                                                                                <xs:enumeration value="Blocked"/>
                                                                                <xs:enumeration value="Pending"/>
                                                                                <xs:enumeration value="Expelled"/>
                                                                        </xs:restriction>
                                                                </xs:simpleType>
                                                        </xs:attribute>
                                                </xs:extension>
                                        </xs:simpleContent>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>



   <!-- Privilege Control List (PCL) -->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
               targetNamespace="urn:ietf:params:xml:ns:conference-pcl"
               elementFormDefault="qualified">




Khartabil & Koskelainen    Expires October 18, 2004            [Page 15]
Internet-Draft                    CPCP                        April 2004



   <xs:complexType name="Conference-PCL">
   <xs:sequence>
        <xs:element name="PCL-target" minOccurs="1" maxOccurs="unbounded">
                <xs:complexType>
                <xs:sequence>
                        <xs:element name="PCL-target-uri" type="xs:anyURI" minOccurs="1"/>
                        <xs:element name="Privileges">
                                <xs:simpleType>
                                <xs:list>
                                <!-- Define the privileges as data type with all possible values -->
                                <xs:simpleType>
                                        <xs:restriction base="xs:string">
                                        <xs:enumeration value="RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE"/>
                                        </xs:restriction>
                                </xs:simpleType>
                                </xs:list>
                                </xs:simpleType>
                        </xs:element>
                </xs:sequence>
                </xs:complexType>
        </xs:element>
   </xs:sequence>
   </xs:complexType>
   </xs:schema>



   <!-- Dial-Out List (DL) -->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-dl"
                        xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:complexType name="Conference-DL">
                <xs:sequence>
                        <xs:element name="DL-target" maxOccurs="unbounded">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="DL-target-URI" type="xs:anyURI"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>



   <!-- Security Control (SC) -->


   <?xml version="1.0" encoding="UTF-8"?>




Khartabil & Koskelainen    Expires October 18, 2004            [Page 16]
Internet-Draft                    CPCP                        April 2004



   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-sc" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:complexType name="Conference-SC">
                <xs:sequence>
                        <xs:element name="Visibility">
                                <xs:simpleType>
                                        <xs:restriction base="xs:string">
                                                <xs:enumeration value="visible"/>
                                                <xs:enumeration value="invisible"/>
                                        </xs:restriction>
                                </xs:simpleType>
                        </xs:element>
                        <xs:element name="Security-mechanism">
                                <xs:complexType>
                                        <xs:attribute name="TLS" type="xs:boolean" default="false"/>
                                        <xs:attribute name="S-MIME" type="xs:boolean" default="false"/>
                                </xs:complexType>
                        </xs:element>
                        <xs:element name="SC-target" minOccurs="0" maxOccurs="unbounded">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="SC-target-URI" type="xs:anyURI"/>
                                                <xs:element name="Authorization-mechanism">
                                                        <xs:simpleType>
                                                                <xs:restriction base="xs:string">
                                                                        <xs:enumeration value="Digest"/>
                                                                        <xs:enumeration value="Digest-AKA"/>
                                                                        <xs:enumeration value="None"/>
                                                                </xs:restriction>
                                                        </xs:simpleType>
                                                </xs:element>
                                        </xs:sequence>
                                        <xs:attribute name="Password" type="xs:string"/>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>


   <!-- Floor policy  -->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-fp" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:complexType name="Conference-floor-policy">
                <xs:sequence>
                        <xs:element name="Floor" maxOccurs="unbounded">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="Media-types">




Khartabil & Koskelainen    Expires October 18, 2004            [Page 17]
Internet-Draft                    CPCP                        April 2004



                                                        <xs:complexType>
                                                                <xs:sequence>
                                                                        <xs:element name="Video" minOccurs="0"/>
                                                                        <xs:element name="Audio" minOccurs="0"/>
                                                                        <xs:element name="Application" minOccurs="0"/>
                                                                        <xs:element name="Data" minOccurs="0"/>
                                                                        <xs:element name="Control" minOccurs="0"/>
                                                                        <xs:element name="Message" minOccurs="0"/>
                                                                        <xs:element name="Text" minOccurs="0"/>
                                                                        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                                                                </xs:sequence>
                                                        </xs:complexType>
                                                </xs:element>
                                                <xs:element name="Algorithm">
                                                        <xs:complexType>
                                                                <xs:sequence>
                                                                        <xs:element name="Moderator-controlled" minOccurs="0"/>
                                                                        <xs:element name="FCFS" minOccurs="0"/>
                                                                        <xs:element name="Random" minOccurs="0"/>
                                                                        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                                                                </xs:sequence>
                                                        </xs:complexType>
                                                </xs:element>
                                                <xs:element name="Max-floor-users" type="xs:nonNegativeInteger" minOccurs="0"/>
                                                <xs:element name="Moderator-URI" type="xs:anyURI" minOccurs="0"/>
                                        </xs:sequence>
                                        <xs:attribute name="moderator-controlled" type="xs:boolean" default="false"/>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>


   <!-- Media policy-->


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-mp" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <xs:element name="Conference-Media-Policy">
                <xs:complexType>
                        <xs:sequence>
                                <xs:element name="Media-types">
                                        <xs:complexType>
                                                <xs:sequence>
                                                        <xs:element name="Video" minOccurs="0"/>
                                                        <xs:element name="Audio" minOccurs="0"/>
                                                        <xs:element name="Application" minOccurs="0"/>
                                                        <xs:element name="Data" minOccurs="0"/>
                                                        <xs:element name="Control" minOccurs="0"/>




Khartabil & Koskelainen    Expires October 18, 2004            [Page 18]
Internet-Draft                    CPCP                        April 2004



                                                        <xs:element name="Message" minOccurs="0"/>
                                                        <xs:element name="Text" minOccurs="0"/>
                                                        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                                                </xs:sequence>
                                        </xs:complexType>
                                </xs:element>
                        </xs:sequence>
                </xs:complexType>
        </xs:element>
   </xs:schema>





5. Floor Control Policy vs. Floor Control Protocol


   Conference floor control is an optional feature provided by a
   separate floor control protocol (FCP). However, creating a floor and
   defining a floor policy belongs to CPCP. Moreover, setting some key
   floor parameters, such as floor moderator in moderator controlled
   floor policy, belongs to CPCP. FCP only defines how to request,
   grant, deny and revoke a floor within given floor policy.


   For example, in a typical conference the privileged conference user
   (creator) uses CPCP for creating a floor for audio plane, defining
   the floor policy as "moderator-controlled" and appointing one user -
   possibly himself -  to act as a floor moderator governing the access
   to the floor.


   When the floor has been created and possible floor moderator has been
   assigned, the floor moderator gets notifications from the focus and
   is able to accept or deny floor requests from the conference users.
   Note that FCP does not create media streams (just the virtual floor
   attached to media), as media streams are created using CPCP. The
   details of FCP are beyond the scope of this draft.


6. An XCAP Usage for Conference Policy Manipulation


6.1 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 9.


6.2 Resource Interdependencies


   The conference policy server must fill the conference URI(s), if a




Khartabil & Koskelainen    Expires October 18, 2004            [Page 19]
Internet-Draft                    CPCP                        April 2004



   conference URI was not proposed by the client. The client then needs
   to perform a HTTP GET to     retrieve the modified policy containing the
   assigned conference URI(s). The CPS MAY assign multiple conference
   URIs to a conference, one for each call signaling    protocol that it
   supports. Section 6.12 and Section 4.2.1 discuss this is more detail.


6.3 Additional Constraints


   These are defined within the XML structure definition.


6.4 Naming Conventions


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


6.5 Authorization Policies


   This application usage does not modify the default XCAP authorization
   policy, which is that only a user can read, write or modify their own
   documents. A server  can allow privileged users to modify documents
   that they don't own, but the establishment and indication of such
   policies is outside the scope of this document. It   is anticipated
   that a future application usage will define which users are allowed
   to modify a list resource.


6.6 MIME Type for CPCP XML Document


   The MIME type for the CPCP XML document is defined in Section 4.1


6.7 Overview of Operation


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


   CPCP is implemented as an XCAP application usage  [8].


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


   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, if user A        wants to expel user B




Khartabil & Koskelainen    Expires October 18, 2004            [Page 20]
Internet-Draft                    CPCP                        April 2004



   from an ongoing conference, user A must first manipulate the
   conference policy data. CPS then communicates that change to the
   focus to     perform the operation.


6.8 Communication Between Conference Entities


   The communication between different (logical) conferencing elements
   is beyond the scope of this document. It can be expected that in most
   cases CPS includes   also those logical functions. If the focus is not
   co-located with CPS, one way for the CPS to communicate changes to
   the conference policy is for the focus to    subscribe to the XCAP
   event package [10].


6.9 Conference Creation and Termination


   Conference is identified by one or more conference URIs. Conference
   URI assignment is discussed in Section 6.12 and Section 4.2.1.


   A user may create a new conference at the CPS by using HTTP PUT and
   sending it to the CPS XCAP URI. Depending on server policy and user
   privileges, the CPS  may accept the creation.


   A conference can be deleted permanently using HTTP DELETE, which
   consequently frees the resources. When the user deletes a conference,
   CPS MUST also        delete all its sub-conferences ("side bars") at a
   server. Conference side bars are separate (independent) URIs at the
   server.


   A running conference instance can be also stopped by modifying the
   conference time information. This leaves conference ACLs and
   privileges intact but stops  the conference.


   If a conference is in progress when deleted or stopped, the focus
   issues signalling requests to terminate all conference related
   sessions it has with clients. In SIP,        the focus issues BYE requests.


6.10 Manipulating the Participant Lists


   A user with sufficient privileges is allowed to perform user
   management operations, such as adding a new user to the conference or
   expelling a user from the    conference. These operations are performed
   by modifying the conference policy at the conference policy server.
   After authorising the user to do such        manipulations, the conference
   policy server communicates the change to the focus. The focus reacts
   by performing operations such as sending SIP INVITE, BYE     or REFER.


   Asking the focus to invite a user into the conference is achieved by
   sending a HTTP PUT request to the CPS that modifies the Dial-Out List




Khartabil & Koskelainen    Expires October 18, 2004            [Page 21]
Internet-Draft                    CPCP                        April 2004



   (DL) adding URIs to it.      The CPS then triggers the focus to send the
   conference invitation, eg: SIP INVITE(s) as needed. Similarly, a user
   can be removed from the Dial-out list by issuing a   HTTP DELETE
   removing the URIs.


   Asking the focus to allow certain users to join the conference is
   done by sending a HTTP PUT request to the CPS that modifies the ACL
   by adding URIs with  access type of "Allowed". The CPS then informs
   the focus of such change to the ACL.


   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 overwritten, though).       This leads easily to the situation
   that the ACL contains many unnecessary rules which are not really
   needed anymore. Therefore, there is a need  to delete ACL    rule. This
   can be achieved with the HTTP DELETE.


   Conflicting rules MUST NOT exist (e.g. both allowed and blocked
   action is defined for same target). It is the responsibly of the CPS
   to ensure such restriction. If a     conflict occurs, the CPS can ...


6.10.1 Expelling a Participant


   Expel operation uses the HTTP PUT request as well, as the user is put
   on the ACL list with an access type of "Expelled". This also triggers
   the CPS to   inform the focus about the need to issue a terminating
   request, such as a SIP BYE.


   A participant cannot be expelled by placing him in the ACL list with
   an action to block. This is because the focus interprets a user
   placed on the block list as a user   who is not allowed to dial into
   the conference, but does not prohibit the focus from inviting that
   user to join, if that user is on the Dial-out list. Having the user
   on an        Expel list explicitly informs the focus not to invite that
   user, even if s/he is on the Dial-out list.


6.11 Privileges: Who can modify the conference policy


   There is a need for different privileges to exist where users can
   modify certain parts of the conference policy XML document. This
   specification does not specify       such privileges and relies on other
   XCAP usage documents to define those privileges. If no such XCAP
   usage document exists, the base XCAP document defines        the default
   privileges so that only the creator of the document is the sole user
   with write access.


   This specification, however, makes ready the CPCP XML document to
   allow an external usage document to define which parts of such an XML




Khartabil & Koskelainen    Expires October 18, 2004            [Page 22]
Internet-Draft                    CPCP                        April 2004



   document a user      can modify (which parts of an XML document a user
   has read/write access to) by dividing the CPCP XML document into
   sections, each with a separate       namespace. It is envisioned that the
   XCAP usage document for read/write access of another XCAP XML
   document uses namespaces as the key to allow/disallow        users from
   reading and/or modifying that XCAP usage document.


6.12 Conference URI(s)


   A conference is identified by one or more conference URIs. Conference
   URIs can be proposed by the creator of the conference policy,  as it
   may be useful to     have human-friendly name in some cases, or can be
   assigned by the CPS. If the creator has proposed a conference URI,
   the server needs to decide whether it        accept the name proposed by
   the client or not. It does this determination by examining if the
   conference URI already exists or not. If it exists, the server ...


   A Conference URI can be SIP, SIPS, TEL, or any supported URI scheme.
   There must be at least one URI for a conference. The CPS MAY assign
   multiple     conference URIs to a conference, one for each call
   signaling protocol that it supports. If the creator of the conference
   policy proposed a conference URI for a       protocol that the server does
   not support, the server ...


7. Examples


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


   Below is an example how to create a conference:



   1. Creating a Conference


   Alice creates a conference as follows:


      PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml HTTP/1.1
      Content-Type:application/conference-policy+xml


   <?xml version="1.0" encoding="US-ASCII"?>
   <Conference xmlns="urn:ietf:params:xml:ns:conference-policy"
                        xmlns:conference-mp="urn:ietf:params:xml:ns:conference-mp"
                        xmlns:conference-fp="urn:ietf:params:xml:ns:conference-fp"
                        xmlns:conference-sc="urn:ietf:params:xml:ns:conference-sc"
                        xmlns:conference-dl="urn:ietf:params:xml:ns:conference-dl"
                        xmlns:conference-pcl="urn:ietf:params:xml:ns:conference-pcl"
                        xmlns:conference-acl="urn:ietf:params:xml:ns:conference-acl"
                        xmlns:conference-time="urn:ietf:params:xml:ns:conference-time"
                        xmlns:conference-info="urn:ietf:params:xml:ns:conference-info"




Khartabil & Koskelainen    Expires October 18, 2004            [Page 23]
Internet-Draft                    CPCP                        April 2004



                        xmlns:conference-settings="urn:ietf:params:xml:ns:conference-settings">
        <conference-settings:Conference-settings>
                <conference-uri:Conference-URI></conference-uri:Conference-URI>
                <Max-participant-count>50</Max-participant-count>
        </conference-settings:Conference-settings>
        <conference-info:Conference-info lang="en">
                <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>
                <Host-info>
                        <SIP-URI>sip:Alice@example.com</SIP-URI>
                        <TEL-URI>tel:+358401111111</TEL-URI>
                        <E-mail>mailto:Alice@example.com</E-mail>
                        <Web-page>http://www.example.com/users/Alice</Web-page>
                </Host-info>
        </conference-info:Conference-info>
        <conference-time:Conference-time>
                <Conference-occurrence>
                        <Start-time>2003-06-16T10:00:00Z</Start-time>
                        <Stop-time>2003-06-16T12:00:00Z</Stop-time>
                </Conference-occurrence>
        </conference-time:Conference-time>
        <conference-acl:ACL>
                <ACL-target-URI Access-type="Allowed">sip:*@example.com</ACL-target-URI>
                <ACL-target-URI Access-type="Blocked">sip:*@*</ACL-target-URI>
        </conference-acl:ACL>
        <conference-pcl:PCL>
                <PCL-target>
                        <PCL-target-URI>sip:Alice@example.com</PCL-target-URI>
                        <Privileges>RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE</Privileges>
                </PCL-target>
        </conference-pcl:PCL>
        <conference-dl:DL>
                <DL-target>
                        <DL-target-URI>sip:alice@operator.com</DL-target-URI>
                </DL-target>
                <DL-target>
                        <DL-target-URI>sip:sarah@operator.com</DL-target-URI>
                </DL-target>
        </conference-dl:DL>
        <conference-sc:SC>
                <Visibility>visible</Visibility>
                <Security-mechanism TLS="false" S-MIME="true"/>
                <SC-target>
                        <SC-target-URI>sip:*@example.com</SC-target-URI>
                        <Authorization-mechanism password="1a2b3c4d">Digest</Authorization-mechanism>
                </SC-target>




Khartabil & Koskelainen    Expires October 18, 2004            [Page 24]
Internet-Draft                    CPCP                        April 2004



        </conference-sc:SC>
        <conference-fp:Conference-floor-policy>
                <Floor moderator-controlled="true">
                        <Media-types>
                                <Audio/>
                        </Media-types>
                        <Algorithm>
                                <Moderator-controlled/>
                        </Algorithm>
                        <Max-floor-users>1</Max-floor-users>
                        <Moderator-URI>sip:Alice@example.com</Moderator-URI>
                </Floor>
        </conference-fp:Conference-floor-policy>
        <conference-mp:Conference-media-policy>
                        <Media-types>
                                <Audio/>
                        </Media-types>
        </conference-mp:Conference-media-policy>
   </Conference>


   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.


   2. Expelling a User


   Continuing with the above example: aftar the conference has started,
   Alice decides to expel Bob who has joined the conference. So she adds him to
   the ACL list with Access-type of value "Blocked".


   The XCAP request looks like:


      PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml?
         Conference/ACL/ACL-target-URI HTTP/1.1
         Content-Type:text/plain


      <ACL-target-URI Access-type="Explelled">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 expelled until his URI is removed from the ACL Expelled list.
   Any attempt Bob makes in rejoining the conference will fail.



   3. Allowing An Expelled Participant To Join Again


   Continuing with the example above, Alice now decides to allow Bob to join




Khartabil & Koskelainen    Expires October 18, 2004            [Page 25]
Internet-Draft                    CPCP                        April 2004



   again after a period of time. She does so by removing his entry in the
   ACL that identifies him as "Expelled".


      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.



   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 thereafter.





8. Security Considerations


   See section Section 4.2.7.


9. IANA Considerations


9.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.


9.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].





Khartabil & Koskelainen    Expires October 18, 2004            [Page 26]
Internet-Draft                    CPCP                        April 2004



   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 9 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
   conferencing.


   Additional information:


   Magic number: None


   File extension: .cl or .xml


   Macintosh file type code: "TEXT"


   Personal and email address for further information: Petri Koskelainen
   (petri.koskelainen@nokia.com)


   Intended Usage: COMMON


   Author/change controller: The IETF


9.3 URN Sub-Namespace Registration for
    urn:ietf:params:xml:ns:conference-policy


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


   URI: The URI for this namespace is
   urn:ietf:params:xml:ns:conference-policy.


   Registrant Contact: IETF, XCON working group, Petri Koskelainen
   (petri.koskelainen@nokia.com)


   XML:










Khartabil & Koskelainen    Expires October 18, 2004            [Page 27]
Internet-Draft                    CPCP                        April 2004



   BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
        "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
    <meta http-equiv="content-type"
      content="text/html;charset=iso-8859-1"/>
    <title>Conference Policy Namespace</title>
   </head>
   <body>
     <h1>Namespace for Conference Policy</h1>
     <h2>application/conference-policy+xml</h2>
     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
   </body>
   </html>
   END



10. Contributors


      Jose Costa-Requena


      Simo Veikkolainen


      Teemu Jalava



11. Acknowledgements


   The authors would like to thank Markus Isomaki, Eunsook Kim and IETF
   conferencing design team for their feedback.


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., Shulzrinne, H., Camarillo, G., Johnston,
         A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
         "SIP: Session Initiation Protocol", RFC 3261, June 2002.


   [5]   Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,




Khartabil & Koskelainen    Expires October 18, 2004            [Page 28]
Internet-Draft                    CPCP                        April 2004



         "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. and H. Khartabil, "Requirements for conference
         policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
         progress), January 2004.


   [8]   Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",
         draft-ietf-simple-xcap-02 (work in progress), February 2004.


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


   [10]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
         Package for Modification Events for the Extensible Markup
         Language (XML) Configuration Access Protocol (XCAP) Managed
         Documents", draft-ietf-simple-xcap-package-01 (work in
         progress), February 2004.


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


   [12]  Rosenberg, J., Shulzrinne, H. and O. Levin, "A Session
         Initiation Protocol (SIP) Event Package for Conference State",
         draft-ietf-sipping-conference-package-03, February 2004.


   [13]  Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-05 (work in progress), June
         2003.



Authors' Addresses


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


   EMail: hisham.khartabil@nokia.com




Khartabil & Koskelainen    Expires October 18, 2004            [Page 29]
Internet-Draft                    CPCP                        April 2004



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


   EMail: petri.koskelainen@nokia.com













































Khartabil & Koskelainen    Expires October 18, 2004            [Page 30]
Internet-Draft                    CPCP                        April 2004



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
   Director.



Full Copyright Statement


   Copyright (C) The Internet Society (2004). 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
   English.


   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
   "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




Khartabil & Koskelainen    Expires October 18, 2004            [Page 31]
Internet-Draft                    CPCP                        April 2004



   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Acknowledgment


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












































Khartabil & Koskelainen    Expires October 18, 2004            [Page 32]