view Side-By-Side changes

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


A Common
                                                           March 3, 2007


 Conference Information Data Model for Centralized Conferencing (XCON)
                draft-ietf-xcon-common-data-model-03.txt
                draft-ietf-xcon-common-data-model-04.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 April 13, September 4, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   This document collects, organizes, and describes the defines an Extensible Markup Language (XML)-based
   conference
   variables that have been introduced in various protocol drafts of the
   XCON and SIPPING working groups.  The goal of this document is to information data model for centralized conferencing
   (XCON).  A conference object, which can be manipulated using a
   conference control protocol, at a conference server represents a



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


   allow the conference control protocols to use a unified common                 March 2007


   particular instantiation of this data model.  The conference
   information data model for XCON.  This defined in this document formally
   defines is an Extensible Markup Language (XML) Schema that represents extension of
   (and thus, compatible with) the common conference information model specified in a conferencing server.  The
   information is modeled as a series of elements, each of which
   contains a set of children and attributes. the Session
   Initiation Protocol (SIP) Event Package for Conference State.















































Novo, et al.            Expires September 4, 2007               [Page 2]

Internet-Draft              Data Model Schema                 March 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  6
   3.  Common Conference Data  Overview . . . . . . . . . . . . . . . . . . . .  4
     3.1.  General . . . . . . .  6
     3.1.  Data Model Structure . . . . . . . . . . . . . . . . . . .  4  6
     3.2.  Common  Conference Policies  . . . . . . . . . . . . . . . .  9
     3.3.  <conference-description> . . . .  7
       3.2.1.  Role Definitions . . . . . . . . . . . . . 10
       3.3.1.  <conference-time> . . . . . .  8
         3.2.1.1.  Role in a Floor  . . . . . . . . . . . . 11
       3.3.2.  <conf-uris> . . . . .  8
         3.2.1.2.  Changing Roles . . . . . . . . . . . . . . . . 13
       3.3.3.  <service-uris> . .  9
   4.  Data Model Definition  . . . . . . . . . . . . . . . . . . 13
       3.3.4.  <maximum-user-count> . .  9
     4.1.  <conference-description> . . . . . . . . . . . . . . . 13
       3.3.5.  <maximum-streams> . . 13
       4.1.1.  <conference-time>  . . . . . . . . . . . . . . . . 13
       3.3.6.  <available-media> . . 14
       4.1.2.  <conf-uris>  . . . . . . . . . . . . . . . . 13
       3.3.7.  <controls> . . . . . 15
       4.1.3.  <service-uris> . . . . . . . . . . . . . . . . . 14
         3.3.7.1.  mute . . . 16
       4.1.4.  <maximum-user-count> . . . . . . . . . . . . . . . . . 16
       4.1.5.  <available-media>  . . . 14
         3.3.7.2.  pause-video . . . . . . . . . . . . . . . 16
         4.1.5.1.  <controls> . . . . 14
         3.3.7.3.  gain . . . . . . . . . . . . . . . . 17
           4.1.5.1.1.  mute . . . . . . . 15
     3.4.  <host-info> . . . . . . . . . . . . . . 17
           4.1.5.1.2.  pause-video  . . . . . . . . . 15
     3.5.  <conference-state> . . . . . . . . 17
           4.1.5.1.3.  gain . . . . . . . . . . . . 15
     3.6.  <floor-information> . . . . . . . . . 18
           4.1.5.1.4.  video-layout . . . . . . . . . . 15
     3.7.  <users> . . . . . . . 18
     4.2.  <host-info>  . . . . . . . . . . . . . . . . . . 16
       3.7.1.  <allowed-users-list> . . . . . 19
     4.3.  <conference-state> . . . . . . . . . . . . 17
       3.7.2.  <privileges-control-list> . . . . . . . . 19
     4.4.  <floor-information>  . . . . . . 18
         3.7.2.1.  <conference-rules> . . . . . . . . . . . . . 19
     4.5.  <users>  . . . 18
           3.7.2.1.1.  <condition> . . . . . . . . . . . . . . . . . 18
           3.7.2.1.2.  <pseudonymous> . . . . . 21
       4.5.1.  <allowed-users-list> . . . . . . . . . . . 19
           3.7.2.1.3.  <has-been-referred> . . . . . . 22
       4.5.2.  <user> . . . . . . . 19
           3.7.2.1.4.  <has-been-invited> . . . . . . . . . . . . . . 19
           3.7.2.1.5.  <has-been-in-conference> . . . 22
         4.5.2.1.  <from-mixer>, <to-mixer> . . . . . . . . 19
           3.7.2.1.6.  <is-in-conference> . . . . . 23
           4.5.2.1.1.  <floor>  . . . . . . . . . 19
           3.7.2.1.7.  <administrator> . . . . . . . . . . 23
       4.5.3.  <sidebars-by-ref>  . . . . . 19
           3.7.2.1.8.  <is-on-allowed-users-list-dial-out> . . . . . 20
           3.7.2.1.9.  <is-on-allowed-users-list-refer> . . . . . . . 20
           3.7.2.1.10. <participant-passcode> . 24
       4.5.4.  <sidebars-by-val>  . . . . . . . . . . . 20
           3.7.2.1.11. <administrators-passcode> . . . . . . . 24
   5.  RELAX NG Schema  . . . 20
         3.7.2.2.  <actions>  . . . . . . . . . . . . . . . . . . . . 21
     3.8.  <user> . . . . . . . . . . . . . . . . . . . . 24
   6.  XML Schema Extensibility . . . . . . 22
       3.8.1.  from-mixer, to-mixer . . . . . . . . . . . . . 33
   7.  XML Example  . . . . 23
         3.8.1.1.  <floor> . . . . . . . . . . . . . . . . . . . . . 23



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


     3.9.  <sidebars-by-ref> 33
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 42
   9.  IANA Considerations  . 24
     3.10. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 24
   4.  RELAX 42
     9.1.  Conference Relax NG schema  . . . . . . . . . . . . . . . . . . . . . . . 24
   5.  XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 48
   6.  XML example  . . . . . . Registration  . . . . . . . . . . . . . . . . . . . 49
   7.  Security Considerations  . . 42
     9.2.  Conference Namespace Registration  . . . . . . . . . . . . 43
   10. Acknowledgements . . . . . 58
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . 43
   11. References . . . 58
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
   10. 43
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
     11.2. Informative References . . . . . . . 58
     10.1. Normative References . . . . . . . . . . . . . . 43
   Appendix A.  Appendix A.  Non-Normative RELAX NG Schema in XML
                Syntax  . . . . . 58
     10.2. Informative References . . . . . . . . . . . . . . . . . . 59 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 69
   Intellectual Property and Copyright Statements . . . . . . . . . . 61 71




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


1.  Introduction

   This document defines an Extensible Markup Language (XML) Schema that
   represents

   Conference objects are a fundamental concept in Centralized
   conferencing, as described in the XCON Conferencing Framework [1].  A
   conference object in a conferencing server.  The
   information is modeled as contains data that represents a series of elements, conference during
   each of which
   contains children and attributes.

   The its various stages (e.g., reserved, started, running, ended,
   etc.).  Conference Object contains Objects are instantiations of the conference
   information data model defined in this document.  Consequently,
   conference objects follow the XML schema, which is used to
   represent format defined in this document.

   A conference object contains the core information that is utilized in any of a conference
   (capabilities,
   (i.e., capabilities, membership, roles, call control signalling, signaling,
   media,
   etc...) etc.) and specifies the set of rights, permissions who, 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 which way, can manipulate that
   information.

   Figure 1 shows logical functional elements of a conference server as
   defined by the XCON working group
   to date Conferencing Framework [1].  They are a
   Conference Control Server, a Floor Control Server, a number of Foci,
   and proposes to create a unified common Notification Service.  A conference
   information data model for XCON.

   This document has been constructed in compliance with control protocol provides
   the XCON
   Framework [1] interface between a conference and media control client, and the Session Initiation Protocol (SIP) Event Package
   for Conference State [2].  It also incorporates data elements
   proposed in several XCON WG
   conference control server.  A floor control protocol (e.g., BFCP [7])
   provides the interface between a floor control client and SIPPING WG drafts.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", the floor
   control server.  A call signaling protocol (e.g., SIP, H.323, PSTN,
   etc.) provides the interface between a call signaling client and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [3].

   This document uses a
   Focus.  A notification protocol (e.g., SIP-based event notifications
   [8]) provides the terminology defined in interface between the XCON Conferencing
   Framework [1] conferencing client 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
   Notification Service.  Within a conference, 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 control
   server, floor control server, and SHOULD be encoded using
   UTF-8.

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






















Novo, et al.            Expires April 13, September 4, 2007               [Page 4]

Internet-Draft          Common Conference              Data Model 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>, <floor-information>,
   <users>, <sidebars-by-ref>, <sidebars-by-val>, child elements.  A
   common conference document must at least include the <conference-
   description>, <host-info>, <conference-state>, 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>                 March 2007


      ...............................................................
      . Conferencing Server                                         .
      .       +---------------------------------------------------+ .
      .       |     |--<subject>       C o n f e r e n c e   o b j e c t           |     |--<free-text> .
      .     +-+--------------------------------------------------+| .
      .     |     |--<keywords>       C o n f e r e n c e   o b j e c t            || .
      .   +-+---------------------------------------------------+|| .
      .   |     |--<web-page>       C o n f e r e n c e   o b j e c t             ||| .
      .   |     |--<security-level> +--------------------------------------------------+||| .
      .   |     |--<allow-sidebars> |     |--<conference-stage> Conference Information Data Model                |||| .
      .   |     |--<conference-time> | +----------------------------------------------+ |||| .
      .   |      |--<entry> | | Conference description  (times, duration)    |    |--<base> |||| .
      .   | | +----------------------------------------------+ |||| .
      .   |    |--<mixing-start-offset> | +----------------------------------------------+ |||| .
      .   | |    |--<mixing-end-offset> | Host information                             | |||| .
      .   |    |--<can-join-after-offset> | +----------------------------------------------+ |||| .
      .   | |    |--<must-join-before-offset> +----------------------------------------------+ |||| .
      .   | | |    |--<request-user> Conference state                             | |||| .
      .   | |    |--<notify-end-of-conference> +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   |    |--<allowed-extend-mixing-end-offset> | |           ... Floor information                            |     |--<conf-uris> |||| .
      .   | |      |--<SIP>



Novo, et al.             Expires April 13, 2007                 [Page 5]

Internet-Draft          Common Conference Schema            October 2006 +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   |    |--<uri> | | Membership (users, roles, capacity)          |    |--<display-text> |||| .
      .   | | +----------------------------------------------+ |||| .
      .   |    |--<purpose> | +----------------------------------------------+ |||| .
      .   |      |--<H323> | | Sidebars, Etc.                               |    |--<H.323-alias> |||| .
      .   | | +----------------------------------------------+ |||| .
      .   |    |--<H.323-URI> | +----------------------------------------------+ |||| .
      .   |      |--<PSTN/ISDN> | | Etc.                                         |    |--<phone number> |||| .
      .   | | +----------------------------------------------+ |||+ .
      .   |    |--<PIN-code> +--------------------------------------------------+|+  .
      .   +----^------------------^-------------^--------|------+   .
      .        |                  |             |    |--<purpose>
        |     |      |    |--<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>
        |     |      |     |--<codecs>
        |     |      |     |    |--<entry>
        |        |          .
      . +------v-------+ +--------v-----+ +-----v-+ +----v-------+  .
      . | Conference   |    |--<entry> | Floor        | |       |    ... |            |  .
      . |     |--<controls> Control      | | Control      | |Foci   |    |--<mute> |Notification|  .
      . | Server       | | Server       |    |--<gain> |       | |Service     |  .
      . +-----^--------+ +---^----------+ +-^-----+ +------------+  .
      ........|..............|..............|..........|.............
              |Conference    |Binary Floor  |Call      |Notification
              |Control       |Control       |Signaling |Protocol
              |Protocol      |Protocol      |Protocol  |   ...
      ........v..............v..............v..........v.............
      .     C  o  n  f  e  r  e  n  c  i  n  g     C  l i  e  n  t  .
      ...............................................................

                 Figure 1: Conference Server Architecture



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


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



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


        |--!<users>
        |     |--<join-handling>
        |     |--<user-admission-policy>
        |     |--<allowed-users-list>
        |     |     |--<target>
        |     |     |-- ...
        |     |
        |     |--<privileges-control-list>
        |     |    |--<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>
        |     |    |--!<endpoint>
        |     |    |      |--<display-text>
        |     |    |      |--<referred>
        |     |    |      |--<status>
        |     |    |      |--<joining-method>
        |     |    |      |--<joining-info>
        |     |    |      |--<disconnection-method>
        |     |    |      |--<disconnection-info>
        |     |    |      |--!<media>
        |     |    |      |    |--<type>
        |     |    |      |    |--<display-text>



Novo, et al.             Expires April 13,                 March 2007                 [Page 8]

Internet-Draft          Common


   The Session Initiation Protocol (SIP) Event Package for Conference Schema            October 2006


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


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

3.2.  Common Conference Policies

   Conference policies collectively refers to RFC 4575 [2], already defines a set of rights,
   permissions data model for
   conferences.  However, that model is SIP specific and limitations pertaining lacks elements
   related to operations being performed
   on a certain conference object data model.




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


   The set some of rights describes the read/write access privileges for functionality defined by the
   conference object XCON conferencing
   framework [1] (e.g., floor control).  The data model as a whole.  Every element of defined in this
   document extends the one defined in RFC 4575 [2].  The result is a
   data model SHOULD has defined two attributes: the attribute 'read-only', that supports more call signaling protocols besides SIP
   and that covers all the attribute 'read-write'.  These attributes describes the read/
   write access privileges for accessing the Conference Object as a
   whole.  It is partially described functionality defined in [1].  When the XCON
   conferencing
   server receives a request for access privacy-sensitive data it needs
   to match it against the 'read-only' and the 'read-write' attributes.
   Each attribute of each individual element is evaluated framework [1].


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 a
   result it is determined if described in RFC 2119 [3].

   This document uses the user can access that element.  The
   attributes specify terminology defined in the minimum subscriber's role that can access or
   modify XCON Conferencing
   Framework [1], the element of SIP conferencing framework [4] and the conference.  Subscribers BFCP
   (Binary Floor Control Protocol) specification [7].  Readers of this
   document are supposed to be familiar with a lower role
   cannot access or modify the element.  If an attribute is not terminology used in
   those documents.


3.  Overview

   The data model defined in some element, the 'read-only' attribute MUST be interpreted as a
   "participant" and the 'read-write' attribute MUST be interpreted as
   an "administrator" by default.  It this document is possible to defined only one of the attributes result of extending
   the element, the other attribute SHOULD data model defined in RFC 4575 [2] with new elements, which carry
   information such as non-SIP URIs or floor-control-related parameters.
   This data model can be
   interpreted used by default.  This draft does not define the set conference servers providing different
   types of
   possible conferencing roles.

   However, it basic conferences.  It is expected that this data model can also
   be further extended with new elements in the case that conflicts can occur given a
   hierarchy of elements.  In that case, future in order to
   implement advanced features.

3.1.  Data Model Structure

   The information in this data model is structured in the lower-level element
   privileges predominate over following
   manner.  All the upper-level privileges element.

   This document defines information related to a more specific right mechanism conference is contained in Section
   3.7.2, beyond the 'read-only' and 'read-write' attributes.
   a <conference-info> element.  The permissions and limits are specified as an integral part of the
   data model, with elements containing <conference-info> element contains
   the allowed ranges for other
   elements (e.g., maximum number of participants) and lists of clients
   allowed to perform certain operations on a conference object.

