XCON                                                        H. Khartabil
Internet-Draft                                            P. Koskelainen
Expires: October 18, 2004 January 14, 2005                                       A. Niemi
                                                                   Nokia
                                                          April 19,
                                                           July 16, 2004

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

Status of this Memo

   This document is an Internet-Draft

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and is any of which I become aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 of RFC2026.
   RFC 3668.

   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.
   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. January 14, 2005.

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 may be used to store
   and manipulate a conference policy.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .   3 . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . .   3 . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   3 . .  5
   4.  Structure of a Conference Policy document  . . . . . . . .   4 . .  6
     4.1   MIME Type for CPCP XML Document  . . . . . . . . . . . . .  6
     4.2    XML Document Description   Conference Root  . . . . . . . . . . . . . . . . .   6
   4.2.1  <Conference-settings> element . . . .  6
     4.3   XML Document Description . . . . . . . . . .   6
   4.2.2  <Conference-info> element . . . . . . .  7
       4.3.1   Conference Settings  . . . . . . . . .   6
   4.2.3  <Conference-time> element . . . . . . . .  7
       4.3.2   Conference Information . . . . . . . .   7
   4.2.4  <ACL> (Access Control List) element . . . . . . . .  8
       4.3.3   Conference Time  . . .   8
   4.2.5  <PCL> (Privilege Control List) element . . . . . . . . . .   9
   4.2.6  <DL> (Dial-Out List) element . . . . . .  9
       4.3.4   Conference Authorization Rules . . . . . . . . .  10
   4.2.7  <SC> (Security Control) element . . . 10
       4.3.5   Conference Dial-Out List . . . . . . . . . .  10
   4.2.8  <Conference-floor-policy> element . . . . . 21
       4.3.6   Conference Refer List  . . . . . . .  11
   4.2.9  <Conference-media-Policy> element . . . . . . . . . 22
       4.3.7   Conference Security Control  . . .  12
   4.3    XML Schema . . . . . . . . . . 22
       4.3.8   Conference Floor Policy  . . . . . . . . . . . . . .  12
   5.     Floor Control Policy vs. Floor Control Protocol . 22
       4.3.9   Conference Media Streams . . . .  19
   6.     An XCAP Usage for Conference Policy Manipulation . . . . .  19
   6.1    Application Unique ID . . . . . . 23
     4.4   XML Schema Extensibility . . . . . . . . . . . .  19
   6.2    Resource Interdependencies . . . . . 24
     4.5   XML Schema . . . . . . . . . . .  19
   6.3    Additional Constraints . . . . . . . . . . . . . 24
   5.  Conference Policy Manipulation and Conference Entity
       Behaviour  . . . . .  20
   6.4    Naming Conventions . . . . . . . . . . . . . . . . . . . .  20
   6.5    Authorization Policies . 30
     5.1   Overview of Operation  . . . . . . . . . . . . . . . . .  20
   6.6    MIME Type for CPCP XML Document . 30
     5.2   Use of External Lists  . . . . . . . . . . . .  20
   6.7    Overview of Operation . . . . . . 31
     5.3   Communication Between Conference Entities  . . . . . . . . 31
     5.4   Manipulating Participant Lists . . . .  20
   6.8    Communication Between Conference Entities . . . . . . . .  21
   6.9    Conference Creation and Termination . . 31
       5.4.1   Expelling a Participant  . . . . . . . . .  21
   6.10   Manipulating the Participant Lists . . . . . . 32
     5.5   Re-joining a Conference  . . . . . .  21
   6.10.1 Expelling a Participant . . . . . . . . . . . 33
     5.6   Floor Control Policy vs. Floor Control Protocol  . . . . . 33
   6.  An XCAP Usage for Conference Policy Manipulation .  22
   6.11   Privileges: Who can modify the conference policy . . . . .  22
   6.12   Conference URI(s) . 34
     6.1   Application Unique ID  . . . . . . . . . . . . . . . . . . 34
     6.2   Resource Interdependencies .  23
   7.     Examples . . . . . . . . . . . . . . . 34
     6.3   Additional Constraints . . . . . . . . . .  23
   8.     Security Considerations . . . . . . . . 34
     6.4   Naming Conventions . . . . . . . . .  26
   9.     IANA Considerations . . . . . . . . . . . 34
     6.5   Authorization Policies . . . . . . . .  26 . . . . . . . . . . 34
     6.6   MIME Type for CPCP XML Document  . . . . . . . . . . . . . 35
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     7.1   An Example CPCP Document . . . . . . . . . . . . . . . . . 35
     7.2   CPCP Manipulations Using XCAP  . . . . . . . . . . . . . . 38
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 41
     9.1   XCAP Application Usage ID  . . . . . . . . . . . . . . . .  26 41
     9.2   application/conference-policy+xml mime MIME TYPE  . . . . . . .  26 41
     9.3   URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:conference-policy . . . . . . . . .  27 42
   10.   Contributors . . . . . . . . . . . . . . . . . . . . . . .  28 . 43
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . .  28 . 43
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 43
   12.1  Normative References . . . . . . . . . . . . . . . . . . .  28 . 43
   12.2  Informative References . . . . . . . . . . . . . . . . . . . 44
       Authors' Addresses . . . . . . . . . . . . . . . . . . . .  29 . . 45
       Intellectual Property and Copyright Statements . . . . . .  31 . . 46

1.  Introduction

   The SIP conferencing framework [11] [13] 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.
   conference, as described in [9].  A centralized serve, centralised server, 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 defines an XML
   Schema in Section 4.3 4 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  In some
   cases, such as some ad-hoc scenarios described in [9], there is needed to store and manipulate a
   static conference policy.

   Other mechanisms, policy which is not changed or manipulated during a
   conference.  This policy document may be given to a focus using a
   number of transports.  Mechanisms such as a web page or a voice
   response system can also be used to manipulate conference policy
   data.

   However, in many cases it is useful to have standardised means to
   manipulate conference policy elements such as access control lists.
   The requirements for such protocol are defined in [8].

   Section 6 of this document describes one such protocol for the
   real-time manipulation of conference policy.  An XML Configuration
   Access Protocol (XCAP) [10] application usage is defined which meets
   the requirements in [8] to store and manipulate a conference policy
   object.

   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].
   [11].

   A focus conforming to this specification MUST support the XML object
   defined in Section 4 .  For manipulation of the the XML object, the
   system MAY support the XCAP usage defined in Section 6.

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]. [13].  Some additional
   definitions are introduced here.

      ACL

         Access

      Conference authorization policy (CAP)

         Conference authorization policy consists of an unordered set of
         rules, which control list (ACL) defines users who can join to a
         conference. Users may have allowed, blocked, pending or
         expelled status in the list. Each permissions and privileges that are
         given to conference has its own ACL.

      CPS participants.

      Conference Policy Server (CPS)

         Conference Policy Server.  See [11] [13]

      Conference participant

         Conference participant is a user who has an 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

         A privileged user is a user that has the creator. Defining
         privileges to modify certain right manipulate parts
         or all of a the conference policy is
         outside the scope of this document. settings.

      CPS XCAP URI

         The URI of the XCAP server that is used to create the
         conference.  The URI contsruction construction is specified in [8]. [10].  It is
         refered
         referred 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 construction is specified in [8]. [10].

4.  Structure of a Conference Policy document

   The conference policy document is an XML [5] [6] 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
   defined by this specification is a URN [2], [3], using the namespace
   identifier 'ietf' defined by [3] [4] and extended by [13]. [15].  This URN is:

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

   A conference

4.1  MIME Type for CPCP XML Document

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

4.2  Conference Root

   A conference policy document begins with the root element tag
   "conference-policy".
   <conference>.  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: the following:

   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>. <settings> element: This element is mandatory and contains
      various conference settings.  It contains the conference URI(s)
      and the 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>. <info> element: This element is optional and includes informational
      information 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":  The <time> element: This optional namespace element defines conference time information. It defines the mandatory
      <Conference-time> element that includes
      information, namely elements defining start and stop times for a
      conference.

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

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

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

   o  "urn:ietf:params:xml:ns:conference-sc":  The <security-control> element: This optional namespace element is for
      security control.  It defines the <SC> element that contains conference security level and
      passwords.

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

   o  "urn:ietf:params:xml:ns:conference-fp":  The <fp> element: This optional namespace element 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

   A user may create a new conference at the CPCP XML CPS by placing a new
   conference policy 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; at the <Conference-URI> element CPS.  Depending on server policy
   and user privileges, the <Max-participant-count> element.

   <Conference-URI> is an optional element. It can occur more than once
   to accommodate multiple signaling protocols. Once a CPS may accept the creation.

   A conference URI is
   set, it MUST         NOT can be changed or removed for deleted permanently by removing the duration of conference
   policy from the CPS, which consequently frees the resources.  When
   the user deletes a conference, the CPS MUST also delete all its
   sub-conferences ("sidebars") at a server.  Conference sidebars have
   unique URIs at the server.

4.3  XML Document Description

