XCON                                                             O. Novo
Internet-Draft                                              G. Camarillo
Intended status: Informational                                  Ericsson
Expires: September 4, 2007                                     D. Morgan
                                                    Fidelity Investments
                                                                 R. Even
                                                                 Polycom
                                                           March 3, 2007


 Conference Information Data Model for Centralized Conferencing (XCON)
                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 September 4, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines an Extensible Markup Language (XML)-based
   conference 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 September 4, 2007               [Page 1]

Internet-Draft              Data Model Schema                 March 2007


   particular instantiation of this data model.  The conference
   information data model defined in this document is an extension of
   (and thus, compatible with) the model specified in 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  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Data Model Structure . . . . . . . . . . . . . . . . . . .  6
     3.2.  Conference Policies  . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  Role Definitions . . . . . . . . . . . . . . . . . . .  8
         3.2.1.1.  Role in a Floor  . . . . . . . . . . . . . . . . .  8
         3.2.1.2.  Changing Roles . . . . . . . . . . . . . . . . . .  9
   4.  Data Model Definition  . . . . . . . . . . . . . . . . . . . .  9
     4.1.  <conference-description> . . . . . . . . . . . . . . . . . 13
       4.1.1.  <conference-time>  . . . . . . . . . . . . . . . . . . 14
       4.1.2.  <conf-uris>  . . . . . . . . . . . . . . . . . . . . . 15
       4.1.3.  <service-uris> . . . . . . . . . . . . . . . . . . . . 16
       4.1.4.  <maximum-user-count> . . . . . . . . . . . . . . . . . 16
       4.1.5.  <available-media>  . . . . . . . . . . . . . . . . . . 16
         4.1.5.1.  <controls> . . . . . . . . . . . . . . . . . . . . 17
           4.1.5.1.1.  mute . . . . . . . . . . . . . . . . . . . . . 17
           4.1.5.1.2.  pause-video  . . . . . . . . . . . . . . . . . 17
           4.1.5.1.3.  gain . . . . . . . . . . . . . . . . . . . . . 18
           4.1.5.1.4.  video-layout . . . . . . . . . . . . . . . . . 18
     4.2.  <host-info>  . . . . . . . . . . . . . . . . . . . . . . . 19
     4.3.  <conference-state> . . . . . . . . . . . . . . . . . . . . 19
     4.4.  <floor-information>  . . . . . . . . . . . . . . . . . . . 19
     4.5.  <users>  . . . . . . . . . . . . . . . . . . . . . . . . . 21
       4.5.1.  <allowed-users-list> . . . . . . . . . . . . . . . . . 22
       4.5.2.  <user> . . . . . . . . . . . . . . . . . . . . . . . . 22
         4.5.2.1.  <from-mixer>, <to-mixer> . . . . . . . . . . . . . 23
           4.5.2.1.1.  <floor>  . . . . . . . . . . . . . . . . . . . 23
       4.5.3.  <sidebars-by-ref>  . . . . . . . . . . . . . . . . . . 24
       4.5.4.  <sidebars-by-val>  . . . . . . . . . . . . . . . . . . 24
   5.  RELAX NG Schema  . . . . . . . . . . . . . . . . . . . . . . . 24
   6.  XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 33
   7.  XML Example  . . . . . . . . . . . . . . . . . . . . . . . . . 33
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 42
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 42
     9.1.  Conference Relax NG Schema Registration  . . . . . . . . . 42
     9.2.  Conference Namespace Registration  . . . . . . . . . . . . 43
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
     11.2. Informative References . . . . . . . . . . . . . . . . . . 43
   Appendix A.  Appendix A.  Non-Normative RELAX NG Schema in XML
                Syntax  . . . . . . . . . . . . . . . . . . . . . . . 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
   Intellectual Property and Copyright Statements . . . . . . . . . . 71




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


