draft-ietf-xcon-common-data-model-02.txt  -->   draft-ietf-xcon-common-data-model-03.txt

view Side-By-Side changes


XCON                                                             O. Novo
Internet-Draft                                              G. Camarillo
Intended status: Informational                                  Ericsson
Expires: January 11, April 13, 2007                                       Ericsson                                        D. Morgan
                                                    Fidelity Investments
                                                                 R. Even
                                                                 Polycom
                                                           July
                                                        October 10, 2006


A Common Conference Information Data Model for Centralized Conferencing
                                 (XCON)
                draft-ietf-xcon-common-data-model-02.txt
                draft-ietf-xcon-common-data-model-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on January 11, April 13, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document collects, organizes, and describes the conference
   variables that have been introduced in various protocol drafts of the
   XCON and SIPPING working groups.  The goal of this document is to



Novo, et al.             Expires January 11, April 13, 2007                 [Page 1]

Internet-Draft          Common Conference Schema               July            October 2006


   allow the conference control protocols to use a unified common
   conference information data model for XCON.  This document formally
   defines an Extensible Markup Language (XML) Schema that represents
   the common conference information in a conferencing server.  The
   information is modeled as a series of elements, each of which
   contains a set of children and attributes.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Common Conference Data . . . . . . . . . . . . . . . . . . . .  4
     3.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  <conference-description> . . . . . . . . . . . . . . . . . 11
       3.2.1.  <conference-time>  . . . .  Common Conference Policies . . . . . . . . . . . . . . 12
       3.2.2.  <conf-uris> . .  9
     3.3.  <conference-description> . . . . . . . . . . . . . . . . . 10
       3.3.1.  <conference-time>  . . 13
       3.2.3.  <service-uris> . . . . . . . . . . . . . . . . 11
       3.3.2.  <conf-uris>  . . . . 13
       3.2.4.  <maximum-user-count> . . . . . . . . . . . . . . . . . 13
       3.2.5.  <maximum-streams>  . . . . . . . . . . . . . . . . . . 14
       3.2.6.  <available-media>  . . . . . . . . . . . . . . . . . . 14
       3.2.7.  <controls> . . . . . . . .
       3.3.3.  <service-uris> . . . . . . . . . . . . . . 14
         3.2.7.1.  mute . . . . . . 13
       3.3.4.  <maximum-user-count> . . . . . . . . . . . . . . . . . 15
         3.2.7.2.  pause-video 13
       3.3.5.  <maximum-streams>  . . . . . . . . . . . . . . . . . . 13
       3.3.6.  <available-media>  . 15
     3.3.  <host-info> . . . . . . . . . . . . . . . . . 13
       3.3.7.  <controls> . . . . . . 16
     3.4.  <conference-state> . . . . . . . . . . . . . . . . 14
         3.3.7.1.  mute . . . . 16
     3.5.  <security-mechanism> . . . . . . . . . . . . . . . . . . . 16
       3.5.1.  <methods> 14
         3.3.7.2.  pause-video  . . . . . . . . . . . . . . . . . . . 14
         3.3.7.3.  gain . . . 17
       3.5.2.  <option-tags> . . . . . . . . . . . . . . . . . . . . 17
       3.5.3.  <feature-tags> 15
     3.4.  <host-info>  . . . . . . . . . . . . . . . . . . . . 17
       3.5.4.  <bodies> . . . 15
     3.5.  <conference-state> . . . . . . . . . . . . . . . . . . . . 17 15
     3.6.  <floor-information>  . . . . . . . . . . . . . . . . . . . 18 15
     3.7.  <users>  . . . . . . . . . . . . . . . . . . . . . . . . . 19 16
       3.7.1.  <allowed-users-list> . . . . . . . . . . . . . . . . . 20 17
       3.7.2.  <privileges-control-list>  . . . . . . . . . . . . . . 20 18
         3.7.2.1.  <data-access-rights> . . . . . . . . . . . . . . . 20
         3.7.2.2.  <conference-rules> . . . . . . . . . . . . . . . . 21
           3.7.2.2.1. 18
           3.7.2.1.1.  <condition>  . . . . . . . . . . . . . . . . . 21
             3.7.2.2.1.1.  <external-list>  . . . . . 18
           3.7.2.1.2.  <pseudonymous> . . . . . . . . 22
             3.7.2.2.1.2.  <pseudonymous> . . . . . . . . 19
           3.7.2.1.3.  <has-been-referred>  . . . . . . 22
             3.7.2.2.1.3.  <has-been-referred> . . . . . . . 19
           3.7.2.1.4.  <has-been-invited> . . . . 22
             3.7.2.2.1.4.  <has-been-invited> . . . . . . . . . . 19
           3.7.2.1.5.  <has-been-in-conference> . . 22
             3.7.2.2.1.5.  <has-been-in-conference> . . . . . . . . . 22
             3.7.2.2.1.6. 19
           3.7.2.1.6.  <is-in-conference> . . . . . . . . . . . . 22
             3.7.2.2.1.7.  <administrator> . . 19
           3.7.2.1.7.  <administrator>  . . . . . . . . . . . 23
             3.7.2.2.1.8.  <is-on-allowed-users-list-dial-out> . . . 23
             3.7.2.2.1.9.  <is-on-allowed-users-list-refer> . 19
           3.7.2.1.8.  <is-on-allowed-users-list-dial-out>  . . . . 23
             3.7.2.2.1.10. <participant-passcode> . 20
           3.7.2.1.9.  <is-on-allowed-users-list-refer> . . . . . . . 20
           3.7.2.1.10. <participant-passcode> . . 23



Novo, et al.            Expires January 11, 2007                [Page 2]

Internet-Draft          Common Conference Schema               July 2006


             3.7.2.2.1.11. <administrators-passcode> . . . . . . . . 24
           3.7.2.2.2.  <actions> . . 20
           3.7.2.1.11. <administrators-passcode>  . . . . . . . . . . 20
         3.7.2.2.  <actions>  . . . . . . 24
       3.7.3.  <user> . . . . . . . . . . . . . . 21
     3.8.  <user> . . . . . . . . . . 25
         3.7.3.1.  from_mixer, to_mixer . . . . . . . . . . . . . . . 26
           3.7.3.1.1.  <floor> . 22
       3.8.1.  from-mixer, to-mixer . . . . . . . . . . . . . . . . . 23
         3.8.1.1.  <floor>  . 27
           3.7.3.1.2.  <gain> . . . . . . . . . . . . . . . . . . . . 27
     3.8. 23



Novo, et al.             Expires April 13, 2007                 [Page 2]

Internet-Draft          Common Conference Schema            October 2006


     3.9.  <sidebars-by-ref>  . . . . . . . . . . . . . . . . . . . . 28
     3.9. 24
     3.10. <sidebars-by-val>  . . . . . . . . . . . . . . . . . . . . 28 24
   4.  XML Schema . . .  RELAX NG schema  . . . . . . . . . . . . . . . . . . . . . . . 28 24
   5.  XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 42 48
   6.  XML example  . . . . . . . . . . . . . . . . . . . . . . . . . 43 49
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 53 58
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 53 58
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 58
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 58
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 53 58
     10.2. Informative References . . . . . . . . . . . . . . . . . . 54 59
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 59
   Intellectual Property and Copyright Statements . . . . . . . . . . 56 61






































Novo, et al.             Expires January 11, April 13, 2007                 [Page 3]

Internet-Draft          Common Conference Schema               July            October 2006


1.  Introduction

   This document defines an Extensible Markup Language (XML) Schema that
   represents the common conference information object in a conferencing server.  The
   information is modeled as a series of elements, each of which
   contains children and attributes.

   The common conference information is a part of the Conference Object.
   The Conference Object contains the XML schema, which is used to
   represent the core information that is utilized in any conference
   (capabilities,membership,
   (capabilities, membership, roles, call control signalling, media,
   etc...) and specifies the set of rights, permissions and limitations
   pertaining to operations being performed on a certain Conference
   Object.

   This document gives an overview of the conference variables that have
   been introduced in various protocol drafts of the XCON working group
   to date and proposes to create a unified common conference
   information data model for XCON.

   This document has been constructed in compliance with the XCON
   Framework [1] and the Session Initiation Protocol (SIP) Event Package
   for Conference State [2].  It also incorporates data elements
   proposed in several XCON WG and SIPPING WG drafts.

   [Editors Note: This document is still in early stages of development
   and is intended to trigger discussions.]


2.  Terminology

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

   This document uses the terminology defined in the XCON Conferencing
   Framework [1] and the SIPPING Conferencing Framework [4].  In
   addition, it uses definitions from The Binary Floor Control Protocol
   [7].


3.  Common Conference Data

3.1.  General

   The conference object data model document is an XML [5] document that
   MUST be well formed and SHOULD be valid.  Conference object data
   model documents MUST be based on XML 1.0 and SHOULD be encoded using



Novo, et al.            Expires January 11, 2007                [Page 4]

Internet-Draft          Common Conference Schema               July 2006
   UTF-8.

   A Common Conference information document begins with the root element
   tag <conference-info> of conference-type.  The <conference-info> has



Novo, et al.             Expires April 13, 2007                 [Page 4]

Internet-Draft          Common Conference Schema            October 2006


   the attribute 'entity' that contains the conference unique identifier
   that identifies the conference being described in the document.

   The <conference-info> element is comprised of <conference-
   description>, <host-info>, <conference-state>, <security-mechanism>,
   <Floor Information>, <floor-information>,
   <users>, <sidebars-by-ref>, <sidebars-by-val>, child elements.  A
   common conference document must at least include the <conference-description>, <conference-
   description>, <host-info>, <conference-state>,
   <available-media>, and <users> child
   elements.  Some of this information can be represented using the
   conference-info-type schema as defined in [2].

   Changes in the state of the conference should be communicated to the
   subscribers using a conference package subscribers (ex.  A Session
   Initiation Protocol (SIP) Event Package for Conference State).
   Critical changes should be communicated to specific subscribers,
   perhaps those with unique roles.  The conference policy control
   protocol msy be used to retrieve the conference state at any time.

   The following non-normative diagram gives an example of the overall
   hierarchy used in this format.  The operator "!" preceding an element
   indicates that this element is MANDATORY in the data model.  The
   operator "*" preceding an element indicates that this element is
   introduced/proposed in this draft.

   !<conference-info>
        |
        |--!<conference-description>
        |     |--<display-text>
        |     |--<subject>
        |     |--<free-text>
        |     |--<keywords>
        |     |--<web-page>
        |     |--<security-level>
        |     |--<allow-sidebars>
        |     |--<conference-stage>*     |--<conference-stage>
        |     |--<conference-time>
        |     |      |--<entry>
        |     |      |    |--<base>
        |     |      |    |--<mixing-start-offset>
        |     |      |    |--<mixing-end-offset>
        |     |      |    |--<can-join-after-offset>
        |     |      |    |--<must-join-before-offset>
        |     |      |    |--<request-user>



Novo, et al.            Expires January 11, 2007                [Page 5]

Internet-Draft          Common Conference Schema               July 2006
        |     |      |    |--<notify-end-of-conference>
        |     |      |    |--<allowed-extend-mixing-end-offset>
        |     |           ...
        |     |--<conf-uris>
        |     |      |--<SIP>



Novo, et al.             Expires April 13, 2007                 [Page 5]

Internet-Draft          Common Conference Schema            October 2006


        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |--<H323>
        |     |      |    |--<H.323-alias>
        |     |      |    |--<H.323-URI>
        |     |      |--<PSTN/ISDN>
        |     |      |    |--<phone number>
        |     |      |    |--<PIN-code>
        |     |      |    |--<purpose>
        |     |      |    |--<rate>*    |--<rate>
        |     |      ...
        |     |--<service-uris>
        |     |      |--<SIP>
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |--<H323>
        |     |      |    |--<H.323-alias>
        |     |      |    |--<H.323-URI>
        |     |      |--<PSTN/ISDN>
        |     |      |    |--<phone number>
        |     |      |--<BFCP>
        |     |      |    |--<conference-ID>
        |     |      ...
        |     |--<maximum-user-count>
        |     |      |--<entry>
        |     |      |--<entry>
        |     |      ...
        |     |--<maximum-streams>
        |     |      |--<entry>
        |     |      |--<entry>
        |     |      ...
        |     |--!<available-media>
        |     |      |--!<entry>
        |     |      |     |--<type>
        |     |      |     |--<display-text>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>
        |     |      |     |--<mix level>     |--<mix-level>
        |     |      |     |--<codecs>
        |     |      |     |    |--<entry>
        |     |      |     |    |--<entry>
        |     |      |     |    ...
        |     |      |     |--<controls>
        |     |      |     |      |--<control>    |--<mute>
        |     |      |     |    |--<gain>
        |     |--<display-text>     |      |     |   ...



Novo, et al.             Expires January 11, April 13, 2007                 [Page 6]

Internet-Draft          Common Conference Schema               July            October 2006


        |     |      |--<entry>
        |     |      |     |--<value>
        |     |      |     |      |--<control>
        |     |     |--<type>
        |     |      |     |--<display-text>
        |     |      |     |--<status>
        |     |     |--<value>      |     |--<mixing-mode>
        |     |      |     ...     |--<mix-level>
        |     |      |     |--<codecs>
        |     |      |     |    |--<entry>
        |     |      |     |    |--<entry>
        |     |      |     |    ...
        |     |      |--<entry>      |     |--<controls>
        |     |     |--<type>      |     |    |--<pause-video>
        |     |--<display-text>     |      |     |     |--<status>   ...
        |     |      ...
        |     |--<mixing-mode>
        |--!<host-info>
        |     |--<display-text>
        |     |--<web-page>
        |     |--<mix level>     |--!<uris>
        |     |     |--!<SIP>
        |     |--<controls>     |     |    |--!<uri>
        |     |      |--<control>     |    |--<display-text>
        |     |     |    |--<purpose>
        |     |--<display-text>     |     |--<H323>
        |     |     |    |--<H.323-alias>
        |     |     |--<value>     |    |--<H.323-URI>
        |     |     |--<PSTN/ISDN>
        |      |--<control>     |     |    |--<phone number>
        |           ...
        |--!<conference-state>
        |     |--<allow-conference-state>
        |     |--<display-text>     |--<user-count>
        |     |--!<active>
        |     |--<locked>
        |
        |--<floor-information>
        |     |--<allow-floor-events>
        |     |--<value>     |--<floor-request-handling>
        |     |--<conference-floor-policy>
        |     |     |--<floor>
        |     ...     |     |    |--<media-types>
        |     |--<codecs>     |     |    |--<algorithm>
        |     |    |--<entry>     |    |--<max-floor-users>
        |     |     |    |--<entry>    |--<moderator-uri>
        |     |     |    |--<moderator-uri>
        |    ...     |     |   ...
        |
        |--!<host-info>     |     |--<display-text>     ...
        |     |--<web-page>



Novo, et al.             Expires April 13, 2007                 [Page 7]

Internet-Draft          Common Conference Schema            October 2006


        |--!<users>
        |     |--!<uris>     |--<join-handling>
        |     |--<user-admission-policy>
        |     |--!<SIP>     |--<allowed-users-list>
        |     |     |--<target>
        |     |--!<uri>     |     |-- ...
        |     |     |--<display-text>
        |     |--<privileges-control-list>
        |     |     |--<purpose>    |--<conference-rules>
        |     |     |--<H323>    |     |--<entry>
        |     |    |--<H.323-alias>    |     |     |--<condition>
        |    |--<H.323-URI>     |    |     |--<PSTN/ISDN>     |     |     |--<identity>
        |    |--<phone number>     |           ...
        |--!<conference-state>    |     |--<allow-conference-state>     |     |--<user-count>     |     |--!<active>     |     |--<locked>



Novo, et al.            Expires January 11, 2007                [Page 7]

Internet-Draft          Common Conference Schema               July 2006     |
        |--<security-mechanism>
        |     |--<entry-protocol=SIP>     |    |     |--<methods>     |     |     |     |--<method>     ...
        |     |    |     ...     |     |     |--<option-tags>     |
        |     |     |--<option-tag>    |     |     |     ...     |--<validity>
        |     |     |--<feature-tags>    |     |     |     |--<feature-tag>     |     |--<from>
        |     |     ...    |     |     |--<bodies>     |     |     |--<until>
        |     |--<body-disposition>     |    |     |     |    |--<body-format>
        |     |    |     ...     |     |--<entry-protocol=H.323>*     |--<actions>
        |     |     |--<version>*    |     |--<entry-protocol=H.320>*     |     |     |--<supported>*     |     ...
        |
        |--<floor-information>     |     |--<allow-floor-events>    |     |--<floor-request-handling>     |     |--<conference-floor-policy>     |     ...
        |     |--<floor>     |    |    ...
        |    |--<media-types>     |
        |     |--!<user>
        |    |--<algorithm>     |    |--<display-text>
        |     |    |--<max-floor-users>    |--<associated-aors>
        |     |    |--<provide-anonymity>
        |    |--<moderator-uri>     |    |--<roles>
        |     |    |--<moderator-uri>    |    |
        |   ...     |    |   ...
        |
        |--!<users>     |     |--<join-handling>    |--<languages>
        |     |--<user-admission-policy>     |     |--<allowed-users-list>    |--<cascaded-focus>
        |     |     |--<target>    |--<sphere>
        |     |     |-- ...    |--<allow-refer-users-dynamically>
        |     |    |--<allow-invite-users-dynamically>
        |     |--<privileges-control-list>     |    |--<allow-remove-users-dynamically>
        |    |--<data-access-rights>     |    |--!<endpoint>
        |     |      |--<entry name=sidebars-by-ref>    |      |--<display-text>
        |     |      |--<entry name=sidebars-by-val>    |      |--<referred>
        |     |      |--<entry name=conference-time>    |     |    |      |--<entry name=mixing-start-offset>



Novo, et al.            Expires January 11, 2007                [Page 8]

Internet-Draft          Common Conference Schema               July 2006


        |     |    |     ...
        |     |    |
        |     |    |--<conference-rules>
        |     |    |     |--<entry>
        |     |    |     |     |--<condition>
        |     |    |     |     |     |--<identity>
        |     |    |     |     |     |     |
        |     |    |     |     |     |     ...
        |     |    |     |     |     |
        |     |    |     |     |     |--<validity>
        |     |    |     |     |     |     |--<from>
        |     |    |     |     |     |     |--<until>
        |     |    |     |     |
        |     |    |     |     |--<actions>
        |     |    |     |     |     |
        |     |    |     |     |     ...
        |     |    |    ...
        |     |
        |     |--!<user>
        |     |    |--<display-text>
        |     |    |--<associated-aors>
        |     |    |--<provide-anonymity>
        |     |    |--<roles>
        |     |    |    |
        |     |    |   ...
        |     |    |--<languages>
        |     |    |--<cascaded-focus>
        |     |    |--<sphere>
        |     |    |--<allow-refer-users-dynamically>
        |     |    |--<allow-invite-users-dynamically>
        |     |    |--<allow-remove-users-dynamically>
        |     |    |--<floors>
        |     |    |     |--<entry>
        |     |    |     |     |--<show-floor-holder>
        |     |    |     |     |--<show-floor-requests>
        |     |    |     ...
        |     |    |--<endpoint>
        |     |    |      |--<display-text>
        |     |    |      |--<referred>
        |     |    |      |--<status>      |--<status>
        |     |    |      |--<joining-method>
        |     |    |      |--<joining-info>
        |     |    |      |--<disconnection-method>
        |     |    |      |--<disconnection-info>
        |     |    |      |--<media>      |--!<media>
        |     |    |      |    |--<type>
        |     |    |      |    |--<display-text>
        |     |    |      |    |--<label>



Novo, et al.             Expires January 11, April 13, 2007                 [Page 9] 8]