4.3.1  Conference Settings

   The mandatory <settings> element contains 2 sub-elements; the
   <conference-uri> element and the <max-participant-count> element.

   <conference-uri> is a mandatory 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>

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

   <allow-sidebars> is an optional element

   Mandatory <Conference-info> with a boolean value
   indicating if sidebars are allowed in this conference or not.  The
   default value, if omitted, is "true" indicating that sidebars are
   allowed.

   <sidebar> is an element has its own namespace and it identifying a side bar.  Multiple <sidebar>
   elements can occur only once indicating multiple sidebars.  No <sidebar>
   elements appearing in a document. It includes informative conference
   parameters which may be helpful describing the purpose of a
   conference, e.g. for search purposes or policy indicates that there are no
   sidebars currently for providing host contact
   information. The <Conference-info this conference.  A <sidebar> element MUST have contains
   a special mandatory 'id' attribute 'xml:lang' to specify the language used in that uniquely identifies the contents of
   this element as defined Section 2.12 of [5].

   Each conference has sidebar.  It
   also contains an optional <Subject> element, which describes <uri> element that hold the current topic in sidebar URI.  It can
   occur more than once to accommodate multiple signaling protocols.
   Once a conference. The optional <Display-name>
   element sidebar URI is set, it MUST NOT be changed or removed for the display name
   duration 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  Only one URI per protocol MUST be set.
   URIs can be made available to potential conference participants by means
   outside added at any time.

   A sidebar MAY have its own policy.  This policy is created exactly in
   the scope of this document. Examples of usage could be
   searching for a conference based on some keywords. same manner as any other conference.  The optional
   <Web-page> <policy> element in the
   <sidebar> element points to a URI where additional information about such policy.  If the conference can be found.

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