1.  Introduction

   Conference objects are a fundamental concept in Centralized
   conferencing, as described in the XCON Conferencing Framework [1].  A
   conference object contains data that represents a conference during
   each of its various stages (e.g., reserved, started, running, ended,
   etc.).  Conference Objects are instantiations of the conference
   information data model defined in this document.  Consequently,
   conference objects follow the XML format defined in this document.

   A conference object contains the core information of a conference
   (i.e., capabilities, membership, roles, call control signaling,
   media, etc.) and specifies who, and in which way, can manipulate that
   information.

   Figure 1 shows logical functional elements of a conference server as
   defined by the XCON Conferencing Framework [1].  They are a
   Conference Control Server, a Floor Control Server, a number of Foci,
   and a Notification Service.  A conference control protocol provides
   the interface between a conference and media control client, and the
   conference control server.  A floor control protocol (e.g., BFCP [7])
   provides the interface between a floor control client and the floor
   control server.  A call signaling protocol (e.g., SIP, H.323, PSTN,
   etc.) provides the interface between a call signaling client and a
   Focus.  A notification protocol (e.g., SIP-based event notifications
   [8]) provides the interface between the conferencing client and the
   Notification Service.  Within a conference, the conference control
   server, floor control server, and focus can modify the information in
   the conference object.






















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


      ...............................................................
      . Conferencing Server                                         .
      .       +---------------------------------------------------+ .
      .       |       C o n f e r e n c e   o b j e c t           | .
      .     +-+--------------------------------------------------+| .
      .     |       C o n f e r e n c e   o b j e c t            || .
      .   +-+---------------------------------------------------+|| .
      .   |       C o n f e r e n c e   o b j e c t             ||| .
      .   | +--------------------------------------------------+||| .
      .   | | Conference Information Data Model                |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | | Conference description  (times, duration)    | |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | | Host information                             | |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | | Conference state                             | |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | | Floor information                            | |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | | Membership (users, roles, capacity)          | |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | | Sidebars, Etc.                               | |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | +----------------------------------------------+ |||| .
      .   | | | Etc.                                         | |||| .
      .   | | +----------------------------------------------+ |||+ .
      .   | +--------------------------------------------------+|+  .
      .   +----^------------------^-------------^--------|------+   .
      .        |                  |             |        |          .
      . +------v-------+ +--------v-----+ +-----v-+ +----v-------+  .
      . | Conference   | | Floor        | |       | |            |  .
      . | Control      | | Control      | |Foci   | |Notification|  .
      . | Server       | | Server       | |       | |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 September 4, 2007               [Page 5]

Internet-Draft              Data Model Schema                 March 2007


   The Session Initiation Protocol (SIP) Event Package for Conference
   State, specified in RFC 4575 [2], already defines a data model for
   conferences.  However, that model is SIP specific and lacks elements
   related to some of the functionality defined by the XCON conferencing
   framework [1] (e.g., floor control).  The data model defined in this
   document extends the one defined in RFC 4575 [2].  The result is a
   data model that supports more call signaling protocols besides SIP
   and that covers all the functionality defined in the XCON
   conferencing 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 described in RFC 2119 [3].

   This document uses the terminology defined in the XCON Conferencing
   Framework [1], the SIP conferencing framework [4] and the BFCP
   (Binary Floor Control Protocol) specification [7].  Readers of this
   document are supposed to be familiar with the terminology used in
   those documents.


3.  Overview

   The data model defined in this document is the result of extending
   the 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 used by conference servers providing different
   types of basic conferences.  It is expected that this data model can
   be further extended with new elements in the future in order to
   implement advanced features.

3.1.  Data Model Structure

   The information in this data model is structured in the following
   manner.  All the information related to a conference is contained in
   a <conference-info> element.  The <conference-info> element contains
   the following child elements:
   o  The <conference-description> element describes the conference as a
      whole.  It has, for instance, information about the URI of the
      conference, maximum users allowed in the conference, media
      available in the conference, or the time the conference will
      start.
   o  The <host-info> element contains information about the entity
      hosting the conference (e.g., its URI).




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


   o  The <conference-state> element informs the subscribers about the
      changes in the overall conference information.
   o  The <floor-information> element contains information about the
      status of the different floors in the conference.
   o  The <users> element describes the membership information as a
      whole.  The <users> element contains a set of <user> child
      elements, each describing a single participant in the conference.
   o  If a participant in the main conference joins a sidebar, a new
      element is created in the conference referenced from the
      <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 element they apply to.

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

   The set of rights describes the read/write access privileges for the
   conference object data model as a whole.  Every element of the data
   model SHOULD define two attributes: the attribute 'read-only', and
   the attribute 'read-write'.  These attributes describes the read/
   write access privileges for accessing the Conference Object as a
   whole.  This is partially described in [1].  When the conferencing
   server receives a request to 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 and as a
   result it is determined if the requestor can access that element.
   The attributes specify the minimum requestor's role that can access
   or modify the element of the conference.  Requestors with a role with
   lower privileges as defined in Section 3.2.1 cannot access or modify
   the element.

   If an attribute is not defined in some element, the 'read-only'
   attribute MUST be interpreted as a "participant" role and the 'read-
   write' attribute MUST be interpreted as an "administrator" role by
   default.  It is possible to defined only one of the attributes of the
   element, the other attribute SHOULD be interpreted by default.  The
   next section defines conferencing roles that are used to represent
   participants within a Conference Object.  Additional roles may be
   defined in the future, as necessary, with their corresponding schema
   extensions, as appropriate.




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


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

   The policies and rights are an integral part of the data model, with
   elements containing the allowed ranges for other elements (e.g.,
   maximum number of participants) and lists of end-points allowed to
   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 scope of this document.  A Conference System
   MAY choose not to support a particular role.  As well, additional
   roles may be defined in the 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
   "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 "administrator" SHOULD have
   the ability to make changes to all conference variables during
   instantiation and full lifecycle of the Conference Object.  The
   "creator" is the 'owner' of the conference and has various privileges
   which SHOULD allow them to modify the conference variables up to the
   time the conference 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 provided Section 5.