Internet-Draft          Common Conference Schema               July            October 2006


        |     |    |      |    |--<src-id>
        |     |    |      |    |--<status>
        |     |    |      |    |--<to_mixer>
        |     |    |      |    |      |--<floor>
        |     |    |      |    |      |--<controls>
        |     |    |      |    |      |      |--<control>    |--<label>
        |     |    |      |    |--<src-id>
        |     |    |     |--<display-text>      |    |--<status>
        |     |    |      |    |--<to-mixer>
        |     |     |--<value>    |      |    |      |--<floor>
        |     |    |      |--<control>      |    |      |--<controls>
        |     |    |      |    |     |--<display-text>      |      |--<mute>
        |     |    |      |    |      |     |--<value>      |--<gain>
        |     |    |      |    |      |     ...
        |     |    |      |    |--<from_mixer>    |--<from-mixer>
        |     |    |      |    |      |--<floor>
        |     |    |      |    |      |--<controls>
        |     |    |      |    |      |      |--<control>
        |     |      |--<pause-video>
        |     |    |      |    |     |--<display-text>      |     ...
        |     |    |      |   ...
        |     |     |--<value>    |      |--<call-info>
        |     |    |      |    |--<sip>
        |      |--<control>     |    |      |    |   |--<display-text>
        |     |    |     |--<display-text>      |    |   |--<call-id>
        |     |    |      |    |     |--<value>   |--<from-tag>
        |     |    |      |    |   |--<to-tag>
        |          ...    ...
        |--<sidebars-by-ref>
        |     |--<entry>
        |     |     |-- <user>
        |   ...     |     |-- <display-text>
        |     |--<entry>
        |      |--<call-info>     |     |-- <user>
        |     |     |-- <display-text>
        |    |--<sip>     ...
        |--<sidebars-by-val>
        |     |--<entry>
        |     |     |
        |   |--<display-text>     |    ...
        |    |      |    |   |--<call-id>
        |     |    |      |    |   |--<from-tag>
        |     |    |      |    |   |--<to-tag>
        |          ...    ...
        |--<sidebars-by-ref>
        |     |--<entry>
        |     |     |-- <user>
        |     |     |-- <display-text>
        |     |--<entry>
        |     |     |-- <user>
        |     |     |-- <display-text>
        |     ...
        |--<sidebars-by-val>
        |     |--<entry>
        |     |     |
        |     |    ...
        |     |--<entry>     |--<entry>
        |     |     |
        |     ...   ...


   The following


   Following sections describe these elements in detail.  The full XML
   schema is provided in Section 4.

3.2.  Common Conference Policies

   Conference policies collectively refers to a set of rights,
   permissions and limitations pertaining to operations being performed
   on a certain conference object data model.




Novo, et al.             Expires January 11, April 13, 2007                 [Page 10] 9]

Internet-Draft          Common Conference Schema               July            October 2006


   XML schema is provided in Section 4.

3.2.  <conference-description>


   The <conference-description> element set of rights describes the read/write access privileges for the
   conference in its
   entirely.  It object data model as a whole.  Every element of the data
   model SHOULD have an extra has defined two attributes: the attribute 'xml:lang' to specify 'read-only',
   and the language used in attribute 'read-write'.  These attributes describes the contents of this element read/
   write access privileges for accessing the Conference Object as defined Section
   2.12 of [5]. a
   whole.  It is comprised of <display-text>, <subject>, <free-
   text>, <keywords>, <web-page>, <security-level>, <allow-sidebars>,
   <conference-stage>, <conference-time>, <conf-uris>, <service-uris>,
   <maximum-user-count>, <maximum-streams>, and <available-media>.

   The child elements <display-text>, <subject>, <free-text> and
   <keywords> are used to describe the conference content.  These
   elements are defined partially described in [2].

   The child element <web-page> is an optional element that points to [1].  When the conferencing
   server receives a
   URI with additional information about request for access privacy-sensitive data it needs
   to match it against the conference.  The child
   elements <security-level> 'read-only' and <allow-sidebars> describe the
   capabilities 'read-write' attributes.
   Each attribute of the conference.

   The <conference-stage> each individual element is evaluated and as a mandatory element
   result it is determined if the user can access that give element.  The
   attributes specify the stage of minimum subscriber's role that can access or
   modify the conference.  This element can have 4 values: reserved, started,
   running, and ended.  At of the reserved stage conference.  Subscribers with a lower role
   cannot access or modify the conference exists only element.  If an attribute is not defined
   in some element, the conference control server.  There is no running focus 'read-only' attribute MUST be interpreted as a
   "participant" and
   there are no subscribers or notifications.  The information is
   accessible only via the conference control protocol.  At the started
   stage, there are no users yet in the conference, still it 'read-write' attribute MUST be interpreted as
   an "administrator" by default.  It is possible to subscribe to defined only one of
   the conference state.  The running stage starts when attributes of the first user joins element, the conference.  In other attribute SHOULD be
   interpreted by default.  This draft does not define the ended stage, there are
   no users connected to set of
   possible conferencing roles.

   However, it can also be the conference, case that conflicts can occur given a
   hierarchy of elements.  In that case, the conference information is
   only in lower-level element
   privileges predominate over the conference server for recurring conference or for CDR.
   At this stage upper-level privileges element.

   This document defines a user can get information only from the conference
   control protocol.  For instance, The Session Initiation Protocol
   (SIP) Event Package for Conference State [2] is only applicable more specific right mechanism in Section
   3.7.2, beyond the start 'read-only' and running stage. 'read-write' attributes.

   The <conference-time> child element has information related to
   conference time permissions and duration limits are specified as an integral part of the conference.  Other
   data model, with elements from
   different namespaces MAY be present for containing the purposes allowed ranges for other
   elements (e.g., maximum number of
   extensibility.  The <conf-uris> participants) and <service-uris> are used lists of clients
   allowed to
   describe the conference-related identifiers. perform certain operations on a conference object.

3.3.  <conference-description>

   The <maximum-user-
   count> child <conference-description> element indicates describes the number of users that can be
   invited conference in its
   entirely.  It SHOULD have an extra attribute 'xml:lang' to specify
   the conference.  The <maximum-streams> child element
   indicates language used in the number contents of streams that can be for every media type.
   The <available-media> child this element as defined Section
   2.12 of [5].  It is comprised of <display-text>, <subject>, <free-
   text>, <keywords>, <web-page>, <security-level>, <allow-sidebars>,
   <conference-stage>, <conference-time>, <conf-uris>, <service-uris>,
   <maximum-user-count>, <maximum-streams>, and <available-media>.

   The child elements <display-text>, <subject>, <free-text> and
   <keywords> are used to describe the media
   characteristics of conference content.  These
   elements are defined in [2].

   The child element <web-page> is an optional element that points to a
   URI with additional information about the conference.  The child



Novo, et al.             Expires January 11, April 13, 2007                [Page 11] 10]

Internet-Draft          Common Conference Schema               July            October 2006


   The following sections


   elements <security-level> and <allow-sidebars> describe the remaining elements in more
   detail.  Other child elements can be used to extend <conference-
   description> in
   capabilities of the future.

3.2.1.  <conference-time> conference.

   The <conference-time> <conference-stage> is a mandatory element contains that give the information related to
   conference time and duration stage of a
   the conference.  The <conference-time>  This element contains one or more <entry> elements each defining can have 4 values: reserved, started,
   running, and ended.  At the reserved stage the time
   information of a single conference occurrence.

   Every <entry> element contains a <mixing-start-offset> child element
   that specifies when exists only
   in the conference media mixing starts before control server.  There is no running focus and
   there are no subscribers or notifications.  The information is
   accessible only via the conference starts, <mixing-end-offset> child element that specifies control protocol.  At the time a conference media mixing stops after started
   stage, there are no users yet in the conference stops.
   The <mixing-end-offset> child element expresses conference, still it is possible
   to subscribe to the offset as signed
   integers representing seconds before/after DTEND field. conference state.  The <mixing-
   start-offset> child element expresses running stage starts when
   the offset as signed integers
   representing seconds before/after DTSTART field.  If first user joins the <mixing-
   start-offset> element is not present, it indicates that conference.  In the
   conference media mixing starts immediately.  If ended stage, there are
   no users connected to the <mixing-end-
   offset> element is not present, it indicates that conference, the conference
   occurrence information is not bounded. <mixing-start-offset> and <mixing-end-
   offset> elements both have
   only in the mandatory 'require-participant'
   attribute.  This attribute has one of 4 values: 'none',
   'administrator', 'moderator', and 'participant'.  For mixing start
   offset, conference server for recurring conference or for CDR.
   At this attribute allows stage a privileged user to define when media
   mixing starts based on can get information only from the latter of conference
   control protocol.  For instance, The Session Initiation Protocol
   (SIP) Event Package for Conference State [2] is only applicable in
   the mixing start time, and the running stage.

   The <conference-time> child element has information related to
   conference time and duration of the first participant, administrator, or moderator arrives.  If
   the value is set to 'none', mixing starts according to conference.  Other elements from
   different namespaces MAY be present for the mixing
   start time.  For mixing end offset, this attribute allows a
   privileged user to define when media mixing ends based on the earlier purposes of the mixing end offset,
   extensibility.  The <conf-uris> and <service-uris> are used to
   describe the time conference-related identifiers.  The <maximum-user-
   count> child element indicates the last participant, or
   moderator leaves.  If number of users that can be
   invited to the value conference.  The <maximum-streams> child element
   indicates the number of streams that can be for every media type.
   The <available-media> child element is set used to 'none', mixing stops
   according describe the media
   characteristics of the conference.

   The following sections describe the remaining elements in more
   detail.  Other child elements can be used to extend <conference-
   description> in the mixing end offset.  If future.

3.3.1.  <conference-time>

   The <conference-time> element contains the information related to
   conference policy was
   modified so that last privileged user is now a normal conference
   participant, time and duration of a conference.  The <conference-time>
   element contains one or more <entry> elements each defining the time
   information of a single conference requires occurrence.

   Every <entry> element contains a privileged user to
   continue; <mixing-start-offset> child element
   that conference MUST terminate.

   An administrator can indicate the time specifies when users can join a conference by populating media mixing starts before the <can-join-after-offset> element.
   Similarly, an administrator can define
   conference starts, <mixing-end-offset> child element that specifies
   the time a conference media mixing stops after which new users
   are not allowed to join the conference anymore.  This is done by
   populating the <must-join-before-offset> stops.
   The <mixing-end-offset> child element expressing expresses the offset as signed
   integers representing seconds before/after DTSTART DTEND field.  The <base> <mixing-
   start-offset> child element specifies the iCalendar object of expresses the offset as signed integers



Novo, et al.             Expires January 11, April 13, 2007                [Page 12] 11]

Internet-Draft          Common Conference Schema               July            October 2006


   conference.  The iCalendar object components are defined in [6].

   The <entry> element also contains the <request-user> child element.
   It is possible to define the time when users or resources on the
   allowed-users-list is requested to join the conference by using the
   <request-users> element.  This element expresses the offset as signed
   integers


   representing seconds before/after DTSTART field.

   The <notify-end-of-conference> element defines in seconds when the
   system has to send a notification when  If the end of <mixing-
   start-offset> element is not present, it indicates that the
   conference is
   near. media mixing starts immediately.  If the <notify-end-of-conference> <mixing-end-
   offset> element is not present, it indicates that the system does conference
   occurrence is not notify bounded. <mixing-start-offset> and <mixing-end-
   offset> elements both have the users mandatory 'require-participant'
   attribute.  This attribute has one of 4 values: 'none',
   'administrator', 'moderator', and 'participant'.  For mixing start
   offset, this attribute allows a privileged user to define when media
   mixing starts based on the end latter of the conference is near.  The <notify-end-of-conference> child element
   expresses the offset as signed integers representing seconds before/
   after DTSTART field.  The <allowed-extend-mixing-end-offset> refers
   to mixing start time, and the possibility to extend
   time the conference.  It has two values:
   allowed, denied.

3.2.2.  <conf-uris>

   The <conf-uris> contains first participant, administrator, or moderator arrives.  If
   the identifiers value is set to be used in order 'none', mixing starts according to
   access the conference by different signaling means.  It contains mixing
   start time.  For mixing end offset, this attribute allows a
   sequence
   privileged user to define when media mixing ends based on the earlier
   of child elements: <SIP>, <H.323>, and <PSTN/ISDN>.  The
   <SIP> element contains the <uri>, <display-text>, and <purpose>.
   <uri>, <display-text>, mixing end offset, and <purpose> are described in [2].  The
   <H.323> element includes either a <H.323-alias> or a <H.323-URI>
   child elements.  The <PSTN/ISDN> has an attribute 'PIN code' with the
   PIN code of time the conference if used and a 'purpose' attribute that
   describes to last participant, or
   moderator leaves.  If the user which phone number value is set to 'none', mixing stops
   according to use. <PSTN/ISDN> element
   may include 1 or more <phone number> child elements and the call rate
   as well.

3.2.3.  <service-uris>

   The <service-uris> describes auxiliary services available for mixing end offset.  If the
   conference.  It contains conference policy was
   modified so that last privileged user is now a sequence of child elements: <SIP>,
   <H.323>, <PSTN/ISDN>, and <BFCP>. <SIP> child element contains <uri>,
   <display-text>, normal conference
   participant, and <purpose>.  The purpose will be used to describe the service.  These elements are described in [2]. <H.323>, and
   <PSTN/ISDN> child elements are described in <conf-uris> section.  The
   <BFCP> has a sub-element <conference-ID> that are used by conference requires a floor
   control server privileged user to provide a client with a
   continue; that conference ID.

3.2.4.  <maximum-user-count>

   The <maximum-user-count> contains MUST terminate.

   An administrator can indicate the overall number of time when users allowed
   to can join the conference.  It contains a sequence of <entry> child
   elements.  An <entry> element MAY contain
   conference by populating the number of <can-join-after-offset> element.
   Similarly, an administrator can define the time after which new users with a



Novo, et al.            Expires January 11, 2007               [Page 13]

Internet-Draft          Common Conference Schema               July 2006


   specific role
   are not allowed to join the conference [8].

3.2.5.  <maximum-streams> anymore.  This is done by
   populating the <must-join-before-offset> element expressing the
   offset as signed integers representing seconds before/after DTSTART
   field.

   The <maximum-streams> contains <base> child element specifies the maximum number iCalendar object of streams that the
   conference.  The iCalendar object components are
   permitted to be involved defined in a conference.  It contains a sequence of
   <entry> child elements.  An [6].

   The <entry> element MAY contain also contains the number of
   streams of every specific type of stream, for instance, audio or
   video.  The minimum value permitted <request-user> child element.
   It is "1" and possible to define the maximum value
   permitted time when users or resources on the
   allowed-users-list is "128". requested to join the conference by using the
   <request-users> element.  This element is optional.

3.2.6.  <available-media> expresses the offset as signed
   integers representing seconds before/after DTSTART field.

   The <available-media> <notify-end-of-conference> element defines in seconds when the
   system has to send a notification when the 'label' attribute that end of the conference is
   near.  If the media
   stream identifier assigned by <notify-end-of-conference> element is not present, it
   indicates that the conferencing server.  This system does not notify the users when the end of
   the conference is near.  The <notify-end-of-conference> child element
   expresses the offset as signed integers representing seconds before/
   after DTSTART field.  The <allowed-extend-mixing-end-offset> refers
   to the possibility to extend the conference.  It has two values:
   allowed, denied.




Novo, et al.             Expires April 13, 2007                [Page 12]

Internet-Draft          Common Conference Schema            October 2006


3.3.2.  <conf-uris>

   The <conf-uris> contains the identifiers to be used in order to
   access the conference by different signaling means.  It contains a
   sequence of <entry> child elements of conference-medium-
   type.  Each <entry> elements: <SIP>, <H.323>, and <PSTN/ISDN>.  The
   <SIP> element contains the <type>, <uri>, <display-text>,
   <status>, <mixing-mode>, <mix level>, <controls, and <codecs> child
   elements.  The attribute 'label' and the <type>, <purpose>.
   <uri>, <display-text>, and
   <status> elements <purpose> are described in [2].  The <codecs>
   <H.323> element
   specifies the allowed codecs in the conference.  It has an attribute
   'decision' that specifies if the focus decides the common codec
   automatically includes either a <H.323-alias> or needs the approvement of a <H.323-URI>
   child elements.  The <PSTN/ISDN> has an attribute 'PIN code' with the moderator
   PIN code of the conference (automatic, moderator-controlled).  The <codecs> element
   contains if used and a <entry> elements.  A <entry> element can have the 'purpose' attribute 'name' that
   describes to the user which phone number to use. <PSTN/ISDN> element
   may include 1 or more <phone number> child elements and 'policy'. the call rate
   as well.

3.3.3.  <service-uris>

   The 'name' attribute identifies a
   codec, and <service-uris> describes auxiliary services available for the 'decision' attribute
   conference.  It contains a sequence of child elements: <SIP>,
   <H.323>, <PSTN/ISDN>, and the policy attribute <BFCP>. <SIP> child element contains
   the policy for that codec (allowed, or disallowed). <uri>,
   <display-text>, and <purpose>.  The purpose will be used to describe
   the service.  These elements are described in [2]. <H.323>, and
   <PSTN/ISDN> child elements <mixing-mode>, <mix level> describe are described in <conf-uris> section.  The
   <BFCP> has a default
   policy by which the mixer will build the outgoing stream from the
   incoming streams.  Notice that this policy is different sub-element <conference-ID> that are used by a floor
   control server to provide a client with a conference ID.

3.3.4.  <maximum-user-count>

   The <maximum-user-count> contains the
   policy describe for overall number of users allowed
   to join the floors for each media.  The <mix level> conference.  It contains a sequence of <entry> child
   elements.  An <entry> element describes MAY contain the number of participants in audio media streams
   or users with a
   specific role allowed to join the conference.

3.3.5.  <maximum-streams>

   The <maximum-streams> contains the maximum number of sub-windows in video media streams (for instance, that are
   permitted to be involved in a
   value of 4 in the <mix level> element for video stremas means 2x2
   layout).  The <mixing-mode> conference.  It contains a sequence of
   <entry> child elements.  An <entry> element MUST MAY contain one and only
   one of the "Moderator-controlled", "FCFS", number of
   streams of every specific type of stream, for instance, audio or
   video.  The minimum value permitted is "1" and "Automatic" values
   indicating the default algorithm to be use with every maximum value
   permitted is "128".  This element is optional.