3.3.  <conference-description> following child elements:
   o  The <conference-description> element describes the conference in its
   entirely. as a
      whole.  It SHOULD have an extra attribute 'xml:lang' to specify has, for instance, information about the language used URI of the
      conference, maximum users allowed in the contents of 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 conference, media
      available in the conference, or the time the conference content.  These
   elements are defined in [2]. will
      start.
   o  The child element <web-page> is an optional <host-info> element that points to a
   URI with additional contains information about the conference.  The child entity
      hosting the conference (e.g., its URI).




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


   elements <security-level> and <allow-sidebars> describe                 March 2007


   o  The <conference-state> element informs the
   capabilities of subscribers about the conference.
      changes in the overall conference information.
   o  The <conference-stage> is a mandatory <floor-information> element that give contains information about the stage
      status of the different floors in the conference.  This
   o  The <users> element can have 4 values: reserved, started,
   running, and ended.  At describes the reserved stage membership information as a
      whole.  The <users> element contains a set of <user> child
      elements, each describing a single participant in the conference exists only conference.
   o  If a participant in the main conference control server.  There is no running focus and
   there are no subscribers or notifications.  The information joins a sidebar, a new
      element is
   accessible only via created in the conference control protocol.  At referenced from the started
   stage, there are no users yet
      <sidebars-by-ref> element or under one of the <sidebars-by-val>
      elements.

3.2.  Conference Policies

   Conference policies specify who, and in which way, information in a
   conference object can be manipulate.  This data model has no strict
   separation between conference membership and media information, and
   its related policies.  Policy-related elements and attributes appear
   with the conference, still it element they apply to.

   [Editor's Note: The Policies section is possible
   to subscribe still under discussion.  For
   more details refer to the conference state. XCON mailing list. ]

   The running stage starts when set of rights describes the first user joins read/write access privileges for the conference.  In
   conference object data model as a whole.  Every element of the ended stage, there are
   no users connected to data
   model SHOULD define two attributes: the conference, attribute 'read-only', and
   the conference information is
   only in attribute 'read-write'.  These attributes describes the conference server for recurring conference or read/
   write access privileges for CDR.
   At this stage a user can get information only from accessing the conference
   control protocol.  For instance, The Session Initiation Protocol
   (SIP) Event Package for Conference State [2] Object as a
   whole.  This is only applicable partially described in [1].  When the start and running stage.

   The <conference-time> child element has information related conferencing
   server receives a request to
   conference time and duration of access privacy-sensitive data it needs
   to match it against the conference.  Other elements from
   different namespaces MAY be present for 'read-only' and the purposes 'read-write' attributes.
   Each attribute of
   extensibility.  The <conf-uris> each individual element is evaluated and <service-uris> are used to
   describe as a
   result it is determined if the conference-related identifiers. requestor can access that element.
   The <maximum-user-
   count> child element indicates attributes specify the number of users minimum requestor's role that can be
   invited to access
   or modify the conference.  The <maximum-streams> child element
   indicates the number of streams that can be for every media type.
   The <available-media> child element is used to describe the media
   characteristics of the conference.

   The following sections describe the remaining elements  Requestors with a role with
   lower privileges as defined in more
   detail.  Other child elements can be used to extend <conference-
   description> Section 3.2.1 cannot access or modify
   the element.

   If an attribute is not defined in some element, the future.

3.3.1.  <conference-time>

   The <conference-time> element contains 'read-only'
   attribute MUST be interpreted as a "participant" role and the information related 'read-
   write' attribute MUST be interpreted as an "administrator" role by
   default.  It is possible to
   conference time and duration of a conference.  The <conference-time>
   element contains defined only one or more <entry> elements each defining the time
   information of a single conference occurrence.

   Every <entry> element contains a <mixing-start-offset> child element
   that specifies when conference media mixing starts before the
   conference starts, <mixing-end-offset> child element that specifies attributes of the time a conference media mixing stops after
   element, the conference stops. other attribute SHOULD be interpreted by default.  The <mixing-end-offset> child element expresses
   next section defines conferencing roles that are used to represent
   participants within a Conference Object.  Additional roles may be
   defined in the offset future, as signed
   integers representing seconds before/after DTEND field.  The <mixing-
   start-offset> child element expresses the offset necessary, with their corresponding schema
   extensions, as signed integers appropriate.




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


   representing seconds before/after DTSTART field.  If the <mixing-
   start-offset> element is not present,                 March 2007


   However, it indicates that the
   conference media mixing starts immediately.  If can also be the <mixing-end-
   offset> element is not present, it indicates case that conflicts can occur given a
   hierarchy of elements.  In that case, the conference
   occurrence is not bounded. <mixing-start-offset> lower-level element
   privileges predominate over the upper-level privileges element.

   The policies and <mixing-end-
   offset> rights are an integral part of the data model, with
   elements both have containing the mandatory 'require-participant'
   attribute.  This attribute has one allowed ranges for other elements (e.g.,
   maximum number of 4 values: 'none',
   'administrator', 'moderator', participants) and 'participant'.  For mixing start
   offset, this attribute allows a privileged user lists of end-points allowed to define when media
   mixing starts based
   perform certain operations on a conference object.

3.2.1.  Role Definitions

   This section defines five logical roles for a Conference System to
   represent participants within a Conference Object.  In hierarchical
   order they are: "administrator", "creator", "moderator",
   "participant", and "observer".  A set of semantics associated with
   each role is out of the latter scope of this document.  A Conference System
   MAY choose not to support a particular role.  As well, additional
   roles may be defined in the mixing start time, and future, as necessary, with their
   corresponding schema extensions.

   These five roles have an intrinsic hierarchical order within a
   specific conference.  By hierarchical order, it is implied that the
   time
   "administrator" by default SHOULD have higher privileges than a
   "creator", which by default SHOULD have higher privileges than a
   "moderator" and so on.  For example, the first participant, administrator, or moderator arrives.  If "administrator" SHOULD have
   the value is set ability to 'none', mixing starts according make changes to all conference variables during
   instantiation and full lifecycle of the mixing
   start time.  For mixing end offset, this attribute allows a
   privileged user to define when media mixing ends based on Conference Object.  The
   "creator" is the earlier 'owner' of the mixing end offset, conference and the time the last participant, or
   moderator leaves.  If the value is set has various privileges
   which SHOULD allow them to 'none', mixing stops
   according modify the conference variables up to the mixing end offset.  If
   time the conference policy was
   modified so that last privileged is instantiated.  The "moderator" is a logical
   entity that will manage the conference.  The "participant" is a
   logical entity with generic privileges that will be attending a
   conference.  The "observer" is a logical entity which can only
   receive media streams from the conference.  All Conference Systems
   MUST have a role defined as "participant".

   Each user participating in a conference instance is an entity that
   can assume one or more roles.  Any entity can be allocated to an
   appropriate logical role.  A role can also be assumed in conjunction
   with the users identity within the Conference System as a result of
   an identity assertion transaction on the Conference System.  If no
   roles are defined for an entity, they SHOULD by default be a
   "participant" but local policy MAY define an alternative.

3.2.1.1.  Role in a Floor

   Floor control in centralized conferencing is described in the Binary
   Floor Control Protocol (BFCP) [7].  Floors can be specified in the



Novo, et al.            Expires September 4, 2007               [Page 8]

Internet-Draft              Data Model Schema                 March 2007


   Conference System or created dynamically.  Users can be added or
   deleted from a floor when the conference is active.

   A floor chair is a logical entity that manages a floor (grants,
   denies, or revokes a floor).  The floor chair is usually in an
   "administrator", "moderator", or "creator" role.  A floor participant
   is a logical entity that requests floors, and possibly information
   about them from a floor control server.  They are usually in a
   "participant" or even a "moderator" role [7].

   Users in a conference MAY assume different roles in different floors.
   They MAY also assume different roles in the same floor, as floor
   transactions are processed.

3.2.1.2.  Changing Roles

   Users can change roles during a conference.  This can be done in two
   ways: First, the user can join a new floor in a different role.
   Second, an "administrator" or "creator" can dynamically change that
   user's role.  This can be accomplished before the conference is
   instantiated, or during the conference, using an appropriate
   conference control protocol.  A logical entity whose role has been
   changed will typically have access to the media streams associated
   with that role.


4.  Data Model Definition

   A conference object 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 UTF-8.

   A conference object document begins with the root element tag
   <conference-info>, which is defined in [2].  The <conference-info>
   element has an 'entity' attribute that contains a conference object
   identifier (ID) that identifies the conference being described in the
   document.

   The <conference-info> element contains the <conference-description>,
   <host-info>, <conference-state>, <floor-information>, <users>,
   <sidebars-by-ref>, <sidebars-by-val> child elements.  All these
   elements, except <floor-information>, are defined in [2].  A
   conference document MUST at least include the <conference-
   description>, <host-info>, <conference-state>, and <users> child
   elements.

   The following non-normative diagram shows the structure of conference
   object documents.  The operator "!" preceding an element indicates



Novo, et al.            Expires September 4, 2007               [Page 9]

Internet-Draft              Data Model Schema                 March 2007


   that the element is mandatory in the data model.  The operator "*"
   following an element indicates that the element is introduced and
   defined in this document.  That is, elements without a "*" have
   already been defined in RFC 4575 [2].

   !<conference-info>
        |
        |--!<conference-description>
        |     |--<display-text>
        |     |--<subject>
        |     |--<free-text>*
        |     |--<keywords>
        |     |--<allow-sidebars>*
        |     |--<conference-time>*
        |     |      |--<entry>*
        |     |      |    |--<base>*
        |     |      |    |--<mixing-start-offset>*
        |     |      |    |--<mixing-end-offset>*
        |     |      |    |--<can-join-after-offset>*
        |     |      |    |--<must-join-before-offset>*
        |     |      |    |--<request-user>*
        |     |      |    |--<notify-end-of-conference>*
        |     |      |    |--<allowed-extend-mixing-end-offset>*
        |     |           ...
        |     |--<conf-uris>
        |     |      |--<entry>*
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |--<H323>*
        |     |      |    |--<H.323-alias>*
        |     |      |    |--<H.323-URI>*
        |     |      |--<PSTN-ISDN>*
        |     |      |    |--<phone number>*
        |     |      ...
        |     |--<service-uris>
        |     |      |--<entry>*
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |--<H323>*
        |     |      |    |--<H.323-alias>*
        |     |      |    |--<H.323-URI>*
        |     |      |--<PSTN-ISDN>*
        |     |      |    |--<phone number>*
        |     |      ...
        |     |--<maximum-user-count>
        |     |      ...



Novo, et al.            Expires September 4, 2007              [Page 10]

Internet-Draft              Data Model Schema                 March 2007


        |     |--!<available-media>
        |     |      |--!<entry>
        |     |      |     |--<type>
        |     |      |     |--<display-text>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<mix-level>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<entry>*
        |     |      |     |    |--<entry>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<mute>*
        |     |      |     |    |--<gain>*
        |     |      |     |   ...
        |     |      |--<entry>
        |     |      |     |--<type>
        |     |      |     |--<display-text>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<mix-level>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<entry>*
        |     |      |     |    |--<entry>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<pause-video>*
        |     |      |     |    |--<video-layout>*
        |     |      |     |   ...
        |     |      ...
        |
        |--<host-info>
        |     |--<display-text>
        |     |--<web-page>
        |     |--!<uris>
        |     |     |--!<entry>
        |     |     |    |--!<uri>
        |     |     |    |--<display-text>
        |     |     |--<H323>*
        |     |     |    |--<H.323-alias>*
        |     |     |    |--<H.323-URI>*
        |     |     |--<PSTN-ISDN>*
        |     |     |    |--<phone number>*
        |           ...
        |--<conference-state>
        |     |--<allow-conference-event-subscription>*
        |     |--<user-count>
        |     |--!<active>



Novo, et al.            Expires September 4, 2007              [Page 11]

Internet-Draft              Data Model Schema                 March 2007


        |     |--<locked>
        |
        |--<floor-information>*
        |     |--<allow-floor-events>*
        |     |--<floor-request-handling>*
        |     |--<conference-floor-policy>*
        |     |     |--<floor>*
        |     |     |    |--<media-types>*
        |     |     |    |--<algorithm>*
        |     |     |    |--<max-floor-users>*
        |     |     |    |--<chair-id>*
        |     |     |    |--<chair-id>*
        |     |     |   ...
        |     |     ...
        |
        |--!<users>
        |     |--<join-handling>*
        |     |--<user-admission-policy>*
        |     |--<allowed-users-list>*
        |     |     |--<target>*
        |     |     |-- ...
        |     |
        |     |
        |     |--!<user>
        |     |    |--<display-text>
        |     |    |--<associated-aors>
        |     |    |--<provide-anonymity>*
        |     |    |--<roles>
        |     |    |    |
        |     |    |   ...
        |     |    |--<languages>
        |     |    |--<cascaded-focus>
        |     |    |--<allow-refer-users-dynamically>*
        |     |    |--<allow-invite-users-dynamically>*
        |     |    |--<allow-remove-users-dynamically>*
        |     |    |--!<endpoint>
        |     |    |      |--<display-text>
        |     |    |      |--<referred>
        |     |    |      |--<status>
        |     |    |      |--<joining-method>
        |     |    |      |--<joining-info>
        |     |    |      |--<disconnection-method>
        |     |    |      |--<disconnection-info>
        |     |    |      |--!<media>
        |     |    |      |    |--<type>
        |     |    |      |    |--<display-text>
        |     |    |      |    |--<label>
        |     |    |      |    |--<src-id>



Novo, et al.            Expires September 4, 2007              [Page 12]

Internet-Draft              Data Model Schema                 March 2007


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


   The following sections describe these elements in detail.  The full
   Relax NG schema is now a normal conference
   participant, and the conference requires a privileged user to
   continue; that conference MUST terminate.

   An administrator can indicate the time when users can join a
   conference by populating the <can-join-after-offset> element.
   Similarly, an administrator can define the time after provided Section 5.

4.1.  <conference-description>

   The <conference-description> element, which new users
   are not allowed to join the conference 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 <base> child element specifies the iCalendar object of the
   conference.  The iCalendar object components are defined in [6].

   The <entry> element also contains [2],
   describes the <request-user> child element. conference as a whole.  It is possible to define the time when users or resources on the
   allowed-users-list is requested SHOULD have an extra
   attribute 'xml:lang' to join specify the conference by using language used in the
   <request-users> element.  This contents of
   this element expresses the offset as signed
   integers representing seconds before/after DTSTART field.

   The <notify-end-of-conference> element defines defined in seconds when the
   system has to send a notification when the end Section 2.12 of the conference is
   near.  If the <notify-end-of-conference> element [5].  It is not present, it
   indicates that the system does not notify the users when the end comprised 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.
   <display-text>, <subject>, <free-text>, <keywords>, <allow-sidebars>,
   <conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>,



Novo, et al.            Expires April 13, September 4, 2007              [Page 12] 13]

Internet-Draft          Common Conference              Data Model 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 child elements: <SIP>, <H.323>,                 March 2007


   and <PSTN/ISDN>. <available-media>.

   The
   <SIP> element contains the <uri>, <display-text>, and <purpose>.
   <uri>, <display-text>, <subject>, <free-text> and <purpose> <keywords> elements
   are described defined 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 the conference if  They are used and a 'purpose' attribute that
   describes to the user which phone number to use. <PSTN/ISDN> element
   may include 1 or more <phone number> child elements and describe the call rate
   as well.

3.3.3.  <service-uris> conference's
   content.

   The <service-uris> child element <allow-sidebars> describes auxiliary services available for the
   conference.  It contains a sequence capabilities of child elements: <SIP>,
   <H.323>, <PSTN/ISDN>, and <BFCP>. <SIP> the
   conference.

   The <conference-time> child element contains <uri>,
   <display-text>, and <purpose>.  The purpose will be used information related to describe
   the service.  These elements are described in [2]. <H.323>,
   conference time and
   <PSTN/ISDN> child elements are described in <conf-uris> section. duration of the conference.  The
   <BFCP> has a sub-element <conference-ID> that <conf-uris> and
   <service-uris> are used by a floor
   control server to provide a client with a conference ID.

3.3.4.  <maximum-user-count> describe the conference-related
   identifiers.  The <maximum-user-count> contains child element indicates the overall
   number of users allowed that can be invited to join the conference.  It contains a sequence of <entry>  The
   <available-media> child
   elements.  An <entry> element MAY contain is used to describe the number media
   characteristics of users with a
   specific role allowed to join the conference.

3.3.5.  <maximum-streams>

   The <maximum-streams> following sections describe these elements in more detail.  Other
   child elements MAY be defined in the future to extend the
   <conference-description> element.