4.1.  <conference-description>

   The <conference-description> element, which is defined in [2],
   describes the conference as a whole.  It SHOULD have an extra
   attribute 'xml:lang' to specify the language used in the contents of
   this element as defined in Section 2.12 of [5].  It is comprised of
   <display-text>, <subject>, <free-text>, <keywords>, <allow-sidebars>,
   <conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>,



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


   and <available-media>.

   The <display-text>, <subject>, <free-text> and <keywords> elements
   are defined in [2].  They are used to describe the conference's
   content.

   The child element <allow-sidebars> describes the capabilities of the
   conference.

   The <conference-time> child element contains information related to
   conference time and duration of the conference.  The <conf-uris> and
   <service-uris> are used to describe the conference-related
   identifiers.  The <maximum-user-count> child element indicates the
   number of users that can be invited to the conference.  The
   <available-media> child element is used to describe the media
   characteristics of the conference.

   The 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 information related to
   conference time and duration of a conference.  The <conference-time>
   element contains one or more <entry> elements each defining the time
   information specifying 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
   the time a conference media mixing stops after the conference stops.
   The <mixing-end-offset> child element expresses the offset as signed
   integers representing seconds before/after DTEND field.  The <mixing-
   start-offset> child element expresses the 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 mixing starts immediately.  If the <mixing-end-
   offset> element 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 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 latter of the mixing start time, and 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 September 4, 2007              [Page 14]

Internet-Draft              Data Model Schema                 March 2007


   privileged user to define when media mixing ends based on the earlier
   of the <mixing-end-offset>, and the time the last participant, or
   moderator leaves.  If the value is set to "none", mixing stops
   according to the <mixing-end-offset>.  If the conference policy was
   modified so that last privileged user 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 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 the <request-user> child element.
   It is possible to define the time when users or resources on the
   <allowed-users-list> is requested to join the conference by using the
   <request-users> element.  This element expresses the offset as signed
   integers representing seconds before/after DTSTART field.

   The <notify-end-of-conference> element defines in seconds when the
   system has to send a notification when the end of the conference is
   approaching.  If the <notify-end-of-conference> element is not
   present, it indicates that the system does not notify the users when
   the end of the conference is 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 the possibility to extend the
   conference.  It has two values: "allowed", "denied".

4.1.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: <entry>, <H.323>, and <PSTN-ISDN>.  The
   <entry> element refers to the SIP protocol.  It keeps the same name
   that is defined in [2] to maintain backwards compatibility with this
   RFC.  The <entry> element contains the <uri>, <display-text>, and
   <purpose> which are described in [2].  The currently defined
   <purpose> values to be used with the <conf-uris> are:
   o  participation: Accessing a URI with this <purpose> will bring the
      party into the conference




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


   o  streaming: Accessing a URI with this <purpose> will commence
      streaming the conference, but not allow active participation
   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 used and a 'purpose' attribute that
   describes to the user which phone number to 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 for the
   conference.  It contains a sequence of child elements: <entry>,
   <H.323>, <PSTN-ISDN>, and <BFCP>.  The <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 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 URI of the main conference
   Future extensions to this schema may define new values and register
   them with IANA.  These elements are described in [2]. <H.323>, and
   <PSTN-ISDN> child elements are described in the <conf-uris> section.

4.1.4.  <maximum-user-count>

   The <maximum-user-count> contains the overall number of users allowed
   to join the conference.  Note that this value is set by an
   administrator and 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 described in [2].  The <codecs> element
   specifies the allowed codecs in the conference.  It has an attribute
   'decision' that specifies if the focus decides the common codec
   automatically or needs the approval of the moderator of the
   conference ("automatic", "moderator-controlled").  The <codecs>
   element contains <entry> elements.  A <entry> element can have the



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 that
   codec (allowed, or disallowed).

   The child elements <mixing-mode> and <mix-level> describe a default
   policy by which the mixer will build the outgoing stream from the
   incoming streams.  Notice that this policy is 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 "4" in the <mix-level> element for video streams implies a
   2x2 layout).  The <mixing-mode> child element MUST contain one and
   only one of the "Moderator-controlled", "FCFS", and "Automatic"
   values indicating the default algorithm to be use with every media
   stream.  The next section explains the <controls> child element.

4.1.5.1.  <controls>

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

4.1.5.1.1.  mute

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

4.1.5.1.2.  pause-video

   The 'pause-video' control is used in conjunction with a video stream
   to cease transmission of associated media.  It has a "boolean" value.
   If this control is not specified, access to the control is not
   available to the client and media SHOULD NOT be transported for the
   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 used in conjunction with a media output stream
   to indicate the amount of amplification of an audio stream.  It has a
   "int" number value.  If this control is not specified, access to the
   control is not available to the client.