3.3.6.  <available-media>

   The <available-media> has the 'label' attribute that is the media stream.
   Next section explains
   stream identifier assigned by the <controls> child element.

3.2.7.  <controls>

   The <controls> conferencing server.  This element
   contains the basic audio and video global
   controls for a conferencing.  It is expected that for most sequence of the
   basic conferencing, these controls are sufficient.  If the conference
   server wants to support more advanced control, then it is recommended
   extension <entry> child elements of conference-medium-
   type.  Each <entry> element contains the data model to be used.  In the <type>, <display-text>,
   <status>, <mixing-mode>, <mix-level>, <controls> element and <codecs> child



Novo, et al.             Expires January 11, April 13, 2007                [Page 14] 13]

Internet-Draft          Common Conference Schema               July            October 2006


   elements.  The attribute 'label' and the schema is extensible, hence new control types can be added in a
   future.  Controls that apply at a different level than endpoint/
   stream would appear at an appropriate place <type>, <display-text>, and
   <status> elements are described in the document.  So,
   moderator controls that affect all media output would go under the
   <available-media> element.

3.2.7.1.  mute [2].  The 'mute' control is used <codecs> element
   specifies the allowed codecs in conjunction with a media stream to
   cease transmission of associated media. the conference.  It has a 'Boolean' value.
   When muting, an attribute
   'decision' that specifies if the control consists of focus decides the following attributes:
   'type', 'name', 'enable'.  And common codec
   automatically or needs the following additional elements:
   'label', and 'value'.  The description approvement of these elements are the
   following:

   type: The 'mute' control has a type moderator of 'Boolean'.

   name: the
   conference (automatic, moderator-controlled).  The control is named 'mute'.

   enable: <codecs> element
   contains a <entry> elements.  A <entry> element can have the
   attribute 'name' and 'policy'.  The enable 'name' attribute specifies if access to the control is
   available to identifies a
   codec, and the client.  The value is of type 'boolean' 'decision' attribute and is set
   to 'true' as default.

   The Control also consists of the following additional elements:

   display-text: Provides a Control label that can be rendered to policy attribute contains
   the
   client.

   value: Provides policy for that codec (allowed, or disallowed).

   The child elements <mixing-mode>, <mix-level> describe a default value for
   policy by which the Control.  For mixer will build the Blue-Print
   example outgoing stream from the value
   incoming streams.  Notice that this policy is 'True'.

3.2.7.2.  pause-video different that the
   policy describe for the floors for each media.  The 'pause-video' control is used <mix-level> child
   element describes the number of participants in conjunction with a audio media stream
   to cease transmission streams
   or the number of associated media.  It has sub-windows in video media streams (for instance, a 'Boolean' value.
   The 'pause-video' control consists
   value of 4 in the following attributes:

   type: <mix-level> element for video stremas means 2x2
   layout).  The 'pause-video' control has a type <mixing-mode> child element MUST contain one and only
   one of 'Boolean'.

   name: The control is named 'pause-video'.

   default: Indicates the default value for "Moderator-controlled", "FCFS", and "Automatic" values
   indicating the 'pause-video' control
   when not set.  The attribute type is 'Boolean' with a default value
   of 'false.  Setting the 'default' attribute algorithm to 'false' specifies that
   media should be transported for the associated use with every media stream.  When
   set to the value of 'true', media should not be transported for
   Next section explains the
   associated media stream.




Novo, <controls> child element.

3.3.7.  <controls>

   The <controls> element contains the basic audio and video global
   controls for a conferencing.  It is expected that for most of the
   basic conferencing, these controls are sufficient.  If the conference
   server wants to support more advanced control, then it is recommended
   extension of the data model to be used.  In the <controls> element
   the schema is extensible, hence new control types can be added in a
   future.  Similarly, controls that apply to a especific users would
   appear under the <users>/<user>/<endpoint> element.  So, moderator
   controls that affect all media output would go under the <available-
   media> element.

3.3.7.1.  mute

   The 'mute' control is used in conjunction with a audio stream to
   cease transmission of associated media.  It has a 'Boolean' value.
   If this control is not specify, the access to the control is not
   available to the client and media SHOULD not be transported for the
   associated media stream.

3.3.7.2.  pause-video

   The 'pause-video' control is used in conjunction with a video stream
   to cease transmission of associated media.  It has a 'Boolena' value.



Novo, et al.             Expires January 11, April 13, 2007                [Page 15] 14]

Internet-Draft          Common Conference Schema               July            October 2006


   enable: The enable attribute specifies if


   If this control is not specify, the access to the control is not
   available to the client.  The value is of type 'boolean' client and is set
   to 'true' as default.

   The Control also consists of media SHOULD not be transported for the following additional elements:

   display-text: Provides
   associated media stream.

3.3.7.3.  gain

   The 'gain' control is used in conjunction with a Control label that can be rendered media output stream
   to indicate the
   client.

   value: Provides amount of amplification of an audio stream.  It has a default
   'Int' number value for the Control.  For from -127 to 127.  If this control is not specify,
   the Blue-Print
   example access to the value control is 'True'.

3.3. not available to the client.

3.4.  <host-info>

   The <host-info> element contains information about the entity hosting
   the conference.  It contains the <display-text>, <web-page> child
   elements.  These child elements are explained in [2]. <host-info>
   contains the <uris> child element as well. <uris> contains a sequence
   of child elements: <SIP>, <H.323>, and <PSTN/ISDN>.  The child
   elements of <uris> are described in <conf-uris> section.

3.4.

3.5.  <conference-state>

   The <conference-state> element and the <user-count>, <active>, and
   <locked> child element are explained in section 5.5 of [2].  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 [2].  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.

3.5.  <security-mechanism>

   The <security-mechanism> contains a series of <entry-protocol> sub-
   elements.

3.6.  <floor-information>

   The <entry-protocol> <floor-information> element has a single mandatory
   attribute, 'name'.  The 'name' attribute identifies a protocol the
   policy of each protocol element is referring to.  Each <entry-
   protocol> sub-element contains <allow-floor-events>, <floor-
   request-handling>, and the policy related to <conference-floor-policy> child elements.
   Other elements from different namespaces MAY be present for the usage
   purposes of a
   particular protocol.

   The <entry-protocol> extensibility.  This element has a series its own XML namespace.
   The absence of child elements: methods,
   option-tags, feature-tags, this namespace and bodies are defined for the SIP
   protocol.  These its elements are described in from an XML document
   indicates that the following sections.
   H.323 protocol has conference does not have a sub floor.

   The <allow-floor-events> element <version> that says which version of
   H.323 is supported.  H.320 protocol has represents a sub 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 <supported>
   that says if H.320 is supported or not. undefined, it has a value of
   FALSE, causing the subscription to floor control events to be
   rejected.




Novo, et al.             Expires January 11, April 13, 2007                [Page 16] 15]

Internet-Draft          Common Conference Schema               July            October 2006


3.5.1.  <methods>

   The <methods> element contains a default-policy attribute and
   <method> elements.


   The default-policy attribute contains the policy
   for methods that are not listed as <method> elements.  A <method> <floor-request-handling> element has two attributes: name and policy.  The name attribute
   identifies a method, and defines the policy attribute contains actions used by the policy for
   that method (allowed or disallowed).

3.5.2.  <option-tags>

   The <option-tags>
   conference focus to control floor requests.  This element contains a default-policy attribute and
   <option-tag> elements.  The default-policy attribute contains defines the
   policy for option-tags
   action that are not listed as <option-tag> elements.
   An <option-tag> element has two attributes: name and policy.  The
   name attribute identifies a method, and the policy attribute contains the policy for that method (mandatory, allowed, or disallowed).

3.5.3.  <feature-tags>

   The <feature-tags> element contains focus is to take when processing a default-policy attribute and
   <feature-tag> elements.  The default-policy attribute contains the
   policy for feature-tags that are not listed as <feature-tag>
   elements.  A <feature-tag> element has two attributes: name and
   policy.  The name attribute identifies particular request
   to a method, and floor within a conference.  This element defines values of:
   o  block: This action instructs the policy
   attribute contains focus to deny the policy for that method (allowed, or
   disallowed).

3.5.4.  <bodies>

   The <bodies> element contains a default-policy attribute, a default-
   encryption attribute and <body-disposition> elements. floor request.
      This action is the default action taken in the absence of any
      other actions.
   o  confirm: This action instructs the focus to allow the request.
      The default-
   policy attribute contains focus then uses the policy for body dispositions that are
   not listed as <body-disposition> elements. defined floor algorithm to further allow
      of deny the floor.  The default-encryption
   attribute contains algorithms used are outside the encryption policy for body dispositions scope of
      this document.

   Note that
   are not listed as <body-disposition> elements.

   A <body-disposition> element can have placing a number value of attributes: name,
   policy, default-policy, and encryption.  The name attribute
   identifies block for this element does not
   guarantee that a body-disposition, and the policy attribute contains participant is blocked from joining the
   policy conference.
   Any other rule that might evaluate to true for this participant that body-disposition (allowed, or disallowed).
   carried an action whose value was higher than block would
   automatically grant confirm/allow permission to that participant.

   The
   default-policy attribute <conference-floor-policy> element is mandatory and contains the policy for body formats that
   are not listed as <body-format> elements.  The encryption
   required boolean attribute that indicates whether or not encryption if the floor is allowed for a particular body
   disposition.

   A <body-disposition> element contains <body-format> elements.  A
   body-format element moderator
   controlled or not.  One or more <Floor> elements can have a two attributes: name and policy.  The



Novo, et al.            Expires January 11, 2007               [Page 17]

Internet-Draft          Common Conference Schema               July 2006


   name attribute identifies a <body-format>, and appear in the policy
   <conference-floor-policy> element.  Every floor is defined using the
   'label' attribute.  If the <available-media> information is included
   in the conference document, the value of this attribute
   contains MUST be equal
   to the policy 'label' value of the corresponding media stream <entry> in the
   <available-media> container.  The number of those elements indicates
   how many floors the conference can have.  A floor can be used for that body-format (allowed one
   or disallowed).

3.6.  <floor-information>

   The <floor-information> more media types; the mandatory <Media-types> element has can contain
   zero or more of the <allow-floor-events>, <floor-
   request-handling>, <Video>, <Audio>, <Application>, <Data>
   ,<Control>, <Message>, and <text> elements indicating the <conference-floor-policy> child elements. media of
   the floor.  One type of media can only appear once.  Other elements from different namespaces MAY media
   types can be present for defined by extensions.

   A floor can be controlled using many algorithms; the
   purposes of extensibility.  This mandatory
   <Algorithm> element has its own XML namespace.
   The absence MUST contain one and only of this namespace the <Moderator-
   controlled>, <FCFS>, and its <Random> elements from an XML document
   indicates that indicating the conference does not have a floor. algorithm.

   The <allow-floor-events> <Max-floor-users> element represents a boolean action.  If set
   to TRUE, in the focus <Floor> element is instructed to accept optional and,
   if present, dictates the maximum number of users who can have the subscription to
   floor
   control events.  If at one time.  The optional <Moderator-URI> indicates the URI of
   the moderator.  It MUST be set to FALSE, if the focus attribute moderator-controlled
   is instructed set to reject
   the subscription.  If this "true".

3.7.  <users>

   The <users> element is undefined, it has a value of
   FALSE, causing contains the subscription to floor control events to be
   rejected. <join-handling>, <user-admission-
   policy>, <allowed-users-list>, <privileges-control-list> and <user>
   child elements.



Novo, et al.             Expires April 13, 2007                [Page 16]

Internet-Draft          Common Conference Schema            October 2006


   The <floor-request-handling> <join-handling> element defines the actions used by the
   conference focus to control floor requests. conference participation.  This element
   defines the action that the focus is to take when processing a
   particular request to a floor within join a conference.  This element defines values
   of:
   o  block: This action instructs the focus to deny access to the floor request.
      conference.  This action is the default action taken in the
      absence of any other actions.
   o  confirm: This action instructs the focus to allow 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.
   o  allow: This action instructs the request.
      The focus then uses to accept the defined floor algorithm conference
      join request and grant access to further allow
      of deny the floor.  The algorithms used are outside conference within the scope
      instructions specified in the transformations of this document. rule.
   o  IVR: This action instructs the focus that the user has to define
      the PIN code.
   o  directed-operator: This action instructs the focus to direct the
      user to an operator.

   Note that placing a value of block for this element does not
   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.

   The <conference-floor-policy> <user-admission-policy> element is mandatory a list of three elements:
   'closedAuthenticated', 'openAuthenticated', and contains 'anonymous'.  If the
   required boolean attribute that indicates if
   <user-admission-policy> element is set to 'closedAuthenticated',
   users must be specified (and authenticate).  If the floor attribute is moderator
   controlled or not.  One or set
   to 'openAuthenticated', users can be add after conference activation.

   The following sections describe the remaining elements in more <Floor>
   detail.  Other child elements can appear be used to extend <conference-
   description> in the
   <conference-floor-policy> element.  Every floor is defined using the
   'label' attribute. future.

3.7.1.  <allowed-users-list>

   The number <allowed-users-list> child element contains a list of those elements indicates how many
   floors user URIs,
   PSTN phone numbers, roles, or domains (*@example.com) that the conference can have.  A floor focus
   uses to determine who can be used for one join the conference, who can invite to join
   a conference, or more
   media types; who the mandatory <Media-types> focus needs to "refer to" the conference.
   The <allowed-users-list> element can contain includes zero or more of <target> child
   element.  This child element includes the <Video>, <Audio>, <Application>, <Data> ,<Control>,
   <Message>, mandatory 'uri' attribute
   and <text> elements indicating the media of the floor.
   One type of media mandatory 'method' attribute.  The same 'uri' attribute with
   different method values can only appear in the list more than once.  Other media types  The
   'method' attribute is a list with the following values: "dial-in",
   "dial-out, and "refer".  The value "dial-in" is used by the focus to
   determine who can be
   defined join the conference.  Value "refer" is used by extensions. the



Novo, et al.             Expires January 11, April 13, 2007                [Page 18] 17]

Internet-Draft          Common Conference Schema               July            October 2006


   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


   focus to "true".

3.7.  <users>

   The <users> element contains the <join-handling>, <user-admission-
   policy>, <allowed-users-list>, <privileges-control-list> and <user>
   child elements.

   The <join-handling> element defines determine the actions used by resources that the
   conference focus needs to control conference participation.  This element
   defines "refer to"
   the action that conference.  In SIP, this is achieved by the focus is to take when processing sending a
   particular
   REFER request to join those potential participants.  In a conference.  This element defines values
   of:
   o  block: This action instructs different
   paradigm, this could also mean that the focus to deny access sends an SMS or an
   email to the
      conference. referred user.  This action is list can be updated during the default action taken
   conference lifetime so it can be used for mid-conference refers as
   well.

   The "refer" value differs from the "dial-out" in that the
      absence dial-out
   contains a list of any other actions.
   o  confirm: This action instructs resources that the focus to place the participant
      on will initiate a pending list (e.g., by parking the call session
   with.  The resources on a music-on-hold
      server), awaiting moderator input for further actions.
   o  allow: This action instructs the focus to accept "refer" value, on the conference
      join request and grant access other hand, are
   expected to initiate the conference within the
      instructions specified in the transformations of this rule.
   o  IVR: This action instructs session establishment towards the focus
   themselves.  It is also envisioned that the user has to define
      the PIN code.
   o  directed-operator: This action instructs the focus difference users will have
   different access rights to direct those lists and therefore a separation
   between the
      user two is needed.

3.7.2.  <privileges-control-list>

   The <privileges-control-list> refers to an operator.

   Note that placing a value virtual set of block for this rights
   pertaining to operations.  This element does not
   guarantee that a participant is blocked from joining contains 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. <conference-
   rules> element.

3.7.2.1.  <conference-rules>

   The <user-admission-policy> <conference-rules> element is a list set of three elements:
   'closedAuthenticated', 'openAuthenticated', and 'anonymous'.  If the
   <user-admission-policy> <entry> child elements
   with specific authorization rules that indicate who is allowed to
   subscribe to conference-information notifications, see floors,
   request/grant floors, and so on.

   Every <entry> element is set represent by the 'id' attribute, each of
   which identifies a rule inside the conference.  It contains the
   <condition> and <actions> sub elements.

3.7.2.1.1.  <condition>

   The <condition> element determines whether a particular privilege
   applies to 'closedAuthenticated',
   users must be specified (and authenticate).  If a user, a role, or domain.

   The <condition> element has the attribute is set <identity> and the <validity> child
   element.  These elements MUST NOT appear more than once in the
   condition part of a single rule.

   The <identity> element restricts matching of a rule either to 'openAuthenticated', users can be add after conference activation. a
   single entity or a group of entities.  The following sections describe <identity> element has the remaining
   <one> and <many> child elements defined in more Section 7.1 of [8].  The
   absence of the <identity> element in a <condition> element indicates
   that the privilege applies to all unauthenticated identities.




Novo, et al.             Expires January 11, April 13, 2007                [Page 19] 18]

Internet-Draft          Common Conference Schema               July            October 2006


   detail.  Other


   The <identity> element has other child elements.  These child
   elements can be used to extend <conference-
   description> in the future.

3.7.1.  <allowed-users-list> are <pseudonymous>, <has-been-referred>, <has-been-invited>,
   <has-been-in-conference>, <is-in-conference>, <administrator>, <is-
   on-allowed-users-list-dial-out>, <is-on-allowed-users-list-refer>,
   <participant-passcode>, and <administrator-passcode>.

   The <allowed-users-list> child <validity> element contains a list of user URIs,
   PSTN phone numbers, roles, or domains (*@example.com) that expresses the focus
   uses to determine who can join validity period of the conference, who can invite to join rule with
   a conference, or who the focus needs to "refer to" the conference. starting and an ending time.  The <allowed-users-list> <validity> element includes zero or more <target> child
   element.  This child element includes the mandatory 'uri' attribute and the mandatory 'method' attribute.  The 'method' attribute is a
   list with the following values: "dial-in", "dial-out, its child
   elements ,<from> and "refer". <until>, are defined in section 7.3 of [8].

3.7.2.1.2.  <pseudonymous>

   The value "dial-in" <pseudonymous> element is used to match participants that have
   provided an authenticated identity to the conference focus, but have
   requested pseudonymity in the conference itself.  A user requests
   pseudonymity by authenticating himself to the conference focus to determine who and
   providing a pseudonym in the signalling protocol (for example, using
   the From-header of a SIP request).

   The <pseudonymous> element can join be combined with the conference.  Value "dial-out" is used by <identity>
   element to provide the focus with a rule on what to determine
   who to invite to join the conference.  Value "refer" do when a
   specific identity is used by authenticated and that identity is requesting
   pseudonymity through the
   focus signalling protocol.