4.1.1.  <conference-time>

   The <conference-time> element contains the maximum number of streams that are
   permitted information related to be involved in
   conference time and duration of a conference.  It  The <conference-time>
   element contains one or more <entry> elements each defining the time
   information specifying a sequence of single conference occurrence.

   Every <entry> element contains a <mixing-start-offset> child elements.  An <entry> element MAY contain
   that specifies when conference media mixing starts before the number of
   streams of every specific type of stream, for instance, audio or
   video.  The minimum value permitted is "1" and
   conference starts, <mixing-end-offset> child element that specifies
   the maximum value
   permitted is "128".  This time a conference media mixing stops after the conference stops.
   The <mixing-end-offset> child element is optional.

3.3.6.  <available-media> expresses the offset as signed
   integers representing seconds before/after DTEND field.  The <available-media> has <mixing-
   start-offset> child element expresses the 'label' attribute that offset as signed integers
   representing seconds before/after DTSTART field.  If the <mixing-
   start-offset> element is not present, it indicates that the
   conference media
   stream identifier assigned by mixing starts immediately.  If the conferencing server.  This <mixing-end-
   offset> element
   contains a sequence of <entry> child is not present, it indicates that the conference
   occurrence is not bounded. <mixing-start-offset> and <mixing-end-
   offset> elements both have the mandatory 'require-participant'
   attribute.  This attribute has one of conference-medium-
   type.  Each <entry> element contains 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 <type>, <display-text>,
   <status>, <mixing-mode>, <mix-level>, <controls> latter of the mixing start time, and <codecs> child the
   time the first participant, administrator, or moderator arrives.  If
   the value is set to "none'", mixing starts according to the mixing
   start time.  For <mixing-end-offset>, this attribute allows a



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


   elements.  The attribute 'label' and the <type>, <display-text>, and
   <status> elements are described in [2].  The <codecs> element
   specifies                 March 2007


   privileged user to define when media mixing ends based on the allowed codecs in earlier
   of the conference.  It has an attribute
   'decision' that specifies if <mixing-end-offset>, and the focus decides time the common codec
   automatically last participant, or needs
   moderator leaves.  If the approvement of value is set to "none", mixing stops
   according to the moderator of <mixing-end-offset>.  If the conference (automatic, moderator-controlled).  The <codecs> element
   contains a <entry> elements.  A <entry> element can have the
   attribute 'name' and 'policy'.  The 'name' attribute identifies policy was
   modified so that last privileged user is now a
   codec, and the 'decision' attribute normal conference
   participant, and the policy attribute contains
   the policy for conference requires a privileged user to
   continue; that codec (allowed, or disallowed).

   The child elements <mixing-mode>, <mix-level> describe conference MUST terminate.

   An administrator can indicate the time when users can join a default
   policy
   conference by which populating the mixer will build <can-join-after-offset> element.
   Similarly, an administrator can define the outgoing stream from time after which new users
   are not allowed to join the
   incoming streams.  Notice that this policy conference anymore.  This is different that done by
   populating the
   policy describe for <must-join-before-offset> element expressing the floors for each media.
   offset as signed integers representing seconds before/after DTSTART
   field.

   The <mix-level> <base> child element describes specifies the number iCalendar object of participants in audio media streams
   or the number of sub-windows in video media streams (for instance, a
   value of 4
   conference.  The iCalendar object components are defined in the <mix-level> element for video stremas means 2x2
   layout). [6].

   The <mixing-mode> <entry> element also contains the <request-user> child element MUST contain one and only
   one of element.
   It is possible to define the "Moderator-controlled", "FCFS", and "Automatic" values
   indicating time when users or resources on the default algorithm
   <allowed-users-list> is requested to be use with every media stream.
   Next section explains join the <controls> child conference by using the
   <request-users> element.

3.3.7.  <controls>  This element expresses the offset as signed
   integers representing seconds before/after DTSTART field.

   The <controls> <notify-end-of-conference> element contains defines in seconds when the basic audio and video global
   controls for
   system has to send a conferencing.  It is expected that for most notification when the end of the
   basic conferencing, these controls are sufficient. conference is
   approaching.  If the conference
   server wants to support more advanced control, then it <notify-end-of-conference> element is recommended
   extension of not
   present, it indicates that the data model to be used.  In system does not notify the <controls> element users when
   the schema end of the conference is extensible, hence new control types can be added in a
   future.  Similarly, controls that apply approaching.  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 a especific users would
   appear under the <users>/<user>/<endpoint> element.  So, moderator
   controls that affect all media output would go under possibility to extend the <available-
   media> element.

3.3.7.1.  mute
   conference.  It has two values: "allowed", "denied".

4.1.2.  <conf-uris>

   The 'mute' control is <conf-uris> contains the identifiers to be used in conjunction with a audio stream order to
   cease transmission of associated media.
   access the conference by different signaling means.  It has contains a 'Boolean' value.
   If this control is not specify, the access
   sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>.  The
   <entry> element refers to the control SIP protocol.  It keeps the same name
   that is not
   available defined in [2] to maintain backwards compatibility with this
   RFC.  The <entry> element contains the client <uri>, <display-text>, and media SHOULD not be transported for the
   associated media stream.

3.3.7.2.  pause-video
   <purpose> which are described in [2].  The 'pause-video' control is currently defined
   <purpose> values to be used in conjunction with the <conf-uris> are:
   o  participation: Accessing a video stream
   to cease transmission of associated media.  It has a 'Boolena' value. URI with this <purpose> will bring the
      party into the conference




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


   If                 March 2007


   o  streaming: Accessing a URI with this control is not specify, the access to the control is not
   available to <purpose> will commence
      streaming the client and media SHOULD conference, but not be transported for the
   associated media stream.

3.3.7.3.  gain allow active participation
   The 'gain' control is used in conjunction with <H.323> element includes either a media output stream
   to indicate <H.323-alias> or a <H.323-URI>
   child elements.  The <PSTN-ISDN> has an attribute 'PIN code' with the amount of amplification
   PIN code of an audio stream.  It has the conference if used and a
   'Int' number value from -127 'purpose' attribute that
   describes to 127.  If this control is not specify, the access user which phone number to the control is not use.  The <PSTN-ISDN>
   element may include one or more <phone number> child elements.

4.1.3.  <service-uris>

   The <service-uris> describes auxiliary services available to for the client.

3.4.  <host-info>
   conference.  It contains a sequence of child elements: <entry>,
   <H.323>, <PSTN-ISDN>, and <BFCP>.  The <host-info> <entry> child element contains
   <uri>, <display-text>, and <purpose>.  The purpose will be used to
   describe the service.  The currently defined <purpose> values to be
   used with the <service-uris> are:
   o  web-page: Indicates the web page containing the additional
      information about the entity hosting conference
   o  recording: Indicates the link at which the recorded conference
      context can be retrieved
   o  event: Indicates the URI at which a subscription to the conference
      event package may be requested.  This would typically be the conference.  It contains
      conference URI of the <display-text>, <web-page> child
   elements. main conference
   Future extensions to this schema may define new values and register
   them with IANA.  These child elements are explained described 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
   <PSTN-ISDN> child elements of <uris> are described in the <conf-uris> section.

3.5.  <conference-state>

4.1.4.  <maximum-user-count>

   The <conference-state> element and <maximum-user-count> contains the <user-count>, <active>, overall number of users allowed
   to join the conference.  Note that this value is set by an
   administrator and
   <locked> can reflect any local policies such as network
   consumption, CPU processing power, and licensing rules.

4.1.5.  <available-media>

   The <available-media> has the 'label' attribute that is the media
   stream identifier assigned by the conferencing server.  This element
   contains a sequence of <entry> child elements of conference-medium-
   type.  Each <entry> element contains the <type>, <display-text>,
   <status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child
   elements.  The attribute 'label' and the <type>, <display-text>, and
   <status> elements are explained described in section 5.5 of [2].  The
   <allow-conference-state> <codecs> element represents a boolean action.  If set
   to TRUE,
   specifies the allowed codecs in the conference.  It has an attribute
   'decision' that specifies if the focus is instructed to allow decides the common codec
   automatically or needs the approval of the moderator of the subscription to
   conference state events, such as ("automatic", "moderator-controlled").  The <codecs>
   element contains <entry> elements.  A <entry> element can have the SIP Event Package



Novo, et al.            Expires September 4, 2007              [Page 16]

Internet-Draft              Data Model Schema                 March 2007


   attribute 'name' and 'policy'.  The 'name' attribute identifies a
   codec, and the 'decision' attribute contains the policy for Conference
   State [2].  If set to FALSE, that
   codec (allowed, or disallowed).

   The child elements <mixing-mode> and <mix-level> describe a default
   policy by which the mixer will build the subscription to conference state
   events would be rejected.  If outgoing stream from the
   incoming streams.  Notice that this element policy is undefined it has different than the
   policy describing the floors for each media.  The <mix-level> child
   element describes the number of participants in audio media streams
   or the number of sub-windows in video media streams (for instance, a
   value of TRUE, causing "4" in the subscription to conference state events to
   be accepted.

3.6.  <floor-information> <mix-level> element for video streams implies a
   2x2 layout).  The <floor-information> <mixing-mode> child element has MUST contain one and
   only one of the <allow-floor-events>, <floor-
   request-handling>, "Moderator-controlled", "FCFS", and "Automatic"
   values indicating the <conference-floor-policy> child elements.
   Other elements from different namespaces MAY default algorithm to be present for the
   purposes of extensibility.  This element has its own XML namespace. use with every media
   stream.  The absence of this namespace and its elements from an XML document
   indicates that next section explains the conference does not have a floor. <controls> child element.

4.1.5.1.  <controls>

   The <allow-floor-events> <controls> element represents a boolean action.  If set
   to TRUE, contains the focus basic audio and video global
   controls for a conference.  It is instructed to accept expected that for the subscription to floor
   control events. majority of
   the basic conferences, these controls are sufficient.  If set to FALSE, the focus is instructed
   conference server wants to reject
   the subscription.  If this element is undefined, support more advanced controls, then it has a value is
   recommended that an extension of
   FALSE, causing the subscription to floor control events to data model be
   rejected.




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


   The <floor-request-handling> element defines used.  In the actions used by
   <controls> element the
   conference focus to schema is extensible, hence new control floor requests.  This element defines types
   can be added in the
   action future.  Similarly, controls that the focus is to take when processing a particular request apply to a floor within a conference.  This element defines values of:
   o  block: This action instructs
   specific user would appear under the focus to deny <users>/<user>/<endpoint>
   element.  So moderator controls that affect all media output would go
   under the floor request.
      This action <available-media> element.

4.1.5.1.1.  mute

   The 'mute' control is the default action taken used in the absence conjunction with an audio stream to
   cease transmission of any
      other actions.
   o  confirm: This action instructs the focus associated media.  It has a "boolean" value.
   If this control is not specified, access to allow the request.
      The focus then uses the defined floor algorithm control is not
   available to further allow
      of deny the floor. client and media SHOULD NOT be transported for the
   associated media stream.

4.1.5.1.2.  pause-video

   The algorithms 'pause-video' control is used are outside the scope of
      this document.

   Note that placing in conjunction with a value video stream
   to cease transmission of block for this element does not
   guarantee that associated media.  It has a participant is blocked from joining the conference.
   Any other rule that might evaluate to true for "boolean" value.
   If this participant that
   carried an action whose value was higher than block would
   automatically grant confirm/allow permission control is not specified, access to that participant.

   The <conference-floor-policy> element the control is mandatory and contains not
   available to the
   required boolean attribute that indicates if client and media SHOULD NOT be transported for the floor
   associated media stream.







Novo, et al.            Expires September 4, 2007              [Page 17]

Internet-Draft              Data Model Schema                 March 2007


4.1.5.1.3.  gain

   The 'gain' control is moderator
   controlled or not.  One or more <Floor> elements can appear used in conjunction with a media output stream
   to indicate the
   <conference-floor-policy> element.  Every floor amount of amplification of an audio stream.  It has a
   "int" number value.  If this control is defined using not specified, access to the
   'label' attribute.  If
   control is not available to the <available-media> information client.

4.1.5.1.4.  video-layout

   The 'video-layout' control is included used in conjunction with a video stream
   to specify how the conference document, the value of this attribute MUST video streams (participants) are viewed by each
   participant.  Only one layout type can be equal
   to specified for each output
   stream.  If there are fewer participants than panels in the 'label' value of specified
   layout, then blanking (black screen) MAY be mixed into the corresponding media stream <entry> in on
   the
   <available-media> container.  The number behalf of those elements indicates
   how many floors the conference can have.  A floor can missing input streams.  If unspecified, the <video-
   layout> default type SHOULD be used for "single-view".

   The <layout> types are as follows:

   single-view: Only one
   or more media types; stream is presented by the mandatory <Media-types> element can contain
   zero or more of focus to all
   participants in one panel.

   dual-view: This dual view option will present the <Video>, <Audio>, <Application>, <Data>
   ,<Control>, <Message>, video side-by-side
   in 2 panels and <text> elements indicating not alter the media aspect ratio of the floor.  One type streams.  This will
   require the focus to introduce blanking on parts of media can only appear once.  Other media
   types can be defined the overall image
   as viewed by extensions.

   A floor can be controlled using many algorithms; the mandatory
   <Algorithm> element MUST contain participants.

   dual-view-crop: This side-by-side layout option instructs the focus
   to alter the aspect ratio of the streams (alter-aspect-ratio=TRUE) so
   that blanking is not necessary.  The focus handles the cropping of
   the streams.

   dual-view-2x1: This layout option instructs the focus to place one
   stream above the other, in essence with two rows and one column.  In
   this option the aspect ratio is not altered and blanking is
   introduced.

   dual-view-2x1-crop: This layout option also instructs the focus to
   place one stream above the other, in essence with two rows and only of one
   column.  In this option the <Moderator-
   controlled>, <FCFS>, aspect ratio is altered and <Random> elements indicating the algorithm.

   The <Max-floor-users> element video
   streams are cropped.

   quad-view: Four equal-sized panels in the <Floor> element a 2x2 layout is optional and,
   if present, dictates the maximum number of users who can have presented by
   the
   floor at one time.  The optional <Moderator-URI> indicates focus to all participants.  Typically the URI aspect ratio of the moderator.  It MUST be set if the attribute moderator-controlled
   streams are maintained (alter-aspect-ratio= FALSE).

   multiple-3x3: Nine equal-sized panels in a 3x3 layout is set presented by
   the focus to "true".

3.7.  <users>

   The <users> element contains all participants.  Typically the aspect ratio of the <join-handling>, <user-admission-
   policy>, <allowed-users-list>, <privileges-control-list> and <user>
   child elements.



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


   The <join-handling> element defines the actions used                 March 2007


   streams are preserved.

   multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is presented
   by the
   conference focus to control conference participation.  This element
   defines all participants.  Typically the action that aspect ratio of the focus is to take when processing a
   particular request
   streams are preserved.

   multiple-5x1: This option refers to join a conference.  This element defines values
   of:
   o  block: This action instructs 5x1 layout where one panel will
   occupy 4/9 of the focus to deny access to mixed video stream while the
      conference.  This action is others will each
   occupy 1/9 of the default action taken in stream.  Typically the
      absence aspect ratio of any other actions.
   o  confirm: the streams
   is preserved.

   automatic: This action instructs option allows the focus to place the participant
      on add panels as streams are
   added up to a pending list (e.g., by parking limit of "panels".

4.2.  <host-info>

   The <host-info> element contains information about the call on a music-on-hold
      server), awaiting moderator input for further actions.
   o  allow: entity hosting
   the conference.  This action instructs information is set before the focus to accept conference
   activation, and is rarely changed during the conference
      join request lifetime.
   The <host-info> element contains the <display-text>, <web-page> and
   <uris> child elements.  The <display-text> and <web-page> child
   elements are explained in [2].  The <uris> child element contains a
   sequence of child elements: <entry>, <H.323>, and grant access <PSTN-ISDN>.  The
   <entry> element refers to the conference within SIP protocol.  It keeps the
      instructions specified same name
   that is defined in the transformations of [2] to maintain backwards compatibility with this rule.
   o  IVR: This action instructs the focus that the user has
   RFC.  Future extensions to the <uris> element may define new values.