4.1.5.1.4.  video-layout

   The 'video-layout' control is used in conjunction with a video stream
   to specify how the video streams (participants) are viewed by each
   participant.  Only one layout type can be specified for each output
   stream.  If there are fewer participants than panels in the specified
   layout, then blanking (black screen) MAY be mixed into the stream on
   the behalf of the missing input streams.  If unspecified, the <video-
   layout> default type SHOULD be "single-view".

   The <layout> types are as follows:

   single-view: Only one stream is presented by the focus to all
   participants in one panel.

   dual-view: This dual view option will present the video side-by-side
   in 2 panels and not alter the aspect ratio of the streams.  This will
   require the focus to introduce blanking on parts of the overall image
   as viewed by the 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 one
   column.  In this option the aspect ratio is altered and the video
   streams are cropped.

   quad-view: Four equal-sized panels in a 2x2 layout is presented by
   the focus to all participants.  Typically the aspect ratio of the
   streams are maintained (alter-aspect-ratio= FALSE).

   multiple-3x3: Nine equal-sized panels in a 3x3 layout is presented by
   the focus to all participants.  Typically the aspect ratio of the



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


   streams are preserved.

   multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is presented
   by the focus to all participants.  Typically the aspect ratio of the
   streams are preserved.

   multiple-5x1: This option refers to a 5x1 layout where one panel will
   occupy 4/9 of the mixed video stream while the others will each
   occupy 1/9 of the stream.  Typically the aspect ratio of the streams
   is preserved.

   automatic: This option allows the focus to add panels as streams are
   added up to a limit of "panels".

4.2.  <host-info>

   The <host-info> element contains information about the entity hosting
   the conference.  This information is set before the conference
   activation, and is rarely changed during the conference 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 <PSTN-ISDN>.  The
   <entry> element refers to the SIP protocol.  It keeps the same name
   that is defined in [2] to maintain backwards compatibility with this
   RFC.  Future extensions to the <uris> element may define new values.

4.3.  <conference-state>

   The <conference-state> element and the <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 allow the
   subscription to conference state events, such as the SIP Event
   Package for Conference State [2].  If set to FALSE, the subscription
   to conference state events would be rejected.  If this element is
   undefined it has a default value of TRUE, causing the subscription to
   conference state events to be accepted.

4.4.  <floor-information>

   The <floor-information> element has the <conference-ID>, <allow-
   floor-events>, <floor-request-handling>, and <conference-floor-
   policy> child elements.  Other elements from different namespaces MAY
   be 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 does not have a
   floor.



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


   The <conference-ID> is used by a floor control server to provide a
   client with a conference ID.

   The <allow-floor-events> element represents a boolean action.  If set
   to TRUE, the focus is instructed to accept the subscription to floor
   control events.  If set to FALSE, the focus is instructed to reject
   the subscription.  If this element is undefined, it has a default
   value of FALSE, causing the subscription to floor control events to
   be rejected.

   The <floor-request-handling> element defines the actions used by the
   conference focus to control floor requests.  This element defines the
   action that the focus is to take when processing a particular request
   to a 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 to allow the request.
      The focus then uses the defined floor algorithm to further allow
      or deny the floor.  The algorithms used are outside the scope of
      this document.

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

   The <conference-floor-policy> element is mandatory and contains the
   required boolean attribute that indicates if the floor is moderator
   controlled or not.  One or more <floor> elements can appear in the
   <conference-floor-policy> element.  Every floor is defined using the
   'label' attribute.  If the <available-media> information is included
   in the conference document, the value of this attribute MUST be equal
   to the 'label' value of the corresponding media stream <entry> in the
   <available-media> container.  The number of those elements indicates
   how many floors the conference can have.  A floor can be used for one
   or more media types; the mandatory <media-types> element can contain
   zero or more of the <video>, <audio>, <application>, <data>
   ,<control>, <message>, and <text> elements indicating the media of
   the floor.  One type of media can only appear once.  Other media
   types can be defined by extensions.

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

   The <max-floor-users> child element in the <floor> element is



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


   optional and, if present, dictates the maximum number of users who
   can have the floor at one time.  The 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 <user> child elements.

   The <join-handling> element defines the actions used by the
   conference focus to control conference participation.  This element
   defines the action that the focus is to take when processing a
   particular request to join a conference.  This element defines values
   of:
   o  "block": This action instructs the focus to deny access to the
      conference.  This action is the default action taken in the
      absence of any other actions.
   o  "confirm": This action instructs the focus to place the
      participant on a pending list (e.g., by parking the call on a
      music-on-hold server), awaiting moderator input for further
      actions.
   o  "allow": This action instructs the focus to accept the conference
      join request and grant access to the conference within the
      instructions specified in the transformations of this rule.
   o  "IVR": This action instructs the focus that the user has to
      provide the PIN code.
   o  "directed-operator": This action instructs the focus to direct the
      user to an operator.

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

   The <user-admission-policy> is an element that lets an organizer (or
   a participant with appropriate rights) choose a policy for the
   conference that controls how users are allowed into the conference.
   A 'closedAuthenticated' policy requires each conference participant
   to be in the allowed users list (listed under the <allowed-users-
   list> XML element) with each participant being sufficiently (up to
   local policy) authenticated.  Conference join requests for users not
   in the allowed users list or participants not authenticated should be
   rejected unless a <join-handling> action of 'confirm' is selected in
   which case the user is placed on a 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 September 4, 2007              [Page 21]