3.7.2.1.3.  <has-been-referred>

   The <has-been-referred> element can be used to determine the resources match those
   participants that the focus needs has referred to "refer to" the conference.  In SIP, this is achieved by the focus sending a
   REFER request

3.7.2.1.4.  <has-been-invited>

   The <has-been-invited> element can be used to match those potential participants.  In a different
   paradigm, this could also mean
   participants that the focus sends an SMS or an
   email to has invited into the referred user.  This list conference.

3.7.2.1.5.  <has-been-in-conference>

   The <has-been-in-conference> element can be updated during used to match those
   participants that have joined the conference lifetime so it in the past.

3.7.2.1.6.  <is-in-conference>

   The <is-in-conference> element can be used for mid-conference refers as
   well.

   The "refer" value differs from the "dial-out" in to match those
   participants that are currently participating in the dial-out
   contains a list of resources that the focus will initiate a session
   with. conference.

3.7.2.1.7.  <administrator>

   The resources on the "refer" value, on the other hand, are
   expected to initiate the session establishment towards the focus
   themselves.  It is also envisioned that difference users will have
   different access rights <administrator> element can be used to match those lists and therefore a separation
   between the two is needed.

3.7.2.  <privileges-control-list>

   The <privileges-control-list> refers to a virtual set of rights,
   permissions and limitations pertaining to operations.  This element
   contains the <data-access-rights> and the <conference-rules>.

3.7.2.1.  <data-access-rights>

   The <data-access-rights> element describes the read/write access
   privileges for accessing the Conference Object as a whole.  It is
   partially described in [1].  The <data-access-rights> contains a list participants
   that are administrators of <entry> elements defined in the Conference Object.  Every element
   has three attributes: the attribute 'name', 'read-only', and the
   attribute 'read-write'.  When the conferencing server receives a
   request for access to privacy-sensitive data it needs to match it
   against the 'read-only' and the 'read-write' attributes.  Each conference.



Novo, et al.             Expires January 11, April 13, 2007                [Page 20] 19]

Internet-Draft          Common Conference Schema               July            October 2006


   attribute of each individual


3.7.2.1.8.  <is-on-allowed-users-list-dial-out>

   The <is-on-allowed-users-list-dial-out> element is evaluated and as a result it
   is determined if the user can access be used to match
   those participants that element.  The attributes
   specify are on the minimum subscriber's role that can access or modify allowed-users-list with the method
   dial-out.

3.7.2.1.9.  <is-on-allowed-users-list-refer>

   The <is-on-allowed-users-list-refer> element of can be used to match
   those participants that are on the conference.  Subscribers allowed-users-list with a lower role cannot
   access or modify the element.  If an method
   refer.

3.7.2.1.10.  <participant-passcode>

   The <participant-passcode> element is not defined in the
   <data-access-rights> then the 'read-only' attribute MUST can be
   interpreted as a "participant" and the 'read-write' attribute MUST be
   interpreted as an "administrator" by default.  It is possible used to
   defined only one of the attributes match those
   participants that have knowledge of a passcode for the element, the other
   attribute SHOULD be interpreted by default.  This draft does conference
   (PIN code).

   A focus need not
   define the set of possible conferencing roles.

   However, it can also be the case that conflicts can occur given care if a
   hierarchy of elements.  In that case, the lower-level element
   privileges predominate over the upper-level privileges element.

3.7.2.2.  <conference-rules>

   The <conference-rules> element is user using a set of <entry> child elements
   with specific authorization rules that indicate who is allowed to
   subscribe passcode to conference-information notifications, see floors,
   request/grant floors, and so on.

   Every <entry> element join is represent by the 'id' attribute, each of
   which identifies calling
   from a rule inside PSTN or an IP phone.  For example: Using a SIP phone, a SIP
   INVITE request arrives directly at the conference.  It contains focus.  The focus examines the
   <condition>
   identity and <actions> sub elements.

3.7.2.2.1.  <condition> discovers that there are no rules allowing this identity
   to join.  The <condition> element focus also determines whether a particular privilege
   applies to a user, a role, or domain. that there are no rules
   explicitly prohibiting this identity from joining.  The <condition> element has the <identity> and the <validity> child
   element.  These elements MUST NOT appear more than once focus in this
   case decides to challenge the
   condition part of identity for a single rule.

   The <identity> element restricts matching of passcode, if there is a
   rule either to a
   single entity or that allows users with a group of entities.  The <identity> element has passcode knowledge to join.  If no such
   rule exists, the
   <one> and <many> child elements defined in Section 7.1 of [9].  The
   absence of focus would not challenge for a passcode.

   For PSTN users, the <identity> element in system can be set up for an IVR system to prompt
   the user for a <condition> element indicates
   that passcode before forwarding the privilege applies request to all unauthenticated identities. the focus.
   The <identity> element has other child elements.  These child
   elements focus does not need to care if there is an IVR system or not.  It
   can apply the same procedure as above.  It checks if there are <external-list>, <pseudonymous>, <has-been-referred>,
   <has-been-invited>, <has-been-in-conference>, <is-in-conference>,
   <administrator>, <is-on-allowed-users-list-dial-out>, <is-on-allowed-
   users-list-refer>, <participant-passcode>, and <administrator-
   passcode>.



Novo, et al.            Expires January 11, 2007               [Page 21]

Internet-Draft          Common Conference Schema               July 2006


   The <validity> element expresses any
   the validity period of rules allowing or denying the identity access.  In this case, the
   identity is the GW.  If no rules exist for that identity but a
   general passcode rule with does, then the focus would challenge the GW/IVR
   for the passcode.

   A focus can challenge for the passcode using, for example, a starting and an ending time. HTTP
   Digest challenge.  The <validity> element username, passcode and its child
   elements ,<from> realm need to be
   assigned and <until>, are defined in section 7.3 distributed is a manner that is outside the scope of
   this document.  Mutliple passcodes can be assigned to multiple users.

3.7.2.1.11.  <administrators-passcode>

   In some cases, administrators of [9].

3.7.2.2.1.1.  <external-list> the conference are assigned a
   different passcode than normal participants.  The <external-list> <administrator-
   passcode> element can be used to match those key participants that are part of
   have knowledge on a resource list that is created externally.  The
   <external-list> element contains key participant passcode for the conference.



Novo, et al.             Expires April 13, 2007                [Page 20]

Internet-Draft          Common Conference Schema            October 2006


   Again, a list of <except> elements and
   allows focus need not care if a user using a passcode to implement join is
   calling from a simple blacklist mechanism.  The <except>
   element contains PSTN or an identity.

3.7.2.2.1.2.  <pseudonymous>

   The <pseudonymous> element IP phone.  It is used to match participants important that have
   provided an authenticated identity to the conference focus, but have
   requested pseudonymity in the conference itself.  A focus
   has a unique identity for each user requests
   pseudonymity by authenticating himself joining from a PSTN phone via a
   gateway.  It is not enough that one identity to be assigned to all
   users joining from the same gateway since administrators have more
   control over conference focus and
   providing duration.  It might be required that a pseudonym in
   gateway maps the telephone number of the PSTN phone into the IP
   signalling protocol (for example, using header that usually carries the From-header of asserted identity
   or a SIP request). user.

3.7.2.2.  <actions>

   The <pseudonymous> element can be combined with the <identity> <actions> element to provide in the focus with a applied rule on what to do when a
   specific identity is authenticated and that identity is requesting
   pseudonymity through a positive grant of
   permission to the signalling protocol.

3.7.2.2.1.3.  <has-been-referred> conference data model or the conferencing system.
   The <has-been-referred> <actions> element can be used to match those
   participants that the focus has referred to the conference.

3.7.2.2.1.4.  <has-been-invited> following operations:
   o  The <has-been-invited> <allow-refer-users-dynamically> element can be used represents a boolean
      action.  If set to match those
   participants that TRUE, the identity is allowed to instruct the
      focus has invited into the conference.

3.7.2.2.1.5.  <has-been-in-conference>

   The <has-been-in-conference> element can be used to match those
   participants that have joined to refer a user to the conference in without modifying the past.

3.7.2.2.1.6.  <is-in-conference>

   The <is-in-conference> element can be used
      allowed-users-list (in SIP terms, the identity is allowed to match those
   participants that are currently participating send
      a REFER request to the focus which results in the conference.






Novo, et al.            Expires January 11, 2007               [Page 22]

Internet-Draft          Common Conference Schema               July 2006


3.7.2.2.1.7.  <administrator>

   The <administrator> element can be used to match those participants
   that are administrators of focus sending a conference.

3.7.2.2.1.8.  <is-on-allowed-users-list-dial-out>

   The <is-on-allowed-users-list-dial-out> element can be used
      REFER request to match
   those participants that are on the allowed-users-list with user the method
   dial-out.

3.7.2.2.1.9.  <is-on-allowed-users-list-refer>

   The <is-on-allowed-users-list-refer> element can be used referrer wishes to match
   those participants that are on join the allowed-users-list with
      conference).  If set to FALSE, the method
   refer.

3.7.2.2.1.10.  <participant-passcode>

   The <participant-passcode> refer request is rejected.  If
      this element can be used to match those
   participants that have knowledge is undefined it has a value of FALSE, causing the
      refer to be rejected.
   o  The <allow-invite-users-dynamically> element represents a passcode for boolean
      action.  If set to TRUE, the identity is allowed to instruct the conference
   (PIN code).

   A
      focus need not care if to invite a user using a passcode to join the conference without modifying the
      allowed-users-list list (in SIP terms, the identity is calling
   from allowed to
      send a PSTN or REFER request to the focus which results in the focus
      sending an IP phone.  For example: Using a SIP phone, a SIP INVITE request arrives directly at to the focus.  The focus examines user the
   identity and discovers that there are no rules allowing this identity referrer wishes to join.  The focus also determines that there are no rules
   explicitly prohibiting join
      the conference).  If set to FALSE, the refer request is rejected.
      If this identity from joining. element is undefined it has a value of FALSE, causing the
      refer to be rejected.
   o  The focus in this
   case decides <allow-remove-users-dynamically> element represents a boolean
      action.  If set to challenge TRUE, the identity for a passcode, if there is a
   rule that allows users with a passcode knowledge allowed to join.  If no such
   rule exists, instruct the
      focus would not challenge for to remove a passcode.

   For PSTN users, user from the system can be set up for an IVR system to prompt conference without modifying the user for a passcode before forwarding
      ruleset (in SIP terms, the identity is allowed to send a REFER
      request to the focus.
   The focus does not need to care if there is which results in the focus sending an IVR system or not.  It
   can apply BYE
      request to the same procedure as above.  It checks if there are any user the rules allowing or denying referrer wishes to leave the identity access.  In this case, conference).
      If set to FALSE, the
   identity refer request is the GW. rejected.  If no rules exist for that identity but this element
      is undefined it has a
   general passcode rule does, then value of FALSE, causing the focus would challenge refer to be
      rejected.
   o  The <show-floor-holder> element defines the GW/IVR
   for actions used by the passcode.

   A
      conference focus can challenge for to control floor requests.  This element defines
      the passcode using, for example, a HTTP
   Digest challenge.  The username, passcode and realm need action that the focus is to be
   assigned and distributed is take when processing a manner that is outside the scope of
   this document.  Mutliple passcodes can be assigned particular
      request to multiple users. a floor within a conference.  This element has defined
      values of:




Novo, et al.             Expires January 11, April 13, 2007                [Page 23] 21]

Internet-Draft          Common Conference Schema               July            October 2006


3.7.2.2.1.11.  <administrators-passcode>

   In some cases, administrators of the conference are assigned a
   different passcode than normal participants.  The <administrator-
   passcode> element can be used to match those key participants that
   have knowledge on a key participant passcode for


      *  block: This action instructs the conference.

   Again, a focus need not care if a user using a passcode to join is
   calling from a PSTN or an IP phone.  It is important that deny the focus
   has a unique identity for each user joining from a PSTN phone via a
   gateway.  It floor
         request.  This action is not enough that one identity to be assigned to all
   users joining from the same gateway since administrators have more
   control over conference duration.  It might be required that a
   gateway maps default action taken in the telephone number
         absence of any other actions.
      *  confirm: This action instructs the PSTN phone into the IP
   signalling protocol header that usually carries focus to allow the asserted identity
   or a user.

3.7.2.2.2.  <actions> request.
         The <actions> element in focus then uses the applied rule is a positive grant of
   permission defined floor algorithm to further
         allow of deny the conference data model or the conferencing system. floor.  The <actions> element has algorithms used are outside the following operations:
         scope of this document.
   o  The <allow-refer-users-dynamically>  Note that placing a value of block for this element represents does not
      guarantee that a boolean
      action.  If set to TRUE, the identity participant is allowed to instruct blocked from joining the
      focus
      conference.  Any other rule that might resolve to refer a user true for this
      participant that carried an action whose value was higher than
      block would automatically grant confirm/allow permission to the conference without modifying the
      allowed-users-list (in SIP terms, the identity that
      participant.
   o  The <show-floor-requests> element is allowed to send
      a REFER request to the focus which results in the focus sending a
      REFER request of type boolean
      transformation.  If set to TRUE, the user the referrer wishes conference participant is
      able to join see the
      conference). floor requests.  If set to FALSE, the refer request conference
      participant is rejected. not able to see floor requests.  If this element is undefined
      undefined, it has a value of FALSE, causing the
      refer floor requests to be rejected.
      not being seen by the conference participant.
   o  The <allow-invite-users-dynamically> element represents a boolean
      action.  If  A rule can be set that provides anonymity to TRUE, the identity is allowed to instruct a specific identity.
      In this case, the focus provides to invite a user to the conference without modifying the
      allowed-users-list list (in SIP terms, rest of the participants
      an anonymous identity for that user, for example anonymous1.  This
      can be achieved by using the <provide-anonymity> element.  It is allowed to
      send a REFER request
      boolean transformation.  If set to TRUE, the focus which results in the focus
      sending conference
      participants will see an INVITE request to anonymous identity for the user the referrer wishes to join
      the conference).  If set to FALSE, the refer request is rejected.
      If this element whose
      identity is undefined it has a value of FALSE, causing present in the
      refer to be rejected. conditions.
   o  The <allow-remove-users-dynamically> <read-write> element represents a boolean action.  If set to
      TRUE, the identity is allowed to instruct modify the
      focus to remove a user from element described
      inside the 'element' attribute in the conference without modifying policy.  If set
      to FALSE, any modifications to the
      ruleset (in SIP terms, element are rejected.
   o  The <read-only> element represents a boolean action.  If set to
      TRUE, the identity is allowed to send a REFER
      request to the focus which results in the focus sending an BYE
      request to read the user element described inside
      the referrer wishes to leave 'element' attribute in the conference). conference policy.  If set to
      FALSE, any attempts to read the refer request is element are rejected.  If this

3.8.  <user>

   The element
      is undefined it has <user> describes a value of FALSE, causing single participant in the refer conference.

   The following elements as well as the attributes of <user> are
   defined in [2], section 5.6: <display-text>, <associated-aors>,
   <roles>, <languages>, <cascaded-focus>, and <endpoint>.

   The <provide-anonymity> provides anonymity to the user.  When a user
   is defined then the role must be defined or set to "participant" by
   default.  This specification does not define the set of possible
   conferencing roles nor the semantics associated with each.




Novo, et al.             Expires January 11, April 13, 2007                [Page 24] 22]

Internet-Draft          Common Conference Schema               July            October 2006


      rejected.
   o


   The <show-floor-holder> <sphere> element defines the actions can be used by the
      conference focus to control floor requests.  This element defines indicate the action that state (e.g., 'work',
   'home', 'meeting', 'travel') the focus user is to take when processing a particular
      request to a floor within currently in.  It is defined
   in section 7.2 of [8].

   The <allow-refer-users-dynamically>, <allow-invite-users-dynamically>
   and <allow-remove-users-dynamically> elements are defined in the
   previous section.

   The <endpoint> element is under a conference. <user> parent.  This element has defined
      values of:
      *  block: This action instructs can
   provide the focus to deny desired level of detail about the floor
         request.  This action is the default action taken user's devices and
   signaling sessions taking part in the
         absence of any conference and has the
   following child elements defined in [2]: <display-text>, <referred>,
   <status>, <joining-method>, <joining-info>, <disconnection-method>,
   <disconnection-info>, <media>, and <call-info>.  The <endpoint>
   element has as well two other actions.
      *  confirm: This action instructs child elements: <to-mixer>, and <from-
   mixer> child element described in the focus following section.

3.8.1.  from-mixer, to-mixer

   Similarly that the controls defined in the <available-media> element,
   controls that apply to allow a particular user appear at this place in the request.
   document.  The focus then uses <to-mixer> element details properties associated with
   the defined floor algorithm incoming streams to further
         allow the mixer. <from-mixer> element details
   properties associated with the outgoing streams from the mixer.  Both
   of deny these elements have the floor. attribute 'name'.  'Name' attribute has
   the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn".  The algorithms used are outside
   "VideoOut" and "AudioOut" media streams detail properties associated
   with the
         scope outgoing video and audio from the mixer.  The "VideoIn" and
   "AudioIn" media stream details properties associated with the
   incoming video and audio to the mixer.  More values can be defined in
   the future.

   Every of this document.
   o  Note these elements have the <floor> and <controls> child
   elements.

3.8.1.1.  <floor>

   The <floors> element describes a floor that placing joins this participant in
   the conference.  If a value of block participant, for this element does not
      guarantee that instance, needs to talk in the
   conference, it first needs to get a participant is blocked floor from joining the moderator of the
   conference.  Any other rule

   The <floor> element has a 'Boolen' value.  A value of 'false'
   indicates that might resolve to true for this
      participant that carried an action whose value was higher than
      block would automatically grant confirm/allow permission to that
      participant.
   o  The <show-floor-requests> element is of type boolean
      transformation.  If set to TRUE, the conference participant is
      able to see user does not hold the floor requests. in this moment.  If set to FALSE, the conference
      participant
   this control is not able to see floor requests.  If specify, this user SHOULD not specify the floor
   option.





Novo, et al.             Expires April 13, 2007                [Page 23]

Internet-Draft          Common Conference Schema            October 2006


3.9.  <sidebars-by-ref>

   The <sidebars-by-ref> element is
      undefined, it has contains a value set of FALSE, causing the floor requests to
      not being seen by the <entry> child
   elements.  Each <entry> child element contains a <user> child element
   with a sidebar conference participant.
   o  A rule can be set that provides anonymity to unique identifier and a specific identity.
      In this case, the focus provides to the rest of the participants
      an anonymous identity for that user, for example anonymous1.  This
      can be achieved by using the <provide-anonymity> <display-text>
   child element.  It  The <sidebars-by-ref> element is a
      boolean transformation.  If set to TRUE, described in Section
   5.9.1 of [2].

   Notice that the conference
      participants will see an anonymous identity for <sidebars-by-ref> child element does not include the user whose
      identity is present
   attribute 'state' defined in the conditions.
   o [2].

3.10.  <sidebars-by-val>

   The <read-write> <sidebars-by-val> element represents contains a boolean action.  If set to
      TRUE, of <entry> child
   elements each containing information about a single sidebar.

   Notice as well that the identity is allowed to modify <sidebars-by-val> and the <entry> child
   element described
      inside do not include the 'element' attribute 'state' defined in [2].