4.3.  <conference-state>

   The <conference-state> element and the PIN code.
   o  directed-operator: This action instructs <user-count>, <active>, and
   <locked> child elements are explained in section 5.5 of [2].  The
   <allow-conference-event-subscription> element represents a boolean
   action.  If set to TRUE, the focus is instructed to direct allow the
      user
   subscription to an operator.

   Note that placing a value of block conference state events, such as the SIP Event
   Package for this element does not
   guarantee that a participant is blocked from joining Conference State [2].  If set to FALSE, the conference.
   Any other rule that might evaluate subscription
   to true for this participant that
   carried an action whose value was higher than block conference state events would
   automatically grant confirm/allow permission to that participant.

   The <user-admission-policy> be rejected.  If this element is
   undefined it has a list default value of three elements:
   'closedAuthenticated', 'openAuthenticated', and 'anonymous'.  If TRUE, causing the
   <user-admission-policy> element is set subscription to
   conference state events to 'closedAuthenticated',
   users must be specified (and authenticate).  If accepted.

4.4.  <floor-information>

   The <floor-information> element has the attribute is set
   to 'openAuthenticated', users can <conference-ID>, <allow-
   floor-events>, <floor-request-handling>, and <conference-floor-
   policy> child elements.  Other elements from different namespaces MAY
   be add after present for the purposes of extensibility.  This element has its
   own XML namespace.  The absence of this namespace and its elements
   from an XML document indicates that the conference activation. does not have a
   floor.



Novo, et al.            Expires September 4, 2007              [Page 19]

Internet-Draft              Data Model Schema                 March 2007


   The following sections describe the remaining elements in more
   detail.  Other child elements can be <conference-ID> is used by a floor control server to extend <conference-
   description> in the future.

3.7.1.  <allowed-users-list> provide a
   client with a conference ID.

   The <allowed-users-list> child <allow-floor-events> element contains represents a list of user URIs,
   PSTN phone numbers, roles, or domains (*@example.com) that boolean action.  If set
   to TRUE, the focus
   uses is instructed to determine who can join accept the conference, who can invite subscription to join
   a conference, or who floor
   control events.  If set to FALSE, the focus needs is instructed to "refer to" reject
   the conference.
   The <allowed-users-list> element includes zero or more <target> child
   element.  This child subscription.  If this element includes the mandatory 'uri' attribute
   and the mandatory 'method' attribute.  The same 'uri' attribute with
   different method values can appear in the list more than once.  The
   'method' attribute is undefined, it has a list with the following values: "dial-in",
   "dial-out, and "refer".  The default
   value "dial-in" is used by of FALSE, causing the focus subscription to
   determine who can join floor control events to
   be rejected.

   The <floor-request-handling> element defines the conference.  Value "refer" is actions used by the



Novo, et al.             Expires April 13, 2007                [Page 17]

Internet-Draft          Common Conference Schema            October 2006
   conference focus to determine control floor requests.  This element defines the resources
   action that the focus needs to "refer to"
   the conference.  In SIP, this is achieved by the focus sending to take when processing a
   REFER particular request
   to those potential participants.  In a different
   paradigm, this could also mean that floor within a conference.  This element defines values of:
   o  "block": This action instructs the focus to deny the floor
      request.  This action is the default action taken in the absence
      of any other actions.
   o  "confirm": This action instructs the focus sends an SMS or an
   email to allow the referred user.  This list can be updated during request.
      The focus then uses the
   conference lifetime so it can be used for mid-conference refers as
   well. defined floor algorithm to further allow
      or deny the floor.  The "refer" value differs from algorithms used are outside the "dial-out" in scope of
      this document.

   Note that the dial-out
   contains placing a list value of resources "block" for this element does not
   guarantee that the focus will initiate a session
   with.  The resources on the "refer" value, on participant is blocked from joining the conference.
   Any other hand, are
   expected rule that might evaluate to initiate the session establishment towards the focus
   themselves.  It is also envisioned TRUE for this participant that difference users will have
   different access rights
   carried an action whose value was higher than "block" would
   automatically grant confirm/allow permission to those lists and therefore a separation
   between the two is needed.

3.7.2.  <privileges-control-list> that participant.

   The <privileges-control-list> refers to a virtual set of rights
   pertaining to operations.  This <conference-floor-policy> element is mandatory and contains the <conference-
   rules> element.

3.7.2.1.  <conference-rules>

   The <conference-rules> element is a set of <entry> child elements
   with specific authorization rules
   required boolean attribute that indicate who indicates if the floor is allowed to
   subscribe to conference-information notifications, see floors,
   request/grant floors, and so on. moderator
   controlled or not.  One or more <floor> elements can appear in the
   <conference-floor-policy> element.  Every <entry> element floor is represent by defined using the 'id' attribute, each of
   which identifies a rule inside
   'label' attribute.  If the conference.  It contains <available-media> information is included
   in the
   <condition> and <actions> sub elements.

3.7.2.1.1.  <condition>

   The <condition> element determines whether a particular privilege
   applies conference document, the value of this attribute MUST be equal
   to a user, a role, or domain.

   The <condition> element has the <identity> and 'label' value of the <validity> child
   element.  These elements MUST NOT appear more than once corresponding media stream <entry> in the
   condition part of a single rule.
   <available-media> container.  The <identity> element restricts matching number of a rule either to a
   single entity those elements indicates
   how many floors the conference can have.  A floor can be used for one
   or a group of entities.  The <identity> more media types; the mandatory <media-types> element has can contain
   zero or more of the
   <one> <video>, <audio>, <application>, <data>
   ,<control>, <message>, and <many> child <text> elements defined in Section 7.1 indicating the media of [8].  The
   absence
   the floor.  One type of media can only appear once.  Other media
   types can be defined by extensions.

   A floor can be controlled using many algorithms; the <identity> mandatory
   <algorithm> element in a <condition> MUST contain one and only one of the <moderator-
   controlled>, <FCFS>, and <random> elements indicating the algorithm.

   The <max-floor-users> child element indicates
   that in the privilege applies to all unauthenticated identities. <floor> element is



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


   The <identity> element has other child elements.  These child
   elements 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 <validity> element expresses                 March 2007


   optional and, if present, dictates the validity period maximum number of users who
   can have the rule with
   a starting and an ending floor at one time.  The <validity> optional <chair-id> indicates
   the BFCP UserID of the moderator.  It MUST be set if the attribute
   moderator-controlled is set to TRUE.

4.5.  <users>

   The <users> element contains the <join-handling>, <user-admission-
   policy>, <allowed-users-list>, and its <user> child
   elements ,<from> and <until>, are defined in section 7.3 of [8].

3.7.2.1.2.  <pseudonymous> elements.

   The <pseudonymous> <join-handling> element defines the actions used by the
   conference focus to control conference participation.  This element
   defines the action that the focus is to take when processing a
   particular request to join a conference.  This element is used defines values
   of:
   o  "block": This action instructs the focus to match participants that have
   provided an authenticated identity deny access to the conference focus, but have
   requested pseudonymity
      conference.  This action is the default action taken in the conference itself.  A user requests
   pseudonymity
      absence of any other actions.
   o  "confirm": This action instructs the focus to place the
      participant on a pending list (e.g., by authenticating himself parking the call on a
      music-on-hold server), awaiting moderator input for further
      actions.
   o  "allow": This action instructs the focus to accept the conference focus
      join request and
   providing a pseudonym in grant access to the signalling protocol (for example, using conference within the
      instructions specified in the From-header transformations of a SIP request).

   The <pseudonymous> element can be combined with this rule.
   o  "IVR": This action instructs the <identity>
   element focus that the user has to
      provide the PIN code.
   o  "directed-operator": This action instructs the focus with a rule on what to do when direct the
      user to an operator.

   Note that placing a
   specific identity is authenticated and value of block for this element does not
   guarantee that identity a participant is requesting
   pseudonymity through blocked from joining the signalling protocol.

3.7.2.1.3.  <has-been-referred>

   The <has-been-referred> element can be used to match those
   participants conference.
   Any other rule that the focus has referred might evaluate to the conference.

3.7.2.1.4.  <has-been-invited>

   The <has-been-invited> element can be used TRUE for this participant that
   carried an action whose value was higher than "block" would
   automatically grant confirm/allow permission to match those
   participants that the focus has invited into the conference.

3.7.2.1.5.  <has-been-in-conference> participant.

   The <has-been-in-conference> <user-admission-policy> is an element can be used to match those
   participants that have joined lets an organizer (or
   a participant with appropriate rights) choose a policy for the
   conference in the past.

3.7.2.1.6.  <is-in-conference>

   The <is-in-conference> element can be used to match those
   participants that controls how users are currently participating in allowed into the conference.

3.7.2.1.7.  <administrator>

   The <administrator> element can
   A 'closedAuthenticated' policy requires each conference participant
   to be used in the allowed users list (listed under the <allowed-users-
   list> XML element) with each participant being sufficiently (up to match those
   local policy) authenticated.  Conference join requests for users not
   in the allowed users list or participants
   that are administrators not authenticated should be
   rejected unless a <join-handling> action of 'confirm' is selected in
   which case the user is placed on a conference. pending list as indicated earlier.
   An 'openAuthenticated' policy requires each conferencing participant
   to be sufficiently authenticated (as before) but does not restrict



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


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

   The <is-on-allowed-users-list-dial-out> element can be used to match
   those                 March 2007


   which participants that are on can join the allowed-users-list conference.  Typically this implies
   that anyone capable of authenticating with the method
   dial-out.

3.7.2.1.9.  <is-on-allowed-users-list-refer> conferencing system
   may join the conference.  An 'anonymous' policy allows any join
   requests in and is the least restrictive in policies.

   The <is-on-allowed-users-list-refer> element following sections describe the remaining elements in more
   detail.  Other child elements can be used to match
   those participants that are on the allowed-users-list with extend <conference-
   description> in the method
   refer.

3.7.2.1.10.  <participant-passcode> future.

4.5.1.  <allowed-users-list>

   The <participant-passcode> <allowed-users-list> child element contains a list of user URIs,
   PSTN phone numbers, roles, or domains (*@example.com) that the focus
   uses to determine who can join the conference, who can be used invited to match those
   participants that have knowledge of
   join a passcode for conference, or who the conference
   (PIN code).

   A focus need not care if a user using a passcode needs to join is calling
   from a PSTN "refer to" the
   conference.  The <allowed-users-list> element includes zero or an IP phone.  For example: Using a SIP phone, a SIP
   INVITE request arrives directly at more
   <target> child elements.  This child element includes the mandatory
   'uri' attribute and the focus. mandatory 'method' attribute.  The focus examines same 'uri'
   attribute with different method values can appear in the list more
   than once.  The 'method' attribute is a list with the
   identity following
   values: "dial-in", "dial-out", and discovers that there are no rules allowing this identity
   to join. "refer".  The value "dial-in" is
   used by the focus also determines that there are no rules
   explicitly prohibiting this identity from joining. to determine who can join the conference.  The
   value "refer" is used by the focus in this
   case decides to challenge determine the identity for a passcode, if there is a
   rule resources that allows users with a passcode knowledge to join.  If no such
   rule exists,
   the focus would not challenge for a passcode.

   For PSTN users, the system can be set up for an IVR system needs to prompt "refer to" the user for a passcode before forwarding conference.  In SIP, this is
   achieved by the focus sending a REFER request to those potential
   participants.  In a different paradigm, this could also mean that the focus.
   The
   focus does not need to care if there is sends an IVR system SMS or not.  It an email to the referred user.  This list can apply
   be updated during the same procedure conference lifetime so it can be used for mid-
   conference refers as above.  It checks if there are any
   the rules allowing or denying the identity access.  In this case, the
   identity is well.

   The "refer" value differs from the GW.  If no rules exist for "dial-out" in that identity but the "dial-out"
   contains a
   general passcode rule does, then list of resources that the focus would challenge will initiate a session
   with.  The resources on the GW/IVR
   for "refer" value, on the other hand, are
   expected to initiate the session establishment toward the passcode.

   A focus can challenge for
   themselves.  It is also envisioned that difference users will have
   different access rights to those lists and therefore a separation
   between the passcode using, for example, two is needed.

4.5.2.  <user>

   The element <user> describes a HTTP
   Digest challenge. single participant in the conference.

   The username, passcode following elements of <user> are defined in [2], section 5.6:
   <display-text>, <associated-aors>, <roles>, <languages>, <cascaded-
   focus>, and realm need to be
   assigned <endpoint>. <user> has two attributes: 'entity' and distributed
   'state'.  The attribute 'state' is defined in [2], section 5.6.  The
   attribute 'entity' contains 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 the unique conference are assigned a
   different passcode than normal participants.  The <administrator-
   passcode> element user identifier.
   Other user identifiers can be used to match those key participants that
   have knowledge on a key participant passcode for the conference. associated with this conference user



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


   Again, a focus need not care if a                 March 2007


   identifier and enable the conferencing system to correlate and map
   these multiple authenticated user using a passcode identities to join is
   calling from a PSTN or an IP phone.  It is important that single global user
   identifier.

   The <provide-anonymity> element provides anonymity to the user.  In
   this case, the focus
   has a unique provides to the rest of the participants an
   anonymous identity for each user joining from a PSTN phone via a
   gateway.  It is not enough that one identity to user, for example anonymousX.  This can
   be assigned to all
   users joining from achieved by using the same gateway since administrators have more
   control over conference duration. <provide-anonymity> element.  It might be required that is a
   gateway maps the telephone number of the PSTN phone into
   boolean transformation.  If set to TRUE, the IP
   signalling protocol header that usually carries conference participants
   will see an anonymous identity for the asserted user whose identity
   or a user.

3.7.2.2.  <actions> is present
   in the conditions.

   The <actions> <endpoint> child element in can provide the applied rule is a positive grant desired level of
   permission to detail
   about the user's devices and their signaling sessions taking part in
   the conference data model or and has the conferencing system. following child elements defined in RFC
   4575 [2]: <display-text>, <referred>, <status>, <joining-method>,
   <joining-info>, <disconnection-method>, <disconnection-info>,
   <media>, and <call-info>.  The <actions> <endpoint>/<media> element has two
   other child elements: <to-mixer>, and <from-mixer> described in the
   following operations:
   o  The <allow-refer-users-dynamically> element represents a boolean
      action.  If set section.

4.5.2.1.  <from-mixer>, <to-mixer>

   Similar to TRUE, the identity is allowed to instruct controls defined in the
      focus <available-media> element,
   controls that apply to refer a particular user appear at this place in the
   data structure.  The <to-mixer> element details properties associated
   with the incoming streams to the conference without modifying mixer.  The <from-mixer> element
   details properties associated with the
      allowed-users-list (in SIP terms, outgoing streams from the identity is allowed to send
      a REFER request to
   mixer.  Both of these elements have the focus which results in attribute 'name'.  The 'name'
   attribute has the focus sending a
      REFER request to values "VideoIn", "VideoOut", "AudioOut", and
   "AudioIn".  The "VideoOut" and "AudioOut" media streams detail
   properties associated with the user outgoing video and audio from the referrer wishes to join
   mixer.  The "VideoIn" and "AudioIn" media stream details properties
   associated with the
      conference).  If set incoming video and audio to FALSE, the refer request is rejected.  If
      this element is undefined it has a value mixer.  More
   values can be defined in the future.

   Each of FALSE, causing these elements have the
      refer to be rejected.
   o <floor> and <controls> child
   elements.

4.5.2.1.1.  <floor>

   The <allow-invite-users-dynamically> <floor> element represents describes a boolean
      action.  If set to TRUE, the identity is allowed to instruct floor that joins this participant in
   the
      focus to invite conference.  If a user participant, for instance, needs to talk in the conference without modifying the
      allowed-users-list list (in SIP terms, the identity is allowed to
      send a REFER request
   conference, it first needs to get the focus which results in floor from the focus
      sending an INVITE request to chair of the
   conference.

   The <floor> element has a "Boolean" value.  A value of FALSE
   indicates that this user does not hold the referrer wishes to join
      the conference). floor in this moment.  If set to FALSE, the refer request



Novo, et al.            Expires September 4, 2007              [Page 23]