Internet-Draft              Data Model Schema                 March 2007


   which participants can join the conference.  Typically this implies
   that anyone capable of authenticating with the conferencing system
   may join the conference.  An 'anonymous' policy allows any join
   requests in and is the least restrictive in policies.

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

4.5.1.  <allowed-users-list>

   The <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 invited to
   join a conference, or who the focus needs to "refer to" the
   conference.  The <allowed-users-list> element includes zero or more
   <target> child elements.  This child 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 a list with the following
   values: "dial-in", "dial-out", and "refer".  The value "dial-in" is
   used by the focus to determine who can join the conference.  The
   value "refer" is used by the focus to determine the resources that
   the focus needs to "refer to" the conference.  In SIP, this is
   achieved by the focus sending a REFER request to those potential
   participants.  In a different paradigm, this could also mean that the
   focus sends an SMS or an email to the referred user.  This list can
   be updated during the conference lifetime so it can be used for mid-
   conference refers as well.

   The "refer" value differs from the "dial-out" in that the "dial-out"
   contains a list of resources that the focus will initiate a session
   with.  The resources on the "refer" value, on the other hand, are
   expected to initiate the session establishment toward the focus
   themselves.  It is also envisioned that difference users will have
   different access rights to those lists and therefore a separation
   between the two is needed.

4.5.2.  <user>

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

   The following elements of <user> are defined in [2], section 5.6:
   <display-text>, <associated-aors>, <roles>, <languages>, <cascaded-
   focus>, and <endpoint>. <user> has two attributes: 'entity' and
   'state'.  The attribute 'state' is defined in [2], section 5.6.  The
   attribute 'entity' contains a unique conference user identifier.
   Other user identifiers can be associated with this conference user



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


   identifier and enable the conferencing system to correlate and map
   these multiple authenticated user identities to a single global user
   identifier.

   The <provide-anonymity> element provides anonymity to the user.  In
   this case, the focus provides to the rest of the participants an
   anonymous identity for that user, for example anonymousX.  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.

   The <endpoint> child element can provide the desired level of detail
   about the user's devices and their signaling sessions taking part in
   the conference and has the 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 <endpoint>/<media> element has two
   other child elements: <to-mixer>, and <from-mixer> described in the
   following section.

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

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

   Each of these elements have the <floor> and <controls> child
   elements.

4.5.2.1.1.  <floor>

   The <floor> 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 the floor from the chair of the
   conference.

   The <floor> element has a "Boolean" value.  A value of FALSE
   indicates that this user does not hold the floor in this moment.  If



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


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

4.5.3.  <sidebars-by-ref>

   The <sidebars-by-ref> element contains a set of <entry> child
   elements.  Each <entry> child element contains a <user> child element
   with a sidebar unique conference user identifier and a <display-text>
   child element.

4.5.4.  <sidebars-by-val>

   The <sidebars-by-val> element contains a set of <entry> child
   elements each containing information about a single sidebar.  By
   using this element, the server can include a full or partial
   description of each sidebar (as a sub-conference) in the body of the
   main conference document.