4.  RELAX NG schema

   In accordance with the conference policy.  If set
      to FALSE, any modifications to the element are rejected.
   o  The <read-only> element represents a boolean action.  If set to
      TRUE, XCON framework document [1], the identity Conference
   Object is allowed to read the element described inside
      the 'element' attribute in the a logical representation of a conference policy.  If set to
      FALSE, any attempts to read the element are rejected.

3.7.3.  <user> instance.  The element <user> describes a single participant
   common conference information schema contains core information that
   is utilized in the any conference.

   The following elements as well as  It also contains the attributes variable
   information part of <user> are
   defined the Conference Object.

   This specification defines some document fragments in [2], section 5.6: <display-text>, <associated-aors>,
   <roles>, <languages>, <cascaded-focus>, and <endpoint>. RELAX NG
   format.


<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
    xmlns:xs="http://relaxng.org/ns/compatibility/annotations/1.0"
    datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
    <start>
        <ref name="conference-type"/>
    </start>

    <!--
        CONFERENCE TYPE
    -->

    <define name="conference-type">
        <element name="conference-info">
            <ref name="role-type"/>
            <zeroOrMore>



Novo, et al.             Expires April 13, 2007                [Page 24]

Internet-Draft          Common Conference Schema            October 2006


                <ref name="conference-description-type"/>
                <element name="host-info">
                    <ref name="host-type"/>
                </element>
                <element name="conference-state">
                    <ref name="conference-state-type"/>
                </element>
                <element name="floor-information">
                    <ref name="floor-information-type"/>
                </element>
                <element name="users">
                    <ref name="user-type"/>
                </element>
                <element name="sidebars-by-ref">
                    <ref name="sidebars-by-ref-type"/>
                </element>
                <element name="sidebars-by-val">
                    <ref name="sidebars-by-val-type"/>
                </element>
            </zeroOrMore>
        </element>
    </define>

    <!--
        CONFERENCE DESCRIPTION TYPE
    -->
    <define name="conference-description-type">
        <element name="conference-description">
            <ref name="role-type"/>
            <optional>
                <element name="display-text">
                    <text/>
                </element>
                <element name="subject">
                    <text/>
                </element>
                <element name="free-text">
                    <text/>
                </element>
                <element name="keywords">
                    <list>
                        <data type="string"/>
                    </list>
                </element>
                <element name="webpage">
                    <data type="anyURI"/>
                </element>
                <element name="security-level">



Novo, et al.             Expires January 11, April 13, 2007                [Page 25]

Internet-Draft          Common Conference Schema               July            October 2006


   The <provide-anonymity> provides anonymity to the user.  When a user
   is defined then the role must be defined or set to "participant" by
   default.  This specification does not define the set of possible
   conferencing roles nor the semantics associated with each.

   The <sphere> element can be used to indicate the state (e.g., 'work',
   'home', 'meeting', 'travel') the user is currently in.  It is defined
   in section 7.2 of [9].

   The <allow-refer-users-dynamically>, <allow-invite-users-dynamically>
   and <allow-remove-users-dynamically> elements are defined in the
   previous section.

   The <floors> element is a container of <entry> child elements, each
   describing a floor that joins this participant in the conference.
   The <entry> element has the <show-floor-holder> and the <show-floor-
   requests> child element.  The <entry> child elements is represent by
   the 'id' attribute, each of which identifies a floor inside the
   conference.

   The <endpoint> element is under a <user> parent.  This element can
   provide the desired level of detail about the user's devices and
   signaling sessions taking part in the conference and has the
   following child elements defined in [2]: <display-text>, <referred>,
   <status>, <joining-method>, <joining-info>, <disconnection-method>,
   <disconnection-info>, <media>, and <call-info>.  The <endpoint>
   element has as well two other child elements: <to_mixer>, and
   <from_mixer> child element described in the following section.

3.7.3.1.  from_mixer, to_mixer

   Similarly that the controls defined in the <available-media> element,
   controls that apply to a particular user appear at this place in the
   document.  The <to_mixer> element details properties associated with
   the incoming streams to the mixer. <from_mixer> element details
   properties associated with the outgoing streams from the mixer.  BOth
   of these elements have the attribute 'name'.  'Name' attribute has
   the values "VideoIn", "Videoout", "AudioOut", and "AudioIn".  The
   "VideoOut" and "AudioOut" media streams detail properties associated
   with the outgoing video and audio from the mixer.  The "VideoIn" and
   "AudioIn" media stream details properties associated with the
   incoming video and audio to the mixer.  More values can be defined in
   the future.

   Every of these elements have the <floor> and <controls> child
   elements.  The <controls> child elements defined the same elements
   described in section 3.2.7 and some new ones.


                    <ref name="SecurityLevel"/>
                </element>
                <element name="allow-sidebars">
                    <data type="boolean"/>
                </element>
                <element name="conference-stage">
                    <ref name="conference-stage-type"/>
                </element>
                <element name="conference-time">
                    <ref name="conferencetime-type"/>
                </element>
                <element name="conf-uris">
                    <ref name="uris-type"/>
                </element>
                <element name="service-uris">
                    <ref name="uris-type"/>
                </element>
                <element name="maximum-user-count">
                    <ref name="maximum-user-count-type"/>
                </element>
                <element name="maximum-streams">
                    <ref name="maximum-streams-type"/>
                </element>
                <element name="available-media">
                    <ref name="conference-media-type"/>
                </element>
            </optional>
            <xs:any/>
        </element>
    </define>

    <!--
        SECURITY LEVEL
    -->
    <define name="SecurityLevel">
        <choice>
            <value type="string">none</value>
            <value type="string">low</value>
            <value type="string">medium</value>
            <value type="string">high</value>
        </choice>
    </define>

    <!--
        CONFERENCE STAGE
    -->
    <define name="conference-stage-type">
        <choice>



Novo, et al.             Expires January 11, April 13, 2007                [Page 26]

Internet-Draft          Common Conference Schema               July            October 2006


3.7.3.1.1.  <floor>

   If a participant, for instance, needs to talk in the conference, it
   first needs to get a floor from the moderator of the conference.  The
   floor control can be enabled or disabled by the moderator during the
   conference creation stage.  When the floor control is not enabled
   then any participant can speak in the conference at any time.  In
   this conference very basic controls like muting or pausing the output
   stream, changing the volume of the output stream are provided to end
   participants.  The <floor> element consists of the following
   attributes:

   floor_id: Uniquely identifies the floor within the context of this
   template and has a value of '1'.

   instances: Value of '1' implies only one occurrence of this floor at
   any one time.

   enable: A value of 'false' indicates that this floor is not enabled
   by default.

   value: A value of false specifies that the instance represented by
   this template does not have control of the floor.

3.7.3.1.2.  <gain>

   The 'gain' control is used in conjunction with a media output stream
   to indicate the amount of amplification of an audio stream.  It has a
   'Int' number value from -127 to 127.  The control consists of the
   following attributes:

   type: The 'gain' control has a type of 'Int'.

   name: The control is named 'gain'.

   enable: The enable attribute specifies if access to the control is
   available to the client.

   The Control also consists of the following additional elements:

   value: Indicates the default value for the 'gain' control when not
   set.

   display-text: Provides a Control label that can be rendered to the
   client.


            <value type="string">reserved</value>
            <value type="string">started</value>
            <value type="string">running</value>
            <value type="string">ended</value>
        </choice>
    </define>

    <!--
        CONFERENCE TIME
    -->
    <define name="conferencetime-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="entry">
                <optional>
                    <element name="base">
                        <text/>
                    </element>
                    <element name="mixing-start-offset">
                        <data type="int"/>
                    </element>
                    <element name="mixing-stop-offset">
                        <data type="int"/>
                    </element>
                    <element name="can-join-after-offset">
                        <data type="int"/>
                    </element>
                    <element name="must-join-before-offset">
                        <data type="int"/>
                    </element>
                    <element name="request-users">
                        <data type="int"/>
                    </element>
                    <element name="notify-end-of-conference">
                        <data type="int"/>
                    </element>
                    <element name="allowed-extend-mixing-end-offset">
                        <data type="boolean"/>
                    </element>
                </optional>
            </element>
        </zeroOrMore>
    </define>

    <!--
        URIS TYPE
    -->
    <define name="uris-type">



Novo, et al.             Expires April 13, 2007                [Page 27]

Internet-Draft          Common Conference Schema            October 2006


        <ref name="role-type"/>
        <oneOrMore>
            <element name="SIP">
                <ref name="uri-type"/>
            </element>
            <element name="H323">
                <ref name="H323-type"/>
            </element>
            <element name="PSTN-ISDN">
                <ref name="PSTN-type"/>
            </element>
            <element name="BFCP">
                <ref name="BFCP-type"/>
            </element>
        </oneOrMore>
    </define>

    <!--
        SIP TYPE
    -->
    <define name="uri-type">
        <ref name="role-type"/>
        <oneOrMore>
            <element name="uri">
                <data type="anyURI"/>
            </element>
            <zeroOrMore>
                <element name="display-text">
                    <text/>
                </element>
                <element name="purpose">
                    <text/>
                </element>
                <element name="PIN-code">
                    <data type="int"/>
                </element>
            </zeroOrMore>
        </oneOrMore>
    </define>

    <!--
        H323 TYPE
   -->
    <define name="H323-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="H.323-alias">
                <text/>



Novo, et al.             Expires April 13, 2007                [Page 28]

Internet-Draft          Common Conference Schema            October 2006


            </element>
            <element name="H.323-URI">
                <data type="anyURI"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        PSTN TYPE
    -->
    <define name="PSTN-type">
        <ref name="role-type"/>
        <attribute name="PIN-code">
            <text/>
        </attribute>
        <attribute name="purpose">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="phone-number">
                <data type="unsignedInt"/>
            </element>
            <element name="rate">
                <data type="unsignedInt"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        BFCP TYPE
    -->
    <define name="BFCP-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="conference-id">
                <data type="unsignedInt"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        MAXIMUM USER TYPE
    -->
    <define name="maximum-user-count-type">
        <ref name="role-type"/>
        <xs:attribute name="role">
            <ref name="single-role-type"/>
        </xs:attribute>
        <zeroOrMore>



Novo, et al.             Expires April 13, 2007                [Page 29]

Internet-Draft          Common Conference Schema            October 2006


            <element name="entry">
                <data type="unsignedInt"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        MAXIMUM STREAM TYPE
    -->
    <define name="maximum-streams-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="entry">
                <ref name="role-type"/>
                <attribute name="type">
                    <ref name="media-stream-type"/>
                </attribute>
                <attribute name="min">
                    <data type="positiveInteger"/>
                </attribute>
                <attribute name="max">
                    <data type="positiveInteger"/>
                </attribute>
            </element>
        </zeroOrMore>
    </define>

    <!--
        MEDIA TYPES
    -->
    <define name="media-stream-type">
        <choice>
            <value type="string">audio</value>
            <value type="string">video</value>
        </choice>
    </define>

    <!--
        CONFERENCE MEDIA TYPE
    -->
    <define name="conference-media-type">
        <ref name="role-type"/>
        <attribute name="label">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="entry">
                <ref name="conference-medium-type"/>



Novo, et al.             Expires April 13, 2007                [Page 30]

Internet-Draft          Common Conference Schema            October 2006


            </element>
        </zeroOrMore>
    </define>

    <!--
        CONFERENCE MEDIUM TYPE
    -->
    <define name="conference-medium-type">
        <ref name="role-type"/>
        <attribute name="label">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="type">
                <text/>
            </element>
            <element name="display-text">
                <text/>
            </element>
            <element name="status">
                <ref name="media-status-type"/>
            </element>
            <element name="mixing-mode">
                <ref name="mix-mode-type"/>
            </element>
            <element name="mix-level">
                <data type="unsignedInt"/>
            </element>
            <element name="codecs">
                <ref name="codecs-type"/>
            </element>
            <element name="controls">
                <ref name="control-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        MIX MODE TYPE
    -->
    <define name="mix-mode-type">
        <choice>
            <value type="string">Moderator-controlled</value>
            <value type="string">FCFS</value>
            <value type="string">"Automatic</value>
        </choice>
    </define>




Novo, et al.             Expires January 11, April 13, 2007                [Page 27] 31]

Internet-Draft          Common Conference Schema               July            October 2006


3.8.  <sidebars-by-ref>

   The <sidebars-by-ref> element contains a set of <entry> child
   elements.  Each <entry> child element contains a <user> child element
   with a sidebar conference unique identifier and a <display-text>
   child element.  The <sidebars-by-ref> element is described in Section
   5.9.1 of [2].

   Notice that the <sidebars-by-ref> child element does not include the
   attribute 'state' defined in [2].

3.9.  <sidebars-by-val>

   The <sidebars-by-val> element contains a set of <entry> child
   elements each containing information about a single sidebar.

   Notice as well that the <sidebars-by-val> and the <entry> child
   element do not include the attribute 'state' defined in [2].


4.  XML Schema

   In accordance with the XCON framework document [1], the


    <!--
        CODECS TYPE
    -->
    <define name="codecs-type">
        <ref name="role-type"/>
        <attribute name="decision">
            <ref name="decision-type"/>
        </attribute>
        <zeroOrMore>
            <element name="entry">
                <ref name="codec-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        CODEC TYPE
    -->
    <define name="codec-type">
        <ref name="role-type"/>
        <attribute name="name">
            <text/>
        </attribute>
        <attribute name="policy">
            <ref name="policy-type"/>
        </attribute>
    </define>

    <!--
        DECISION TYPE
    -->
    <define name="decision-type">
        <choice>
            <value type="string">Automatic</value>
            <value type="string">Moderator-controlled</value>
        </choice>
    </define>

    <!--
        POLICY TYPE
    -->
    <define name="policy-type">
        <choice>
            <value type="string">Allowed</value>
            <value type="string">Disallowed</value>
        </choice>
    </define>




Novo, et al.             Expires April 13, 2007                [Page 32]

Internet-Draft          Common Conference
   Object is a logical representation of a conference instance.  The
   common conference information schema contains core information that
   is utilized in any conference.  It also contains the variable
   information part of the Schema            October 2006


    <!--
        CONTROL TYPE
    -->
    <define name="control-type">
        <choice>
            <value type="string">integer</value>
            <value type="string">real</value>
            <value type="string">boolean</value>
        </choice>
    </define>

    <!--
        HOST TYPE
    -->
    <define name="host-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="web-page">
                <data type="anyURI"/>
            </element>
            <element name="uris">
                <ref name="uris-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        CONFERENCE STATE TYPE
    -->
    <define name="conference-state-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="allow-conference-state">
                <data type="boolean"/>
            </element>
            <element name="user-count">
                <data type="unsignedInt"/>
            </element>
            <element name="active">
                <data type="boolean"/>
            </element>
            <element name="locked">
                <data type="boolean"/>
            </element>
        </zeroOrMore>



Novo, et al.             Expires April 13, 2007                [Page 33]

Internet-Draft          Common Conference Object.

   This specification makes use of XML namespaces for identifying common
   conference information documents and document fragments.  The
   namespace URI for elements defined by this specification is a URN:
   urn:ietf:params:xml:ns:common-conference-schema.


   <?xml version="1.0" encoding="UTF-8" ?>
    <xs:schema xmlns="urn:ietf:params:xml:ns:common-conference-schema"
      xmlns:info="urn:ietf:params:xml:ns:conference-info"
      xmlns:compol="urn:ietf:params:xml:ns:common-policy"
      xmlns:role="urn:ietf:params:xml:ns:role-schema"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
     targetNamespace="urn:ietf:params:xml:ns:common-conference-schema" elementFormDefault="qualified" attributeFormDefault="unqualified">
      <xs:import namespace="urn:ietf:params:xml:ns:conference-info" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\conference-info.xsd" />
      <xs:import namespace="urn:ietf:params:xml:ns:common-policy" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\common-policy.xsd" />
      <xs:import namespace="urn:ietf:params:xml:ns:role-schema" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\role-schema.xsd" />

      <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/> Schema            October 2006


    </define>

    <!--
        FLOOR INFORMATION TYPE
    -->

    <define name="floor-information-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="allow-floor-events">
                <data type="boolean"/>
            </element>
            <element name="floor-request-handling">
                <ref name="floor-request-type"/>
            </element>
            <element name="conference-floor-policy">
                <ref name="Conference-floor-policy"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        FLOOR REQUEST TYPE
    -->

    <define name="floor-request-type">
        <choice>
            <value type="string">block</value>
            <value type="string">confirm</value>
        </choice>
    </define>

    <!--
        CONFERENCE INFO FLOOR POLICY
    -->

    <define name="Conference-floor-policy">
        <ref name="role-type"/>
        <attribute name="moderator-controlled">
            <data type="boolean"/>
        </attribute>
        <attribute name="label">
            <text/>
        </attribute>
        <oneOrMore>
            <element name="Floor">
                <zeroOrMore>
                    <element name="Media-types">



Novo, et al.             Expires January 11, April 13, 2007                [Page 28] 34]

Internet-Draft          Common Conference Schema               July            October 2006


      -->
      <xs:element name="conference-info" type="conference-type"/>
      <!--
       CONFERENCE TYPE
      -->
      <xs:complexType name="conference-type">
         <xs:sequence>
           <xs:element name="conference-description" type="conference-description-type"/>
           <xs:element name="host-info" type="host-type"/>
           <xs:element name="conference-state" type="conference-state-type"/>
           <xs:element name="security-mechanism" type="security-mechanisms-type" minOccurs="0"/>
           <xs:element name="floor-information" type="floor-information-type" minOccurs="0"/>
           <xs:element name="users" type="users-type"/>
           <xs:element name="sidebars-by-ref" type="sidebars-by-ref-type" minOccurs="0"/>
           <xs:element name="sidebars-by-val" type="sidebars-by-val-type" minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
      </xs:complexType>
      <!--
        CONFERENCE DESCRIPTION TYPE
      -->
      <xs:complexType name="conference-description-type">
         <xs:sequence>
           <xs:element name="display-text" type="xs:string" minOccurs="0"/>
           <xs:element name="subject" type="xs:string" minOccurs="0"/>
           <xs:element name="free-text" type="xs:string" minOccurs="0"/>
           <xs:element name="keywords" type="info:keywords-type" minOccurs="0"/>
           <xs:element name="webpage" type="xs:anyURI" minOccurs="0"/>
           <xs:element name="security-level" type="SecurityLevel" minOccurs="0"/>
           <xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/>
           <xs:element name="conference-stage" type="conference-stage-type"/>
           <xs:element name="conference-time" type="conferencetime-type" minOccurs="0"/>
           <xs:element name="conf-uris" type="uris-type" minOccurs="0"/>
           <xs:element name="service-uris" type="uris-type" minOccurs="0"/>
           <xs:element name="maximum-user-count" type="maximum-user-count-type" minOccurs="0"/>
           <xs:element name="available-media" type="conference-media-type"/>
           <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:complexType>
      <!--
        SECURITY LEVEL
      -->
      <xs:simpleType name="SecurityLevel">
         <xs:restriction base="xs:string">
           <xs:enumeration value="none"/>
           <xs:enumeration value="low"/>
           <xs:enumeration value="medium"/>


                        <ref name="role-type"/>
                        <zeroOrMore>
                            <element name="Video">
                                <empty/>
                            </element>
                            <element name="Audio">
                                <empty/>
                            </element>
                            <element name="Application">
                                <empty/>
                            </element>
                            <element name="Data">
                                <empty/>
                            </element>
                            <element name="Control">
                                <empty/>
                            </element>
                            <element name="Message">
                                <empty/>
                            </element>
                            <element name="Text">
                                <empty/>
                            </element>
                        </zeroOrMore>
                    </element>
                    <element name="Algorithm">
                        <ref name="role-type"/>
                        <zeroOrMore>
                            <element name="Moderator-controlled">
                                <empty/>
                            </element>
                            <element name="FCFS">
                                <empty/>
                            </element>
                            <element name="Random">
                                <empty/>
                            </element>
                        </zeroOrMore>
                    </element>
                    <element name="Max-floor-users">
                        <data type="nonNegativeInteger"/>
                    </element>
                    <element name="Moderator-URI">
                        <data type="anyURI"/>
                    </element>
                </zeroOrMore>
            </element>
        </oneOrMore>