Internet-Draft              Data Model Schema                 March 2007


   this control is rejected.
      If not specified, this user SHOULD NOT specify the floor
   option.

4.5.3.  <sidebars-by-ref>

   The <sidebars-by-ref> element is undefined it has contains a value set of FALSE, causing the
      refer to be rejected.
   o <entry> child
   elements.  Each <entry> child element contains a <user> child element
   with a sidebar unique conference user identifier and a <display-text>
   child element.

4.5.4.  <sidebars-by-val>

   The <allow-remove-users-dynamically> <sidebars-by-val> element represents contains a boolean
      action.  If set to TRUE, the identity is allowed to instruct of <entry> child
   elements each containing information about a single sidebar.  By
   using this element, the
      focus to remove server can include a user from full or partial
   description of each sidebar (as a sub-conference) in the body of the
   main conference without modifying document.


5.  RELAX NG Schema

   In accordance with the
      ruleset (in SIP terms, XCON framework document [1], the identity Conference
   Object is allowed to send a REFER
      request to the focus which results logical representation of a conference instance.  The
   conference information schema contains core information that is
   utilized in any conference.  It also contains the focus sending an BYE
      request to the user the referrer wishes to leave the conference).
      If set to FALSE, variable
   information part of the refer request is rejected.  If this Conference Object.

   This specification defines some document fragments in RELAX NG
   format.

   namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
   namespace ns1 = "urn:ietf:params:xml:ns:conference-info-urn"
   namespace ns2 = "urn:ietf:params:xml:ns:common-policy"
   default namespace ns3 = "urn:ietf:params:xml:ns:conference-schema"

   start = element conference-info { conference-type }
   # CONFERENCE TYPE
   conference-type =
     attribute entity { text },
     attribute version { xsd:unsignedInt }?,
     attribute state { state-type }?,
     role-type,
     conference-description-type,
     element host-info { host-type }?,
     element conference-state { conference-state-type }?,
     element floor-information { floor-information-type }?,
     element users { users-type },
     element sidebars-by-ref { sidebars-by-ref-type }?,



Novo, et al.            Expires September 4, 2007              [Page 24]

Internet-Draft              Data Model Schema                 March 2007


     element sidebars-by-val { sidebars-by-val-type }?,
     anyElement*
   # CONFERENCE DESCRIPTION TYPE
   conference-description-type =
     element
      is undefined it has a value of FALSE, causing the refer to be
      rejected.
   o  The <show-floor-holder> conference-description {
       role-type,
       attribute xml:lang { xsd:language }?,
       attribute state { state-type }?,
       element display-text { text }?,
       element defines the actions used by the
      conference focus to control floor requests.  This subject { text }?,
       element free-text { text }?,
       element defines
      the action that the focus is to take when processing a particular
      request to a floor within a conference.  This keywords {
         list { xsd:string* }
       }?,
       element allow-sidebars { xsd:boolean }?,
       element conference-time { conferencetime-type }?,
       element conf-uris { uris-type }?,
       element service-uris { uris-type }?,
       element maximum-user-count { xsd:int }?,
       element available-media { conference-media-type }?,
       anyElement*
     }
   # CONFERENCE TIME
   conferencetime-type =
     role-type,
     element has defined
      values of: entry {
       element base { text }?,
       element mixing-start-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" },
         attribute required-participant { single-role-type },
         anyAttribute
       }?,
       element mixing-end-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" },
         attribute required-participant { single-role-type },
         anyAttribute
       }?,
       element can-join-after-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" }
       }?,
       element must-join-before-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" }
       }?,
       element notify-end-of-conference { xsd:int }?,
       element allowed-extend-mixing-end-offset {
         allowed-extend-mixing-values
       }?,
       anyElement*



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


      *  block: This action instructs the focus to deny the floor
         request.  This action is the default action taken in the
         absence of any other actions.
      *  confirm: This action instructs the focus to allow the request.
         The focus then uses the defined floor algorithm to further
         allow of deny the floor.  The algorithms used are outside the
         scope of this document.
   o  Note that placing a value of block for this                 March 2007


     }*,
     anyElement*
   # ALLOWED EXTEND MIXING VALUES
   allowed-extend-mixing-values =
     xsd:string "allowed" | xsd:string "denied"
   # URIS TYPE
   uris-type =
     role-type,
     attribute state { state-type }?,
     (element entry { uri-type }*
      & element does not
      guarantee that a participant is blocked from joining the
      conference.  Any other rule 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> H323 { H323-type }*
      & element PSTN-ISDN { PSTN-type }*),
     anyElement*
   # SIP TYPE
   uri-type =
     role-type,
     (element uri { xsd:anyURI },
      element display-text { text }?,
      element is of type boolean
      transformation.  If set to TRUE, the conference participant is
      able to see the floor requests.  If set to FALSE, the conference
      participant is not able to see floor requests.  If this purpose { text }?,
      anyElement*)*
   # H323 TYPE
   H323-type =
     role-type,
     element H.323-alias { text }?,
     element H.323-URI { xsd:anyURI }?,
     anyElement*
   # PSTN TYPE
   PSTN-type =
     role-type,
     attribute PIN-code { xsd:unsignedInt },
     attribute purpose { xsd:unsignedInt },
     (element phone-number { xsd:unsignedInt },
      anyElement*)+
   # BFCP TYPE
   BFCP-type =
     role-type,
     (element conference-ID { xsd:unsignedInt },
      anyElement*)*
   # MAXIMUM USER TYPE
   maximum-user-count-type =
     role-type,
     anyAttribute,
     (element entry {
        xsd:unsignedInt,
        attribute role { single-role-type }
      },
      anyElement*)+
   # CONFERENCE MEDIA TYPE



Novo, et al.            Expires September 4, 2007              [Page 26]

Internet-Draft              Data Model Schema                 March 2007


   conference-media-type =
     role-type,
     attribute state { state-type }?,
     element entry { conference-medium-type }*,
     anyElement*
   # CONFERENCE MEDIUM TYPE
   conference-medium-type =
     role-type,
     attribute label { text },
     element display-text { text }?,
     element is
      undefined, it has a value of FALSE, causing the floor requests to
      not being seen by the conference participant.
   o  A rule can be set that provides anonymity to 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> element.  It is a
      boolean transformation.  If set to TRUE, the conference
      participants will see an anonymous identity for the user whose
      identity is present in the conditions.
   o  The <read-write> type { text }?,
     element status { media-status-type }?,
     element mixing-mode { mix-mode-type }?,
     element mix-level { xsd:unsignedInt }?,
     element represents a boolean action.  If set to
      TRUE, the identity is allowed to modify the codecs { codecs-type }?,
     element described
      inside the 'element' controls { controls-type }?,
     anyElement*
   # CONTROLS TYPE
   controls-type =
     role-type,
     attribute in the conference policy.  If set
      to FALSE, any modifications to the state { state-type }?,
     element are rejected.
   o  The <read-only> control { control-type }*,
     anyElement*
   # MIX MODE TYPE
   mix-mode-type =
     xsd:string "moderator-controlled"
     | xsd:string "FCFS"
     | xsd:string "automatic"
   # CODECS TYPE
   codecs-type =
     role-type,
     attribute decision { decision-type },
     element represents a boolean action.  If set to
      TRUE, the identity is allowed to read the codec { codec-type }*,
     anyElement*
   # CODEC TYPE
   codec-type =
     role-type,
     attribute name { text },
     attribute policy { policy-type }
   # DECISION TYPE
   decision-type =
     xsd:string "automatic" | xsd:string "moderator-controlled"
   # POLICY TYPE
   policy-type = xsd:string "allowed" | xsd:string "disallowed"
   # CONTROL TYPE
   control-type =
     element mute { xsd:boolean }
     | element pause-video { xsd:boolean }



Novo, et al.            Expires September 4, 2007              [Page 27]

Internet-Draft              Data Model Schema                 March 2007


     | element gain {
         xsd:int { minInclusive = "-127" maxInclusive = "127" }
       }
     | element video-layout {
         xsd:string "single-view"
         | xsd:string "dual-view"
         | xsd:string "dual-view-crop"
         | xsd:string "dual-view-2x1"
         | xsd:string "dual-view-2x1-crop"
         | xsd:string "quad-view"
         | xsd:string "multiple-3x3"
         | xsd:string "multiple-4x4"
         | xsd:string "multiple-5x1"
         | xsd:string "automatic"
       }
     | anyElement*
   # HOST TYPE
   host-type =
     role-type,
     (element display-text { text },
      element web-page { xsd:anyURI },
      element uris { uris-type },
      anyElement*)*
   # CONFERENCE STATE TYPE
   conference-state-type =
     role-type,
     element allow-conference-event-subscription { xsd:boolean }?,
     element user-count { xsd:unsignedInt }?,
     element active { xsd:boolean }?,
     element locked { xsd:boolean }?,
     anyElement*
   # FLOOR INFORMATION TYPE
   floor-information-type =
     role-type,
     (element conference-ID { BFCP-type },
      element allow-floor-events { xsd:boolean },
      element floor-request-handling { floor-request-type },
      element conference-floor-policy { Conference-floor-policy },
      anyElement*)*
   # FLOOR REQUEST TYPE
   floor-request-type = xsd:string "block" | xsd:string "confirm"
   # CONFERENCE FLOOR POLICY
   Conference-floor-policy =
     role-type,
     element floor {
       attribute moderator-controlled { xsd:boolean },
       attribute label { text },
       anyAttribute,



Novo, et al.            Expires September 4, 2007              [Page 28]

Internet-Draft              Data Model Schema                 March 2007


       (element media-types {
          role-type,
          (xsd:string "video"
           | xsd:string "audio"
           | xsd:string "application"
           | xsd:string "data"
           | xsd:string "control"
           | xsd:string "message"
           | xsd:string "text")
        },
        element described inside
      the 'element' algorithm {
          role-type,
          (xsd:string "moderator-controlled"
           | xsd:string "FCFS"
           | xsd:string "random")
        },
        element max-floor-users { xsd:nonNegativeInteger },
        element chair-id { xsd:anyURI },
        anyElement*)*
     }+
   # USERS TYPE
   users-type =
     attribute in the conference policy.  If set to
      FALSE, any attempts to read the state { state-type }?,
     role-type,
     element join-handling { join-handling-type }?,
     element user-admission-policy { user-admission-policy-type }?,
     element user-must-be-specified { xsd:boolean }?,
     element are rejected.

3.8.  <user>

   The allowed-users-list { UserList }?,
     element <user> describes a single participant in the 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. { user-type }*,
     anyElement*
   # USERS ADMISSION POLICY
   user-admission-policy-type =
     xsd:string "closedAuthenticated"
     | xsd:string "openAuthenticated"
     | xsd:string "anonymous"
   # JOIN HANDLING TYPE
   join-handling-type =
     xsd:string "block"
     | xsd:string "allow"
     | xsd:string "confirm"
     | xsd:string "IVR"
     | xsd:string "directed-operator"
   # USERLIST
   UserList =
     role-type,
     element target { target-type }*,
     anyElement*
   # TARGET TYPE



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


   The <sphere>                 March 2007


   target-type =
     role-type,
     attribute uri { xsd:anyURI },
     attribute method { method-type }
   # METHOD TYPE
   method-type =
     xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer"
   # USER TYPE
   user-type =
     role-type,
     attribute entity { xsd:anyURI },
     attribute state { state-type }?,
     element display-text { text }?,
     element associated-aors { uris-type }?,
     element provide-anonymity { xsd:boolean }?,
     element can be used to indicate the roles { roles-type }?,
     element languages {
       list { xsd:language }
     }?,
     element cascaded-focus { xsd:anyURI }?,
     element allow-refer-users-dynamically { xsd:boolean }?,
     element allow-invite-users-dynamically { xsd:boolean }?,
     element allow-remove-users-dynamically { xsd:boolean }?,
     element endpoint { endpoint-type }*,
     anyElement*
   # ENDPOINT TYPE
   endpoint-type =
     role-type,
     attribute entity { text },
     attribute state (e.g., 'work',
   'home', 'meeting', 'travel') the user is 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> { state-type }?,
     element display-text { text }?,
     element is under a <user> parent.  This referred { conference-info-urn* }?,
     element status { endpoint-status-type }?,
     element joining-method { joining-type }?,
     element joining-info { conference-info-urn* }?,
     element disconnection-method { disconnection-type }?,
     element disconnection-info { conference-info-urn* }?,
     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> media { media-type }*,
     element call-info { conference-info-urn* }?,
     anyElement*
   # MEDIA TYPE
   media-type =
     attribute id { xsd:int },
     attribute state { state-type }?,
     anyAttribute,
     element display-text { text }?,
     element type { text }?,
     element label { text }?,



Novo, et al.            Expires September 4, 2007              [Page 30]

Internet-Draft              Data Model Schema                 March 2007


     element has as well two other child elements: <to-mixer>, and <from-
   mixer> child src-id { text }?,
     element status { media-status-type }?,
     element described in the following section.

3.8.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> { mixer-type }?,
     element from-mixer { mixer-type }?,
     anyElement*
   # MIXER TYPE
   mixer-type =
     role-type,
     attribute state { state-type }?,
     (element floor { xsd:boolean },
      element details properties associated with
   the incoming streams to the mixer. <from-mixer> controls { controls-type })?,
     anyElement*
   # SIDEBARS-BY-REF TYPE
   sidebars-by-ref-type =
     role-type,
     attribute state { state-type }?,
     element entry { uri-type }*,
     anyElement*
   # SIDEBARS-BY-VAL TYPE
   sidebars-by-val-type =
     role-type,
     attribute state { state-type }?,
     element entry { conference-type }*,
     anyElement*
   # ROLES_TYPE
   roles-type =
     element details
   properties associated with the outgoing streams from the mixer.  Both
   of these elements have the entry { single-role-type }*,
     anyElement*
   # ROLE TYPE
   role-type =
     attribute 'name'.  'Name' read-only { single-role-type }?,
     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.

3.8.1.1.  <floor>

   The <floors> write-only { single-role-type }?,
     anyAttribute
   # SINGLE ROLE TYPE
   single-role-type =
     xsd:string "administrator"
     | xsd:string "creator"
     | xsd:string "moderator"
     | xsd:string "participant"
     | xsd:string "observer"
   # *********************************
   # EXTENSIBILITY OF THE SCHEMA
   # *********************************

   # EXTENSIBILITY ELEMENTS
   anyElement =
     element describes a floor that joins this participant in
   the conference.  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> * {
       (attribute * { text }



Novo, et al.            Expires September 4, 2007              [Page 31]

Internet-Draft              Data Model Schema                 March 2007


        | text
        | anyElement)*
     }
   # EXTENSIBILITY ATTRIBUTES
   anyAttribute =
     attribute * - (entity
                    | version
                    | state
                    | xml:lang
                    | required-participant
                    | PIN-code
                    | purpose
                    | role
                    | type
                    | min
                    | max
                    | label
                    | decision
                    | name
                    | policy
                    | moderator-controlled
                    | uri
                    | method
                    | id
                    | domain
                    | read-only
                    | write-only
                    | ns3:*) { text }*
   # *************************************************************
   # TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
   # *************************************************************

   # WILDCARD FOR EVENT-PACKAGE NAMESPACE
   conference-info-urn =
     element has a 'Boolen' value.  A value of 'false'
   indicates that this user does not hold the floor in this moment.  If
   this control is not specify, this user SHOULD not specify the floor
   option. * - ns1:*  {
       mixed {
         (attribute * { text }
          | conference-info-urn)*
       }
     }
   # DEFINITION OF STATE TYPE
   state-type = "full" | "partial" | "deleted"
   # DEFINITION OF ENDPOINT STATUS TYPE
   media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive"
   # ENDPOINT STATUS TYPE
   endpoint-status-type =
     "pending"
     | "dialing-out"



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