5.  RELAX NG Schema

   In accordance with the XCON framework document [1], the Conference
   Object is a logical representation of a conference instance.  The
   conference information schema contains core information that is
   utilized in any conference.  It also contains the variable
   information part of the 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 conference-description {
       role-type,
       attribute xml:lang { xsd:language }?,
       attribute state { state-type }?,
       element display-text { text }?,
       element subject { text }?,
       element free-text { text }?,
       element 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 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 September 4, 2007              [Page 25]

Internet-Draft              Data Model Schema                 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 H323 { H323-type }*
      & element PSTN-ISDN { PSTN-type }*),
     anyElement*
   # SIP TYPE
   uri-type =
     role-type,
     (element uri { xsd:anyURI },
      element display-text { text }?,
      element 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 type { text }?,
     element status { media-status-type }?,
     element mixing-mode { mix-mode-type }?,
     element mix-level { xsd:unsignedInt }?,
     element codecs { codecs-type }?,
     element controls { controls-type }?,
     anyElement*
   # CONTROLS TYPE
   controls-type =
     role-type,
     attribute state { state-type }?,
     element 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 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 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 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 allowed-users-list { UserList }?,
     element user { 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 September 4, 2007              [Page 29]

Internet-Draft              Data Model Schema                 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 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 { state-type }?,
     element display-text { text }?,
     element 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 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 src-id { text }?,
     element status { media-status-type }?,
     element 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 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 entry { single-role-type }*,
     anyElement*
   # ROLE TYPE
   role-type =
     attribute read-only { single-role-type }?,
     attribute 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 * {
       (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 * - 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 September 4, 2007              [Page 32]

Internet-Draft              Data Model Schema                 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 * - ns2:*  {
       mixed {
         (attribute * { text }
          | common-policy)*
       }
     }


6.  XML Schema Extensibility

   The Conference Information Data Model defined in this document is
   meant to be extensible toward specific application domains.  Such
   extensions are accomplished by defining elements, child elements and
   attributes that are specific to the desired application domain.  The
   IETF MAY extend the data model schema with extension elements from
   the 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 an example of a 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.



Novo, et al.            Expires 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">
      <!--
          CONFERENCE DESCRIPTION
      -->

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


              </SIP>
              <SIP>
                  <uri>http://www.example.comlive.ram</uri>
                  <purpose>streaming</purpose>
              </SIP>
          </conf-uris>
          <!--
            SERVICE URIS
          -->
          <service-uris state="full">
              <SIP>
                  <uri>http://www.example.com/formula1/</uri>
                  <purpose>web-page</purpose>
              </SIP>
          </service-uris>
          <!--
            MAXIMUM USER COUNT
          -->
          <maximum-user-count>
              <entry role="administrator">2</entry>
              <entry role="moderator">5</entry>
              <entry role="participant">150</entry>
          </maximum-user-count>
          <!--
            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 September 4, 2007              [Page 35]

Internet-Draft              Data Model Schema                 March 2007


      </conference-description>
      <!--
          HOST INFO
        -->
      <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>
      <!--
          USERS



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


        -->
      <users state="full">
          <join-handling>allow</join-handling>
          <!--
           ALLOWED USERS LIST
          -->
          <allowed-users-list>
              <target uri="sip:bob@example.com" method="dial-out"/>
              <target uri="sip:alice@example.com" method="dial-out"/>
              <target uri="sip:carol@example.com" method="dial-out"/>
              <target uri="sip:john@example.com" method="refer"/>
          </allowed-users-list>
          <!--
            PRIVILEGES CONTROL LIST
          -->
          <privileges-control-list>
              <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>
          <!--
            USER
          -->




Novo, et al.            Expires September 4, 2007              [Page 37]

Internet-Draft              Data Model Schema                 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>
              <!--
                  ENDPOINTS
              -->
              <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
                  -->
                  <media id="1">
                      <label>10235</label>
                      <src-id>432424</src-id>
                  </media>
                  <!--
                      CALL INFO
                  -->



Novo, et al.            Expires September 4, 2007              [Page 38]

Internet-Draft              Data Model Schema                 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>

          <!--
              USER
          -->

          <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>
              <!--
                  ENDPOINTS
              -->
              <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 September 4, 2007              [Page 39]

Internet-Draft              Data Model Schema                 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>
                  <!--
                      CALL INFO
                  -->
                  <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


              <!--
                  ENDPOINTS
              -->
              <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>
                  <!--
                      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>
                  <!--
                      CALL INFO
                  -->
                  <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 September 4, 2007              [Page 42]

Internet-Draft              Data Model Schema                 March 2007


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


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


Appendix A.  Appendix A.  Non-Normative RELAX NG Schema 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="conference-info">
      <ref name="conference-type"/>
     </element>
    </start>
    <!--
           CONFERENCE TYPE
       -->
    <define name="conference-type">
     <attribute name="entity">
      <text/>
     </attribute>
     <optional>
      <attribute name="version">
       <data type="unsignedInt"/>
      </attribute>
     </optional>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <ref name="role-type"/>
     <ref name="conference-description-type"/>
     <optional>
      <element name="host-info">
       <ref name="host-type"/>
      </element>
     </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 September 4, 2007              [Page 44]

Internet-Draft              Data Model Schema                 March 2007


      </element>
     </optional>
     <element name="users">
      <ref name="users-type"/>
     </element>
     <optional>
      <element name="sidebars-by-ref">
       <ref name="sidebars-by-ref-type"/>
      </element>
     </optional>
     <optional>
      <element name="sidebars-by-val">
       <ref name="sidebars-by-val-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CONFERENCE DESCRIPTION TYPE
       -->
    <define name="conference-description-type">
     <element name="conference-description">
      <ref name="role-type"/>
      <optional>
       <attribute name="xml:lang">
        <data type="language"/>
       </attribute>
      </optional>
      <optional>
       <attribute name="state">
        <ref name="state-type"/>
       </attribute>
      </optional>
      <optional>
       <element name="display-text">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="subject">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="free-text">
        <text/>



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


       </element>
      </optional>
      <optional>
       <element name="keywords">
        <list>
         <zeroOrMore>
          <data type="string"/>
         </zeroOrMore>
        </list>
       </element>
      </optional>
      <optional>
       <element name="allow-sidebars">
        <data type="boolean"/>
       </element>
      </optional>
      <optional>
       <element name="conference-time">
        <ref name="conferencetime-type"/>
       </element>
      </optional>
      <optional>
       <element name="conf-uris">
        <ref name="uris-type"/>
       </element>
      </optional>
      <optional>
       <element name="service-uris">
        <ref name="uris-type"/>
       </element>
      </optional>
      <optional>
       <element name="maximum-user-count">
        <data type="int"/>
       </element>
      </optional>
      <optional>
       <element name="available-media">
        <ref name="conference-media-type"/>
       </element>
      </optional>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </element>
    </define>
    <!--
           CONFERENCE TIME



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


       -->
    <define name="conferencetime-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="entry">
       <optional>
        <element name="base">
         <text/>
        </element>
       </optional>
       <optional>
        <element name="mixing-start-offset">
         <data 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="mixing-end-offset">
         <data 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="can-join-after-offset">
         <data type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
        </element>
       </optional>
       <optional>
        <element name="must-join-before-offset">
         <data type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
        </element>
       </optional>
       <optional>
        <element name="notify-end-of-conference">



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


         <data type="int"/>
        </element>
       </optional>
       <optional>
        <element name="allowed-extend-mixing-end-offset">
         <ref name="allowed-extend-mixing-values"/>
        </element>
       </optional>
       <zeroOrMore>
        <ref 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>
    <!--
           URIS TYPE
       -->
    <define name="uris-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <interleave>
      <zeroOrMore>
       <element name="entry">
        <ref name="uri-type"/>
       </element>
      </zeroOrMore>
      <zeroOrMore>
       <element name="H323">
        <ref name="H323-type"/>
       </element>
      </zeroOrMore>
      <zeroOrMore>



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


       <element name="PSTN-ISDN">
        <ref name="PSTN-type"/>
       </element>
      </zeroOrMore>
     </interleave>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           SIP TYPE
       -->
    <define name="uri-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="uri">
       <data type="anyURI"/>
      </element>
      <optional>
       <element name="display-text">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="purpose">
        <text/>
       </element>
      </optional>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           H323 TYPE
      -->
    <define name="H323-type">
     <ref name="role-type"/>
     <optional>
      <element name="H.323-alias">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="H.323-URI">
       <data type="anyURI"/>
      </element>
     </optional>



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


     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           PSTN TYPE
       -->
    <define name="PSTN-type">
     <ref name="role-type"/>
     <attribute name="PIN-code">
      <data type="unsignedInt"/>
     </attribute>
     <attribute name="purpose">
      <data type="unsignedInt"/>
     </attribute>
     <oneOrMore>
      <element name="phone-number">
       <data type="unsignedInt"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </oneOrMore>
    </define>
    <!--
           BFCP TYPE
       -->
    <define name="BFCP-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="conference-ID">
       <data type="unsignedInt"/>
      </element>
      <zeroOrMore>
       <ref 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 September 4, 2007              [Page 50]

Internet-Draft              Data Model Schema                 March 2007


        <ref name="single-role-type"/>
       </attribute>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </oneOrMore>
    </define>
    <!--
           CONFERENCE MEDIA TYPE
       -->
    <define name="conference-media-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="entry">
       <ref name="conference-medium-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CONFERENCE MEDIUM TYPE
       -->
    <define name="conference-medium-type">
     <ref name="role-type"/>
     <attribute name="label">
      <text/>
     </attribute>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="type">
       <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="mixing-mode">
       <ref name="mix-mode-type"/>
      </element>
     </optional>
     <optional>
      <element name="mix-level">
       <data type="unsignedInt"/>
      </element>
     </optional>
     <optional>
      <element name="codecs">
       <ref name="codecs-type"/>
      </element>
     </optional>
     <optional>
      <element name="controls">
       <ref name="controls-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CONTROLS TYPE
       -->
    <define name="controls-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="control">
       <ref name="control-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           MIX MODE TYPE
       -->



Novo, et al.            Expires September 4, 2007              [Page 52]

Internet-Draft              Data Model Schema                 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>
    <!--
           CODECS TYPE
       -->
    <define name="codecs-type">
     <ref name="role-type"/>
     <attribute name="decision">
      <ref name="decision-type"/>
     </attribute>
     <zeroOrMore>
      <element name="codec">
       <ref name="codec-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CODEC TYPE
       -->
    <define name="codec-type">
     <ref name="role-type"/>
     <attribute name="name">
      <text/>
     </attribute>
     <attribute name="policy">
      <ref name="policy-type"/>
     </attribute>
    </define>
    <!--
           DECISION TYPE
       -->
    <define name="decision-type">
     <choice>
      <value type="string">automatic</value>
      <value type="string">moderator-controlled</value>
     </choice>
    </define>
    <!--
           POLICY TYPE
       -->



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


    <define name="policy-type">
     <choice>
      <value type="string">allowed</value>
      <value type="string">disallowed</value>
     </choice>
    </define>
    <!--
           CONTROL TYPE
       -->
    <define 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">single-view</value>
        <value type="string">dual-view</value>
        <value type="string">dual-view-crop</value>
        <value type="string">dual-view-2x1</value>
        <value type="string">dual-view-2x1-crop</value>
        <value type="string">quad-view</value>
        <value type="string">multiple-3x3</value>
        <value type="string">multiple-4x4</value>
        <value type="string">multiple-5x1</value>
        <value type="string">automatic</value>
       </choice>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </choice>
    </define>
    <!--
           HOST TYPE
       -->
    <define name="host-type">
     <ref name="role-type"/>
     <zeroOrMore>



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


      <element name="display-text">
       <text/>
      </element>
      <element name="web-page">
       <data type="anyURI"/>
      </element>
      <element name="uris">
       <ref name="uris-type"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           CONFERENCE STATE TYPE
       -->
    <define name="conference-state-type">
     <ref name="role-type"/>
     <optional>
      <element name="allow-conference-event-subscription">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="user-count">
       <data type="unsignedInt"/>
      </element>
     </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>
    <!--
           FLOOR INFORMATION TYPE
       -->
    <define name="floor-information-type">
     <ref name="role-type"/>



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


     <zeroOrMore>
      <element name="conference-ID">
       <ref name="BFCP-type"/>
      </element>
      <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>
       <ref name="anyElement"/>
      </zeroOrMore>
     </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"/>
     <oneOrMore>
      <element name="floor">
       <attribute name="moderator-controlled">
        <data type="boolean"/>
       </attribute>
       <attribute name="label">
        <text/>
       </attribute>
       <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 September 4, 2007              [Page 56]

Internet-Draft              Data Model Schema                 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>
    <!--
           USERS TYPE
       -->
    <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>
    <!--
           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>
     </choice>
    </define>
    <!--
           USERLIST
       -->
    <define name="UserList">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="target">
       <ref name="target-type"/>



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


      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           TARGET TYPE
       -->
    <define name="target-type">
     <ref name="role-type"/>
     <attribute name="uri">
      <data type="anyURI"/>
     </attribute>
     <attribute name="method">
      <ref name="method-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>
    <!--
           USER TYPE
       -->
    <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 September 4, 2007              [Page 59]

Internet-Draft              Data Model Schema                 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 September 4, 2007              [Page 60]

Internet-Draft              Data Model Schema                 March 2007


    </define>
    <!--
           ENDPOINT TYPE
       -->
    <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 September 4, 2007              [Page 61]

Internet-Draft              Data Model Schema                 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>
    <!--
           MEDIA TYPE
       -->
    <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 September 4, 2007              [Page 62]

Internet-Draft              Data Model Schema                 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>
    <!--
           MIXER TYPE
       -->
    <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 September 4, 2007              [Page 63]

Internet-Draft              Data Model Schema                 March 2007


    </define>
    <!--
           SIDEBARS-BY-REF TYPE
       -->
    <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>
    <!--
           SIDEBARS-BY-VAL TYPE
       -->
    <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>
    <!--
           ROLES_TYPE
       -->
    <define name="roles-type">
     <zeroOrMore>
      <element name="entry">
       <ref name="single-role-type"/>
      </element>
     </zeroOrMore>



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


     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ROLE TYPE
       -->
    <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>
    <!--
           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
           *********************************
       -->
    <!--
           EXTENSIBILITY ELEMENTS
       -->
    <define name="anyElement">
     <element>
      <anyName/>
      <zeroOrMore>
       <choice>
        <attribute>
         <anyName/>
        </attribute>



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


        <text/>
        <ref name="anyElement"/>
       </choice>
      </zeroOrMore>
     </element>
    </define>
    <!--
           EXTENSIBILITY ATTRIBUTES
       -->
    <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>
    <!--
           *************************************************************
           TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
           *************************************************************



Novo, et al.            Expires September 4, 2007              [Page 66]

Internet-Draft              Data Model 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 Schema                 March 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 September 4, 2007              [Page 68]

Internet-Draft              Data Model Schema                 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 V3C
   Boston, MA  02109-3614
   USA

   Email: Dave.Morgan@fmr.com






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


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   Email: roni.even@polycom.co.il












































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


Full Copyright Statement

   Copyright (C) The 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, 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 September 4, 2007              [Page 71]