Novo, et al.             Expires January 11, April 13, 2007                [Page 29] 35]

Internet-Draft          Common Conference Schema               July            October 2006


           <xs:enumeration value="high"/>
         </xs:restriction>
      </xs:simpleType>


    </define>

    <!--
        CONFERENCE STAGE
        USERS TYPE
    -->
      <xs:simpleType name="conference-stage-type">
         <xs:restriction base="xs:string">
           <xs:enumeration value="reserved"/>
           <xs:enumeration value="started"/>
           <xs:enumeration value="running"/>
           <xs:enumeration value="ended"/>
         </xs:restriction>
      </xs:simpleType>
    <define name="users-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="join-handling">
                <ref name="join-handling-type"/>
            </element>
            <element name="user-admission-policy">
                <ref name="user-admission-policy-type"/>
            </element>
            <element name="user-must-be-specified">
                <data type="boolean"/>
            </element>
            <element name="allowed-users-list">
                <ref name="UserList"/>
            </element>
            <element name="privileges-control-list">
                <ref name="privileges-control-list-type"/>
            </element>
            <element name="user">
                <ref name="user-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        CONFERENCE TIME
        USERS ADMISSION POLICY
    -->
      <xs:complexType name="conferencetime-type">
         <xs:sequence>
           <xs:element name="entry" minOccurs="0" maxOccurs="unbounded">
             <xs:complexType>
                <xs:sequence>
                   <xs:element name="base" type="xs:string"/>
                   <xs:element name="mixing-start-offset" type="xs:integer" minOccurs="0"/>
                   <xs:element name="mixing-stop-offset" type="xs:integer" minOccurs="0"/>
                   <xs:element name="can-join-after-offset" type="xs:integer" minOccurs="0"/>
                   <xs:element name="must-join-before-offset" type="xs:integer" minOccurs="0"/>
                   <xs:element name="request-users" type="xs:integer" minOccurs="0"/>
                   <xs:element name="notify-end-of-conference" type="xs:integer" minOccurs="0"/>
                   <xs:element name="allowed-extend-mixing-end-offset" type="xs:boolean" default="true" minOccurs="0"/>
                   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
                </xs:sequence>
             </xs:complexType>
           </xs:element>
         </xs:sequence>
        </xs:complexType>
    <define name="user-admission-policy-type">
        <choice>
            <value type="string">closedAuthenticated</value>
            <value type="string">openAuthenticated</value>
            <value type="string">anonymous</value>
        </choice>
    </define>
    <!--
         URIS
        JOIN HANDLING TYPE
    -->
        <xs:complexType name="uris-type">
           <xs:sequence>
              <xs:element name="SIP" type="uri-type" maxOccurs="unbounded"/>
              <xs:element name="H323" type="H323-type" maxOccurs="unbounded"/>
              <xs:element name="PSTN-ISDN" type="PSTN-type" maxOccurs="unbounded"/>
              <xs:element name="BFCP" type="BFCP-type" maxOccurs="unbounded"/>
           </xs:sequence>
        </xs:complexType>
        <!--
    <define name="join-handling-type">
        <choice>
            <value type="string">block</value>
            <value type="string">allow</value>
            <value type="string">confirm</value>
            <value type="string">IVR</value>
            <value type="string">directed-operator</value>



Novo, et al.             Expires January 11, April 13, 2007                [Page 30] 36]

Internet-Draft          Common Conference Schema               July            October 2006


          SIP TYPE
        -->
        <xs:complexType name="uri-type">
           <xs:sequence>
              <xs:element name="uri" type="xs:anyURI"/>
              <xs:element name="display-text" type="xs:string" minOccurs="0"/>
              <xs:element name="purpose" type="xs:string" minOccurs="0"/>
              <xs:element name="PIN-code" type="xs:integer" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


        </choice>
    </define>

    <!--
          H323 TYPE
        USERLIST
    -->
        <xs:complexType name="H323-type">
           <xs:sequence>
              <xs:element name="H.323-alias" type="xs:string" minOccurs="0"/>
              <xs:element name="H.323-URI" type="xs:anyURI"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
    <define name="UserList">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="target">
                <ref name="Target"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
           PSTN TYPE
        TARGET
    -->
        <xs:complexType name="PSTN-type">
           <xs:sequence>
              <xs:element name="phone-number" type="xs:unsignedInt" minOccurs="0"/>
              <xs:element name="rate" type="xs:unsignedInt" minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="PIN-code" type="xs:string" use="required"/>
           <xs:attribute name="purpose" type="xs:string"/>
        </xs:complexType>
    <define name="Target">
        <ref name="role-type"/>
        <attribute name="uri">
            <data type="anyURI"/>
        </attribute>
        <attribute name="method">
            <ref name="method-type"/>
        </attribute>
    </define>
    <!--
           BFCP
        METHOD TYPE
    -->
        <xs:complexType name="BFCP-type">
           <xs:sequence>
              <xs:element name="conference-id" type="xs:unsignedInt" minOccurs="0"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
    <define name="method-type">
        <choice>
            <value type="string">dial-in</value>
            <value type="string">dial-out</value>
            <value type="string">refer</value>
        </choice>
    </define>
    <!--
           MAXIMUM USER
        PRIVILEGES CONTROL LIST TYPE
    -->
        <xs:complexType name="maximum-user-count-type">
           <xs:sequence>
    <define name="privileges-control-list-type">
        <ref name="role-type"/>
        <oneOrMore>
            <element name="conference-rules">
                <ref name="conference-rules-type"/>
            </element>
        </oneOrMore>
    </define>




Novo, et al.             Expires January 11, April 13, 2007                [Page 31] 37]

Internet-Draft          Common Conference Schema               July            October 2006


              <xs:element name="entry" type="xs:unsignedInt" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="role" type="role:role-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


    <!--
        CONFERENCE MEDIA RULES TYPE
    -->
        <xs:complexType name="conference-media-type">
           <xs:sequence>
              <xs:element name="entry" type="conference-medium-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="label" type="xs:string" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
    <define name="conference-rules-type">
        <ref name="role-type"/>
        <attribute name="id">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="entry">
                <ref name="conference-rule-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        CONFERENCE MEDIUM RULE TYPE
    -->
        <xs:complexType name="conference-medium-type">
           <xs:sequence>
              <xs:element name="type" type="xs:string"/>
              <xs:element name="display-text" type="xs:string" minOccurs="0"/>
              <xs:element name="status" type="info:media-status-type" minOccurs="0"/>
              <xs:element name="mixing-mode" type="mix-mode-type" minOccurs="0"/>
              <xs:element name="mix level" type="xs:unsignedInt" minOccurs="0"/>
              <xs:element name="codecs" type="codecs-type" minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="label" type="xs:string" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
    <define name="conference-rule-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="condition">
                <ref name="condition-type"/>
            </element>
            <element name="action">
                <ref name="action-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
           MIX MODE
        CONDITION TYPE
    -->
        <xs:simpleType name="mix-mode-type">
           <xs:restriction base="xs:string">
              <xs:enumeration value="Moderator-controlled"/>
              <xs:enumeration value="FCFS"/>
              <xs:enumeration value="Automatic"/>
           </xs:restriction>
        </xs:simpleType>
    <define name="condition-type">
        <ref name="role-type"/>
        <element name="identity">
            <ref name="identity-type"/>
        </element>
        <element name="validity">
            <ref name="validityType"/>
        </element>
    </define>
    <!--
           CODECS
        IDENTITY TYPE
    -->
        <xs:complexType name="codecs-type">
           <xs:sequence>
              <xs:element name="entry" type="codec-type" maxOccurs="unbounded"/>
    <define name="identity-type">
        <ref name="role-type"/>
        <element name="identity">
            <ref name="identityType"/>
        </element>



Novo, et al.             Expires January 11, April 13, 2007                [Page 32] 38]

Internet-Draft          Common Conference Schema               July            October 2006


           </xs:sequence>
           <xs:attribute name="decision" type="decision-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           CODEC TYPE
        -->
        <xs:complexType name="codec-type">
           <xs:attribute name="name" type="xs:string" use="required"/>
           <xs:attribute name="policy" type="policy-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           DECISION TYPE
        -->
        <xs:simpleType name="decision-type">
           <xs:restriction base="xs:string">
              <xs:enumeration value="Automatic"/>
              <xs:enumeration value="Moderator-controlled"/>
           </xs:restriction>
        </xs:simpleType>
        <!--
           POLICY TYPE
        -->
        <xs:simpleType name="policy-type">
           <xs:restriction base="xs:string">
              <xs:enumeration value="Allowed"/>
              <xs:enumeration value="Disallowed"/>
           </xs:restriction>
        </xs:simpleType>
        <!--
           HOST TYPE
        -->
        <xs:complexType name="host-type">
           <xs:sequence>
              <xs:element name="display-text" type="xs:string" minOccurs="0"/>
              <xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
              <xs:element name="uris" type="uris-type" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:complexType>


        <element name="validity">
            <ref name="validityType"/>
        </element>
    </define>

    <!--
           CONFERENCE STATE
        ROLES IDENTITY TYPE
    -->
        <xs:complexType name="conference-state-type">
           <xs:sequence>
              <xs:element name="allow-conference-state" type="xs:boolean" minOccurs="0"/>
    <define name="identityType">
        <choice>
            <element name="one">
                <ref name="oneType"/>
            </element>
            <element name="many">
                <ref name="manyType"/>
            </element>
            <element name="pseudonymous">
                <text/>
            </element>
            <element name="has-been-referred">
                <text/>
            </element>
            <element name="has-been-invited">
                <text/>
            </element>
            <element name="has-been-in-conference">
                <text/>
            </element>
            <element name="is-in-conference">
                <text/>
            </element>
            <element name="administrator">
                <text/>
            </element>
            <element name="is-on-allowed-users-list-dial-out">
                <text/>
            </element>
            <element name="is-on-allowed-users-list-refer">
                <text/>
            </element>
            <element name="participant-passcode">
                <text/>
            </element>
            <element name="administrator-passcode">
                <text/>
            </element>
        </choice>
    </define>



Novo, et al.             Expires January 11, April 13, 2007                [Page 33] 39]

Internet-Draft          Common Conference Schema               July            October 2006


              <xs:element name="user-count" type="xs:unsignedInt" minOccurs="0"/>
              <xs:element name="active" type="xs:boolean" minOccurs="0"/>
              <xs:element name="locked" type="xs:boolean" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
              </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


    <!--
           SECURITY MECHANISMS
        ACTION TYPE
    -->
        <xs:complexType name="security-mechanisms-type">
           <xs:sequence>
               <xs:element name="entry-protocol" type="security-mechanism-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
    <define name="action-type">
        <choice>
            <element name="allow-refer-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-invite-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-remove-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="show-floor-holder">
                <ref name="floor-request-type"/>
            </element>
            <element name="show-floor-request">
                <data type="boolean"/>
            </element>
            <element name="provide-anonymity">
                <data type="boolean"/>
            </element>
            <element name="read-only">
                <ref name="single-role-type"/>
            </element>
            <element name="read-write">
                <ref name="single-role-type"/>
            </element>
        </choice>
    </define>

    <!--
           SECURITY MECHANISM
        USER TYPE
    -->
        <xs:complexType name="security-mechanism-type">
           <xs:sequence>
           <xs:element name="methods" type="methods-type" minOccurs="0"/>
              <xs:element name="option-tags" type="option-tags-type" minOccurs="0"/>
              <xs:element name="feature-tags" type="feature-tags-type" minOccurs="0"/>
              <xs:element name="bodies" type="bodies-type" minOccurs="0"/>
              <xs:element name="version" type="xs:unsignedInt" minOccurs="0"/>
              <xs:element name="supported" type="xs:boolean" minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="name" type="xs:string" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:complexType>
        <!--
           METHODS TYPE
        -->
        <xs:complexType name="methods-type">
           <xs:sequence>
              <xs:element name="method" type="codec-type" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="default-policy" type="policy-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
    <define name="user-type">
        <ref name="role-type"/>
        <attribute name="state">
            <ref name="state-type"/>
        </attribute>
        <zeroOrMore>
            <element name="user">
                <ref name="one-user-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
           OPTION TAGS
        ONE USER TYPE
        -->
        <xs:complexType name="option-tags-type">
           <xs:sequence>



Novo, et al.             Expires January 11, April 13, 2007                [Page 34] 40]

Internet-Draft          Common Conference Schema               July            October 2006


              <xs:element name="option-tag" type="codec-type" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="default-policy" type="default-policy-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           DEFAULT POLICY TYPE


    -->
        <xs:simpleType name="default-policy-type">
           <xs:restriction base="xs:string">
              <xs:enumeration value="Allowed"/>
              <xs:enumeration value="Disallowed"/>
              <xs:enumeration value="Mandatory"/>
           </xs:restriction>
        </xs:simpleType>
        <!--
           FEATURE TAGS TYPE
        -->
        <xs:complexType name="feature-tags-type">
           <xs:sequence>
              <xs:element name="feature-tag" type="codec-type" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="default-policy" type="policy-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           BODIES TYPE
        -->
        <xs:complexType name="bodies-type">
           <xs:sequence>
              <xs:element name="body-disposition" type="body-type" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="default-policy" type="policy-type" use="required"/>
           <xs:attribute name="default-encryption" type="policy-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           BODY TYPE
        -->
        <xs:complexType name="body-type">
           <xs:sequence>
              <xs:element name="body-format" type="codec-type" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="name" type="xs:string" use="required"/>
    <define name="one-user-type">
        <ref name="role-type"/>
        <attribute name="entity">
            <data type="anyURI"/>
        </attribute>
        <attribute name="state">
            <ref name="state-type"/>
        </attribute>
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="associated-aors">
                <ref name="uris-type"/>
            </element>
            <element name="provide-anonymity">
                <data type="boolean"/>
            </element>
            <element name="roles">
                <ref name="single-role-type"/>
            </element>
            <element name="languages">
                <list>
                    <data type="language"/>
                </list>
            </element>
            <element name="cascaded-focus">
                <data type="anyURI"/>
            </element>
            <element name="sphere">
                <ref name="sphereType"/>
            </element>
            <element name="allow-refer-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-invite-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-remove-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="endpoint">
                <ref name="endpoint-type"/>
            </element>
        </zeroOrMore>
    </define>




Novo, et al.             Expires January 11, April 13, 2007                [Page 35] 41]

Internet-Draft          Common Conference Schema               July            October 2006


           <xs:attribute name="policy" type="policy-type" use="required"/>
           <xs:attribute name="default-policy" type="policy-type" use="required"/>
           <xs:attribute name="encryption" type="policy-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


    <!--
           FLOOR INFORMATION
        ENDPOINT TYPE
    -->
        <xs:complexType name="floor-information-type">
           <xs:sequence>
              <xs:element name="allow-floor-events" type="xs:boolean" maxOccurs="unbounded"/>
              <xs:element name="floor-request-handling" type="floor-request-type" maxOccurs="unbounded"/>
              <xs:element name="conference-floor-policy" type="Conference-floor-policy" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
    <define name="endpoint-type">
        <ref name="role-type"/>
        <attribute name="entity">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="referred">
                <ref name="execution-type"/>
            </element>
            <element name="status">
                <ref name="endpoint-status-type"/>
            </element>
            <element name="joining-method">
                <ref name="joining-type"/>
            </element>
            <element name="joining-info">
                <ref name="execution-type"/>
            </element>
            <element name="disconnection-method">
                <ref name="disconnection-type"/>
            </element>
            <element name="disconnection-info">
                <ref name="execution-type"/>
            </element>
            <element name="media">
                <ref name="media-type"/>
            </element>
            <element name="call-info">
                <ref name="call-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
           FLOOR REQUEST
        MEDIA TYPE
    -->
        <xs:simpleType name="floor-request-type">
           <xs:restriction base="xs:string">
              <xs:enumeration value="block"/>
              <xs:enumeration value="confirm"/>
           </xs:restriction>
        </xs:simpleType>
        <!--
           CONFERENCE FLOOR POLICY
        -->
        <xs:complexType name="Conference-floor-policy">
           <xs:sequence>
              <xs:element name="Floor" maxOccurs="unbounded">
                 <xs:complexType>
                    <xs:sequence>
                       <xs:element name="Media-types">
                          <xs:complexType>
                             <xs:sequence>
                                <xs:element name="Video" minOccurs="0"/>
                                <xs:element name="Audio" minOccurs="0"/>
                                <xs:element name="Application" minOccurs="0"/>
                                <xs:element name="Data" minOccurs="0"/>
                                <xs:element name="Control" minOccurs="0"/>
                                <xs:element name="Message" minOccurs="0"/>
                                <xs:element name="Text" minOccurs="0"/>
                                <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                             </xs:sequence>
                          </xs:complexType>
                       </xs:element>
    <define name="media-type">
        <attribute name="id">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="display-text">



Novo, et al.             Expires January 11, April 13, 2007                [Page 36] 42]