3.9.  <sidebars-by-ref>

   The <sidebars-by-ref> element contains a set of <entry> child
   elements.  Each <entry> child element contains a <user> child                 March 2007


     | "dialing-in"
     | "alerting"
     | "on-hold"
     | "connected"
     | "muted-via-focus"
     | "disconnecting"
     | "disconnected"
   # JOINING TYPE
   joining-type = "dialed-in" | "dialed-out" | "focus-owner"
   # DISCONNECTION TYPE
   disconnection-type = "departed" | "booted" | "failed" | "busy"
   # ******************************************
   # TYPE DEFINED IN THE COMMON POLICY DOCUMENT
   # ******************************************

   # WILDCARD FOR COMMON-POLICY NAMESPACE
   common-policy =
     element
   with a sidebar conference unique identifier and a <display-text>
   child element. * - ns2:*  {
       mixed {
         (attribute * { text }
          | common-policy)*
       }
     }


6.  XML Schema Extensibility

   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' Conference Information Data Model defined in [2].

3.10.  <sidebars-by-val>

   The <sidebars-by-val> element contains a set of <entry> this document is
   meant to be extensible toward specific application domains.  Such
   extensions are accomplished by defining elements, child elements each containing information about a single sidebar.

   Notice as well that the <sidebars-by-val> and
   attributes that are specific to the <entry> child
   element do not include desired application domain.  The
   IETF MAY extend the attribute 'state' defined in [2].


4.  RELAX NG data model schema

   In accordance with extension elements from
   the XCON framework document [1], the Conference
   Object same namespace, but other instances are free to extend it from
   other than urn:ietf:params:xml:ns:conference-schema.

   Elements or attributes from unknown namespaces MUST be ignored.


7.  XML Example

   The following is a logical representation an example of a conference instance. information document.
   The
   common conference information schema contains core information 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 utilized one sidebar in any
   the conference.  It also contains  Also note that there is one floor moderator for the variable
   information part of
   audio and a different floor moderator for the Conference Object.

   This specification defines some document fragments in 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"> video.



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


                    <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> September 4, 2007              [Page 33]

Internet-Draft              Data Model Schema                 March 2007


  <?xml version="1.0" encoding="UTF-8"?>
  <conference-info xmlns="urn:ietf:params:xml:ns:conference-schema"
      entity="conference123" state="full">
      <!--
        SECURITY LEVEL
          CONFERENCE DESCRIPTION
      -->
    <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-description xml:lang="en-us">
          <display-text>Discussion of Formula-1 racing</display-text>
          <subject> Sports:Formula-1</subject>
          <free-text>This is a conference example</free-text>
          <keywords>Formula-1, cars</keywords>
          <webpage>http://www.example.com/users/formula-1</webpage>
          <security-level>low</security-level>
          <allow-sidebars>true</allow-sidebars>
          <conference-stage>running</conference-stage>
          <!--
          CONFERENCE STAGE TIME
          -->
    <define name="conference-stage-type">
        <choice>
          <conference-time>
              <entry>
                  <base>BEGIN:VCALENDAR
                      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>

                  <mixing-start-offset required-participant="moderator"
                      > 2006-10-17T14:29:00Z</mixing-start-offset>
                  <mixing-end-offset required-participant="participant"
                      > 2006-10-17T16:31:00Z</mixing-end-offset>
                  <must-join-before-offset
                      > 2006-10-17T15:30:00Z</must-join-before-offset>
              </entry>
          </conference-time>
          <!--
          CONFERENCE UNIQUE IDENTIFIERS
          -->
          <conf-uris state="full">
              <SIP>
                  <uri>tel:+3585671234</uri>
                  <display-text>Conference Bridge</display-text>
                  <purpose>participation</purpose>



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


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


              </SIP>
              <SIP>
                  <uri>http://www.example.comlive.ram</uri>
                  <purpose>streaming</purpose>
              </SIP>
          </conf-uris>
          <!--
        CONFERENCE TIME
            SERVICE URIS
          -->
    <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>
          <service-uris state="full">
              <SIP>
                  <uri>http://www.example.com/formula1/</uri>
                  <purpose>web-page</purpose>
              </SIP>
          </service-uris>
          <!--
        URIS TYPE
            MAXIMUM USER COUNT
          -->
    <define name="uris-type">
          <maximum-user-count>
              <entry role="administrator">2</entry>
              <entry role="moderator">5</entry>
              <entry role="participant">150</entry>
          </maximum-user-count>
          <!--
            AVAILABLE MEDIA
          -->
          <available-media>
              <entry label="10234">
                  <display-text>main audio</display-text>
                  <type>audio</type>
                  <status>sendrecv</status>
                  <mixing-mode>automatic</mixing-mode>
                  <mix-level>3</mix-level>
                  <codecs decision="automatic">
                      <codec name="PCMU" policy="allowed"/>
                  </codecs>
              </entry>
              <entry label="10235">
                  <display-text>main video</display-text>
                  <type>video</type>
                  <status>sendrecv</status>
                  <mixing-mode>automatic</mixing-mode>
                  <mix-level>4</mix-level>
                  <codecs decision="automatic">
                      <codec name="H.263" policy="allowed"/>
                  </codecs>
              </entry>
          </available-media>



Novo, et al.            Expires April 13, September 4, 2007              [Page 27] 35]

Internet-Draft          Common Conference              Data Model 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>                 March 2007


      </conference-description>
      <!--
        SIP TYPE
          HOST INFO
        -->
    <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>
      <host-info>
          <display-text>Formula1</display-text>
          <web-page>http://www.example.com/formula1/</web-page>
          <uris state="full">
              <SIP>
                  <uri>sip:alice@example.com</uri>
              </SIP>
              <SIP>
                  <uri>sip:carol@example.com</uri>
              </SIP>
          </uris>
      </host-info>
      <!--
          CONFERENCE STATE
        -->
      <conference-state>
          <allow-conference-state>true</allow-conference-state>
          <user-count>3</user-count>
          <active>true</active>
          <locked>false</locked>
      </conference-state>
      <!--
          FLOOR INFORMATION
        -->
      <floor-information>
          <allow-floor-events>true</allow-floor-events>
          <floor-request-handling>confirm</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>
              </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</moderator-uri>
              </floor>
          </conference-floor-policy>
      </floor-information>
      <!--
        H323 TYPE
   -->
    <define name="H323-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="H.323-alias">
                <text/>
          USERS



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


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


        -->
      <users state="full">
          <join-handling>allow</join-handling>
          <!--
        PSTN TYPE
           ALLOWED USERS LIST
          -->
    <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>
          <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>
          <!--
        BFCP TYPE
            PRIVILEGES CONTROL LIST
          -->
    <define name="BFCP-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="conference-id">
                <data type="unsignedInt"/>
            </element>
        </zeroOrMore>
    </define>
          <privileges-control-list>
              <conference-rules>
                  <entry id="1">
                      <condition>
                          <identity>
                              <many domain="example.com"/>
                          </identity>
                          <validity>
                              <to>2006-10-17T16:30:00Z</to>
                              <from>2006-10-17T14:30:00Z</from>
                          </validity>
                      </condition>
                      <action>
                          <allow-invite-users-dynamically
                              >true</allow-invite-users-dynamically>
                      </action>
                  </entry>
                  <entry id="2">
                      <condition>
                          <identity>
                              <one id="bob@example.com"/>
                          </identity>
                      </condition>
                      <action>
                          <show-floor-holder>block</show-floor-holder>
                      </action>
                  </entry>
              </conference-rules>
          </privileges-control-list>
          <!--
        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, September 4, 2007              [Page 29] 37]

Internet-Draft          Common Conference              Data Model Schema            October 2006


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


          <user entity="bob534" state="partial">
              <display-text>Bob Hoskins</display-text>
              <associated-aors state="full">
                  <SIP>
                      <uri>mailto:bob@example.com</uri>
                      <display-text>email</display-text>
                  </SIP>
              </associated-aors>
              <provide-anonymity>false</provide-anonymity>
              <roles>
                  <entry>participant</entry>
              </roles>
              <languages>en</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>
              <!--
        MAXIMUM STREAM TYPE
                  ENDPOINTS
              -->
    <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>
              <endpoint entity="sip:bob@example.com" state="full">
                  <display-text>Bob's Laptop</display-text>
                  <referred>
                      <when>2006-10-17T14:00:00Z</when>
                      <reason>expert required</reason>
                      <by>sip:alice@example.com</by>
                  </referred>
                  <status>connected</status>
                  <joining-method>dialed-out</joining-method>
                  <joining-info>
                      <when>2006-10-17T14:00:00Z</when>
                      <reason>invitation</reason>
                      <by>sip:alice@example.com</by>
                  </joining-info>

                  <!--
                      MEDIA TYPES
                  -->
    <define name="media-stream-type">
        <choice>
            <value type="string">audio</value>
            <value type="string">video</value>
        </choice>
    </define>
                  <media id="1">
                      <label>10235</label>
                      <src-id>432424</src-id>
                  </media>
                  <!--
        CONFERENCE MEDIA TYPE
                      CALL INFO
                  -->
    <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, September 4, 2007              [Page 30] 38]

Internet-Draft          Common Conference              Data Model Schema            October 2006


            </element>
        </zeroOrMore>
    </define>                 March 2007


                  <call-info>
                      <sip>
                          <display-text>full info</display-text>
                          <call-id>hsjh8980vhsb78</call-id>
                          <from-tag>vav738dvbs</from-tag>
                          <to-tag>8954jgjg8432</to-tag>
                      </sip>
                  </call-info>
              </endpoint>
          </user>

          <!--
        CONFERENCE MEDIUM TYPE
              USER
          -->
    <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>

          <user entity="alice334" state="full">
              <display-text>Alice Kay</display-text>
              <associated-aors state="full">
                  <SIP>
                      <uri>mailto:alice@example.com</uri>
                      <display-text>email</display-text>
                  </SIP>
              </associated-aors>
              <provide-anonymity>false</provide-anonymity>
              <roles>
                  <entry>moderator</entry>
              </roles>
              <languages>en</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>
              <!--
        MIX MODE TYPE
                  ENDPOINTS
              -->
    <define name="mix-mode-type">
        <choice>
            <value type="string">Moderator-controlled</value>
            <value type="string">FCFS</value>
            <value type="string">"Automatic</value>
        </choice>
    </define>
              <endpoint entity="sip:alice@example.com" state="full">
                  <display-text>Alice's Desktop</display-text>
                  <status>connected</status>
                  <joining-method>dialed-in</joining-method>
                  <joining-info>
                      <when>2006-10-17T13:35:08Z</when>
                      <reason>invitation</reason>
                      <by>sip:conference@example.com</by>
                  </joining-info>
                  <!--



Novo, et al.            Expires April 13, September 4, 2007              [Page 31] 39]

Internet-Draft          Common Conference              Data Model Schema            October 2006                 March 2007


                      MEDIA
                  -->
                  <media id="1">
                      <label>10235</label>
                      <src-id>432424</src-id>
                      <status>sendrecv</status>
                  </media>
                  <media id="2">
                      <label>10234</label>
                      <src-id>532535</src-id>
                      <status>sendrecv</status>
                  </media>
                  <!--
        CODECS TYPE
                      CALL INFO
                  -->
    <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>
                  <call-info>
                      <sip>
                          <display-text>full info</display-text>
                          <call-id>truy45469123478</call-id>
                          <from-tag>asd456cbgt</from-tag>
                          <to-tag>3456jgjg1234</to-tag>
                      </sip>
                  </call-info>
              </endpoint>
          </user>

          <!--
                  -->
          <user entity="carol233" state="full">
              <display-text>Carol More</display-text>
              <associated-aors state="full">
                  <SIP>
                      <uri>mailto:carol@example.com</uri>
                      <display-text>email</display-text>
                  </SIP>
              </associated-aors>
              <provide-anonymity>false</provide-anonymity>
              <roles>
                  <entry>administrator</entry>
              </roles>
              <languages>en</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>



Novo, et al.            Expires September 4, 2007              [Page 40]

Internet-Draft              Data Model Schema                 March 2007


              <!--
        CODEC TYPE
                  ENDPOINTS
              -->
    <define name="codec-type">
        <ref name="role-type"/>
        <attribute name="name">
            <text/>
        </attribute>
        <attribute name="policy">
            <ref name="policy-type"/>
        </attribute>
    </define>
              <endpoint entity="sip:carol@example.com" state="full">
                  <display-text>Carol's Computer</display-text>
                  <status>connected</status>
                  <joining-method>dialed-in</joining-method>
                  <joining-info>
                      <when>2006-10-17T13:30:05Z</when>
                      <reason>invitation</reason>
                      <by>sip:conference@example.com</by>
                  </joining-info>
                  <!--
        DECISION TYPE
                      MEDIA
                  -->
    <define name="decision-type">
        <choice>
            <value type="string">Automatic</value>
            <value type="string">Moderator-controlled</value>
        </choice>
    </define>
                  <media id="1">
                      <label>10235</label>
                      <src-id>432424</src-id>
                      <status>sendrecv</status>
                  </media>
                  <media id="2">
                      <label>10234</label>
                      <src-id>532535</src-id>
                      <status>sendrecv</status>
                  </media>
                  <!--
        POLICY TYPE
                      CALL INFO
                  -->
    <define name="policy-type">
        <choice>
            <value type="string">Allowed</value>
            <value type="string">Disallowed</value>
        </choice>
    </define>
                  <call-info>
                      <sip>
                          <display-text>full info</display-text>
                          <call-id>wevb12562321894</call-id>
                          <from-tag>asw456wedf</from-tag>
                          <to-tag>2365dfrt3497</to-tag>
                      </sip>
                  </call-info>
              </endpoint>
          </user>
      </users>
      <!--
           SIDEBARS BY REFERENCE
         -->
      <sidebars-by-ref state="full">
          <entry>
              <uri>sips:conference123;grid=40</uri>
              <display-text>private with Bob</display-text>
          </entry>
      </sidebars-by-ref>



Novo, et al.            Expires September 4, 2007              [Page 41]

Internet-Draft              Data Model Schema                 March 2007


      <!--
           SIDEBARS BY VALUE
         -->
      <sidebars-by-val>
          <entry entity="conference123;grid=40">
              <users>
                  <user entity="bob534"/>
                  <user entity="carol233"/>
              </users>
          </entry>
      </sidebars-by-val>
  </conference-info>


   Note that due to RFC formatting conventions, this documents splits
   lines whose content would exceed 72 characters.  Two backslash
   characters mark where line folding has taken place.  These
   backslashes would not appear in the actual XML data model.


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


9.  IANA Considerations

9.1.  Conference Relax NG Schema Registration


     URI:  urn:ietf:params:xml:ns:conference-schema

     Relax NG Schema:  The Relax NG schema to be registered is contained
        in Section 4.  Its first line is

     namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

        and its last line is

     }






Novo, et al.            Expires April 13, September 4, 2007              [Page 32] 42]

Internet-Draft          Common Conference              Data Model 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,                 March 2007                [Page 33]

Internet-Draft          Common


9.2.  Conference 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 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 April 13, 2007                [Page 34]

Internet-Draft          Common Namespace Registration

   URI: urn:ietf:params:xml:ns:conference-schema


10.  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.  We
   would like to thank Orit Levin, Adam Roach, Mary Barnes, Chris
   Boulton, Umesh Chandra, and Jari Urpilainen for their comments.
   Also, We would like to thank Hisham Khartabil, Petri Koskelainen, and
   Aki Niemi for letting us use the policy information of their cpcp
   drafts in this document.


11.  References

11.1.  Normative References

   [1]  Barnes, M., "A Framework and Data Model for Centralized
        Conferencing", draft-ietf-xcon-framework-07 (work in progress),
        January 2007.

   [2]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
        Initiation Protocol (SIP) Event Package for Conference Schema State",
        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 (SIP)", RFC 4353, February 2006.

   [5]  Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
        "Extensible Markup Language (XML) 1.0 (Second Edition)", World
        Wide Web Consortium FirstEdition REC-xml-20001006, October 2006


                        <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> 2000,
        <http://www.w3.org/TR/2000/REC-xml-20001006>.

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

11.2.  Informative References

   [7]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
        Protocol (BFCP)", RFC 4582, November 2006.



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


    </define>

    <!--
        USERS TYPE
    -->
    <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>
    <!--
        USERS ADMISSION POLICY
    -->
    <define name="user-admission-policy-type">
        <choice>
            <value type="string">closedAuthenticated</value>
            <value type="string">openAuthenticated</value>
            <value type="string">anonymous</value>
        </choice>
    </define>
    <!--
        JOIN HANDLING TYPE
    -->
    <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 April 13,                 March 2007                [Page 36]