4.2.3 <Conference-time> element

   The information related to a
   sidebar of.

   A conference time and lifetime is contained
   in the <Conference-time> element. The identified by one or more conference may occur URIs, one for
   each call signaling protocol that is supported.  There must be at
   least one URI for a
   limited period conference.  Conference URIs can be proposed by
   the creator of time (i.e. bounded), or the conference policy, as it may be
   unbounded (i.e. it does not useful to 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
   human-friendly name in some cases, or more
   <Conference-occurrence> elements each defining the time information
   of a single conference occurrence. Multiple <Conference-occurrence>
   elements MAY can be used if assigned by the CPS.  If
   the creator has proposed a conference is active at multiple
   irregularly spaced times; each additional <Conference-occurrence>
   element contains time information for a specific occurrence.

   For each occurrence, URI, the <Start-time> element specifies when a
   conference starts. server needs to decide
   whether it accept the <Stop-time> element specifies name proposed by the client or not.  It does
   this determination by examining if the time a conference stops. URI already exists
   or not.  If the <Start-time> element is not present, it
   indicates that exists, the conference starts immediately. If CPS rejects the <Stop-time>
   is set request to zero, then conference occurrence is not bounded, i.e.
   permanent, though it will not become active until the <Start-time>.
   If create the <Stop-time> element is not present, it indicates
   conference with that the conference terminates as soon as the last participant leaves URI.  Similarly, the
   conference. The focus might wait a small period of time before
   terminating CPS rejects the conference, in case
   request to create a participant joins straight
   after the last participant leaves.

   When saying that conference with a conference starts, or becomes active (start-time), URI for a signalling
   protocol it means that the mixing starts. does not support.

   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 Conference URI can be dialled to shortly before start time.

   A conference terminates with stop-time. SIP, SIPS, TEL, or any supported URI scheme.
   The creator is free CPS MAY assign multiple conference URIs to set
   the stop-time a conference, one for
   each call signaling protocol that it supports.

   Sidebar URIs are subject 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. same behaviour.

4.3.2  Conference Information

   The stop-time can be changed by
   the optional <info> element includes informative conference creator, during
   parameters which may be helpful describing the purpose of a
   conference, e.g.  for search purposes or for providing host contact
   information.  The <info> element MUST have a special attribute
   'xml:lang' to allow the extension
   of the conference based on best effort. A conference always
   terminates when specify the conference policy is removed, regardless of language used in the
   stop time.

   The absence contents 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 as defined Section 2.12 of Access Control List (ACL) is to control who can join
   the conference.A [6].

   Each 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 an optional <subject> element, which describes
   the       target current topic in a conference.  The optional <display-name>
   element is allowed to join the conference.
   Blocked means that display name of the target is conference, which usually does not allowed to join
   change over time.

   <free-text> and <keywords> are optional elements.  They provide
   additional textual information about the conference.  This
   information can be used in the where the allowed URIs are wild-carded and
   the user wants made available to explicitly block one potential participant, whose
   URI falls within conference
   participants by means outside the wildcarded URIs, from joining. scope of this document.  Examples
   of usage could be searching for a conference based on some keywords.
   The other way
   around is also possible optional <web-page> element points to a URI where additional
   information about the blocked URIs are wildcarded and conference can be found.

   The optional <host-info> element contains several elements.  It gives
   additional information about the user wants to explicitly allow one potential participant, whose
   URI falls within hosting the wildcarded URIs, to join. Pending means that
   authorisation conference.  This
   information can, for example, be included into the target is not granted and while further
   processing is required - such as consulting SDP fields of the moderator. Expelled
   means        that user
   SIP INVITE requests sent by the focus.  The <uri> element is expelled from current optional
   and can occur more than once.

4.3.3  Conference Time

   The information related to conference time and lifetime is not
   allowed to join or be dialled-out (even if dial-out list includes
   user's URI).

   Wildcards are allowed contained
   in ACL as follows. The domain part is allowed
   to be wildcard only if the username is <time> element.  The conference may occur for a wildcard. Wildcard in limited period
   of time (i.e.  bounded), or the
   domain part MUST conference may be immediately after the @-sign. A wildcard in the
   domain is interpreted as unbounded (i.e.  it
   does not have a specified end time).  Bounded conferences may occur
   multiple zones. For example:
   sip:*@*.example.com includes sip:*@engineering.example.com as well as
   sip:*@tester.engineering.example.com. times(e.g.  on weekly basis).

   The use of wildcarding has been
   restricted to avoid ambiguous entries in <time> element contains one or more <occurrence> elements each
   defining the access control list.

   Examples time information 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 a single conference occurrence.
   Multiple <occurrence> elements MAY be used if overlapping rules
   are found. Basically, this means that user specific rule is searched
   first and if it a conference is not found, then most active
   at multiple times; each additional <occurrence> element contains time
   information for a specific wildcard rule is
   utilized.

   There is occurrence.

   For each occurrence, the <mixing-start-time> element specifies when a need for
   conference media mixing starts.  the ACL to contain an entry that defines <mixing-stop-time> element
   specifies the
   default access types for users time a conference media mixing stops.  If the
   <mixing-start-time> element is not explicitly allowed nor blocked
   from joining present, it indicates that the conference, i.e. everybody else. For example:
   "Pending" action for *@*.
   conference media mixing starts immediately.  If that entry the
   <mixing-stop-time> element is missing, not present, it indicates that the focus local
   policy dictates
   conference occurrence is not bounded, i.e.  permanent, though media
   mixing will not become active until the behaviour.

   Sip: <mixing-start-time>.
   <mixing-start-time> and sips: schemes are treated as equivalent in <mixing-stop-time> elements both have the ACL since it
   defines users
   mandatory 'require-participant' attribute.  This attribute has one of
   3 values: "none", "key-participant", and not the security used by users.

   It is also possible "participant".  For mixing
   start time, this attribute allows a privileged user to ask define when
   media mixing starts based on the focus latter of the mixing start time, and
   the time the first participant or key participant arrives.  If the
   value is set to refer users "none", mixing starts according to the
   conference. An optional Boolean mixing start
   time.  For mixing stop time, this attribute "refer" exists in the
   <ACL-target-URI> that indicates allows a privileged user
   to define when media mixing stops based on the server that the creator earlier of the
   conference wishes for mixing
   stop time, and the focus to refer time the identified potential
   participants last participant or key participant
   leaves.  If the value is set to "none", mixing stops according to the
   mixing stop time.

   Users can be allowed to join a conference when before the media mixing
   time starts and after a certain time.  A conference occurrence has
   started.  In SIP, this is achieved privileged user
   can indicate the time when users can join by populating the focus sending
   <can-join-after> element.  Similarly, 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 conference privileged user
   can be applied in conferencing context
   (e.g. who is define the time after which new users are not allowed to modify ACL, who join the
   conference anymore.  This is allowed done by populating the
   <must-join-before> element.

   It is possible to expel users
   etc). This document defines only one privilege and leaves define 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 time when users has what privileges. The <PCL> element may
   contain one or more <PCL-target> elements. The <PCL-target> element
   carries 2 pieces of information: resources on the target URI, <PCL-target-URI>
   dial-out list and on the privileges for that URI, <Privileges>. All mandatory elements.

   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 refer-list are
   allowed to   subscribe requested to join the
   conference state event package [12]and
   be notified.

4.2.6 <DL> (Dial-Out List) element

   The dial-out list (DL) by using the <request-users> element.  It is a list of user URIs also possible
   to define that the focus uses to
   learn who to invite users and resources on the dial-out list and the
   refer-list are requested 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 only after the mandatory <DL-target-URI> element. first
   a participant or key participant has joined.  This elements carries is achieved with
   the URI 'require-participant' attribute.  A value of "none" indicates
   that the user to be invited.

4.2.7 <SC> (Security Control) element

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

   This element specified
   time has its own XML namespace. lapsed.

   The conference security settings start with the mandatory >SC>
   element. It contains the mandatory <Visibility> element. This element
   can hold one absence of      two values: visible or invisible. The <Visibility>
   element controls whether this conference time information in the <Conference-URI>,
   <Conference-time> and <Conference-info> elements may be made
   available publicly. For example, an application at indicates that a
   conference
   server might list the ongoing conferences on web page, or it may
   allow searching starts immediately and terminates when the conference
   policy is removed.  See Section 4.2 for conferences based on more details.

   A running conference instance can be extended or stopped by modifying
   the keywords listed in conference time information.  Note that those conference times do
   not guarantee resources for the
   <Conference-info> element. Setting <Visibility> conference to "invisible"
   instructs occur.

   If a conference is in progress when deleted or stopped, the application not focus
   issues signalling requests 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 terminate all conference related
   sessions it has with participants.  In SIP, the focus issues BYE
   requests.

4.3.4  Conference Authorization Rules

   One of the key components of conference policy is the
   <Visibility> element set of
   authorization rules that specify who is allowed to "visible".

   We join a conference,
   see floors and request/grant them, subscribe to
   conference-information notifications and so on.  The unordered list
   of authorization rules together define two mechanisms for securing the signaling between users and conference authorization
   policy

   The conference authorization rules are enclosed in the focus: TLS
   <authorization-rules> element and S/MIME. TLS is used to provide transport layer
   security on a hop-by-hop basis. According are formatted according to SIP [6], using SIPS URI
   scheme the XML
   schema defined in a request signifies that TLS must the common policy framework [1].  In
   <authorization-rules> element, there can be used to secure multiple rules, each
   hop over which the request rule
   is forwarded until the request reaches represented by the
   SIP entity responsible for <rule> element, each of which consist of three
   parts: conditions, actions and transformations.  Conditions determine
   whether a particular rule applies to a request.  Each action or
   transformation in the domain portion applied rule is a positive grant of permission
   to the Request-URI. conference participant.  The <Security-mechanism>element inside the <SC> details of each specific element has 2 boolean
   parameter: TLS
   and S/MIME. When in TLS parameter attribute is set described in [1].

   Asking the focus to "true"
   (thus implying allow certain users to join the use of SIPS URI scheme, if SIP conference is used as
   achieved by modifying an existing authorization rule or creating a
   new one.  The CPS then informs the
   signaling protocol), focus of such change.

   If the conference is long-lasting, it is required possible that TLS is used end-to-end. In
   other words, TLS must be used also on the last hop between the entity
   responsible for new rules are
   added all the domain portion time but old rules are almost never removed (some of
   them are overwritten, though).  This leads easily to the Request-URI and situation
   that the conference policy server.

   If end-to-end confidentiality of entire SIP messages is contains many unnecessary rules which are
   not required
   by the conference policy, but it really needed anymore.  Therefore, there is required that the message bodies
   within SIP are encrypted, the S/MIME attribute must have a value
   "true".

   TLS and S/MIME may need to delete
   rules.  This can be required independent achieved by removing that portion of each other. In other
   words, it the policy.

   Conflicting rules may be required to use neither, one, or exist (for example, both depending on
   the settings of these parameters. allowed and blocked
   action is defined for same target).  The conference creator can define an authentication common policy for directives [1]
   dictate the
   participants. behaviour in such situations.

   This is done with section outlines the optional <SC-target> element.

   If new conditions, actions and transformations
   for conference authorization policy.

4.3.4.1  Conditions

4.3.4.1.1  Identity

4.3.4.1.1.1  Interpreting the <SC-target> <id> Element

   The <identity> element is present, then at least one
   <SC-target-URI> inside already defined in the <SC-target> element must be present, each
   identifies a user or a set of users common policy
   framework [1].  However, the rules for which interpreting the authentication
   mechanism apply. The target URI can be wildcarded as described identities in
   <id> elements are left for each application to define separately.
   This document, however, does not define the ACL rules for interpreting
   identities in Section 4.2.4.

   The authentication policy defined <id> elements in the optional
   <Authorization-mechanism> element defines how the participants should
   be authenticated. Two authentication mechanisms conferencing applications since those
   interpretation rules are defined in this
   document: Digest and Digest-AKA. The authentication policy can also
   be set signalling protocol specific.

      OPEN ISSUE: Do we need to none. state more than this? How are identities
      derived from users that join using POTS, H.323, etc.?

4.3.4.1.1.2  Matching Any Identity

   The password associated with each user in the Digest
   authentication is included in the optional <Password> attribute. This
   attribute is ignored if authentication <any> element is set used to "none".

4.2.8 <Conference-floor-policy> element match any participant.  This element has its own XML namespace. allows a
   conference to be open to anyone.

4.3.4.1.1.3  Matching Unauthenticated Identities

   The absence of this namespace
   and its elements from an XML document indicates <unauthenticated> element is used to match unauthenticated
   participants.  That is, participants that have provided no
   authenticated identity to the conference
   does not have a floor. focus.

4.3.4.1.1.4  Matching AnonymousIdentities

   The <Conference-floor-policy> <anonymous> element is mandatory and contains the required
   boolean attribute used to match participants that indicates if have
   provided an authenticated identity to the floor is moderator controlled
   or not. One or more <Floor> elements can appear conference focus, but have
   requested anonymity in the
   <Conference-floor-policy> element. The number of those elements
   indicates how many floors the conference can         have. A floor itself.

4.3.4.1.1.5  Matching Referred Identities

   The <has-been-referred> element can be used for one or more media types; to match those
   participants that the mandatory <Media-types> focus has referred to the conference.

4.3.4.1.1.6  Matching Invited Identities

   The <has-been-invited> element can contain zero or more of the <Video>, <Audio>, <Application>,
   <Data> ,<Control>, <Message>, and <text> elements indicating be used to match those
   participants that the
   media of focus has invited into the floor. One type conference.

4.3.4.1.1.7  Matching Identities of media can only appear        once. Other
   media types Former Conference Participants

   The <has-been-in-conference> element can be defined by extensions.

   A floor used to match those
   participants that have joined the conference in the past.

4.3.4.1.1.8  Matching Identities Currently in the Conference

   The <is-in-conference> element can be controlled using many algorithms; used to match those
   participants that are currently participating in the mandatory
   <Algorithm> conference.

4.3.4.1.1.9  Matching Key Participant Identities

   The <key-participant> element MUST contain one and only can be used to match those participants
   that are key participants of a conference.

4.3.4.1.1.10  Matching Identities on the
   <Moderator-controlled>, <FCFS>, and <Random> elements indicating the
   algorithm. Dial-out List

   The <Max-floor-users> <is-on-dialout-list> element in can be used to match those
   participants that are on the <Floor> element is optional and,
   if present, dictates dial-out list.

4.3.4.1.1.11  Matching Identities on the maximum number of users who Refer List

   The <is-on-refer-list> element can have be used to match those
   participants that are on the
   floor at one time. refer list.

4.3.4.1.1.12  Floor ID

   The optional <Moderator-URI> indicates the URI of
   the moderator. <floor-id> element can be used to assign users as floor
   moderators.  It MUST be set if used in conjunction with the attribute moderator-controlled
   is set to "true".

4.2.9 <Conference-media-Policy> <id> element

   Media policy is an integral part of
   that identifies the conference policy. It defines
   e.g. what kind floor moderator.  The <floor-id> element carries
   the floor ID of media topologies exist in the conference. This
   document defines a very basic media policy floor that states the media
   types user is a conference has. This moderator of.  The
   transformation <is-floor-moderator> is used by the focus to know what media
   types to invite users with and what media types it should accept from
   dialling assert that the user
   identified using the <id> condition is the floor moderator of the
   floor identified in users. the <floor-id> condition.

4.3.4.1.1.13  Matching PIN Codes

   The details of media manipulation <pin> element can be used to match those participants that are defined
   elsewhere. User with sufficient privileges
   have knowledge on a PIN code for the conference.  For example:

        <rule id="1">
                <conditions>
                        <pin>12345</pin>
                </conditions>
                <actions>
                        <join-handling>allow</join-handling>
                </actions>
                <transformations/>
        </rule>

   So the condition is the PIN.  If any user knows the PIN, ignoring
   their identity, the user is allowed to create,
   modify join.

   A combination of the <identity> condition and delete the media policy (e.g. add new media types).

   This element has its own XML namespace.

   The definition <pin>  condition
   creates the possibility of assigning users personal PIN codes  to
   enable them to join a conference.  For example:

        <rule id="2">
                <conditions>
                        <identity>
                                <id>358401234567</id>
                        </identity>
                        <pin>67890</pin>
                </conditions>
                <actions>
                        <join-handling>allow</join-handling>
                </actions>
                <transformations/>
        </rule>

4.3.4.1.1.14  Matching Passwords

   The <password> element can be used to match those participants that
   are have knowledge on a password for the conference.  For example:

        <rule id="3">
                <conditions>
                        <password>pass1</password>
                </conditions>
                <actions>
                        <join-handling>allow</join-handling>
                </actions>
                <transformations/>
        </rule>

   So the condition is the password.  If any user knows the password,
   ignoring their identity, the user is allowed to join.

   A combination of the <identity> condition and the <password>
   condition creates the possibility of assigning users personal
   passwords to enable them to join a conference.  For example:

        <rule id="4">
                <conditions>
                        <identity>
                                <id>alice@example.com</id>
                        </identity>
                        <password>pass2</password>
                </conditions>
                <actions>
                        <join-handling>allow</join-handling>
                </actions>
                <transformations/>
        </rule>

4.3.4.2  Actions

4.3.4.2.1  Conference State Events

   The <allow-conference-state> element represents a boolean action.  If
   set to TRUE, the focus is instructed to allow the subscription to
   conference state events, such as the SIP Event Package for Conference
   State [14].  If set to FALSE, the subscription to conference state
   events would be rejected.

   If this element is undefined it has a value of TRUE, causing the
   subscription to conference state events to be accepted.

      OPEN ISSUE: Is a simple block/allow sufficient here, or should the
      subscription handling be similar to e.g.  presence, and have three
      states (block, confirm, allow), or possibly even four states
      (block, confirm, polite-block, allow)?

4.3.4.2.2  Floor Control Events

   The <allow-floor-events> element represents a boolean action.  If set
   to TRUE, the focus is instructed to accept the subscription to floor
   control events.  If set to FALSE, the focus is instructed to reject
   the subscription.

   If this element is undefined, it has a value of FALSE, causing the
   subscription to floor control events to be rejected.

      OPEN ISSUE: Is a simple block/allow sufficient here, or should the
      subscription handling be similar to e.g.  presence, and have three
      states (block, confirm, allow), or possibly even four states
      (block, confirm, polite-block, allow)?

4.3.4.2.3  Conference Join Handling

   The "join-handling" element defines the actions used by the
   conference focus to control conference participation.  This element
   defines the action that the focus is to take when processing a
   particular request to join a conference.  This element is an
   enumerated integer type, with defined values of:

   block:  This action instructs the focus to deny access to the
      conference.  This action has a value of zero and it is the lowest
      value of the "join-handling" element.  This action is the default
      action taken in the absence of any other actions.

   confirm:  This action instructs the focus to place the participant on
      a pending list (e.g., by parking the call on a music-on-hold
      server), awaiting moderator input for further actions.  This
      action has a value of one.

   allow:  This action instructs the focus to accept the conference join
      request and grant access to the conference within the instructions
      specified in the transformations of this rule.  This action has a
      value of two.

   Note that placing a value of block for this element doesn't guarantee
   that a participant is blocked from joining the conference.  Any other
   rule that might evaluate to true for this participant that carried an
   action whose value was higher than block would automatically grant
   confirm/allow permission to that participant.

4.3.4.2.4  Dynamically Referring Users

   The <allow-refer-users-dynamically> element represents a boolean
   action.  If set to TRUE, the identity is allowed  to instruct the
   focus to refer a user to the conference without modifying the
   refer-list (in SIP terms, the identity is allowed to send a REFER
   request to the focus which results in the focus sending a REFER
   request to the user the referrer wishes to join the conference).  If
   set to FALSE, the refer request is rejected.

   If this element is undefined it has a value of FALSE, causing the
   refer to be rejected.

4.3.4.2.5  Dynamically Inviting Users

   The <allow-invite-users-dynamically> element represents a boolean
   action.  If set to TRUE, the identity is allowed  to instruct the
   focus to invite a user to the conference without modifying the
   dial-out list (in SIP terms, the identity is allowed to send a REFER
   request to the focus which results in the focus sending an INVITE
   requested to the user the referrer wishes to join the conference).
   If set to FALSE, the refer request is rejected.

   If this element is undefined it has a value of FALSE, causing the
   refer to be rejected.

4.3.4.2.6  Modifying Conference setting

   The <allow-modify-settings> element represents a boolean action.  If
   set to TRUE, the identity is allowed  to modify the conference
   settings in the conference policy.  If set to FALSE, any
   modifications to the conference settings are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.7  Modifying Conference Information

   The <allow-modify-information> element represents a boolean action.
   If set to TRUE, the identity is allowed  to modify the conference
   information in the conference policy.  If set to FALSE, any
   modifications to the conference information are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.8  Modifying Conference Time

   The <allow-modify-time> element represents a boolean action.  If set
   to TRUE, the identity is allowed  to modify the conference time in
   the conference policy.  If set to FALSE, any modifications to the
   conference time are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.9  Modifying Authorization rules

   The <allow-modify-authorization-rules> element represents a boolean
   action.  If set to TRUE, the identity is allowed  to modify the
   authorization rules of a conference in the conference policy.  If set
   to FALSE, any modifications to the rules are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.10  Modifying Conference Dial-out List

   The <allow-modify-dol> element represents a boolean action.  If set
   to TRUE, the identity is allowed  to modify the conference dial-out
   list in the conference policy.  If set to FALSE, any modifications to
   the dial-out list are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.11  Modifying Conference Refer List

   The <allow-modify-rl> element represents a boolean action.  If set to
   TRUE, the identity is allowed  to modify the conference refer list in
   the conference policy.  If set to FALSE, any modifications to the
   refer list are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.12  Modifying Conference Security Control

   The <allow-modify-sc> element represents a boolean action.  If set to
   TRUE, the identity is allowed  to modify the conference security
   control settings in the conference policy.  If set to FALSE, any
   modifications to the security control settings are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.13  Modifying Conference Floor Policy

   The <allow-modify-fp> element represents a boolean action.  If set to
   TRUE, the identity is allowed  to modify the conference floor policy
   in the conference policy.  If set to FALSE, any modifications to the
   floor policy are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.14  Modifying Conference media streams

   The <allow-modify-ms> element represents a boolean action.  If set to
   TRUE, the identity is allowed  to modify the conference media streams
   in the conference policy.  If set to FALSE, any modifications to the
   media streams are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.15  Creating Sidebars

   The <allow-sidebar> element represents a boolean action.  If set to
   TRUE, the identity is allowed  to create and manipulate a sidebar by
   creating and modifying a <sidebar> element in a conference policy.
   If set to FALSE, any sidebar creation and manipulation is rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.16  Modifying Conference Dial-in List

   The conference dial-in list is virtual and is not represented by a
   physical list in the conference policy.  It is rather a collection of
   authorization rules that allow users to join a conference.  The
   <allow-modify-dil> element represents a boolean action.  If set to
   TRUE, the identity is allowed  to create an authorization rule in the
   conference policy that give a user a join handling of "allow" (See
   Section 4.3.4.2.3.  If set to FALSE, any modifications to
   authorization rules are rejected.

   If this element is undefined it has a value of FALSE, causing the
   modifications to be rejected.

4.3.4.2.17  Authenticating a User

   The <authenticate> element defines the mechanism used by the
   conference focus to authenticate a user.  This element is an
   enumerated integer type, with defined values of:

   none:  This action instructs the focus not to authenticate the user.
      This action has a value of zero and it is the lowest value of the
      <authenticate-user> element.  This action is the default action
      taken in the absence of any other actions.

   asserted-id:  This action instructs the focus to authenticate the
      user by asserting their identity using means outside the scope of
      this document (for example, using digest-AKA).  This action has a
      value of one.

   shared-secret:  This action instructs the focus to authenticate the
      user using a shared secret (for example, using digest).  This
      action has a value of two.

   certificate:  This action instructs the focus to authenticate the
      user using a certificate (for example, using PGP).  This action
      has a value of three.

4.3.4.3  Transformations

4.3.4.3.1  Key Participant

   When the <is-key-participant> element is set to TRUE, the joining
   participant is denoted as a key participant.  If set to FALSE, the
   participant is not denoted as a key participant.

   If this element is undefined, it has a value of FALSE, causing no key
   participant status to be given to the participant.

4.3.4.3.2  Floor Moderator

   When the <is-floor-moderator> element is set to TRUE, the joining
   conference participant is denoted as floor moderator, meaning that
   they are privileged to control the floor in the conference.  If set
   to FALSE, floor moderator privileges are not given to the conference
   participant.

   If this element is undefined, it has a value of FALSE, causing no
   floor moderator privileges to being granted.

4.3.4.3.3  Conference Information

   The <show-conference-info> element is of type boolean transformation.
   If set to TRUE, conference information is shown to the conference
   participant.  If set to FALSE, conference information is not shown to
   the participant.

   The <show-conference-info> element controls whether information in
   the <settings>, <time> and <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.  Not setting this transformation to any users instructs the
   application not to reveal any such information to any user.  However,
   information in other elements, such as <dialout-list>, should not be
   seen by anyone else other than a privileged user, even with this
   transformation enabled for a user.

   If this element is undefined, it has a value of FALSE, causing no
   conference information to being shown.

      OPEN ISSUE: Do we require more granularity for this element?
      Perhaps an enumerated integer type, with defined levels of
      information about the conference, or a set of boolean
      transformations, each granting a single piece of conference
      information, like the ability to see "sidebar" elements?

4.3.4.3.4  Floor Holder

   The <show-floor-holder> element is of type boolean transformation.
   If set to TRUE, the conference participant is able to see who is
   currently holding the floor.  If set to FALSE, the participant is not
   able to see the floor holder.

   If this element is undefined, it has a value of FALSE, causing the
   floor holder not be shown to the participant.

4.3.4.3.5  Floor Requests

   The <show-floor-requests> element is of type boolean transformation.
   If set to TRUE, the conference participant is able to see the floor
   requests.  If set to FALSE, the conference participant is not able to
   see floor requests.

   If this element is undefined, it has a value of FALSE, causing the
   floor requests to not being seen by the conference participant.

4.3.5  Conference Dial-Out List

   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 created
   at conference policy creation time or updated during the conference
   lifetime so it can be used for mid-conference invites (and
   mass-invites) as well.

   Asking the focus to invite (add) a user into the conference is
   achieved by adding that user's URI to the Dial-Out List (DL).  The
   CPS then triggers the focus to send the conference invitation, eg:
   SIP INVITE as needed.  Similarly, a user can be removed from the
   Dial-out list by removing the URI from the dial-out list.

   The <dialout-list> element is optional and includes zero or more
   <target> elements.  The <target> element includes the mandatory 'uri'
   attribute.  The <target> element can be extended.

4.3.6  Conference Refer List

   The refer list (RL) contains a list of resources that the focus needs
   to refer to the conference.  In SIP, this is achieved by the focus
   sending a REFER request to those potential participants.  This list
   can be updated during the conference lifetime so it can be used for
   mid-conference refers as well.

   The <refer-list> element is optional and identical to the
   <dialout-list> element in Section 4.3.5.

4.3.7  Conference Security Control

   The conference security currently encompasses one aspects: the
   integrity and confidentiality of the signalling messages.

   The conference security settings start with the optional
   <security-control> element.

   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 [5], 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 <security-control>
   element has 2 boolean attributes: 'tls' and 's-mime'.  When the 'tls'
   attribute 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 signalling protocol messages
   is not required by the conference policy, but it is required that the
   message bodies within the signalling protocol messages 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 attributes.

4.3.8  Conference Floor Policy

   The absence of the <floor-policy> element from an XML document
   indicates that the conference does not have a floor.

   One or more <floor> elements can appear in the <floor-policy>
   element.  The number of those elements indicates how many floors the
   conference can have.  The <floor> element contains the required
   'floor-control' attribute that uniquely identifies a floor and
   indicates the floor control protocol URI.  It also contains the
   required boolean attribute 'moderator-controlled' that indicates if
   the floor is moderator controlled or not.

   A floor can be used for one or more media streams; the mandatory
   <media-streams> element can contain zero or more of the <video>,
   <audio>, <application>, <data> ,<control>, <message>, and <text>
   elements indicating the media of the floor.  Other media types can be
   defined by extensions.  Each media stream is identified with the
   'media-id' attribute.  This attribute is mandatory and MUST be unique
   for all media streams in a conference.  It is used to correlate the
   conference media stream in Section 4.3.9 with the ones for a floor.
   It is also used to correlate the media streams used in the signalling
   protocols with those in the conference policy, used, for example, in
   SDP "i" field [19].

   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.3.9  Conference Media Streams

   Media policy is an integral part of the conference policy.  It
   defines e.g.  what kind of media topologies exist in the conference.
   Media policy is documented in [18].This document does not define
   media policy, but instead enables the user to specify the media
   streams a conference has.  This is used by the focus to know what
   media streams to invite users with and what media streams 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).

   The definition starts with the mandatory <Conference-media-policy> optional <media-streams> element.
   This element contains lists the media streams allowed for this conference.
   The format of this mirrors that of the <media-streams> element in
   floor policy in Section 4.3.8.  The absence of this element indicates
   that the conference will use media according to the focus local
   policy.

4.4  XML Schema Extensibility

   The schema as be extended at multiple places:

   o  The <conference> element to enable more conference policy
      information to be added

   o  The <settings> element to allow for future conference settings to
      be defined

   o  The <info> element to allow further conference and host
      information to be conveyed

   o  The <occurrence> element to allow further conference timing
      information

   o  The <target> element in <dialout-list> and <refer-list> to allow
      extensions on the behaviour of the focus.  For example, how many
      times to retry inviting a user

   o  The <security-control> element to allow new security setting for a
      conference to be introduced into

   o  The <algorithm> element in <floor-policy> to allow new algorithms
      to be introduced into how a floor is granted

   o  The <floor> element in <floor-policy> to allow extensions to floor
      policy for a mandatory <Media-types> floor

   o  The <media-streams> element that
   lists the to allow introduction of new media types allowed for this conference.
      streams

   o  The format of this
   mirrors that of the same <sidebar> element in floor policy.

4.3 to allow introduction of new sidebar
      information

4.5  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"
                        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" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:conference-policy" elementFormDefault="qualified">
        <!-- This import brings in the XML language attribute xml:lang-->
        <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"/> namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
        <!-- The root Conference Element -->
        <xs:element name="Conference"> name="conference">
                <xs:complexType>
                        <xs:sequence>
                                <xs:element name="Conference-Settings" type="conference-settings:conference-settings"/> name="settings" type="ConferenceSettings"/>
                                <xs:element name="Conference-Info" type="conference-info:Conference-Info"/> name="info" type="ConferenceInfo" minOccurs="0"/>
                                <xs:element name="Conference-Time" type="conference-time:Conference-Time"/> name="time" type="ConferenceTime" minOccurs="0"/>
                                <xs:element name="ACL" type="conference-acl:Conference-ACL"/> name="authorization-rules" type="ConferenceAuthorizationRules" minOccurs="0"/>
                                <xs:element name="PCL" type="conference-pcl:Conference-PCL"/> name="dailout-list" type="Target" minOccurs="0"/>
                                <xs:element name="DL" type="conference-dl:Conference-DL"/> name="refer-list" type="Target" minOccurs="0"/>
                                <xs:element name="SC" type="conference-sc:Conference-SC"/> name="security-control" type="ConferenceSC" minOccurs="0"/>
                                <xs:element name="Conference-floor-policy" type="conference-fp:Conference-Floor-Policy"/> name="floor-policy" type="ConferenceFloorPolicy" minOccurs="0"/>
                                <xs:element name="Conference-media-policy" type="conference-mp:Conference-Media-Policy"/> name="media-streams" type="ConferenceMediaStreams" minOccurs="0"/>
                                <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
                        </xs:sequence>
                </xs:complexType>
        </xs:element>
   </xs:schema>
        <!-- Conference settings 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"> name="ConferenceSettings">
                <xs:sequence>
                        <xs:element name="Conference-uri" name="conference-uri" type="xs:anyURI" minOccurs="0" minOccurs="1" maxOccurs="unbounded"/>
                        <xs:element name="Max-participant-count" name="max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/>
                        <xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/>
                        <xs:element name="sidebar" type="Sidebar" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
                </xs:sequence>
        </xs:complexType>
   </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"> name="ConferenceInfo">
                <xs:sequence>
                        <xs:element name="Subject" name="subject" type="xs:string" minOccurs="0"/>
                        <xs:element name="Display-name" name="display-name" type="xs:string" minOccurs="0"/>
                        <xs:element name="Free-text" name="free-text" type="xs:string" minOccurs="0"/>
                        <xs:element name="Keywords" name="keywords" minOccurs="0">
                                <xs:simpleType>
                                        <xs:list itemType="xs:string"/>
                                </xs:simpleType>
                        </xs:element>
                        <xs:element name="Web-page" name="web-page" type="xs:anyURI" minOccurs="0"/>
                        <xs:element name="Host-info" name="host-info" minOccurs="0">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="URI" name="uri" type="xs:anyURI" minOccurs="0"/> minOccurs="0" maxOccurs="unbounded"/>
                                                <xs:element name="E-mail" name="e-mail" type="xs:anyURI" minOccurs="0"/>
                                                <xs:element name="Web-page" name="web-page" type="xs:anyURI" minOccurs="0"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                        <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
                </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"> name="ConferenceTime">
                <xs:sequence>
                        <xs:element name="Conference-occurrence" name="occurrence" minOccurs="0" maxOccurs="unbounded">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="Start-time" name="mixing-start-time" type="StartStopTime" minOccurs="0"/>
                                                <xs:element name="mixing-stop-time" type="StartStopTime" minOccurs="0"/>
                                                <xs:element name="can-join-after" type="xs:dateTime" minOccurs="0"/>
                                                <xs:element name="Stop-time" name="must-join-before" type="xs:dateTime" minOccurs="0"/>
                                                <xs:element name="request-users" type="StartStopTime" minOccurs="0"/>
                                                <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>
        <!-- Access Control List ACL Conferenece Authorisation -->

   <?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"> name="ConferenceAuthorizationRules">
                <xs:sequence>
                        <xs:element name="ACL-target-URI" maxOccurs="unbounded"> name="rule" type="ruleType" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
        </xs:complexType>
        <xs:complexType name="ruleType">
                <xs:sequence>
                        <xs:element name="conditions" minOccurs="0">
                                <xs:complexType>
                                        <xs:simpleContent>
                                                <xs:extension base="xs:anyURI">
                                        <xs:sequence>
                                                <xs:element ref="condition" minOccurs="0" maxOccurs="unbounded"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                        <xs:element name="actions" minOccurs="0">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element ref="action" minOccurs="0" maxOccurs="unbounded"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                        <xs:element name="transformations" minOccurs="0">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element ref="transformation" minOccurs="0" maxOccurs="unbounded"/>
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
                <xs:attribute name="Refer" name="id" type="xs:string" use="required"/>
        </xs:complexType>
        <xs:element name="condition" abstract="true"/>
        <xs:element name="action" abstract="true"/>
        <xs:element name="transformation" abstract="true"/>
        <xs:element name="identity" substitutionGroup="condition">
                <xs:complexType>
                        <xs:choice>
                                <xs:element name="id" type="xs:anyURI"/>
                                <xs:sequence>
                                        <xs:element name="domain" type="xs:string"/>
                                        <xs:sequence minOccurs="0">
                                                <xs:element name="except" type="xs:anyURI" maxOccurs="unbounded"/>
                                        </xs:sequence>
                                </xs:sequence>
                                <xs:sequence>
                                        <xs:element name="any" type="xs:string"/>
                                        <xs:sequence minOccurs="0">
                                                <xs:element name="except" type="xs:anyURI" maxOccurs="unbounded"/>
                                        </xs:sequence>
                                </xs:sequence>
                        </xs:choice>
                </xs:complexType>
        </xs:element>
        <xs:element name="unauthenticated" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="anonymous" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="has-been-referred" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="has-been-invited" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="has-been-in-conference" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="is-in-conference" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="key-participant" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="is-on-dialout-list" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="is-on-refer-list" type="xs:string" substitutionGroup="condition"/>
        <xs:element name="floor-id" type="xs:anyURI" substitutionGroup="condition"/>
        <xs:element name="pin" type="xs:anyURI" substitutionGroup="condition"/>
        <xs:element name="password" type="xs:anyURI" substitutionGroup="condition"/>

        <xs:element name="allow-conference-state" type="xs:boolean" default="false"/>
                                                        <xs:attribute name="Access-type" use="required"> substitutionGroup="action"/>
        <xs:element name="allow-floor-events" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="join-handling" substitutionGroup="action">
                <xs:simpleType>
                        <xs:restriction base="xs:string">
                                <xs:enumeration value="Allowed"/>
                                                                                <xs:enumeration value="Blocked"/> value="block"/>
                                <xs:enumeration value="Pending"/> value="allow"/>
                                <xs:enumeration value="Expelled"/> value="confirm"/>
                        </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">
   <xs:complexType name="Conference-PCL">
   <xs:sequence>
        <xs:element name="PCL-target" minOccurs="1" maxOccurs="unbounded">
                <xs:complexType>
                <xs:sequence> name="allow-refer-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="PCL-target-uri" type="xs:anyURI" minOccurs="1"/> name="allow-invite-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="Privileges">
                                <xs:simpleType>
                                <xs:list>
                                <!-- Define the privileges as data type with all possible values --> name="allow-modify-settings" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-information" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-time" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-authorization-rules" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-dol" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-rl" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-sc" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-fp" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-ms" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-sidebar" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="allow-modify-dil" type="xs:boolean" substitutionGroup="action"/>
        <xs:element name="authenticate" substitutionGroup="action">
                <xs:simpleType>
                        <xs:restriction base="xs:string">
                                <xs:enumeration value="RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE"/> value="none"/>
                                <xs:enumeration value="digest-aka"/>
                                <xs:enumeration value="digest"/>
                        </xs:restriction>
                </xs:simpleType>
                                </xs:list>
                                </xs:simpleType>
                        </xs:element>
                </xs:sequence>
                </xs:complexType>
        </xs:element>
   </xs:sequence>
   </xs:complexType>
   </xs:schema>

        <xs:element name="is-key-participant" type="xs:boolean" substitutionGroup="transformation"/>
        <xs:element name="is-floor-moderator" type="xs:boolean" substitutionGroup="transformation"/>
        <xs:element name="show-conference-info" type="xs:boolean" substitutionGroup="transformation"/>
        <xs:element name="show-floor-holder" type="xs:boolean" substitutionGroup="transformation"/>
        <xs:element name="show-floor-requests" type="xs:boolean" substitutionGroup="transformation"/>
        <!-- Dial-Out List (DL) Target -->

   <?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"> name="Target">
                <xs:sequence>
                        <xs:element name="DL-target" name="target" minOccurs="0" maxOccurs="unbounded">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="DL-target-URI" type="xs:anyURI"/>
                                                <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                                        </xs:sequence>
                                        <xs:attribute name="uri" type="xs:anyURI" use="required"/>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>
        <!-- Security Control (SC) -->

   <?xml version="1.0" encoding="UTF-8"?>
   <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"> name="ConferenceSC">
                <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"> name="security-mechanism">
                                <xs:complexType>
                                        <xs:attribute name="TLS" name="tls" type="xs:boolean" default="false"/>
                                        <xs:attribute name="S-MIME" name="s-mime" type="xs:boolean" default="false"/>
                                </xs:complexType>
                        </xs:element>
                        <xs:element name="SC-target"
                        <xs:any namespace="##other" processContents="lax" 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> maxOccurs="unbounded"/>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>
        <!-- Conference Floor policy Control 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"> name="ConferenceFloorPolicy">
                <xs:sequence>
                        <xs:element name="Floor" name="floor" maxOccurs="unbounded">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element name="Media-types"> name="media-streams" type="ConferenceMediaStreams"/>
                                                <xs:element name="algorithm">
                                                        <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" name="moderator-controlled" minOccurs="0"/>
                                                                        <xs:element name="Message" name="fcfs" minOccurs="0"/>
                                                                        <xs:element name="Text" name="random" 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"/> name="max-floor-users" type="xs:nonNegativeInteger" minOccurs="0" default="1"/>
                                                <xs:element name="Random" name="moderator-URI" type="xs:anyURI" 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="floor-control" type="xs:anyURI"/>
                                        <xs:attribute name="moderator-controlled" type="xs:boolean" default="false"/>
                                </xs:complexType>
                        </xs:element>
                </xs:sequence>
        </xs:complexType>
   </xs:schema>
        <!-- Conference 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> Streams -->
        <xs:complexType name="ConferenceMediaStreams">
                <xs:sequence>
                        <xs:element name="Video" minOccurs="0"/> name="video" type="Media" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="Audio" minOccurs="0"/> name="audio" type="Media" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="Application" minOccurs="0"/> name="application" type="Media" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="Data" minOccurs="0"/> name="data" type="Media" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="Control" minOccurs="0"/> name="control" type="Media" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="Message" minOccurs="0"/> name="message" type="Media" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="Text" minOccurs="0"/> name="text" type="Media" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
        </xs:complexType>
                                </xs:element>
        <!-- Start/Stop time -->
        <xs:complexType name="StartStopTime">
                <xs:simpleContent>
                        <xs:extension base="xs:dateTime">
                                <xs:attribute name="required-participant" use="required">
                                        <xs:simpleType>
                                                <xs:restriction base="xs:string">
                                                        <xs:enumeration value="key-participant"/>
                                                        <xs:enumeration value="participant"/>
                                                        <xs:enumeration value="none"/>
                                                </xs:restriction>
                                        </xs:simpleType>
                                </xs:attribute>
                        </xs:extension>
                </xs:simpleContent>
        </xs:complexType>
        <!-- Sidebar -->
        <xs:complexType name="Sidebar">
                <xs:sequence>
                        <xs:element name="uri" type="xs:anyURI" minOccurs="1" maxOccurs="unbounded"/>
                        <xs:element name="policy" type="xs:anyURI" minOccurs="0"/>
                        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:attribute name="id" type="xs:string" use="required"/>
        </xs:complexType>
        <!-- Media -->
        <xs:complexType name="Media">
                <xs:attribute name="media-id" type="xs:string" use="required"/>
        </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 Policy Manipulation and
   defining a floor Conference Entity Behaviour

5.1  Overview of Operation

   This document assumes that the user knows the location of conference
   policy belongs serve, the details of that discovery are beyond the scope of
   this document.

   CPCP allows clients to CPCP. Moreover, setting some key
   floor parameters, such as floor moderator manipulate the conference policy at conference
   policy server (CPS).  CPS is able to inform the focus about changes
   in moderator controlled
   floor conference policy, belongs if necessary.  For example, if new users are
   added to CPCP. FCP only defines how 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 request,
   grant, deny and revoke a floor within given the conference policy server (CPS) when
   they perform manipulation operations.  It is assumed that the CPS
   informs other conferencing entities, such as focus, the floor policy. control
   server and the mixer directly or via the focus.  For example, if user
   A wants to expel user B from an ongoing conference, user A must first
   manipulate the conference policy data.  The CPS then communicates
   that change to the focus to perform the operation.

5.2  Use of External Lists

   External lists MAY be used in a typical conference policy.  They can be used
   in the dial-out list, the refer-list and the authorization policy.
   An external list is a list of resources created by means outside the
   scope of this document.

   A privileged conference user
   (creator) of the conference policy uses CPCP for creating an external list by
   placing its manipulation URI in an element that carries a floor for audio plane, defining URI.  At
   the time the focus needs to activate the floor policy as "moderator-controlled" surrounding the URI,
   the focus fetches the URIs for the members of the external list using
   the list URI.  For example, a conference creator creates a conference
   and appointing one user -
   possibly himself - places the URI of an external list in the dial-out list.  At some
   point, the focus needs to act as a floor moderator governing invite using on the access dial-out list to join
   the floor.

   When conference.  It is at that moment that the floor has been created focus retrieves the
   members of the external list.  It then sends INVITE (in SIP terms) to
   the members of that external list.  This results in all participants
   connected to one focus.

   In can happen that the external list is not accessible at the time
   the focus requires it.  In this case, the external list is ignored,
   and possible floor moderator in the case of an authorization rule, that rule fails.

   There are also cases where the external list has been
   assigned, manipulated.
   It is outside the floor moderator gets notifications from scope of this document how the focus and can learn of
   such manipulation.  But if is able to accept or deny floor requests from the conference users.
   Note that FCP does not create media streams (just does, it reacts in a similar manner as
   it would have if the virtual floor
   attached list was local and has been modified.

   If an external list contains a reference to media), as media streams are created using CPCP. yet another list, that
   reference is ignored.

5.3  Communication Between Conference Entities

   The
   details of FCP are communication between different (logical) conferencing elements
   is beyond the scope of this draft.

6. An XCAP Usage for Conference Policy Manipulation

6.1 Application Unique ID

   XCAP requires application usages document.  It can be expected that in
   most cases CPS includes also those logical functions.

5.4  Manipulating Participant Lists

   A user with sufficient privileges is allowed to define perform user
   management operations, such as adding a unique application usage
   ID (AUID) in either new user to the IETF tree conference or
   expelling a vendor tree. This
   specification defines user from the    "conference-policy" AUID within conference.  These operations are performed
   by modifying the IETF
   tree, via conference policy at the IANA registration in Section 9.

6.2 Resource Interdependencies

   The conference policy server must fill server.

   After authorising the user to do such manipulations, the conference URI(s), if
   policy server communicates the change to the focus.  The focus reacts
   by performing singlling operations such as sending SIP INVITE, BYE or
   REFER.

5.4.1  Expelling a
   conference URI was not proposed Participant

   Expelling a user is performed by the client. a privileged user creating or
   manipulating an existing authorization rule and setting that user's
   <join-handling> action to "block>.  The client then needs focus reacts by terminating
   the session with that participant, such as a sending SIP BYE request.

   Care must be taken since if one rules allows a user to perform join and one
   blocks a HTTP GET user from joining, the result in that the user is allowed to
   join.  For example, Bob can join a conference since an authorization
   rule has been defined to allow everyone at example.com:

        <rule id="1">
                <conditions>
                        <identity>
                                <domain>example.com</domain>
                        </identity>
                </conditions>
                <actions>
                        <join-handling>allow</join-handling>
                </actions>
                <transformations/>
        </rule>

   Setting the following rule will not block Bob from joining nor will
   it expel him since the above rule overrides it:

        <rule id="2">
                <conditions>
                        <identity>
                                <uri>bob@example.com</uri>
                        </identity>
                </conditions>
                <actions>
                        <join-handling>block</join-handling>
                </actions>
                <transformations/>
        </rule>

   So, in order to     retrieve expel Bob, the original rule has to be modified policy containing using
   the
   assigned conference URI(s). The CPS MAY assign multiple <except> element:

        <rule id="1">
                <conditions>
                        <identity>
                                <domain>example.com</domain>
                                <except>bob@domain.com</except>
                        </identity>
                </conditions>
                <actions>
                        <join-handling>allow</join-handling>
                </actions>
                <transformations/>
        </rule>

5.5  Re-joining a Conference

   Participants can drop out of a conference
   URIs for many reasons including:
   client crash, out of coverage, had to a conference, one leave 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 a while.  It might be
   of interest to enable that need user to be defined for this
   application usage.

6.5 Authorization Policies

   This application usage does not modify re-join the default XCAP authorization
   policy, which is conference.  To allow
   that, participants that have departed the conference gracefully can
   only re-join if a user can read, write or modify their own
   documents. A server  can allow privileged users user has added an authorization rule
   allowing them to modify documents join.  Participants that they don't own, but the establishment and indication of such
   policies is outside have departed the scope of this document. It   is anticipated
   that a future application usage will define which users are allowed
   to modify
   conference ungracefully (eg: crash) require a list resource.

6.6 MIME Type for CPCP XML Document

   The MIME type for special behaviour from
   the CPCP XML document focus .  The focus is defined in Section 4.1

6.7 Overview of Operation

   This document assumes that the aware when a user knows the location of has not gracefully
   departed a conference
   policy server (the XCAP URI), (for example; it did not receive a SIP BYE
   request and media is no longer being received).  If this is the details of that discovery are
   beyond case,
   the scope of this     document.

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

   CPCP allows clients required to manipulate re-issue the conference policy at conference
   policy server (CPS). CPS invitation or referral to that
   user after a pre-configured unit of time.

5.6  Floor Control Policy vs. Floor Control Protocol

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

   For example, if new users are
   added to the dial-out list, then in a typical conference policy server informs the
   focus which makes privileged conference user
   uses CPCP for creating a floor for audio plane, defining the invitations floor
   policy as requested.

   Some assumptions about "moderator-controlled" and appointing one user - possibly
   himself - to act as a floor moderator governing the conferencing architecture are made.
   Clients always connect access to the conference policy server (CPS) when
   they perform XCAP    operations. It is assumed that CPS informs other
   conferencing entities, such as focus,
   floor.

   When the floor control server has been created and mixer
   directly or via focus. For example, if user A        wants a floor moderator has been
   assigned, the floor moderator gets notifications from the focus and
   is able to expel user B accept or deny floor requests from an ongoing conference, user A must first manipulate the conference policy data. CPS then communicates users.
   Note that change to FCP does not create media streams (just the
   focus virtual floor
   attached to     perform the operation.

6.8 Communication Between Conference Entities media), as media streams are created using CPCP.  The communication between different (logical) conferencing elements
   is
   details of FCP are 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 draft.

6.  An XCAP Usage for the CPS to communicate changes Conference Policy Manipulation

6.1  Application Unique ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the conference policy is for IETF tree or a vendor tree.  This
   specification defines the focus to    subscribe to "conference-policy" AUID within 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 IETF
   tree, via the IANA registration in Section 6.12 and Section 4.2.1.

   A user may create a new 9.

6.2  Resource Interdependencies

   The 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 server MAY fill the creation.

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

   A running conference instance can be also stopped URI.  If the CPS does not allow
   assignments of URIs by modifying the
   conference time information. This leaves conference ACLs and
   privileges intact but stops client, it rejects the conference.

   If request with a conference is
   "409" response and SHOULD include a body 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 response detailing
   the Participant Lists

   A user with sufficient privileges is allowed to perform user
   management operations, error.  XCAP Base document [10] section 7.2.1 explains how such as adding a new user to the
   response body is constructed.  The CPS MAY assign multiple conference or
   expelling
   URIs to a user from conference, one for each call signaling protocol that it
   supports.  Section 4.3.1  discusses this is more detail.

   Sidebar URIs are subject to the    conference. same behaviour.

6.3  Additional Constraints

   These operations are performed
   by modifying the conference policy at the conference policy server.
   After authorising defined within the user XML structure definition.

6.4  Naming Conventions

   There are no naming conventions that need to do such        manipulations, the conference
   policy be defined for this
   application usage.

6.5  Authorization Policies

   A server communicates the change can allow privileged users to the focus. modify documents that they
   don't own.  The focus reacts
   by performing operations establishment and indication of such as sending SIP INVITE, BYE     or REFER.

   Asking policies is done
   by setting the focus to invite a user into authorization rules as described in Section 4.3.4.

6.6  MIME Type for CPCP XML Document

   The MIME type for the conference CPCP XML document is achieved by
   sending defined in Section 4.1

7.  Examples

   The following is an example of a HTTP PUT request document compliant to the CPS that modifies schema:

   Below is an example how to create a conference:

7.1  An Example CPCP Document

   Alice creates a conference with the Dial-Out List
   (DL) adding follows policy:

   o  Conference URIs are suggested to it. be sip:myconference@example.com
      and tel:+3581234567.

   o  Maximum number of participants in the conference is 10.

   o  The CPS then triggers conference allows side-bars

   o  Media mixing starts at the focus to send latter of 9:30 am and the first
      participant arrives

   o  Media mixing sends at 12:30 pm.  The conference invitation, eg: SIP INVITE(s) as needed. Similarly, a user
   can be removed from the Dial-out list by issuing does not need a   HTTP DELETE
   removing the URIs.

   Asking the focus
      key participant to allow certain users continue.

   o  Users can join 5 minutes before media mixing starts and cannot
      join half an hour before media mixing ends.

   o  Users are requested to join a conference (invited and referred) 5
      minutes before the conference starts and no participant nor
      key-participant is
   done by sending a HTTP PUT request needed for this action to take place.

   o  Everyone at the CPS that modifies the ACL
   by adding URIs with  access type of "Allowed". The CPS then informs
   the focus of such change domain example.com is allowed to join and can
      subscribe to the ACL.

   If the conference state event package.

   o  Alice 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 a key participant

   o  Alice will be invited to join the situation
   that conference while Sarah will be
      referred to the ACL contains many unnecessary rules which are not really
   needed anymore. Therefore, there conference.

   o  No TLS, will be used but S/MIME is a need required.

   o  PIN code is set to delete ACL    rule. This
   can be achieved with the HTTP DELETE.

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

6.10.1 Expelling abcd1234.

   o  One floor is created for audio and a Participant

   Expel operation uses the HTTP PUT request as well, as first-come-first-serve
      policy.

   o  Two media are made available in the user is put
   on conference:audio and video.

   The resulting CPCP document looks like

   <?xml version="1.0" encoding="UTF-8"?>
   <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <settings>
                <conference-uri>sip:myconference@example.com</conference-uri>
                <max-participant-count>10</max-participant-count>
                <allow-sidebars>true</allow-sidebars>
        </settings>
        <info xml:lang="en-us">
                <subject>What's happening tonight</subject>
                <display-name>Party Goer's</display-name>
                <free-text>John and Peter will join the ACL list conference soon</free-text>
                <keywords>party nightclub beer</keywords>
                <host-info>
                        <uri>sip:Alice@example.com</uri>
                        <uri>tel:+3581234567</uri>
                        <e-mail>mailto:Alice@example.com</e-mail>
                        <web-page>http://www.example.com/users/Alice</web-page>
                </host-info>
        </info>
        <time>
                <occurrence>
                        <mixing-start-time required-participant="participant">2004-12-17T09:30:00-05:00</mixing-start-time>
                        <mixing-stop-time required-participant="none">2004-12-17T12:30:00-05:00</mixing-stop-time>
                        <can-join-after>2001-12-17T09:25:00-05:00</can-join-after>
                        <must-join-before>2004-12-17T12:00:00-05:00</must-join-before>
                        <request-users required-participant="none">2001-12-17T09:30:00-05:00</request-users>
                </occurrence>
        </time>
        <authorization-rules>
                <rule id="1">
                        <conditions>
                                <identity>
                                        <domain>example.com</domain>
                                </identity>
                        </conditions>
                        <actions>
                                <allow-conference-state>true</allow-conference-state>
                                <join-handling>allow</join-handling>
                        </actions>
                        <transformations/>
                </rule>
                <rule id="2">
                        <conditions>
                                <identity>
                                        <id>alice@example.com</id>
                                </identity>
                        </conditions>
                        <actions>
                                <allow-sidebar>true</allow-sidebar>
                        </actions>
                        <transformations>
                               <is-key-participant>true</is-key-participant>
                        </transformations>
                </rule>
        </authorization-rules>
        <dailout-list>
                <target uri="sip:bob@example.com"/>
        </dailout-list>
        <refer-list >
                <target uri="sip:sarah@example.com"/>
        </refer-list >
        <security-control>
                <security-mechanism tls="false" s-mime="true"/>
                <pin>13579</pin>
                <password>abcd1234</password>
        </security-control>
        <floor-policy>
                <floor floor-control="fcp://example.com/floorabc" moderator-controlled="false">
                        <media-streams>
                                <audio media-id="2"/>
                        </media-streams>
                        <algorithm>
                                <fcfs/>
                        </algorithm>
                        <max-floor-users>1</max-floor-users>
                </floor>
        </floor-policy>
        <media-streams>
                <video media-id="1"/>
                <audio media-id="2"/>
        </media-streams>
   </conference>

7.2  CPCP Manipulations Using XCAP

   1.  Creating a Conference

   Continuing with an access type of "Expelled". This also triggers the CPS example from Section 7.1, Alice's client uses
   XCAP to transport the conference policy to   inform the focus about conference policy
   server

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

      Content-Type: application/conference-policy+xml

      [conference policy from Section 7.1 goes here.

   At exactly 2004-12-17T09:30:00-05:00, the need focus sends SIP INVITE
   request to issue a terminating
   request, such as Alice and a SIP BYE.

   A participant cannot REFER request to Sarah.  At
   2004-12-17T09:25:00-05:00, SIP INVITE requests can be expelled by placing him in the ACL list with
   an action accepted from
   anyone at domain example.com.  Any attempts to block. This is because join the focus interprets conference by
   users in other domains are rejected.

   2.  Expelling a user
   placed on User

   After the block list as a user   who is not allowed conference has started, Alice decides to dial into expel Bob who has
   joined the conference, but does not prohibit conference.  So she modifies the focus from inviting authorization rule that
   user
   allows everyone at example.com to join, if that user is on the Dial-out list. Having the user
   on an        Expel list explicitly informs join:

      PUT
      http://xcap.example.com/services/conferences/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1

      Content-Type:text/plain

   <identity>
        <domain>example.com</domain>
        <except>bob@example.com</except>
   </identity>

   At this point, 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 sends a need for different privileges SIP BYE request to exist where users can
   modify certain parts of Bob ending Bob's
   participation in the conference policy XML document. conference.  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 also guarantees that only the creator of Bob
   cannot rejoin the document conference since he is explicitly blocked.  Any
   attempt Bob makes in rejoining the sole user conference will fail.

   3.  Allowing An Expelled Participant To Join Again

   Continuing with write access.

   This specification, however, makes ready the CPCP XML document example above, Alice now decides to allow an external usage document Bob to define which parts of such an XML
   document
   join again after a user      can modify (which parts period of an XML document a user
   has read/write access to) time.  She does so 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 rewriting parts of another XCAP XML
   document uses namespaces as
   the key to allow/disallow        users from
   reading and/or modifying rule that XCAP usage document.

6.12 Conference URI(s)

   A conference is identified by one or more conference URIs. Conference
   URIs blocks him from joining.

      PUT
      http://xcap.example.com/services/conferences/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1

      Content-Type:text/plain

   <identity>
        <domain>example.com</domain>
   </identity>

   Bob can be proposed by the creator of now rejoin 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 sending a conference URI,
   the server needs SIP INVITE request.

   4.  Allowing Sarah to decide whether it        accept the name proposed by
   the client or not. It does this determination by examining if Refer Users

   Alice now decides that Sarah can ask the
   conference URI already exists or not. If it exists, focus to refer users to the server ...
   conference:

      PUT
      http://xcap.example.com/services/conferences/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id="3"] HTTP/1.1

      Content-Type:text/plain

   <rule id="3">
        <conditions>
                <identity>
                        <uri>sarah@example.com</uri>
                </identity>
        </conditions>
        <actions>
                <allow-refer-users-dynamically>true</allow-refer-users-dynamically>
        </actions>
        <transformations/>
   </rule>
   5.  Removing 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

   Alice now decides she no longer wants this conference URIs to a conference, one for each call
   signaling protocol that it supports. If exist and
   therefore deletes the creator 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
   policy proposed a server
   terminates the focus thereafter.

8.  Security Considerations

   A conference URI for a       protocol document may contain information that is highly
   sensitive.  Its delivery to the conference server does
   not support, needs to happen
   strictly, paying special attention to integrity and confidentiality.
   Reading the server ...

7. Examples

   The following document is an example of also a document compliant to security concern since the schema:

   Below conference
   policy contains sensitive information like the PIN code, password of
   the conference, the topic of the conference, who is an example how allowed 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"
                        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
   and the URIs of the users that can participate.

   Manipulations of 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>
        </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, policy have similar security issues.
   Users with relevant privileges can manipulate parts of the conference server creates a focus
   policy giving themselves and
   sends SIP INVITE requests others privileges to Alice manipulate the
   conference policy, including the dial-out list and Sarah. After the focus is created,
   SIP INVITE requests security
   control settings for a conference.  This can be accepted from anyone at domain example.com.
   Any attempts to join happen because the
   conference by users in other domains are rejected.

   2. Expelling a User

   Continuing with policy it self carries the above example: aftar identities and the conference has started,
   Alice decides
   authorization rules that apply to expel Bob who has joined those identities.  Those
   authorization rules carry the conference. So she adds him privileges that certain identities
   have.  If an unauthorized user gets access to this document
   (pretending to be someone else), s/he can manipulate those rules
   giving himself and other unauthorized users access to the ACL list with Access-type conference
   policy.  S/he can also manipulate other parts 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 conference
   policy under a false identity.  Some of the conference. This also guarantees things that Bob cannot rejoin a malicious
   user can do include: denying users certain privileges, giving himself
   floor moderation, removing users from lists, removing rules for
   certain identities, giving privileges to other malicious users,
   changing the media streams and changing conference since
   he is expilictly expelled until his URI time.  Therefore,
   it is removed from very important that only authorized clients are able to
   manipulate the ACL Expelled list. conference policy.  Any attempt Bob makes in rejoining the conference will fail.

   3. Allowing An Expelled Participant To Join Again

   Continuing with policy transport
   protocol MUST provide authentication, confidentiality and integrity.

   In the example above, Alice now decides to allow Bob case that XCAP is used to join
   again after create and manipulate a period of time. She does so by removing his entry in conference
   policy, the
   ACL XCAP base specification mandates that identifies him all XCAP servers
   MUST implement HTTP Authentication: Basic and Digest Access
   Authentication [16].  Furthermore, XCAP servers MUST implement HTTP
   over TLS [17].  It is recommended that administrators of XCAP servers
   use an HTTPS URI 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 XCAP root services URI, so that the digest
   client authentication occurs over TLS.  By using these means, XCAP
   client and therefore
   deletes server can ensure the conference:

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

   As a result confidentiality and integrity of this action, the focus sends SIP BYE requests to all current
   participants in the conference. The
   XCAP created conference server terminates the focus thereafter.

8. Security Considerations

   See section Section 4.2.7. policy document  and its manipulation
   operations, and that only authorized clients are allowed to perform
   them.

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 MIME TYPE

   MIME media type: application

   MIME subtype name: conference-policy+xml

   Mandatory parameters: none

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

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

   Security considerations: See section 10 of RFC 3023 [6] [7] 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]. [15].

   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:

   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, Adam Roach, Eunsook Kim
   Kim, Roni Evan and the IETF
   conferencing design team XCON working group for their feedback. feedback and
   suggestions.

12.  References

12.1  Normative References

   [1]   Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J.
         Rosenberg, "Common Policy", Internet-Draft
         I-D.ietf-geopriv-common-policy, February 2004.

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

   [2]

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

   [3]

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

   [4]   Rosenberg et al.,

   [5]   Rosenberg, 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]

   [6]   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]

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

   [7]

   [8]   Koskelainen, P. and H. Khartabil, "Requirements for conference
         policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
         progress), January 2004.

   [8]

   [9]   Johnston, A. and O. Levin, "Session Initiation Protocol Call
         Control - Conferencing for User Agents",
         draft-ietf-sipping-cc-conferencing-03 (work in progress),
         February 2004.

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

   [9]

   [11]  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]

   [12]  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]

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

   [12]

   [14]  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]

   [15]  Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-05 RFC 3688, January 2004.

   [16]  Franks, J., "HTTP Authentication: Basic and Digest Access
         Authentication", RFC 2617, June 1999.

   [17]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

12.2  Informative References

   [18]  Jennings, C. and B. Rosen, "Media Mixer Control for XCON",
         draft-jennings-xcon-media-control-00 (work in progress),
         February 2004.

   [19]  Handly, M., Eriksson, G., Jacobson, V. and C. Perkins,
         "Grouping of Media Lines in SDP", draft-ietf-mmusic-sdp-new-18
         (work in progress), June
         2003. 2004.

Authors' Addresses

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

   EMail: hisham.khartabil@nokia.com

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

   EMail: petri.koskelainen@nokia.com

   Aki Niemi
   Nokia
   P.O. Box 100
   NOKIA GROUP, FIN  00045
   Finland

   Phone: +358 50 389 1644
   EMail: aki.niemi@nokia.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   Intellectual Property Rights 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 nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which that may cover technology that may be required to practice implement
   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 at
   ietf-ipr@ietf.org.

Disclaimer 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. Validity

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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