Internet-Draft          Common Conference Schema               July            October 2006


                    <xs:element name="Algorithm">
                       <xs:complexType>
                          <xs:sequence>
                             <xs:element name="Moderator-controlled" minOccurs="0"/>
                             <xs:element name="FCFS" minOccurs="0"/>
                             <xs:element name="Random" minOccurs="0"/>
                             <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                          </xs:sequence>
                       </xs:complexType>
                    </xs:element>
                    <xs:element name="Max-floor-users" type="xs:nonNegativeInteger" minOccurs="0"/>
                    <xs:element name="Moderator-URI" type="xs:anyURI" minOccurs="0"/>
                 </xs:sequence>
                 <xs:attribute name="moderator-controlled" type="xs:boolean" default="false"/>
                 <xs:attribute name="label" type="xs:string" use="required"/>
                 </xs:complexType>
              </xs:element>
           </xs:sequence>
        </xs:complexType>
        <!--
           USERS TYPE
        -->
        <xs:complexType name="users-type">
           <xs:sequence>
              <xs:element name="join-handling" type="join-handling-type" minOccurs="0"/>
              <xs:element name="user-admission-policy" type="user-admission-policy-type"/>
              <xs:element name="user-must-be-specified" type="xs:boolean" minOccurs="0"/>
              <xs:element name="allowed-users-list" type="UserList" minOccurs="0"/>
              <xs:element name="privileges-control-list" type="privileges-control-list-type" minOccurs="0"/>
              <xs:element name="user" type="user-type" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


                <text/>
            </element>
            <element name="type">
                <text/>
            </element>
            <element name="label">
                <text/>
            </element>
            <element name="src-id">
                <text/>
            </element>
            <element name="status">
                <ref name="media-status-type"/>
            </element>
            <element name="to-mixer">
                <ref name="mixer-type"/>
            </element>
            <element name="from-mixer">
                <ref name="mixer-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        MIXER TYPE
    -->
    <define name="mixer-type">
        <ref name="role-type"/>
        <optional>
            <element name="floor">
                <data type="boolean"/>
            </element>
            <element name="controls">
                <ref name="control-type"/>
            </element>
        </optional>
    </define>

    <!--
           USERS ADMISSION POLICY
        -->
        <xs:simpleType name="user-admission-policy-type">
           <xs:restriction base="xs:string">
              <xs:enumeration value="closedAuthenticated"/>
              <xs:enumeration value="openAuthenticated"/>
              <xs:enumeration value="anonymous"/>
           </xs:restriction>
        </xs:simpleType>
        <!--
           JOIN HANDLING
        SIDEBARS-BY-REF TYPE
    -->
        <xs:simpleType name="join-handling-type">
    <define name="sidebars-by-ref-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="entry">
                <ref name="uri-type"/>
            </element>
        </zeroOrMore>
    </define>



Novo, et al.             Expires January 11, April 13, 2007                [Page 37] 43]

Internet-Draft          Common Conference Schema               July            October 2006


           <xs:restriction base="xs:string">
              <xs:enumeration value="block"/>
              <xs:enumeration value="allow"/>
              <xs:enumeration value="confirm"/>
              <xs:enumeration value="IVR"/>
              <xs:enumeration value="directed-operator"/>
           </xs:restriction>
         </xs:simpleType>
         <!--
           USERLIST
         -->
         <xs:complexType name="UserList">
           <xs:sequence>
              <xs:element name="target" type="Target" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
         </xs:complexType>
         <!--
           TARGET
         -->
          <xs:complexType name="Target">
           <xs:complexContent>
              <xs:restriction base="xs:anyType">
                 <xs:sequence>
                     <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                 </xs:sequence>
                 <xs:attribute name="uri" type="xs:anyURI" use="required"/>
                 <xs:attribute name="method" type="xs:methodType" use="required"/>
               </xs:restriction>
           </xs:complexContent>
         </xs:complexType>


    <!--
           METHOD
        SIDEBARS-BY-VAL TYPE
    -->
        <xs:complexType name="methodType">
           <xs:complexContent>
              <xs:restriction base="xs:anyType">
                 <xs:choice minOccurs="0">
                    <xs:element name="dial-in" type="xs:string"/>
                    <xs:element name="dial-out" type="xs:string"/>
                    <xs:element name="refer" type="xs:string"/>
                    <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                 </xs:choice>
              </xs:restriction>
           </xs:complexContent>
        </xs:complexType>
    <define name="sidebars-by-val-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="entry">
                <ref name="conference-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        ********************************************************************************
        TYPES DEFINED IN THE EVENT PACKAGES FOR CONFERENCE STATE
        ********************************************************************************
    -->

    <!--
          PRIVILEGES CONTROL LIST
       MEDIA STATUS TYPE
    -->

    <define name="media-status-type">
        <choice>
            <value type="string">recvonly</value>
            <value type="string">sendonly</value>
            <value type="string">sendrecv</value>
            <value type="string">inactive</value>
        </choice>
    </define>

    <!--
        EXECUTION TYPE
    -->

    <define name="execution-type">
        <zeroOrMore>
            <element name="when">
                <data type="int"/>
            </element>
            <element name="reason">
                <data type="string"/>
            </element>
            <element name="by">
                <data type="anyURI"/>
            </element>
        </zeroOrMore>
    </define>



Novo, et al.             Expires January 11, April 13, 2007                [Page 38] 44]

Internet-Draft          Common Conference Schema               July            October 2006


         <xs:complexType name="privileges-control-list-type">
           <xs:sequence>
              <xs:element name="data-access-rights" type="data-access-rights-type" maxOccurs="unbounded"/>
              <xs:element name="conference-rules" type="conference-rules-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:complexType>
         <!--
           DATA ACCESS RIGHTS TYPE
         -->
         <xs:complexType name="data-access-rights-type">
           <xs:sequence>
              <xs:element name="entry" type="entry-rights-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:complexType>
        <!--
           ENTRY RIGHTS TYPE
        -->
        <xs:complexType name="entry-rights-type">
           <xs:attribute name="name" type="xs:string" use="required"/>
           <xs:attribute name="read-only" type="role:role-type" use="required"/>
           <xs:attribute name="read-write" type="role:role-type" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


    <!--
           CONFERENCE RULES
        CALL TYPE
    -->
        <xs:complexType name="conference-rules-type">
           <xs:sequence>
              <xs:element name="entry" type="conference-rule-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="id" type="xs:string" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>

    <define name="call-type">
        <zeroOrMore>
            <element name="sip">
                <ref name="sip-dialog-id-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
           CONFERENCE RULE
        SIP DIALOG ID TYPE
    -->
        <xs:complexType name="conference-rule-type">
           <xs:sequence>
              <xs:element name="condition" type="condition-type" maxOccurs="unbounded"/>
              <xs:element name="action" type="action-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>

    <define name="sip-dialog-id-type">
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="call-id">
                <text/>
            </element>
            <element name="from-tag">
                <text/>
            </element>
            <element name="to-tag">
                <text/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        DISCONNECTION TYPE
    -->

    <define name="disconnection-type">
        <choice>
            <value type="string">departed</value>
            <value type="string">booted</value>
            <value type="string">failed</value>
            <value type="string">busy</value>
        </choice>
    </define>

    <!--
           CONDITION
        JOINING TYPE
        -->



Novo, et al.             Expires January 11, April 13, 2007                [Page 39] 45]

Internet-Draft          Common Conference Schema               July            October 2006


        <xs:complexType name="condition-type">
           <xs:sequence>
              <xs:element name="identity" type="identity-type"/>
              <xs:element name="validity" type="compol:validityType"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


    -->

    <define name="joining-type">
        <choice>
            <value type="string">dialed-in</value>
            <value type="string">dialed-out</value>
            <value type="string">focus-owner</value>
        </choice>
    </define>

    <!--
       ENDPOINT STATUS TYPE
    -->

    <define name="endpoint-status-type">
        <choice>
            <value type="string">pending</value>
            <value type="string">dialing-out</value>
            <value type="string">dialing-in</value>
            <value type="string">alerting</value>
            <value type="string">on-hold</value>
            <value type="string">connected</value>
            <value type="string">muted-via-focus</value>
            <value type="string">disconnecting</value>
            <value type="string">disconnected</value>
        </choice>
    </define>

    <!--
           IDENTITY
        STATE TYPE
    -->
        <xs:complexType name="identity-type">
           <xs:sequence>
              <xs:element name="identity" type="identityType" maxOccurs="unbounded"/>
              <xs:element name="validity" type="compol:validityType" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>

    <define name="state-type">
        <choice>
            <value type="string">full</value>
            <value type="string">partial</value>
            <value type="string">deleted</value>
        </choice>
    </define>
    <!--
           ROLES IDENTITY
        ***********************************************
        TYPE DEFINED IN THE ROLE DOCUMENT
        ***********************************************
    -->
        <xs:complexType name="identityType">
           <xs:complexContent>
              <xs:restriction base="xs:anyType">
                 <xs:choice minOccurs="0">
                    <xs:element name="one" type="compol:oneType"/>
                    <xs:element name="many" type="compol:manyType"/>
                    <xs:element name="external-list" type="xs:string"/>
                    <xs:element name="pseudonymous" type="xs:string"/>
                    <xs:element name="has-been-referred" type="xs:string"/>
                    <xs:element name="has-been-invited" type="xs:string"/>
                    <xs:element name="has-been-in-conference" type="xs:string"/>
                    <xs:element name="is-in-conference" type="xs:string"/>
                    <xs:element name="administrator" type="xs:string"/>
                    <xs:element name="is-on-allowed-users-list-dial-out" type="xs:string"/>
                    <xs:element name="is-on-allowed-users-list-refer" type="xs:string"/>
                    <xs:element name="participant-passcode" type="xs:string"/>
                    <xs:element name="administrator-passcode" type="xs:string"/>
                    <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                 </xs:choice>
              </xs:restriction>
           </xs:complexContent>
        </xs:complexType>

    <!--
           ACTION
        ROLE TYPE
    -->
        <xs:complexType name="action-type">
           <xs:complexContent>
              <xs:restriction base="xs:anyType">



Novo, et al.             Expires January 11, April 13, 2007                [Page 40] 46]

Internet-Draft          Common Conference Schema               July            October 2006


                 <xs:choice minOccurs="0" maxOccurs="unbounded">
                   <xs:element name="allow-refer-users-dynamically" type="xs:boolean"/>
                   <xs:element name="allow-invite-users-dynamically" type="xs:boolean"/>
                   <xs:element name="allow-remove-users-dynamically" type="xs:boolean"/>
                   <xs:element name="show-floor-holder" type="floor-request-type"/>
                   <xs:element name="show-floor-request" type="xs:boolean"/>
                   <xs:element name="provide-anonymity" type="xs:boolean"/>
                   <xs:element name="read-only" type="role:role-type"/>
                   <xs:element name="read-write" type="role:role-type"/>
                 </xs:choice>
              </xs:restriction>
           </xs:complexContent>
         </xs:complexType>


    <define name="role-type">
        <attribute name="read-only">
            <ref name="single-role-type"/>
        </attribute>

        <attribute name="write-only">
            <ref name="single-role-type"/>
        </attribute>
    </define>

    <!--
        SINGLE ROLE TYPE
    -->

    <define name="single-role-type">
        <choice>
            <value type="string">Administrator</value>
            <value type="string">Creator</value>
            <value type="string">Moderator</value>
            <value type="string">Participant</value>
            <value type="string">Observer</value>
        </choice>
    </define>

    <!--
           USER
        ************************************************************
        TYPE DEFINED IN THE COMMON POLICY DOCUMENT
        ************************************************************
    -->
        <xs:complexType name="user-type">
           <xs:sequence>
              <xs:element name="user" type="one-user-type" minOccurs="0" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="state" type="info:state-type" use="optional" default="full"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>


    <!--
           ONE USER
       VALIDITY TYPE
    -->
        <xs:complexType name="one-user-type">
           <xs:sequence>
              <xs:element name="display-text" type="xs:string" minOccurs="0"/>
              <xs:element name="associated-aors" type="info:uris-type" minOccurs="0"/>
              <xs:element name="provide-anonymity" type="xs:boolean" minOccurs="0"/>
              <xs:element name="roles" type="role:role-type" minOccurs="0"/>
              <xs:element name="languages" type="info:user-languages-type" minOccurs="0"/>
              <xs:element name="cascaded-focus" type="xs:anyURI" minOccurs="0"/>
              <xs:element name="sphere" type="compol:sphereType" minOccurs="0"/>
              <xs:element name="allow-refer-users-dynamically" type="xs:boolean"/>
              <xs:element name="allow-invite-users-dynamically" type="xs:boolean"/>
              <xs:element name="allow-remove-users-dynamically" type="xs:boolean"/>
              <xs:element name="floors" type="show-floors-type"/>
              <xs:element name="endpoint" type="info:endpoint-type" minOccurs="0" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="entity" type="xs:anyURI"/>
           <xs:attribute name="state" type="info:state-type" use="optional" default="full"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>

    <define name="validityType">
        <choice>
            <element name="from">
                <data type="int"/>
            </element>
            <element name="until">
                <data type="int"/>
            </element>
        </choice>
    </define>

    <!--
        ONE TYPE



Novo, et al.             Expires January 11, April 13, 2007                [Page 41] 47]

Internet-Draft          Common Conference Schema               July            October 2006


           SHOW FLOORS TYPE
        -->
        <xs:complexType name="show-floors-type">
           <xs:sequence>
              <xs:element name="entry" type="show-floor-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           SHOW FLOOR TYPE
        -->
        <xs:complexType name="show-floor-type">
           <xs:sequence>
              <xs:element name="show-floor-holder" type="xs:boolean" minOccurs="0"/>
              <xs:element name="show-floor-request" type="xs:boolean"/>
              <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="id" type="xs:string" use="required"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           SIDEBARS-BY-REF TYPE


    -->
        <xs:complexType name="sidebars-by-ref-type">
           <xs:sequence>
              <xs:element name="entry" type="info:uri-type" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
        <!--
           SIDEBARS-BY-VAL TYPE
        -->
        <xs:complexType name="sidebars-by-val-type">
           <xs:sequence>
              <xs:element name="entry" type="conference-type" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
   </xs:schema>
    <define name="oneType">
        <attribute name="id">
            <data type="anyURI"/>
        </attribute>
    </define>

    <!--
        MANY TYPE
    -->
    <define name="manyType">
        <choice>
            <element name="except">
                <ref name="exceptType"/>
            </element>
        </choice>
        <attribute name="domain">
            <text/>
        </attribute>
    </define>

    <define name="exceptType">
        <attribute name="domain">
            <text/>
        </attribute>
        <attribute name="id">
            <data type="anyURI"/>
        </attribute>
    </define>

    <!--
      SPHERE TYPE
    -->
    <define name="sphereType">
        <attribute name="value">
            <text/>
        </attribute>
    </define>

</grammar>




5.  XML Schema Extensibility

   The Common Conference Information Data Model defined in this document
   is meant to be extensible toward specific application domains.  Such



Novo, et al.             Expires April 13, 2007                [Page 48]

Internet-Draft          Common Conference Schema            October 2006


   an extension is accomplished by defining elements, child elements and
   attributes that are specific to the desired application domain.  Each



Novo, et al.            Expires January 11, 2007               [Page 42]

Internet-Draft          Common Conference Schema               July 2006
   extension MUST define its own namespace.  Points of extension MUST be
   defined in the schema, and SHOULD be done using the <any
   namespace="##other"> <anyName>/
   <except> construct.

   Elements or attributes from unknown namespaces MUST be ignored.


6.  XML example

   The following is an example of a common conference information
   document.  The conference starts on October 17, 2006, at 10:30 AM in
   New York City and finishes the same day at 12:30 PM every week.  In
   this example, there are currently 3 participants in a conference, one
   administrator, one moderator, and one participant.  Note that
   sidebars are allowed in this conference and there is one sidebar in
   the conference.  Also note that there is one floor moderator for the
   audio and a different floor moderator for the video.


   <?xml version="1.0" encoding="UTF-8"?>
      <conference-info
       xmlns="urn:ietf:params:xml:ns:common-conference-schema"
       xmlns:info="urn:ietf:params:xml:ns:conference-info"
       xmlns:sesspol="urn:ietf:params:xml:ns:sessionpolicy"
       xmlns:compol="urn:ietf:params:xml:ns:common-policy"
       entity="sips:conference@example.com">
      <!--
        CONFERENCE DESCRIPTION
      -->
       <info:conference-description xml:lang="en-us">
        <info:display-text>Discussion of the best moments in Formula-1\\
   racing</info:display-text> Formula-1 racing<
        /info:display-text>
        <info:subject> Sports:Formula-1</info:subject>
        <info:free-text>This is a conference example</info:free-text>
        <info:keywords>Formula-1, cars</info:keywords>
        <web-page>http://www.example.com/users/alice/formula-1\\
   </web-page>
        <web-page>http://www.example.com/users/alice/formula-1<
        /web-page>
        <security-level>low</security-level>
        <allow-sidebars>true</allow-sidebars>
        <conference-stage>running</conference-stage>
       <!--
        CONFERENCE TIME
        -->
        <conference-time>
         <entry>
          <base>
              BEGIN:VCALENDAR
              PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
          <base>BEGIN:VCALENDAR



Novo, et al.             Expires January 11, April 13, 2007                [Page 43] 49]

Internet-Draft          Common Conference Schema               July            October 2006


              PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
              VERSION:2.0
              BEGIN:VEVENT
              DTSTAMP:20051103T140728Z
              UID:carol at example.com
              ORGANIZER:MAILTO:carol at example.com
              DTSTART:20061017T143000Z
              RRULE:FREQ=WEEKLY
              DTEND:20061017T163000Z
          </base>
              DTEND:20061017T163000Z</base>

          <mixing-start-offset required-participant="moderator">
          20061017T142900Z</mixing-start-offset>
          <mixing-end-offset required-participant="participant">
           20061017T163100Z</mixing-end-offset>
          <must-join-before-offset>
           20061017T15300Z</must-join-before-offset>
         </entry>
        </conference-time>
        <!--
        CONFERENCE UNIQUE IDENTIFIERS
        -->
        <info:conf-uris>
         <info:SIP>
          <info:uri>tel:+3585671234</info:uri>
          <info:display-text>Conference Bridge</info:display-text>
          <info:purpose>participation</info:purpose>
         </info:SIP>
         <info:SIP>
          <info:uri>http://www.example.com/54634/live.ram</info:uri>
          <info:purpose>streaming</info:purpose>
         </info:SIP>
        </info:conf-uris>
        <!--
          SERVICE URIS
        -->
        <info:service-uris>
         <info:SIP>
          <info:uri>http://www.example.com/formula1/</info:uri>
          <info:purpose>web-page</info:purpose>
         </info:SIP>
        </info:service-uris>
        <!--
          MAXIMUM USER COUNT
        -->
        <maximum-user-count>
         <entry role = "administrator">2</entry>
         <entry role = "moderator">5</entry>
         <entry role = "participant">150</entry>
        </maximum-user-count>



Novo, et al.             Expires January 11, April 13, 2007                [Page 44] 50]