Internet-Draft          Common Conference


   [8]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.


Appendix A.  Appendix A.  Non-Normative RELAX NG Schema            October 2006


        </choice>
    </define>

    <!--
        USERLIST
    -->
    <define name="UserList">
        <ref name="role-type"/>
        <zeroOrMore> in XML Syntax

   <?xml version="1.0" encoding="UTF-8"?>
   <grammar ns="urn:ietf:params:xml:ns:conference-schema"
    xmlns="http://relaxng.org/ns/structure/1.0"
    xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
    datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
    <start>
     <element name="target"> name="conference-info">
      <ref name="Target"/> name="conference-type"/>
     </element>
        </zeroOrMore>
    </define>
    </start>
    <!--
        TARGET
           CONFERENCE TYPE
       -->
    <define name="Target">
        <ref name="role-type"/> name="conference-type">
     <attribute name="uri"> name="entity">
      <text/>
     </attribute>
     <optional>
      <attribute name="version">
       <data type="anyURI"/> type="unsignedInt"/>
      </attribute>
     </optional>
     <optional>
      <attribute name="method"> name="state">
       <ref name="method-type"/> name="state-type"/>
      </attribute>
    </define>
    <!--
        METHOD TYPE
    -->
    <define name="method-type">
        <choice>
            <value type="string">dial-in</value>
            <value type="string">dial-out</value>
            <value type="string">refer</value>
        </choice>
    </define>
    <!--
        PRIVILEGES CONTROL LIST TYPE
    -->
    <define name="privileges-control-list-type">
     </optional>
     <ref name="role-type"/>
        <oneOrMore>
     <ref name="conference-description-type"/>
     <optional>
      <element name="conference-rules"> name="host-info">
       <ref name="conference-rules-type"/> name="host-type"/>
      </element>
        </oneOrMore>
    </define>
     </optional>
     <optional>
      <element name="conference-state">
       <ref name="conference-state-type"/>
      </element>
     </optional>
     <optional>
      <element name="floor-information">
       <ref name="floor-information-type"/>



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


    <!--
        CONFERENCE RULES TYPE
    -->
    <define name="conference-rules-type">
        <ref name="role-type"/>
        <attribute name="id">
            <text/>
        </attribute>
        <zeroOrMore>                 March 2007


      </element>
     </optional>
     <element name="entry"> name="users">
      <ref name="conference-rule-type"/> name="users-type"/>
     </element>
        </zeroOrMore>
    </define>
    <!--
        CONFERENCE RULE TYPE
    -->
    <define name="conference-rule-type">
        <ref name="role-type"/>
        <zeroOrMore>
     <optional>
      <element name="condition"> name="sidebars-by-ref">
       <ref name="condition-type"/> name="sidebars-by-ref-type"/>
      </element>
     </optional>
     <optional>
      <element name="action"> name="sidebars-by-val">
       <ref name="action-type"/> name="sidebars-by-val-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
        CONDITION
           CONFERENCE DESCRIPTION TYPE
       -->
    <define name="condition-type"> name="conference-description-type">
     <element name="conference-description">
      <ref name="role-type"/>
        <element name="identity">
      <optional>
       <attribute name="xml:lang">
        <data type="language"/>
       </attribute>
      </optional>
      <optional>
       <attribute name="state">
        <ref name="identity-type"/>
        </element> name="state-type"/>
       </attribute>
      </optional>
      <optional>
       <element name="validity">
            <ref name="validityType"/> name="display-text">
        <text/>
       </element>
    </define>
    <!--
        IDENTITY TYPE
    -->
    <define name="identity-type">
        <ref name="role-type"/>
      </optional>
      <optional>
       <element name="identity">
            <ref name="identityType"/> name="subject">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="free-text">
        <text/>



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


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

    <!--
        ROLES IDENTITY TYPE
    -->
    <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/>                 March 2007


       </element>
      </optional>
      <optional>
       <element name="has-been-invited">
                <text/> name="keywords">
        <list>
         <zeroOrMore>
          <data type="string"/>
         </zeroOrMore>
        </list>
       </element>
      </optional>
      <optional>
       <element name="has-been-in-conference">
                <text/> name="allow-sidebars">
        <data type="boolean"/>
       </element>
      </optional>
      <optional>
       <element name="is-in-conference">
                <text/> name="conference-time">
        <ref name="conferencetime-type"/>
       </element>
      </optional>
      <optional>
       <element name="administrator">
                <text/> name="conf-uris">
        <ref name="uris-type"/>
       </element>
      </optional>
      <optional>
       <element name="is-on-allowed-users-list-dial-out">
                <text/> name="service-uris">
        <ref name="uris-type"/>
       </element>
      </optional>
      <optional>
       <element name="is-on-allowed-users-list-refer">
                <text/> name="maximum-user-count">
        <data type="int"/>
       </element>
      </optional>
      <optional>
       <element name="participant-passcode">
                <text/> name="available-media">
        <ref name="conference-media-type"/>
       </element>
            <element name="administrator-passcode">
                <text/>
      </optional>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </element>
        </choice>
    </define>
    <!--
           CONFERENCE TIME



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


    <!--
        ACTION TYPE                 March 2007


       -->
    <define name="action-type">
        <choice> name="conferencetime-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="allow-refer-users-dynamically">
                <data type="boolean"/> name="entry">
       <optional>
        <element name="base">
         <text/>
        </element>
       </optional>
       <optional>
        <element name="allow-invite-users-dynamically"> name="mixing-start-offset">
         <data type="boolean"/> type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
         <attribute name="required-participant">
          <ref name="single-role-type"/>
         </attribute>
         <ref name="anyAttribute"/>
        </element>
       </optional>
       <optional>
        <element name="allow-remove-users-dynamically"> name="mixing-end-offset">
         <data type="boolean"/> type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
         <attribute name="required-participant">
          <ref name="single-role-type"/>
         </attribute>
         <ref name="anyAttribute"/>
        </element>
       </optional>
       <optional>
        <element name="show-floor-holder">
                <ref name="floor-request-type"/> name="can-join-after-offset">
         <data type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
        </element>
       </optional>
       <optional>
        <element name="show-floor-request"> name="must-join-before-offset">
         <data type="boolean"/> type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
        </element>
       </optional>
       <optional>
        <element name="provide-anonymity"> name="notify-end-of-conference">



Novo, et al.            Expires September 4, 2007              [Page 47]

Internet-Draft              Data Model Schema                 March 2007


         <data type="boolean"/> type="int"/>
        </element>
       </optional>
       <optional>
        <element name="read-only"> name="allowed-extend-mixing-end-offset">
         <ref name="single-role-type"/> name="allowed-extend-mixing-values"/>
        </element>
            <element name="read-write">
       </optional>
       <zeroOrMore>
        <ref name="single-role-type"/> name="anyElement"/>
       </zeroOrMore>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ALLOWED EXTEND MIXING VALUES
       -->
    <define name="allowed-extend-mixing-values">
     <choice>
      <value type="string">allowed</value>
      <value type="string">denied</value>
     </choice>
    </define>
    <!--
        USER
           URIS TYPE
       -->
    <define name="user-type"> name="uris-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <interleave>
      <zeroOrMore>
       <element name="user"> name="entry">
        <ref name="one-user-type"/> name="uri-type"/>
       </element>
      </zeroOrMore>
    </define>
    <!--
        ONE USER TYPE
      <zeroOrMore>
       <element name="H323">
        <ref name="H323-type"/>
       </element>
      </zeroOrMore>
      <zeroOrMore>



Novo, et al.            Expires April 13, September 4, 2007              [Page 40] 48]

Internet-Draft          Common Conference              Data Model Schema            October 2006                 March 2007


       <element name="PSTN-ISDN">
        <ref name="PSTN-type"/>
       </element>
      </zeroOrMore>
     </interleave>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           SIP TYPE
       -->
    <define name="one-user-type"> name="uri-type">
     <ref name="role-type"/>
        <attribute name="entity">
     <zeroOrMore>
      <element name="uri">
       <data type="anyURI"/>
        </attribute>
        <attribute name="state">
            <ref name="state-type"/>
        </attribute>
        <zeroOrMore>
      </element>
      <optional>
       <element name="display-text">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="associated-aors">
                <ref name="uris-type"/>
            </element>
            <element name="provide-anonymity">
                <data type="boolean"/> name="purpose">
        <text/>
       </element>
            <element name="roles">
      </optional>
      <zeroOrMore>
       <ref name="single-role-type"/>
            </element> name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           H323 TYPE
      -->
    <define name="H323-type">
     <ref name="role-type"/>
     <optional>
      <element name="languages">
                <list>
                    <data type="language"/>
                </list> name="H.323-alias">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="cascaded-focus"> name="H.323-URI">
       <data type="anyURI"/>
      </element>
            <element name="sphere">
     </optional>



Novo, et al.            Expires September 4, 2007              [Page 49]

Internet-Draft              Data Model Schema                 March 2007


     <zeroOrMore>
      <ref name="sphereType"/>
            </element>
            <element name="allow-refer-users-dynamically"> name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           PSTN TYPE
       -->
    <define name="PSTN-type">
     <ref name="role-type"/>
     <attribute name="PIN-code">
      <data type="boolean"/>
            </element> type="unsignedInt"/>
     </attribute>
     <attribute name="purpose">
      <data type="unsignedInt"/>
     </attribute>
     <oneOrMore>
      <element name="allow-invite-users-dynamically"> name="phone-number">
       <data type="boolean"/> type="unsignedInt"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </oneOrMore>
    </define>
    <!--
           BFCP TYPE
       -->
    <define name="BFCP-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="allow-remove-users-dynamically"> name="conference-ID">
       <data type="boolean"/> type="unsignedInt"/>
      </element>
            <element name="endpoint">
      <zeroOrMore>
       <ref name="endpoint-type"/>
            </element> name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           MAXIMUM USER TYPE
       -->
    <define name="maximum-user-count-type">
     <ref name="role-type"/>
     <ref name="anyAttribute"/>
     <oneOrMore>
      <element name="entry">
       <data type="unsignedInt"/>
       <attribute name="role">



Novo, et al.            Expires April 13, September 4, 2007              [Page 41] 50]

Internet-Draft          Common Conference              Data Model Schema            October 2006                 March 2007


        <ref name="single-role-type"/>
       </attribute>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </oneOrMore>
    </define>
    <!--
        ENDPOINT
           CONFERENCE MEDIA TYPE
       -->
    <define name="endpoint-type"> name="conference-media-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="entity">
            <text/> name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <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"> name="entry">
       <ref name="media-type"/> name="conference-medium-type"/>
      </element>
            <element name="call-info">
     </zeroOrMore>
     <zeroOrMore>
      <ref name="call-type"/>
            </element> name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
        MEDIA
           CONFERENCE MEDIUM TYPE
       -->
    <define name="media-type"> name="conference-medium-type">
     <ref name="role-type"/>
     <attribute name="id"> name="label">
      <text/>
     </attribute>
        <zeroOrMore>
     <optional>
      <element name="display-text">



Novo, et al.             Expires April 13, 2007                [Page 42]

Internet-Draft          Common Conference Schema            October 2006
       <text/>
      </element>
     </optional>
     <optional>
      <element name="type">
       <text/>
      </element>
            <element name="label">
                <text/>
            </element>
            <element name="src-id">
                <text/>
            </element>
     </optional>
     <optional>
      <element name="status">
       <ref name="media-status-type"/>



Novo, et al.            Expires September 4, 2007              [Page 51]

Internet-Draft              Data Model Schema                 March 2007


      </element>
     </optional>
     <optional>
      <element name="to-mixer"> name="mixing-mode">
       <ref name="mixer-type"/> name="mix-mode-type"/>
      </element>
     </optional>
     <optional>
      <element name="from-mixer">
                <ref name="mixer-type"/> name="mix-level">
       <data type="unsignedInt"/>
      </element>
        </zeroOrMore>
    </define>
    <!--
        MIXER TYPE
    -->
    <define name="mixer-type">
        <ref name="role-type"/>
     </optional>
     <optional>
      <element name="floor">
                <data type="boolean"/> name="codecs">
       <ref name="codecs-type"/>
      </element>
     </optional>
     <optional>
      <element name="controls">
       <ref name="control-type"/> name="controls-type"/>
      </element>
     </optional>
    </define>

    <!--
        SIDEBARS-BY-REF TYPE
    -->
    <define name="sidebars-by-ref-type">
        <ref name="role-type"/>
     <zeroOrMore>
            <element name="entry">
      <ref name="uri-type"/>
            </element> name="anyElement"/>
     </zeroOrMore>
    </define>



Novo, et al.             Expires April 13, 2007                [Page 43]

Internet-Draft          Common Conference Schema            October 2006
    <!--
        SIDEBARS-BY-VAL
           CONTROLS TYPE
       -->
    <define name="sidebars-by-val-type"> name="controls-type">
     <ref name="role-type"/>
        <zeroOrMore>
            <element name="entry">
     <optional>
      <attribute name="state">
       <ref name="conference-type"/>
            </element>
        </zeroOrMore>
    </define>

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

    <!--
       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"> name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="when">
                <data type="int"/>
            </element>
            <element name="reason">
                <data type="string"/>
            </element>
            <element name="by">
                <data type="anyURI"/> name="control">
       <ref name="control-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           MIX MODE TYPE
       -->



Novo, et al.            Expires April 13, September 4, 2007              [Page 44] 52]

Internet-Draft          Common Conference              Data Model Schema            October 2006                 March 2007


    <define name="mix-mode-type">
     <choice>
      <value type="string">moderator-controlled</value>
      <value type="string">FCFS</value>
      <value type="string">automatic</value>
     </choice>
    </define>
    <!--
        CALL
           CODECS TYPE
       -->
    <define name="call-type"> name="codecs-type">
     <ref name="role-type"/>
     <attribute name="decision">
      <ref name="decision-type"/>
     </attribute>
     <zeroOrMore>
      <element name="sip"> name="codec">
       <ref name="sip-dialog-id-type"/> name="codec-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
        SIP DIALOG ID
           CODEC TYPE
       -->
    <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"> name="codec-type">
     <ref name="role-type"/>
     <attribute name="name">
      <text/>
            </element>
        </zeroOrMore>
     </attribute>
     <attribute name="policy">
      <ref name="policy-type"/>
     </attribute>
    </define>
    <!--
        DISCONNECTION
           DECISION TYPE
       -->
    <define name="disconnection-type"> name="decision-type">
     <choice>
      <value type="string">departed</value>
            <value type="string">booted</value> type="string">automatic</value>
      <value type="string">failed</value>
            <value type="string">busy</value> type="string">moderator-controlled</value>
     </choice>
    </define>
    <!--
        JOINING
           POLICY TYPE
       -->



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


    -->                 March 2007


    <define name="joining-type"> name="policy-type">
     <choice>
      <value type="string">dialed-in</value> type="string">allowed</value>
      <value type="string">dialed-out</value>
            <value type="string">focus-owner</value> type="string">disallowed</value>
     </choice>
    </define>
    <!--
       ENDPOINT STATUS
           CONTROL TYPE
       -->
    <define name="endpoint-status-type"> name="control-type">
     <choice>
      <element name="mute">
       <data type="boolean"/>
      </element>
      <element name="pause-video">
       <data type="boolean"/>
      </element>
      <element name="gain">
       <data type="int">
        <param name="minInclusive">-127</param>
        <param name="maxInclusive">127</param>
       </data>
      </element>
      <element name="video-layout">
       <choice>
        <value type="string">pending</value>
            <value type="string">dialing-out</value>
            <value type="string">dialing-in</value> type="string">single-view</value>
        <value type="string">alerting</value> type="string">dual-view</value>
        <value type="string">on-hold</value> type="string">dual-view-crop</value>
        <value type="string">connected</value> type="string">dual-view-2x1</value>
        <value type="string">muted-via-focus</value> type="string">dual-view-2x1-crop</value>
        <value type="string">disconnecting</value> type="string">quad-view</value>
        <value type="string">disconnected</value>
        </choice>
    </define>

    <!--
        STATE TYPE
    -->

    <define name="state-type">
        <choice> type="string">multiple-3x3</value>
        <value type="string">full</value> type="string">multiple-4x4</value>
        <value type="string">partial</value> type="string">multiple-5x1</value>
        <value type="string">deleted</value> type="string">automatic</value>
       </choice>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </choice>
    </define>
    <!--
        ***********************************************
        TYPE DEFINED IN THE ROLE DOCUMENT
        ***********************************************
    -->

    <!--
        ROLE
           HOST TYPE
       -->
    <define name="host-type">
     <ref name="role-type"/>
     <zeroOrMore>



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


    <define name="role-type">
        <attribute name="read-only">                 March 2007


      <element name="display-text">
       <text/>
      </element>
      <element name="web-page">
       <data type="anyURI"/>
      </element>
      <element name="uris">
       <ref name="single-role-type"/>
        </attribute>

        <attribute name="write-only"> name="uris-type"/>
      </element>
      <zeroOrMore>
       <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> name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
        ************************************************************
        TYPE DEFINED IN THE COMMON POLICY DOCUMENT
        ************************************************************
    -->


    <!--
       VALIDITY
           CONFERENCE STATE TYPE
       -->
    <define name="validityType">
        <choice> name="conference-state-type">
     <ref name="role-type"/>
     <optional>
      <element name="from"> name="allow-conference-event-subscription">
       <data type="int"/> type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="until"> name="user-count">
       <data type="int"/> type="unsignedInt"/>
      </element>
        </choice>
     </optional>
     <optional>
      <element name="active">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="locked">
       <data type="boolean"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
        ONE
           FLOOR INFORMATION TYPE
       -->
    <define name="floor-information-type">
     <ref name="role-type"/>



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


    -->
    <define name="oneType">
        <attribute name="id">                 March 2007


     <zeroOrMore>
      <element name="conference-ID">
       <ref name="BFCP-type"/>
      </element>
      <element name="allow-floor-events">
       <data type="anyURI"/>
        </attribute> 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>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
        MANY
           FLOOR REQUEST TYPE
       -->
    <define name="manyType"> name="floor-request-type">
     <choice>
            <element name="except">
                <ref name="exceptType"/>
            </element>
      <value type="string">block</value>
      <value type="string">confirm</value>
     </choice>
        <attribute name="domain">
            <text/>
        </attribute>
    </define>
    <!--
           CONFERENCE FLOOR POLICY
       -->
    <define name="exceptType">
        <attribute name="domain">
            <text/>
        </attribute> name="Conference-floor-policy">
     <ref name="role-type"/>
     <oneOrMore>
      <element name="floor">
       <attribute name="id"> name="moderator-controlled">
        <data type="anyURI"/> type="boolean"/>
       </attribute>
    </define>

    <!--
      SPHERE TYPE
    -->
    <define name="sphereType">
       <attribute name="value"> name="label">
        <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
       <ref name="anyAttribute"/>
       <zeroOrMore>
        <element name="media-types">
         <ref name="role-type"/>
         <choice>
          <value type="string">video</value>
          <value type="string">audio</value>
          <value type="string">application</value>



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


   an extension is accomplished by defining elements, child elements and
   attributes that are specific to the desired application domain.  Each
   extension MUST define its own namespace.  Points of extension MUST be
   defined in the schema, and SHOULD be done using the <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">                 March 2007


          <value type="string">data</value>
          <value type="string">control</value>
          <value type="string">message</value>
          <value type="string">text</value>
         </choice>
        </element>
        <element name="algorithm">
         <ref name="role-type"/>
         <choice>
          <value type="string">moderator-controlled</value>
          <value type="string">FCFS</value>
          <value type="string">random</value>
         </choice>
        </element>
        <element name="max-floor-users">
         <data type="nonNegativeInteger"/>
        </element>
        <element name="chair-id">
         <data type="anyURI"/>
        </element>
        <zeroOrMore>
         <ref name="anyElement"/>
        </zeroOrMore>
       </zeroOrMore>
      </element>
     </oneOrMore>
    </define>
    <!--
        CONFERENCE DESCRIPTION
           USERS TYPE
       -->
       <info:conference-description xml:lang="en-us">
        <info:display-text>Discussion of 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>
        <security-level>low</security-level>
        <allow-sidebars>true</allow-sidebars>
        <conference-stage>running</conference-stage>
    <define name="users-type">
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <ref name="role-type"/>
     <optional>
      <element name="join-handling">
       <ref name="join-handling-type"/>
      </element>
     </optional>
     <optional>
      <element name="user-admission-policy">
       <ref name="user-admission-policy-type"/>
      </element>
     </optional>
     <optional>



Novo, et al.            Expires September 4, 2007              [Page 57]

Internet-Draft              Data Model Schema                 March 2007


      <element name="user-must-be-specified">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="allowed-users-list">
       <ref name="UserList"/>
      </element>
     </optional>
     <zeroOrMore>
      <element name="user">
       <ref name="user-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
        CONFERENCE TIME
           USERS ADMISSION POLICY
       -->
        <conference-time>
         <entry>
          <base>BEGIN:VCALENDAR
    <define name="user-admission-policy-type">
     <choice>
      <value type="string">closedAuthenticated</value>
      <value type="string">openAuthenticated</value>
      <value type="string">anonymous</value>
     </choice>
    </define>
    <!--
           JOIN HANDLING TYPE
       -->
    <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>
     </choice>
    </define>
    <!--
           USERLIST
       -->
    <define name="UserList">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="target">
       <ref name="target-type"/>



Novo, et al.            Expires April 13, September 4, 2007              [Page 49] 58]

Internet-Draft          Common Conference              Data Model Schema            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>

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


      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
        CONFERENCE UNIQUE IDENTIFIERS
           TARGET TYPE
       -->
        <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>
    <define name="target-type">
     <ref name="role-type"/>
     <attribute name="uri">
      <data type="anyURI"/>
     </attribute>
     <attribute name="method">
      <ref name="method-type"/>
     </attribute>
    </define>
    <!--
          SERVICE URIS
           METHOD TYPE
       -->
        <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>
    <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 COUNT TYPE
       -->
        <maximum-user-count>
         <entry role = "administrator">2</entry>
         <entry role = "moderator">5</entry>
         <entry role = "participant">150</entry>
    <define name="user-type">
     <ref name="role-type"/>
     <attribute name="entity">
      <data type="anyURI"/>
     </attribute>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="associated-aors">



Novo, et al.            Expires April 13, September 4, 2007              [Page 50] 59]

Internet-Draft          Common Conference              Data Model Schema            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>
          <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>
          <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/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<                 March 2007


       <ref name="uris-type"/>
      </element>
     </optional>
     <optional>
      <element name="provide-anonymity">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="roles">
       <ref name="roles-type"/>
      </element>
     </optional>
     <optional>
      <element name="languages">
       <list>
        <data type="language"/>
       </list>
      </element>
     </optional>
     <optional>
      <element name="cascaded-focus">
       <data type="anyURI"/>
      </element>
     </optional>
     <optional>
      <element name="allow-refer-users-dynamically">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="allow-invite-users-dynamically">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="allow-remove-users-dynamically">
       <data type="boolean"/>
      </element>
     </optional>
     <zeroOrMore>
      <element name="endpoint">
       <ref name="endpoint-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>



Novo, et al.            Expires April 13, September 4, 2007              [Page 51] 60]

Internet-Draft          Common Conference              Data Model Schema            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>
      <!--
        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>
       </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<
        /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>                 March 2007


    </define>
    <!--
          PRIVILEGES CONTROL LIST
           ENDPOINT TYPE
       -->
        <privileges-control-list>
         <conference-rules>
          <entry id="1">
    <define name="endpoint-type">
     <ref name="role-type"/>
     <attribute name="entity">
      <text/>
     </attribute>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="referred">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <optional>
      <element name="status">
       <ref name="endpoint-status-type"/>
      </element>
     </optional>
     <optional>
      <element name="joining-method">
       <ref name="joining-type"/>
      </element>
     </optional>
     <optional>
      <element name="joining-info">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <optional>
      <element name="disconnection-method">
       <ref name="disconnection-type"/>
      </element>
     </optional>



Novo, et al.            Expires April 13, September 4, 2007              [Page 52] 61]

Internet-Draft          Common Conference              Data Model Schema            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: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>                 March 2007


     <optional>
      <element name="disconnection-info">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <zeroOrMore>
      <element name="media">
       <ref name="media-type"/>
      </element>
     </zeroOrMore>
     <optional>
      <element name="call-info">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
          USER
           MEDIA TYPE
       -->
        <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<
    <define name="media-type">
     <attribute name="id">
      <data type="int"/>
     </attribute>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <ref name="anyAttribute"/>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="type">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="label">



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


         /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>                 March 2007


       <text/>
      </element>
     </optional>
     <optional>
      <element name="src-id">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="status">
       <ref name="media-status-type"/>
      </element>
     </optional>
     <optional>
      <element name="to-mixer">
       <ref name="mixer-type"/>
      </element>
     </optional>
     <optional>
      <element name="from-mixer">
       <ref name="mixer-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
          USER
           MIXER TYPE
       -->
        <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>
    <define name="mixer-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <optional>
      <element name="floor">
       <data type="boolean"/>
      </element>
      <element name="controls">
       <ref name="controls-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>



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


         </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>                 March 2007


    </define>
    <!--
          ENDPOINTS
           SIDEBARS-BY-REF TYPE
       -->
         <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>
    <define name="sidebars-by-ref-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="entry">
       <ref name="uri-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           MEDIA
           SIDEBARS-BY-VAL TYPE
       -->
          <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>
    <define name="sidebars-by-val-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="entry">
       <ref name="conference-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
            CALL INFO
           ROLES_TYPE
       -->
          <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>
    <define name="roles-type">
     <zeroOrMore>
      <element name="entry">
       <ref name="single-role-type"/>
      </element>
     </zeroOrMore>



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


          </info:call-info>
         </info:endpoint>
        </info:user>                 March 2007


     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
          USER
           ROLE TYPE
       -->
        <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>
    <define name="role-type">
     <optional>
      <attribute name="read-only">
       <ref name="single-role-type"/>
      </attribute>
     </optional>
     <optional>
      <attribute name="write-only">
       <ref name="single-role-type"/>
      </attribute>
     </optional>
     <ref name="anyAttribute"/>
    </define>
    <!--
          ENDPOINTS
           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>
    <!--
           *********************************
           EXTENSIBILITY OF THE SCHEMA
           *********************************
       -->
         <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
           EXTENSIBILITY ELEMENTS
       -->
          <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>
    <define name="anyElement">
     <element>
      <anyName/>
      <zeroOrMore>
       <choice>
        <attribute>
         <anyName/>
        </attribute>



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


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


        <text/>
        <ref name="anyElement"/>
       </choice>
      </zeroOrMore>
     </element>
    </define>
    <!--
         SIDEBARS BY REFERENCE
           EXTENSIBILITY ATTRIBUTES
       -->
       <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>
    <define name="anyAttribute">
     <zeroOrMore>
      <attribute>
       <anyName>
        <except>
         <name ns="">entity</name>
         <name ns="">version</name>
         <name ns="">state</name>
         <name ns="">xml:lang</name>
         <name ns="">required-participant</name>
         <name ns="">PIN-code</name>
         <name ns="">purpose</name>
         <name ns="">role</name>
         <name ns="">type</name>
         <name ns="">min</name>
         <name ns="">max</name>
         <name ns="">label</name>
         <name ns="">decision</name>
         <name ns="">name</name>
         <name ns="">policy</name>
         <name ns="">moderator-controlled</name>
         <name ns="">uri</name>
         <name ns="">method</name>
         <name ns="">id</name>
         <name ns="">domain</name>
         <name ns="">read-only</name>
         <name ns="">write-only</name>
         <nsName ns=""/>
         <nsName ns="urn:ietf:params:xml:ns:conference-schema"/>
        </except>
       </anyName>
       <text/>
      </attribute>
     </zeroOrMore>
    </define>
    <!--
         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
   characters mark where the lines folding has taken place.  These
   backslash would not appear in the actual XML data model.
           *************************************************************
           TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
           *************************************************************



Novo, et al.            Expires April 13, September 4, 2007              [Page 57] 66]

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, Jari 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., "A Framework and Schema                 March 2007


       -->
    <!--
           WILDCARD FOR EVENT-PACKAGE NAMESPACE
       -->
    <define name="conference-info-urn">
     <element>
      <anyName>
       <except>
        <nsName ns="urn:ietf:params:xml:ns:conference-info-urn"/>
        <nsName ns=""/>
       </except>
      </anyName>
      <mixed>
       <zeroOrMore>
        <choice>
         <attribute>
          <anyName/>
         </attribute>
         <ref name="conference-info-urn"/>
        </choice>
       </zeroOrMore>
      </mixed>
     </element>
    </define>
    <!--
           DEFINITION OF STATE TYPE
       -->
    <define name="state-type">
     <choice>
      <value>full</value>
      <value>partial</value>
      <value>deleted</value>
     </choice>
    </define>
    <!--
           DEFINITION OF ENDPOINT STATUS TYPE
       -->
    <define name="media-status-type">
     <choice>
      <value>recvonly</value>
      <value>sendonly</value>
      <value>sendrecv</value>
      <value>inactive</value>
     </choice>
    </define>
    <!--
           ENDPOINT STATUS TYPE
       -->



Novo, et al.            Expires September 4, 2007              [Page 67]

Internet-Draft              Data Model for Centralized
        Conferencing", draft-ietf-xcon-framework-05 (work in progress),
        September 2006.

   [2]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
        Initiation Protocol (SIP) Event Package for Conference State",
        RFC 4575, August 2006.

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

   [4]  Rosenberg, J., "A Framework for Conferencing with the Session
        Initiation Protocol (SIP)", RFC 4353, February 2006.

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


    <define name="endpoint-status-type">
     <choice>
      <value>pending</value>
      <value>dialing-out</value>
      <value>dialing-in</value>
      <value>alerting</value>
      <value>on-hold</value>
      <value>connected</value>
      <value>muted-via-focus</value>
      <value>disconnecting</value>
      <value>disconnected</value>
     </choice>
    </define>
    <!--
           JOINING TYPE
       -->
    <define name="joining-type">
     <choice>
      <value>dialed-in</value>
      <value>dialed-out</value>
      <value>focus-owner</value>
     </choice>
    </define>
    <!--
           DISCONNECTION TYPE
       -->
    <define name="disconnection-type">
     <choice>
      <value>departed</value>
      <value>booted</value>
      <value>failed</value>
      <value>busy</value>
     </choice>
    </define>
    <!--
           ******************************************
           TYPE DEFINED IN THE COMMON POLICY DOCUMENT
           ******************************************
       -->
    <!--
           WILDCARD FOR COMMON-POLICY NAMESPACE
       -->
    <define name="common-policy">
     <element>
      <anyName>
       <except>
        <nsName ns="urn:ietf:params:xml:ns:common-policy"/>
        <nsName ns=""/>



Novo, et al.            Expires April 13, September 4, 2007              [Page 58] 68]

Internet-Draft          Common Conference              Data Model Schema            October 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]  Schulzrinne, H., "Common Policy: A Document Format for
        Expressing Privacy Preferences",
        draft-ietf-geopriv-common-policy-11 (work in progress),
        August 2006.

   [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.                 March 2007


       </except>
      </anyName>
      <mixed>
       <zeroOrMore>
        <choice>
         <attribute>
          <anyName/>
         </attribute>
         <ref name="common-policy"/>
        </choice>
       </zeroOrMore>
      </mixed>
     </element>
    </define>
   </grammar>



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 V3C
   Boston, MA  02109-3614
   USA

   Email: Dave.Morgan@fmr.com






Novo, et al.            Expires April 13, September 4, 2007              [Page 59] 69]

Internet-Draft          Common Conference              Data Model Schema            October 2006                 March 2007


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   Email: roni.even@polycom.co.il












































Novo, et al.            Expires April 13, September 4, 2007              [Page 60] 70]

Internet-Draft          Common Conference              Data Model Schema            October 2006                 March 2007


Full Copyright Statement

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

   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 SOCIETY, THE IETF TRUST 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

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Novo, et al.            Expires April 13, September 4, 2007              [Page 61] 71]


----