Internet-Draft          Common Conference Schema               July            October 2006


        </maximum-user-count>
        <!--
          AVAILABLE MEDIA
        -->
        <info:available-media>
         <info:entry label="10234">
          <info:display-text>main audio</info:display-text>
          <info:type>audio</info:type>
          <info:status>sendrecv</info:status>
          <mixing-mode>automatic</mixing-mode>
          <mix level>3</mix level>
          <mix-level>3</mix-level>
          <codecs decision="automatic">
           <codec name="PCMU" policy="allowed"/>
          </codecs>
         </info:entry>
         <info:entry label="10235">
          <info:display-text>main video</info:display-text>
          <info:type>video</info:type>
          <mixing-mode>automatic</mixing-mode>
          <mix level>4</mix level>
          <mix-level>4</mix-level>
          <info:status>sendrecv</info:status>
          <sesspol:codecs decision="automatic">
           <sesspol:codec name="H.263" policy="allowed"/>
          </sesspol:codecs>
         </info:entry>
        </info:available-media>
       </info:conference-description>
      <!--
        HOST INFO
      -->
       <info:host-info>
        <info:display-text>Formula1</info:display-text>
        <info:web-page>http://www.example.com/users/formula-1/\\
   </info:web-page>
        <info:web-page>http://www.example.com/formula-1/<
        /info:web-page>
        <info:uris>
         <info:SIP>
          <info:uri>sip:alice@example.com</info:uri>
         </info:SIP>
         <info:SIP>
          <info:uri>sip:carol@example.com</info:uri>
         </info:SIP>
        </info:uris>
       </info:host-info>
      <!--
        CONFERENCE STATE
      -->
       <info:conference-state>
        <allow-conference-state>true \\
   </allow-conference-state>
        <allow-conference-state>true<



Novo, et al.             Expires January 11, April 13, 2007                [Page 45] 51]

Internet-Draft          Common Conference Schema               July            October 2006


        /allow-conference-state>
        <info:user-count>3</info:user-count>
        <info:active>true</info:active>
        <info:locked>false</info:locked>
       </info:conference-state>
      <!--
        SECURITY MECHANISM
      -->
       <security-mechanism>
        <entry-protocol name="SIP">
         <sesspol:methods default-policy="allowed">
          <sesspol:method name="MESSAGE" policy="disallowed"/>
         </sesspol:methods>
          <sesspol:option-tags default-policy="disallowed">
           <sesspol:option-tag name="100rel" policy="mandatory"/>
           <sesspol:option-tag name="preconditions" policy="allowed"/>
          </sesspol:option-tags>
          <sesspol:feature-tags default-policy="disallowed">
           <sesspol:feature-tag name="video" policy="allowed"/>
          </sesspol:feature-tags>
          <sesspol:bodies default-policy="allowed" \\
   default-encryption="allowed">
           <sesspol:body-disposition name="session" policy="allowed" \\
   encryption="disallowed" default-policy="disallowed">
            <sesspol:body-format name="application/sdp" \\
   policy="allowed"/>
          </sesspol:body-disposition>
          </sesspol:bodies>
        </entry-protocol>
      </security-mechanism>
      <!--
        FLOOR INFORMATION
      -->
      <floor-information>
      <allow-floor-events>true</allow-floor-events>
      <floor-request-handling>1 </floor-request-handling>
      <conference-floor-policy>
       <floor moderator-controlled="true" label="10234">
        <media-types>audio</media-types>
        <algorithm>Moderator-controlled</algorithm>
        <max-floor-users>1</max-floor-users>
        <moderator-uri>sip:alice@example.com \\
   </moderator-uri>
        <moderator-uri>sip:alice@example.com<
       /moderator-uri>
       </floor>
       <floor moderator-controlled="true" label="10235">
        <media-types>video</media-types>
        <algorithm>Moderator-controlled</algorithm>
        <max-floor-users>1</max-floor-users>
        <moderator-uri>sip:carol@example.com \\



Novo, et al.            Expires January 11, 2007               [Page 46]

Internet-Draft          Common Conference Schema               July 2006


   </moderator-uri>
        <moderator-uri>sip:carol@example.com<
        /moderator-uri>
       </floor>
      </conference-floor-policy>
     </floor-information>
      <!--
        USERS
      -->
       <users>
        <join-handling>allow</join-handling>
        <!--
         ALLOWED USERS LIST
        -->
        <allowed-users-list>
         <target uri="sip:bob@example.com" method="dial-out"/>
         <target uri="sip:alice@example.com" method="dial-out"/>
         <target uri="sip:carol@example.com" method="dial-out"/>
         <target uri="sip:john@example.com" method="refer"/>
        </allowed-users-list>
        <!--
          PRIVILEGES CONTROL LIST
        -->
        <privileges-control-list>
         <data-access-rights>
          <conference-description read-only= "observer"/>
          <security-level read-only= "administrator"/>
          <allow-sidebars read-only= "creator" \\
   read-write= "creator"/>
          <conference-time read-only= "administrator"/>
          <maximum-user-count read-write= "creator"/>
          <codecs read-only= "creator" read-write= "creator"/>
          <host-info read-write= "creator"/>
          <conference-state read-write= "creator"/>
          <security-mechanism read-only= "creator"/>
          <floor-information read-only= "administrator"/>
          <allowed-users-list read-only= "administrator"/>
          <privileges-control-list read-only= "creator"/>
          <conditions read-only= "creator"/>
          <validity read-only= "creator"/>
          <allow-conference-state read-only= "observer"/>
          <sidebars-by-ref read-only= "observer"\\
   read-write= "creator"/>
          <sidebars-by-val read-only= "observer"\\
   read-write= "creator"/>
         </data-access-rights>
         <conference-rules>
          <entry id="1">
           <conditions>
            <compol:identity>



Novo, et al.             Expires January 11, April 13, 2007                [Page 47] 52]

Internet-Draft          Common Conference Schema               July            October 2006


           <conditions>
            <compol:identity>
             <compol:domain>example.com</compol:domain>
            </compol:identity>
            <compol:validity>
             <compol:from>20061017T143000Z</compol:from>
             <compol:to>20061017T163000Z</compol:to>
            </compol:validity>
           </conditions>
           <compol:actions>
            <compol:allow-conference-state>true\\
   </compol:allow-conference-state>
            <compol:allow-conference-state>true<
            /compol:allow-conference-state>
           </compol:actions>
          </entry>
          <entry id="2">
           <conditions>
            <compol:identity>
             <compol:uri>bob@example.com</compol:uri>
            </compol:identity>
           </conditions>
           <compol:actions>
            <join-handling>block</join-handling>
           </compol:actions>
          </entry>
         </conference-rules>
        </privileges-control-list>
        <!--
          USER
        -->
        <info:user entity="sip:bob@example.com">
         <info:display-text>Bob Hoskins</display-text>
         <info:associated-aors>
          <info:entry>
           <info:uri>mailto:bob@example.com</info:uri>
           <info:display-text>email</info:display-text>
          </info:entry>
         </info:associated-aors>
         <provide-anonymity>false</provide-anonymity>
         <info:roles>
          <info:entry>participant</info:entry>
         </info:roles>
         <info:languages>en</info:languages>
         <sphere value="work"/>
         <allow-refer-users-dynamically>false\\
   </allow-refer-users-dynamically>
         <allow-invite-users-dynamically>false\\
   </allow-invite-users-dynamically>
         <allow-remove-users-dynamically>false\\
   </allow-remove-users-dynamically>
         <floors>
         <allow-refer-users-dynamically>false<
         /allow-refer-users-dynamically>
         <allow-invite-users-dynamically>false<
         /allow-invite-users-dynamically>
         <allow-remove-users-dynamically>false<



Novo, et al.             Expires January 11, April 13, 2007                [Page 48] 53]

Internet-Draft          Common Conference Schema               July            October 2006


          <entry id="1">
           <show-floor-holder>false</show-floor-holder>
           <show-floor-requests>false \\
   </show-floor-requests>
          </entry>
          </floors>


         /allow-remove-users-dynamically>
         <!--
          ENDPOINTS
         -->
         <info:endpoint entity="sip:bob@example.com">
          <info:display-text>Bob's Laptop</info:display-text>
          <info:referred>
           <info:when>20061017T140000Z</info:when>
           <info:reason>expert required</info:reason>
           <info:by>sip:alice@example.com</info:by>
          </info:referred>
          <info:status>connected</info:status>
          <info:joining-method>dialed-out</info:joining-method>
          <info:joining-info>
           <info:when>20061017T140000Z</info:when>
           <info:reason>invitation</info:reason>
           <info:by>sip:alice@example.com</info:by>
          </info:joining-info>
          <!--
           MEDIA
          -->
          <info:media id="1">
           <info:label>10235</info:label>
           <info:src-id>432424</info:src-id>
          </info:media>
          <!--
            CALL INFO
          -->
          <info:call-info>
           <info:sip>
            <info:display-text>full info</info:display-text>
            <info:call-id>hsjh8980vhsb78</info:call-id>
            <info:from-tag>vav738dvbs</info:from-tag>
            <info:to-tag>8954jgjg8432</info:to-tag>
           </info:sip>
          </info:call-info>
         </info:endpoint>
        </info:user>
        <!--
          USER
        -->
        <info:user entity="sip:alice@example.com">
         <info:display-text>Alice Kay</info:display-text>
         <info:associated-aors>
          <info:entry>
           <info:uri>mailto:alice@example.com</info:uri>
           <info:display-text>email</info:display-text>
          </info:entry>



Novo, et al.             Expires January 11, April 13, 2007                [Page 49] 54]

Internet-Draft          Common Conference Schema               July            October 2006


         <info:associated-aors>
          <info:entry>
           <info:uri>mailto:alice@example.com</info:uri>
           <info:display-text>email</info:display-text>
          </info:entry>


         </info:associated-aors>
         <provide-anonymity>false</provide-anonymity>
         <info:roles>
          <info:entry>moderator</info:entry>
         </info:roles>
         <info:languages>en</info:languages>
         <sphere value="work"/>
         <allow-refer-users-dynamically>true\\
   </allow-refer-users-dynamically>
         <allow-invite-users-dynamically>true\\
   </allow-invite-users-dynamically>
         <allow-remove-users-dynamically>true\\
   </allow-remove-users-dynamically>
         <allow-refer-users-dynamically>true<
         /allow-refer-users-dynamically>
         <allow-invite-users-dynamically>true<
         /allow-invite-users-dynamically>
         <allow-remove-users-dynamically>true<
         /allow-remove-users-dynamically>
         <!--
          ENDPOINTS
         -->
         <info:endpoint entity="sip:alice@example.com">
          <info:display-text>Alice's Desktop</info:display-text>
          <info:status>connected</info:status>
          <info:joining-method>dialed-in</info:joining-method>
          <info:joining-info>
           <info:when>20061017T133508Z</info:when>
           <info:reason>invitation</info:reason>
           <info:by>sip:conference@example.com</info:by>
          </info:joining-info>
          <!--
           MEDIA
          -->
          <info:media id="1">
           <info:label>10235</info:label>
           <info:src-id>432424</info:src-id>
           <info:status>sendrecv</info:status>
          </info:media>
          <info:media id="2">
           <info:label>10234</info:label>
           <info:src-id>532535</info:src-id>
           <info:status>sendrecv</info:status>
          </info:media>
          <!--
            CALL INFO
          -->
          <info:call-info>
           <info:sip>
            <info:display-text>full info</info:display-text>
            <info:call-id>truy45469123478</info:call-id>
            <info:from-tag>asd456cbgt</info:from-tag>
            <info:to-tag>3456jgjg1234</info:to-tag>
           </info:sip>



Novo, et al.             Expires January 11, April 13, 2007                [Page 50] 55]

Internet-Draft          Common Conference Schema               July            October 2006


            <info:display-text>full info</info:display-text>
            <info:call-id>truy45469123478</info:call-id>
            <info:from-tag>asd456cbgt</info:from-tag>
            <info:to-tag>3456jgjg1234</info:to-tag>
           </info:sip>


          </info:call-info>
         </info:endpoint>
        </info:user>
        <!--
          USER
        -->
        <info:user entity="sip:carol@example.com">
         <info:display-text>Carol More</info:display-text>
         <info:associated-aors>
          <info:entry>
           <info:uri>mailto:carol@example.com</info:uri>
           <info:display-text>email</info:display-text>
          </info:entry>
         </info:associated-aors>
         <provide-anonymity>false</provide-anonymity>
         <info:roles>
          </info:entry>administrator</info:entry>
         </info:roles>
         <info:languages>en</info:languages>
         <sphere value="work"/>
         <allow-refer-users-dynamically>true\\
   </allow-refer-users-dynamically>
         <allow-invite-users-dynamically>true\\
   </allow-invite-users-dynamically>
         <allow-remove-users-dynamically>true\\
   </allow-remove-users-dynamically>
         <allow-refer-users-dynamically>true<
         /allow-refer-users-dynamically>
         <allow-invite-users-dynamically>true<
         /allow-invite-users-dynamically>
         <allow-remove-users-dynamically>true<
         /allow-remove-users-dynamically>
         <!--
          ENDPOINTS
         -->
         <info:endpoint entity="sip:carol@example.com">
          <info:display-text>Carol's Computer</info:display-text>
          <info:status>connected</info:status>
          <info:joining-method>dialed-in</info:joining-method>
          <info:joining-info>
           <info:when>20061017T133005Z</info:when>
           <info:reason>invitation</info:reason>
           <info:by>sip:conference@example.com</info:by>
          </info:joining-info>
          <!--
           MEDIA
          -->
          <info:media id="1">
           <info:label>10235</info:label>
           <info:src-id>432424</info:src-id>
           <info:status>sendrecv</info:status>
          </info:media>
          <info:media id="2">
           <info:label>10234</info:label>



Novo, et al.             Expires January 11, April 13, 2007                [Page 51] 56]

Internet-Draft          Common Conference Schema               July            October 2006


           <info:src-id>432424</info:src-id>
           <info:status>sendrecv</info:status>
          </info:media>
          <info:media id="2">
           <info:label>10234</info:label>


           <info:src-id>532535</info:src-id>
           <info:status>sendrecv</info:status>
          </info:media>
          <!--
            CALL INFO
          -->
          <info:call-info>
           <info:sip>
            <info:display-text>full info</info:display-text>
            <info:call-id>wevb12562321894</info:call-id>
            <info:from-tag>asw456wedf</info:from-tag>
            <info:to-tag>2365dfrt3497</info:to-tag>
           </info:sip>
          </info:call-info>
         </info:endpoint>
        </info:user>
       </users>
       <!--
         SIDEBARS BY REFERENCE
       -->
       <info:sidebars-by-ref>
        <info:entry>
         <info:uri>sips:conference@example.com;grid=40</info:uri>
         <info:display-text>private with Bob</info:display-text>
        </info:entry>
       </info:sidebars-by-ref>
       <!--
         SIDEBARS BY VALUE
       -->
       <info:sidebars-by-val>
        <info:entry entity="sips:conference@example.com;grid=40">
         <info:users>
          <info:user entity="sip:bob@example.com"/>
          <info:user entity="sip:carol@example.com"/>
         </info:users>
        </info:entry>
       </info:sidebars-by-val>
      </info:conference-info>



   Note that due to RFC formatting conventions, this documents splits
   lines whose content would exceed 72 characters.  Two backslash



Novo, et al.            Expires January 11, 2007               [Page 52]

Internet-Draft          Common Conference Schema               July 2006
   characters mark where the lines folding has taken place.  These
   backslash would not appear in the actual XML data model.






Novo, et al.             Expires April 13, 2007                [Page 57]

Internet-Draft          Common Conference Schema            October 2006


7.  Security Considerations

   A malicious user can manipulate parts of the Conference Information
   Data Model privileges document giving themselves and others
   privileges to manipulate the data model.  It is very important that
   only authorized clients are able to manipulate the Conference
   Information Data Model document.  Any conference control protocol
   MUST provide authentication, confidentiality and integrity.


8.  IANA Considerations


9.  Acknowledgements

   This document is really a distillation of many ideas discussed over a
   long period of time.  These ideas were contributed by many different
   drafts in the XCON working group and the SIPPING working group.  I
   would like to thanks Orit Levin, Adam Roach, Mary Barnes, Chris
   Boulton, Umesh Chandra, Orit Levin, and Jari Urpilainen Urpilainen, and Srivatsa
   Srinivasan for their comments.  Also, I would like to thanks Hisham
   Khartabil, Petri Koskelainen, and Aki Niemi to let us use the policy
   information of their cpcp drafts in this document.


10.  References

10.1.  Normative References

   [1]  Barnes, M. and C. Boulton, M., "A Framework and Data Model for Centralized
        Conferencing", draft-barnes-xcon-framework-02 draft-ietf-xcon-framework-05 (work in progress), February 2005.
        September 2006.

   [2]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
        Initiation Protocol (SIP) Event Package for Conference State",
        draft-ietf-sipping-conference-package-12 (work in progress),
        July 2005.
        RFC 4575, August 2006.

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

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



Novo, et al.            Expires January 11, 2007               [Page 53]

Internet-Draft          Common Conference Schema               July 2006


        May 2005. Protocol (SIP)", RFC 4353, February 2006.

   [5]  Sperberg-McQueen, C.,  Paoli, J., Maler, E., Sperberg-McQueen, C., and T. Bray,
        "Extensible Markup Language (XML) 1.0 (Second Edition)", World
        Wide Web Consortium FirstEdition http://www.w3.org/TR/2000/REC-xml-20001006, REC-xml-20001006, October 2000,
        <http://www.w3.org/TR/2000/REC-xml-20001006>.




Novo, et al.             Expires April 13, 2007                [Page 58]

Internet-Draft          Common Conference Schema            October 2000. 2006


   [6]  Dawson, F. and Stenerson, D., "Internet Calendaring and
        Scheduling Core Object Specification (iCalendar)", RFC 2445,
        November 1998.

10.2.  Informative References

   [7]  Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
         draft-ietf-xcon-bfcp-06 (work in progress), December 2005.

   [8]   Levin, O., "Centralized Conference Control Protocol",
         draft-levin-xcon-cccp-04
        draft-ietf-xcon-bfcp-06 (work in progress), January 2006.

   [9] December 2005.

   [8]  Schulzrinne, H., "Common Policy: An XML A Document Format for
        Expressing Privacy Preferences",
         draft-ietf-geopriv-common-policy-10
        draft-ietf-geopriv-common-policy-11 (work in progress),
         May
        August 2006.

   [10]

   [9]  Camarillo, G., "Session Description Protocol (SDP) Format for
        Binary Floor Control Protocol  (BFCP) Streams",
        draft-ietf-mmusic-sdp-bfcp-03 (work in progress), December 2005.






















Novo, et al.            Expires January 11, 2007               [Page 54]

Internet-Draft          Common Conference Schema               July 2006


Authors' Addresses

   Oscar Novo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Oscar.Novo@ericsson.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   David P. Morgan
   Fidelity Investments
   82 Devonshire St, MZ V8C
   Boston, MA  02109-3614
   USA

   Email: Dave.Morgan@fmr.com





Novo, et al.             Expires April 13, 2007                [Page 59]

Internet-Draft          Common Conference Schema            October 2006


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   Email: roni.even@polycom.co.il












































Novo, et al.             Expires January 11, April 13, 2007                [Page 55] 60]

Internet-Draft          Common Conference Schema               July            October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

   This document and the information contained herein 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 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.


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made 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 implementers or users of this
   specification can be obtained from the IETF 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 that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein 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 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 (2006).  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. IETF
   Administrative Support Activity (IASA).





Novo, et al.             Expires January 11, April 13, 2007                [Page 56] 61]


----