view Side-By-Side changes

XCON                                                             O. Novo
Internet-Draft                                              G. Camarillo
Intended status: Standards Track                                Ericsson
Expires: October 19, 2007 May 3, 2008                                           D. Morgan
                                                    Fidelity Investments
                                                                 R. Even
                                                                 Polycom
                                                          April 17,
                                                        October 31, 2007


 Conference Information Data Model for Centralized Conferencing (XCON)
                draft-ietf-xcon-common-data-model-05.txt
                draft-ietf-xcon-common-data-model-06.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 October 19, 2007. May 3, 2008.

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 information data model is designed to convey
   information about the conference server represents a and about participation in the



Novo, et al.               Expires October 19, 2007 May 3, 2008                  [Page 1]

Internet-Draft              Data Model Schema                 April               October 2007


   particular instantiation of this data model.


   conference.  The conference information data model defined in this
   document is constitutes an extension of
   (and thus, compatible with) the model data format specified in the
   Session Initiation Protocol (SIP) Event Package for Conference State.















































Novo, et al.            Expires October 19, 2007                [Page 2]

Internet-Draft              Data Model Schema                 April 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Data Model Structure Format  . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Role Definitions . . . . . . . . .  Data Model Namespace . . . . . . . . . . . .  7
       3.2.1.  Role in a Floor . . . . . . .  6
     3.3.  The Conference Object Identifier . . . . . . . . . . . .  8
       3.2.2.  Changing Roles .  7
     3.4.  Data Model Structure . . . . . . . . . . . . . . . . . . .  8
   4.  Data Model Definition  . . . . . . . . . . . . . . . . . . . .  8  9
     4.1.  <conference-description> .  <conference-info>  . . . . . . . . . . . . . . . . 13
       4.1.1.  <conference-time> . . . . 12
     4.2.  <conference-description> . . . . . . . . . . . . . . 14
       4.1.2.  <conf-uris> . . . 13
       4.2.1.  <display-text> . . . . . . . . . . . . . . . . . . 15
       4.1.3.  <service-uris> . . 13
       4.2.2.  <subject>  . . . . . . . . . . . . . . . . . . 16
       4.1.4.  <maximum-user-count> . . . . 13
       4.2.3.  <free-text>  . . . . . . . . . . . . . 16
       4.1.5.  <available-media> . . . . . . . . 13
       4.2.4.  <keywords> . . . . . . . . . . 16
         4.1.5.1.  <controls> . . . . . . . . . . . . 13
       4.2.5.  <allow-sidebars> . . . . . . . . 17
           4.1.5.1.1.  mute . . . . . . . . . . . 13
       4.2.6.  <conference-time>  . . . . . . . . . . 17
           4.1.5.1.2.  pause-video . . . . . . . . 14
       4.2.7.  <conf-uris>  . . . . . . . . . 17
           4.1.5.1.3.  gain . . . . . . . . . . . . 15
       4.2.8.  <service-uris> . . . . . . . . . 18
           4.1.5.1.4.  video-layout . . . . . . . . . . . 15
       4.2.9.  <maximum-user-count> . . . . . . 18
     4.2.  <host-info> . . . . . . . . . . . 15
       4.2.10. <available-media>  . . . . . . . . . . . . 19
     4.3.  <conference-state> . . . . . . 15
     4.3.  <host-info>  . . . . . . . . . . . . . . 19
     4.4.  <floor-information> . . . . . . . . . 18
     4.4.  <conference-state> . . . . . . . . . . 19
     4.5.  <users> . . . . . . . . . . 18
       4.4.1.  <allow-conference-event-subscription>  . . . . . . . . 18
       4.4.2.  <user-count> . . . . . . . 21
       4.5.1.  <allowed-users-list> . . . . . . . . . . . . . . 18
       4.4.3.  <active> . . . 22
       4.5.2.  <user> . . . . . . . . . . . . . . . . . . . . 18
       4.4.4.  <locked> . . . . 22
         4.5.2.1.  <from-mixer>, <to-mixer> . . . . . . . . . . . . . 24
           4.5.2.1.1.  <floor> . . . . . . 19
     4.5.  <floor-information>  . . . . . . . . . . . . . 24
       4.5.3.  <sidebars-by-ref> . . . . . . 19
       4.5.1.  <conference-ID>  . . . . . . . . . . . . 24
       4.5.4.  <sidebars-by-val> . . . . . . . 19
       4.5.2.  <allow-floor-events> . . . . . . . . . . . 24
   5.  RELAX NG Schema . . . . . . 19
       4.5.3.  <floor-request-handling> . . . . . . . . . . . . . . . 19
       4.5.4.  <conference-floor-policy>  . . 25
   6.  XML Schema Extensibility . . . . . . . . . . . . 20
     4.6.  <users>  . . . . . . . 32
   7.  XML Example . . . . . . . . . . . . . . . . . . 20
       4.6.1.  <join-handling>  . . . . . . . 33
   8.  Security Considerations . . . . . . . . . . . . 21
       4.6.2.  <user-admission-policy>  . . . . . . . 41
   9.  IANA Considerations . . . . . . . . 21
       4.6.3.  <allowed-users-list> . . . . . . . . . . . . . 41
     9.1.  Conference Relax NG Schema Registration . . . . 22
       4.6.4.  <user> and Its <user> Sub-elements . . . . . 41
     9.2.  Conference Namespace Registration . . . . . 22
         4.6.4.1.  <display-text> . . . . . . . 41
     9.3.  Conference Object Identifier Registration . . . . . . . . 41
     9.4.  Conference User Identifier Registration . . . 23
         4.6.4.2.  <associated-aors>  . . . . . . 42
   10. Acknowledgements . . . . . . . . . . 23
         4.6.4.3.  <provide-anonymity>  . . . . . . . . . . . . . 42
   11. References . . 24
         4.6.4.4.  <roles>  . . . . . . . . . . . . . . . . . . . . . 24
         4.6.4.5.  <languages>  . . . 42
     11.1. Normative References . . . . . . . . . . . . . . . . 24



Novo, et al.               Expires May 3, 2008                  [Page 2]

Internet-Draft              Data Model Schema               October 2007


         4.6.4.6.  <cascaded-focus> . . . 42
     11.2. Informative References . . . . . . . . . . . . . . 24
         4.6.4.7.  <allow-refer-users-dynamically>  . . . . 42
   Appendix A.  Appendix A.  Non-Normative . . . . . 24
         4.6.4.8.  <allow-invite-users-dynamically> . . . . . . . . . 24
         4.6.4.9.  <allow-remove-users-dynamically> . . . . . . . . . 25
         4.6.4.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 25
     4.7.  <sidebars-by-ref>  . . . . . . . . . . . . . . . . . . . . 26
     4.8.  <sidebars-by-val>  . . . . . . . . . . . . . . . . . . . . 26
   5.  RELAX NG Schema in  . . . . . . . . . . . . . . . . . . . . . . . 26
   6.  XML
                Syntax Schema Extensibility . . . . . . . . . . . . . . . . . . . 33
   7.  XML Example  . . . . 43
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
   8.  Security Considerations  . . . 66
   Intellectual Property and Copyright Statements . . . . . . . . . . 68



Novo, et al.            Expires October 19, 2007                [Page 3]

Internet-Draft              Data Model Schema                 April 2007


1.  Introduction

   Conference objects are a fundamental concept in Centralized
   conferencing, as described in the XCON Conferencing Framework [4].  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 [4].  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 [5])
   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
   [6]) 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 October 19, 2007                [Page 4]

Internet-Draft              Data Model Schema                 April 2007


      ............................................................... . Conferencing Server . .       +---------------------------------------------------+ . .       |       C o n f e r e n c e   o b j e c t           | . 41
     8.1.  Authentication .     +-+--------------------------------------------------+| . .     |       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                             | |||| . 41
     8.2.  Confidentiality  .   | | +----------------------------------------------+ |||| . .   | | +----------------------------------------------+ |||| . .   | | | Conference state                             | |||| . .   | | +----------------------------------------------+ |||| . .   | | +----------------------------------------------+ |||| . .   | | | Floor information                            | |||| . .   | | +----------------------------------------------+ |||| . .   | | +----------------------------------------------+ |||| . .   | | | Membership (users, roles, capacity)          | |||| . .   | | +----------------------------------------------+ |||| . .   | | +----------------------------------------------+ |||| 41
     8.3.  Integrity  . .   | | | Sidebars, Etc.                               | |||| . .   | | +----------------------------------------------+ |||| . .   | | +----------------------------------------------+ |||| . .   | | | Etc.                                         | |||| . .   | | +----------------------------------------------+ |||+ . .   | +--------------------------------------------------+|+ . .   +----^------------------^-------------^--------|------+ . .        |                  |             |        | . . +------v-------+ +--------v-----+ +-----v-+ +----v-------+ . . | Conference   | | Floor        | |       | |            | . . | Control      | | Control      | |Foci   | |Notification| . . | Server       | | Server       | |       | |Service     | 42
   9.  IANA Considerations  . . +-----^--------+ +---^----------+ +-^-----+ +------------+ .
      ........|..............|..............|..........|.............
              |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: . . . . . . . . . . . . . . . . 42
     9.1.  Conference Server Architecture



Novo, et al.            Expires October 19, 2007                [Page 5]

Internet-Draft              Data Model Relax NG Schema                 April 2007


   The Session Initiation Protocol (SIP) Event Package for Registration  . . . . . . . . . 42
     9.2.  Conference
   State, specified in RFC 4575 [1], 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 [4] (e.g., floor control).  The data model defined in this
   document extends the one defined Namespace Registration  . . . . . . . . . . . . 42
     9.3.  Conference Object Identifier Registration  . . . . . . . . 42
     9.4.  Conference User Identifier 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 RFC 4575 [1].  The result XML
                Syntax  . . . . . . . . . . . . . . . . . . . . . . . 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
   Intellectual Property and Copyright Statements . . . . . . . . . . 65
























Novo, et al.               Expires May 3, 2008                  [Page 3]

Internet-Draft              Data Model Schema               October 2007


1.  Introduction

   There is a core data model that supports more call signaling protocols besides SIP
   and set of conference information that covers all the functionality defined is utilized
   in any conference, independent of the XCON
   conferencing framework [4].


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 [2]. specific conference media.
   This document uses core data set called the terminology 'conference information data model' is
   defined in the XCON Conferencing
   Framework [4], the SIP conferencing framework [7] and the BFCP
   (Binary Floor Control Protocol) specification [5].  Readers of this document are supposed to be familiar with the terminology used in
   those documents.


3.  Overview using an Extensible Markup Language (XML)-
   based.  The conference information data model defined in this
   document is logically represented by the result of extending
   the data model defined conference object.

   Conference objects are a fundamental concept in RFC 4575 [1] with new elements, which carry
   information such Centralized
   Conferencing, as non-SIP URIs or floor-control-related parameters.
   This described in the Centralized Conferencing Framework
   [4].  A conference object contains data model can be used by that represents a conference servers providing different
   types
   during each of basic conferences.  It is expected that this data model its various stages (e.g., created/creation, reserved/
   reservation, active/activation, completed/completion).  A conference
   object can be further extended with new elements in the future in order to
   implement advanced features.

3.1.  Data Model Structure manipulated using a conference control protocol at a
   conference server.  The conference object represents a particular
   instantiation of a conference information in this data model is structured in model.  Consequently,
   conference objects follow the following
   manner.  All XML format defined in this document.

   A conference object contains the core information related to of a conference is contained
   (i.e., capabilities, membership, call control signaling, media, etc.)
   and specifies who, and in which way that information can be
   manipulated.

   Figure 1 shows the logical functional elements of a <conference-info> element.  The <conference-info> element contains conference server
   as defined by the following child elements:
   o  The <conference-description> element describes Centralized Conferencing Framework [4].  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 control client and the conference
   control server.  A floor control protocol (e.g., BFCP [5]) provides
   the interface between a floor control client and the floor control
   server.  A call signaling protocol (e.g., SIP, H.323, Q.931, ISUP,
   etc.) provides the conference as interface between a
      whole.  It has, for instance, information about call signaling client and a
   Focus.  A notification protocol (e.g., SIP-based event notifications
   [6]) provides the URI of interface between the
      conference, maximum users allowed in conferencing client and the
   Notification Service.  Within a conference, media
      available in the conference, or conference control
   server, floor control server, and focus can modify the time information in
   the conference will
      start. object.













Novo, et al.               Expires May 3, 2008                  [Page 4]

Internet-Draft              Data Model Schema               October 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, 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  The <host-info> element contains information about the entity
      hosting the conference (e.g., its URI).  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 October 19, 2007 May 3, 2008                  [Page 6] 5]

Internet-Draft              Data Model Schema                 April               October 2007


   o


   The <conference-state> element informs the subscribers about the
      changes Session Initiation Protocol (SIP) Event Package for Conference
   State, specified in the overall conference information.
   o  The <floor-information> element contains information about the
      status RFC4575 [1], already defines a data format for
   conferences.  However, that model is SIP specific and lacks elements
   related to some of the different floors in the conference.
   o  The <users> element describes functionality defined by the membership information as a
      whole.  The <users> element contains Centralized
   Conferencing Framework [4] (e.g., floor control).  The data model
   defined in this document constitutes a set superset of <user> child
      elements, each describing a single participant in the conference.
   o  If data format
   defined in RFC4575 [1].  The result is a participant data format that supports
   more call signaling protocols besides SIP and that covers all the
   functionality defined in the main conference joins a sidebar, a new
      element is created Centralized Conferencing Framework [4].


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

   This document uses the conference referenced from terminology defined in the
      <sidebars-by-ref> element or under one of Centralized
   Conferencing Framework [4], the <sidebars-by-val>
      elements.

3.2.  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", SIPPING conferencing framework [7]
   and "observer".  A set the BFCP (Binary Floor Control Protocol) specification [5].
   Readers of semantics associated this document should be familiar with
   each role the terminology used
   in those documents.


3.  Overview

   The data model specified in this document is out of the scope result of this document.  A Conference System
   MAY choose not to support a particular role.  As well, additional
   roles may be extending
   the data format defined in the future, as necessary, RFC4575 [1] 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" new elements.  Examples
   of such extensions include scheduling elements, media control
   elements, floor control elements, non-SIP URIs, and so on.  For example, the "administrator" SHOULD have
   the ability to make changes addition of
   localization extensions to all text elements.  This data model can be
   used by conference variables during
   instantiation and full lifecycle servers providing different types of the Conference Object.  The
   "creator" basic
   conferences.  It is expected that this data model can be further
   extended with new elements in the 'owner' of the future in order to implement
   additional advanced features.

3.1.  Data Model Format

   A conference object document is an XML [8] document that MUST be well
   formed and has various privileges
   which SHOULD allow them to modify the conference variables up to be valid.  Conference object documents MUST be
   based on XML 1.0 and SHOULD be encoded using UTF-8.

3.2.  Data Model Namespace

   This specification defines a new namespace specification for
   identifying the
   time elements defined in the conference data model.  This namespace
   is instantiated. as follows:




Novo, et al.               Expires May 3, 2008                  [Page 6]

Internet-Draft              Data Model Schema               October 2007


   urn:ietf:params:xml:ns:xcon-conference-info

3.3.  The "moderator" is a logical
   entity that will manage the conference. Conference Object Identifier

   The "participant" is a
   logical entity with generic privileges that will conference object identifier (XCON-URI) can be attending viewed as a
   conference.  The "observer" is key to
   accessing a logical entity which specific conference object.  It can only
   receive media streams from be used, for
   instance, by the conference.  All Conference Systems
   MUST have a role defined as "participant".

   Each user participating in conference control protocol to access, manipulate
   and delete a conference instance object.  A conference object identifier is an entity that
   can assume one or more roles.  Any entity can be allocated
   provided to an
   appropriate logical role. the conferencing client by the conference notification
   service or through out-of-band mechanisms (e.g.  E-Mail).

   A role can also be assumed in conjunction conferencing system may maintain a relationship between the
   conference object identifiers and the identifiers associated with
   each of the complementary centralized conferencing protocols (e.g.,
   call signaling protocols, BFCP, etc.).  To facilitate the users identity within maintenance
   of these relationships, the Conference System conference object identifier acts as a result
   top level identifier within the conferencing system for the purpose
   of
   an identity assertion transaction on identifying the Conference System.  If no
   roles are defined interfaces for an entity, they SHOULD by default be these other protocols.  This
   implicit binding provides a
   "participant" but local policy MAY define an alternative. structured mapping of the various
   protocols with the associated conference object Identifier.  Figure 2
   illustrates the relationship between the identifiers used for the
   protocols and the general conference object identifier (XCON-URI).


                            +--------------------------+
                            |       Conference         |
                            |         Object           |
                            |       Identifier         |
                            +--------------------------+
                            |  xcon:Ji092i@example.com |
                            +------+-------------------+
                                        |
                                        |
                                        |
                      +-----------------+---------------+
                      |                                 |
          +-----------+-----------+          +----------+---------+
          |   CSP Conference IDs  |          |BFCP 'Conference ID'|
          +-----------------------+          +--------------------+
          |h323:Ji092i@example.com|          |        Ji092i      |
          |tel:+44(0)2920930033   |          +----------+---------+
          |sip:Ji092i@example.com |                     |
          +-----------------------+             +-------|--------+
                                                | BFCP 'Floor ID'|
                                                +----------------+
                                                |      543       |
                                                |     09cnJk     |
                                                +----------------+



Novo, et al.               Expires October 19, 2007 May 3, 2008                  [Page 7]

Internet-Draft              Data Model Schema                 April               October 2007


3.2.1.  Role in a Floor

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


                    Figure 2: Conference System or created dynamically.  Users can be added or
   deleted from a floor when Object Mapping

   In Figure 2, 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 object identifier acts as the top level
   key in the identification process.  The call signaling protocols have
   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 [5].

   Users in a associated conference MAY assume different roles in different floors.
   They MAY also assume different roles user identifier, often represented in the same floor, as
   form of URIs.  The binary floor
   transactions are processed.

3.2.2.  Changing Roles

   Users can change roles during a conference.  This can be done control protocol, as defined in two
   ways: First, [5],
   defines the user can join 'conference ID' identifier which represents a new conference
   instance within floor in control.  When created within the conferencing
   system, the 'conference ID' has a different role.
   Second, an "administrator" or "creator" can dynamically change that
   user's role.  This can be accomplished before 1:1 mapping to the unique
   conference is
   instantiated, or during object Identifier(XCON-URI).  Operations associated with
   the conference, using an appropriate conference control protocol.  A logical entity whose role has been
   changed will typically have access to protocols are directly associated with the media streams
   conference object, thus the primary identifier associated with that role.


4.  Data Model Definition

   A these
   protocols is the conference object document identifier(XCON-URI).  The
   mappings between additional protocols/interface is an XML [8] document not strictly 1:1
   and does allow for multiple occurrences.  For example, multiple call
   signaling protocols will each have a representation that MUST is
   implicitly linked to the top level conference object identifier e.g.
   H323 and SIP URIs that represent a conference instance.  It should be well
   formed
   noted that a conferencing system is free to structure such
   relationships as required and SHOULD this information is just included as a
   guideline that can be valid.  Conference object used.

   Further elements can be added to the tree representation in Figure 2
   to enable a complete representation of a conference instance within a
   conferencing system.

3.4.  Data Model Structure

   The information in this data model documents
   MUST be based on XML 1.0 and SHOULD be encoded using UTF-8.

   A is structured in the following
   manner.  All the information related to a conference object document begins with is contained in
   a <conference-info> element.  The <conference-info> element contains
   the root following child elements:

   o  The <conference-description> element tag
   <conference-info>, which is defined describes the conference as a
      whole.  It has, for instance, information about the URI of the
      conference, maximum users allowed in [1]. the conference, media
      available in the conference, or the time the conference will
      start.
   o  The <conference-info> <host-info> element has an 'entity' attribute that contains a conference object
   identifier (XCON-URI) that identifies information about the entity
      hosting the conference being described
   in (e.g., its URI).
   o  The <conference-state> element informs the document.

   A conferencing system may maintain a relationship between subscribers about the
      changes in the overall conference object identifiers and information.
   o  The <floor-information> element contains information about the identifiers associated with
   each
      status of the complimentary centralized conferencing protocols (e.g.,
   call signaling protocols, BFCP, etc.).

   This implicit binding provides different floors in the conference.
   o  The <users> element describes the membership information as a structured mapping
      whole.  The <users> element contains a set of <user> child
      elements, each describing a single participant in the various conference.




Novo, et al.               Expires October 19, 2007 May 3, 2008                  [Page 8]

Internet-Draft              Data Model Schema                 April               October 2007


   protocols with


   o  If a participant in the associated main conference object Identifier.  Figure 2
   illustrates the relationship between the identifiers used for the
   protocols within the framework [4] and the general XCON-URI.


                            +--------------------------+
                            |       Conference         |
                            |         Object           |
                            |       Identifier         |
                            +--------------------------+
                            |  xcon:Ji092i@example.com |
                            +------+-------------------+
                                        |
                                        |
                                        |
                      +-----------------+---------------+
                      |                                 |
          +-----------+-----------+             +-------+-------+
          |   CSP Conference IDs  |             | BFCP 'confid' |
          +-----------------------+             +---------------+
          |h323:Ji092i@example.com|             |    Ji092i     |
          |tel:+44(0)2920930033   |             +-------+-------+
          |sip:Ji092i@example.com |                     |
          +-----------------------+             +-------|-------+
                                                | BFCP 'floorid |
                                                +---------------+
                                                |    UEK78d     |
                                                |    09cnJk     |
                                                +---------------+


                    Figure 2: Conference Object Mapping

   Further elements can be added to the tree representation in Figure 2
   to enable joins a complete representation of sidebar, a new
      element is created in the conference instance within a
   conferencing system.

   The <conference-info> referenced from the
      <sidebars-by-ref> element contains or under one of the <conference-description>,
   <host-info>, <conference-state>, <floor-information>, <users>,
   <sidebars-by-ref>, <sidebars-by-val> child
      elements.  All these
   elements, except <floor-information>,

   Note that some of the elements described above such <conference-
   info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
   val> are not defined in the data model but are defined in the data
   format of RFC 4575 [1].  A
   conference document MUST at least include  We describe them here because they are part
   of the <conference-
   description>, <host-info>, <conference-state>, and <users> child
   elements. basic structure of the data model.


4.  Data Model Definition

   The following non-normative diagram shows the structure of conference
   object documents.  The operator "!" preceding an element indicates
   that the element is mandatory in the data model.  The operator "*"



Novo, et al.            Expires October 19, 2007                [Page 9]

Internet-Draft              Data Model Schema                 April 2007
   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 [1].

   !<conference-info>
        |
        |--!<conference-description>
        |     |--<display-text>
        |     |--<subject>
        |     |--<free-text>*     |--<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>*      |--<entry>
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |--<H323>*
        |     |      |    |--<H.323-alias>*
        |     |      |    |--<H.323-URI>*
        |     |      |--<PSTN-ISDN>*
        |     |      |    |--<phone number>*
        |     |      ...
        |     |--<service-uris>
        |     |      |--<entry>*      |--<entry>



Novo, et al.               Expires May 3, 2008                  [Page 9]

Internet-Draft              Data Model Schema               October 2007


        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |--<H323>*
        |     |      |    |--<H.323-alias>*
        |     |      |    |--<H.323-URI>*
        |     |      |--<PSTN-ISDN>*
        |     |      |    |--<phone number>*
        |     |      ...
        |     |--<maximum-user-count>
        |     |      ...
        |     |--!<available-media>



Novo, et al.            Expires October 19, 2007               [Page 10]

Internet-Draft              Data Model Schema                 April 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>     |--<uris>
        |     |     |--!<entry>     |--<entry>
        |     |     |    |--!<uri>    |--<uri>
        |     |     |    |--<display-text>
        |     |     |--<H323>*
        |     |     |    |--<H.323-alias>*
        |     |     |    |--<H.323-URI>*
        |     |     |--<PSTN-ISDN>*
        |     |     |    |--<phone number>*
        |           ...
        |--<conference-state>
        |     |--<allow-conference-event-subscription>*
        |     |--<user-count>
        |     |--!<active>     |--<active>
        |     |--<locked>



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 11] 10]

Internet-Draft              Data Model Schema                 April               October 2007


        |
        |--<floor-information>*
        |     |--<conference-ID>*
        |     |--<allow-floor-events>*
        |     |--<floor-request-handling>*
        |     |--<conference-floor-policy>*
        |     |     |--<floor>*
        |     |     |    |--<media-types>*    |--!<media-label>*
        |     |     |    |--<algorithm>*    |--!<algorithm>*
        |     |     |    |--<max-floor-users>*
        |     |     |    |--<chair-id>*
        |     |     |    |--<chair-id>*    |--<moderator-id>*
        |     |     |   ...
        |     |     ...
        |
        |--!<users>
        |     |--<join-handling>*
        |     |--<user-admission-policy>*
        |     |--<allowed-users-list>*
        |     |     |--<target>*
        |     |     |-- ...
        |     |
        |     |
        |     |--!<user>     |--<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>      |--<media>
        |     |    |      |    |--<type>
        |     |    |      |    |--<display-text>
        |     |    |      |    |--<label>
        |     |    |      |    |--<src-id>
        |     |    |      |    |--<status>



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 12] 11]

Internet-Draft              Data Model Schema                 April               October 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>
        |     |     |
        |     ...   ...


                      Figure 3: Non-normative diagram

   The following sections describe these elements in detail.  The full
   Relax NG schema is provided Section 5.

4.1.  <conference-info>

   A conference object document begins with the root element tag
   <conference-info>, which is defined in RFC4575 [1].  The <conference-
   info> attributes are described in RFC4575 [1].  Notice that the
   <conference-info> element does not have the attributes 'state' and
   'version' defined in RFC4575[1] for this element because this



Novo, et al.               Expires May 3, 2008                 [Page 12]

Internet-Draft              Data Model Schema               October 2007


   attribute only applies to notifications mechanism.  RFC4575 [1]
   defines as well an 'entity' attribute that contains the conference
   object identifier (XCON-URI) that identifies the conference being
   described in the document.

   The following sections describe <conference-info> element contains the <conference-description>,
   <host-info>, <conference-state>, <floor-information>, <users>,
   <sidebars-by-ref>, and <sidebars-by-val> child elements.  All these elements
   elements, except <floor-information>, are defined in detail.  The full
   Relax NG schema is provided Section 5.

4.1. [1].  A
   conference document MUST at least include the <conference-
   description> and <users> child elements.

4.2.  <conference-description>

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

   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.2.1.  <display-text>

   The <display-text> element is described in section 5.3 of RFC 4575
   [1].

4.2.2.  <subject>

   The <subject> element is described in section 5.3 of RFC 4575 [1].

4.2.3.  <free-text>

   The <free-text> element is described in section 5.3 of RFC 4575 [1].

4.2.4.  <keywords>

   The <keywords> element is described in section 5.3 of RFC 4575 [1].

4.2.5.  <allow-sidebars>

   The <allow-sidebars> element represents a boolean action.  If set to
   TRUE, the conference is allowed to create sidebar conferences.





Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 13]

Internet-Draft              Data Model Schema                 April               October 2007


   and <available-media>.


4.2.6.  <conference-time>

   The <display-text>, <subject>, <free-text> <conference-time> element contains the information related to
   conference time and <keywords> 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 the following child elements:

   o  <base>: The <base> child element specifies the iCalendar object of
      the conference.  The iCalendar object components are defined in [1].  They are used to describe the conference's
   content. in
      RFC 2445 [3].
   o  <mixing-start-offset>: The <mixing-start-offset> child element <allow-sidebars> describes
      specifies when the capabilities of conference media mixing starts before the
   conference.
      conference starts.  The <conference-time> <mixing-start-offset> child element contains information related to
      expresses the offset as signed integers representing seconds
      before/after the iCalendar DTSTART field [3].  If the <mixing-
      start-offset> element is not present, it indicates that the
      conference time media mixing starts immediately.  The <mixing-start-
      offset> has the mandatory 'required-participant' attribute.  This
      attribute has one of 4 values: "none", "administrator",
      "moderator", and duration "participant".  This attribute allows a
      privileged user to define when media mixing starts based on the
      latter of the conference.  The <conf-uris> mixing start time, and
   <service-uris> are used to describe the conference-related
   identifiers.  The <maximum-user-count> child element indicates time the
   number of users that can be invited first
      participant, administrator, or moderator arrives.  If the value is
      set to "none'", mixing starts according to the conference. mixing start time.
   o  <mixing-end-offset>: The
   <available-media> <mixing-end-offset> child element is used to describe that
      specifies the time a conference media
   characteristics of mixing stops after the conference.
      conference stops.  The following sections describe these elements in more detail.  Other <mixing-end-offset> child elements MAY be defined in element expresses
      the future to extend offset as signed integers representing seconds before/after
      the
   <conference-description> element.

4.1.1.  <conference-time>

   The <conference-time> iCalendar DTEND field [3].  If the <mixing-end-offset> element contains
      is not present, it indicates that the information related to conference time and duration of a conference. occurrence is not
      bounded.  The <conference-time>
   element contains one or more <entry> <mixing-end-offset> elements each defining both have the mandatory
      'required-participant' attribute.  This attribute has one of 4
      values: "none", "administrator", "moderator", and "participant".
      This attribute allows a privileged user to define when media
      mixing ends based on the earlier of the <mixing-end-offset>, and
      the time
   information specifying a single the last participant, or moderator leaves.  If the value
      is set to "none", mixing stops according to the <mixing-end-
      offset>.  If the conference occurrence.

   Every <entry> element contains a <mixing-start-offset> child element policy was modified so that specifies when last
      privileged user is now a normal conference media mixing starts before participant, and the
      conference starts, <mixing-end-offset> child element requires a privileged user to continue; that specifies conference
      MUST terminate.
   o  <can-join-after-offset>: An administrator can indicate the time
      when users can join a conference media mixing stops by populating the <can-join-
      after-offset> element.





Novo, et al.               Expires May 3, 2008                 [Page 14]

Internet-Draft              Data Model Schema               October 2007


   o  <must-join-before-offset>: An administrator can define the time
      after which new users are not allowed to join the conference stops.
   The <mixing-end-offset> child
      anymore.  This is done by populating the <must-join-before-offset>
      element expresses expressing the offset as signed integers representing
      seconds before/after DTEND DTSTART field.  The <mixing-
   start-offset> child
   o  <request-user>: It is possible to define the time when users or
      resources on the <allowed-users-list> are 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.  If the <mixing-
   start-offset>
   o  <notify-end-of-conference>: The <notify-end-of-conference> element is not present, it indicates that
      defines in seconds when the system has to send a notification when
      the end of the conference media mixing starts immediately. is approaching.  If the <mixing-end-
   offset> <notify-end-of-
      conference> element is not present, it indicates that the system
      does not notify the users when the end of the conference
   occurrence is not bounded. <mixing-start-offset> and <mixing-end-
   offset> elements both have
      approaching.  The <notify-end-of-conference> child element
      expresses the offset as signed integers representing seconds after
      DTSTART field.
   o  <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
      end-offset> refers to the possibility to extend the conference.
      It has a boolean value.

4.2.7.  <conf-uris>

   The <conf-uris> contains the identifiers to be used in order to
   access the mandatory 'require-participant'
   attribute.  This attribute has one conference by different signaling means.  The <conf-uris>
   element is described in section 5.3.1 of 4 values: "none",
   "administrator", "moderator", and "participant".  For <mixing-start-
   offset>, this attribute allows a privileged user RFC 4575[1].  Future
   extensions to this schema may define when media
   mixing starts based on new values and register them
   with IANA.

4.2.8.  <service-uris>

   The <service-uris> describes auxiliary services available for the latter
   conference.  The <service-uris> element is described in section 5.3.2
   of the mixing start time, RFC4575[1].  Future extensions to this schema may define new
   values and register them with IANA.

4.2.9.  <maximum-user-count>

   The <maximum-user-count> contains the
   time the first participant, administrator, or moderator arrives.  If overall number of users allowed
   to join the conference.  Note that this value is set to "none'", mixing starts according to by an
   administrator and can reflect any local policies such as network
   consumption, CPU processing power, and licensing rules.

4.2.10.  <available-media>

   The <available-media> has the mixing
   start time.  For <mixing-end-offset>, this 'label' attribute that is the media
   stream identifier assigned by the conferencing server.  The attribute allows a



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 14] 15]

Internet-Draft              Data Model Schema                 April               October 2007


   privileged user to define when media mixing ends based on the earlier


   'label' is described in RFC 4575 [1], section 5.3.4.  The <available-
   media> element contains a sequence of <entry> child elements.  Each
   <entry> element contains the <mixing-end-offset>, and the time the last participant, or
   moderator leaves.  If the value following child elements:

   o  The <type> element is set to "none", mixing stops
   according to the <mixing-end-offset>.  If the conference policy was
   modified so that last privileged user described in section 5.3.4 of RFC 4575 [1].
   o  The <display-text> element is described in section 5.3.4 of RFC
      4575 [1].
   o  The <status> element 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 described in section 5.3.4 of RFC 4575
      [1].
   o  The child element <mixing-mode> describes a
   conference default policy by populating
      which the <can-join-after-offset> element.
   Similarly, an administrator can define mixer will build the time after which new users
   are not allowed to join outgoing stream from the conference anymore.  This incoming
      streams.  Notice that this policy is done by
   populating different than the <must-join-before-offset> element expressing policy
      describing the
   offset as signed integers representing seconds before/after DTSTART
   field. floors for each media.  The <base> <mixing-mode> child
      element specifies MUST contain one and only one of the iCalendar object "Moderator-
      controlled", "FCFS", and "Automatic" values indicating the default
      algorithm to use with every media stream.  The "Moderator-
      controlled" value indicates that the moderator of the
   conference. conference,
      controls the media stream policy.  The iCalendar object components are defined in [3]. "FCFS" value indicates a
      'first-come-first-served' policy.
   o  The <entry> <codecs> element also contains specifies the <request-user> child element. allowed codecs in the
      conference.  It is possible to define has an attribute 'decision' that specifies if the time when users
      focus decides the common codec automatically or resources on needs the
   <allowed-users-list> is requested to join approval
      of the conference by using moderator of the
   <request-users> element.  This conference ("automatic", "moderator-
      controlled").  The <codecs> element expresses contains <entry> elements.  A
      <entry> element can have the offset as signed
   integers representing seconds before/after DTSTART field. attribute 'name' and 'policy'.  The <notify-end-of-conference> element defines in seconds when
      'name' attribute identifies a codec.  The list of possible codecs
      accepted as a 'name' attribute is defined by the IANA registry for
      RTP Payload Types.  The possible values of the
   system has to send a notification when attribute 'name'
      are the end values of the conference is
   approaching.  If 'subtype' column of the <notify-end-of-conference> RTP Payload Format
      media types per RFC4855[9] defined in IANA [10].  The 'policy'
      attribute contains the policy for that codec (allowed, or
      disallowed).
   o  The <controls> element contains the basic audio and video global
      control elements for a conference.  It is not
   present, it indicates expected that for the system does not notify the users when
   the end
      majority of the basic conferences, these controls are sufficient.
      If the conference server wants to support more advanced controls,
      then it 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 recommended that an extension to the possibility to extend data model be
      used.  In the
   conference.  It has two values: "allowed", "denied".

4.1.2.  <conf-uris>

   The <conf-uris> contains <controls> element the identifiers to schema is extensible, hence
      new control types can be used added in order to
   access the conference by different signaling means.  It contains a
   sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>. future.  So moderator
      controls that affect all media output would go under the
      <available-media> element.  The
   <entry> following controls elements are
      defined for <controls>:
      *  The <mute> element refers to the SIP protocol.  It keeps the same name
   that is defined used in [1] to maintain backwards compatibility conjunction with this
   RFC.  The <entry> element contains an audio stream
         to cease transmission of associated media.  That means that for
         the <uri>, <display-text>, entire duration where mute is applicable, all current and
   <purpose> which are described in [1].  The currently defined
   <purpose> values to be used with
         future participants of the <conf-uris> are:
   o  participation: Accessing a URI with this <purpose> conference are muted and will bring not
         receive any audio.  It has a "boolean" value.  If this control
         is not specified, access to the
      party into control is not available to the conference



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 15] 16]

Internet-Draft              Data Model Schema                 April               October 2007


   o  streaming: Accessing a URI


         client.
      *  The <pause-video> element is used in conjunction with a video
         stream to cease transmission of associated media.  It has a
         "boolean" value.  If this <purpose> will commence
      streaming control is not specified, the conference, but access
         to the control is not allow active participation available to the client.
      *  The <H.323> <gain> element includes either a <H.323-alias> or a <H.323-URI>
   child elements.  The <PSTN-ISDN> has an attribute 'PIN code' is used in conjunction with a media output
         stream to indicate the
   PIN code amount of amplification of an audio
         stream.  It has an "int" number value.  This control has two
         attributes that defines the conference if used minimum and a 'purpose' attribute that
   describes maximum amplification
         levels: 'min' and 'max'.  If this control is not specified,
         access 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 control is not available for to the
   conference.  It contains a sequence of child elements: <entry>,
   <H.323>, and <PSTN-ISDN>. client.
      *  The <entry> child <video-layout> element contains <uri>,
   <display-text>, and <purpose>.  The purpose will be is used in conjunction with a video
         stream to describe specify how the service.  The currently defined <purpose> values to video streams (of participants) are
         viewed by each participant.  Only one layout type can be used with
         specified for each output stream.  If there are fewer
         participants than panels in the <service-uris> are:
   o  web-page: Indicates specified layout, then blanking
         (black screen) MAY be mixed into the web page containing 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, although any number of custom layouts may be
         specified in future extensions:
         +  single-view: Only one stream is presented by the additional
      information about focus to
            all participants in one panel.
         +  dual-view: This dual view option will present the conference
   o  recording: Indicates video
            side-by-side in 2 panels and not alter the link at which aspect ratio of
            the recorded conference
      context can be retrieved
   o  event: Indicates streams.  This will require the URI at which a subscription focus to introduce
            blanking on parts of the conference
      event package may be requested.  This would typically be overall image as viewed by the
      conference URI of
            participants.
         +  dual-view-crop: This side-by-side layout option instructs
            the main conference
   Future extensions focus to this schema may define new values and register
   them with IANA.  These elements are described in [1]. <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 alter the overall number aspect ratio of users allowed
   to join the conference.  Note streams (alter-
            aspect-ratio=TRUE) so that this value blanking 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> not necessary.  The <available-media> has the 'label' attribute that is
            focus handles the media
   stream identifier assigned by cropping of the conferencing server. streams.
         +  dual-view-2x1: This element
   contains a sequence of <entry> child elements of conference-medium-
   type.  Each <entry> element contains layout option instructs the <type>, <display-text>,
   <status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child
   elements.  The attribute 'label' focus to
            place one stream above the other, in essence with two rows
            and one column.  In this option the <type>, <display-text>, aspect ratio is not
            altered and
   <status> elements are described blanking is introduced.
         +  dual-view-2x1-crop: This layout option also instructs the
            focus to place one stream above the other, in [1].  The <codecs> element
   specifies essence with
            two rows and one column.  In this option the allowed codecs in aspect ratio is
            altered and the conference.  It has an attribute
   'decision' that specifies if video streams are cropped.
         +  quad-view: Four equal-sized panels in a 2x2 layout is
            presented by the focus decides the common codec
   automatically or needs to all participants.  Typically the approval
            aspect ratio of the moderator of streams are maintained (alter-aspect-
            ratio= FALSE).
         +  multiple-3x3: Nine equal-sized panels in a 3x3 layout is
            presented by the
   conference ("automatic", "moderator-controlled").  The <codecs>
   element contains <entry> elements.  A <entry> element can have focus to all participants.  Typically the
            aspect ratio of the streams are preserved.




Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 16] 17]

Internet-Draft              Data Model Schema                 April               October 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


         +  multiple-4x4: Sixteen equal-sized panels in a default
   policy by which the mixer will build the outgoing stream from the
   incoming streams.  Notice that this policy 4x4 layout is different than the
   policy describing
            presented by the floors for each media.  The <mix-level> child
   element describes focus to all participants.  Typically the number
            aspect ratio of participants in audio media streams
   or the number of sub-windows in video media streams (for instance, are preserved.
         +  multiple-5x1: This option refers to a
   value 5x1 layout where one
            panel will occupy 4/9 of "4" in the <mix-level> element for mixed video streams implies a
   2x2 layout).  The <mixing-mode> child element MUST contain one and
   only one of stream while the "Moderator-controlled", "FCFS", and "Automatic"
   values indicating
            others will each occupy 1/9 of the default algorithm to be use with every media stream.  The next section explains  Typically the <controls> child element.

4.1.5.1.  <controls>
            aspect ratio of the streams is preserved.
         +  automatic: This option allows the focus to add panels as
            streams are added.

4.3.  <host-info>

   The <controls> <host-info> element contains information about the entity hosting
   the basic audio and video global
   controls for a conference.  It  This information is expected that for the majority of
   the basic conferences, these controls are sufficient.  If the set before conference server wants to support more advanced controls, then it
   activation, and is
   recommended that an extension of the data model be used.  In rarely changed during the
   <controls> conference lifetime.
   The <host-info> element the schema is extensible, hence new control types
   can be added and its child elements are described in the future.  Similarly, controls that apply
   RFC4575[1], section 5.4.  Future extensions 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 <host-info>
   element may define new values.

4.4.  <conference-state>

   The 'mute' control <conference-state> is used introduced in conjunction with an audio stream to
   cease transmission of associated media.  It has RFC4575 [1].  The
   <conference-state> element contains the <allow-conference-event-
   subscription>, <user-count>, <active>, and <locked> child elements.

4.4.1.  <allow-conference-event-subscription>

   The <allow-conference-event-subscription> element represents a "boolean" value.
   boolean action.  If this control is not specified, access set to TRUE, the control focus is not
   available instructed to allow the client and media SHOULD NOT be transported
   subscription to conference state events, such as RFC4575 'SIP Event
   Package for Conference State' [1].  If set to FALSE, the
   associated media stream.

4.1.5.1.2.  pause-video

   The 'pause-video' control is used in conjunction with a video stream subscription
   to cease transmission of associated media.  It has a "boolean" value. conference state events would be rejected.  If this control is not specified, access to the control element is not
   available to
   undefined it has a default value of TRUE, causing the client and media SHOULD NOT subscription to
   conference state events to be transported for the
   associated media stream. accepted.

4.4.2.  <user-count>

   The <user-count> child element is explained in RFC 4575 [1], section
   5.5.1.

4.4.3.  <active>

   The <active> child element is explained in RFC 4575 [1], section
   5.5.2.







Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 17] 18]

Internet-Draft              Data Model Schema                 April               October 2007


4.1.5.1.3.  gain


4.4.4.  <locked>

   The 'gain' control <locked> child element is used explained 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 RFC 4575 [1], section
   5.5.3.

4.5.  <floor-information>

   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 <floor-information> element contains the specified
   layout, then blanking (black screen) <conference-ID>, <allow-
   floor-events>, <floor-request-handling>, and <conference-floor-
   policy> child elements.  Other elements from different namespaces MAY
   be mixed into the stream on present for the behalf purposes of extensibility.  The absence of this
   element from an XML document indicates that the missing input streams.  If unspecified, the <video-
   layout> default type SHOULD be "single-view". conference does not
   have a floor.

4.5.1.  <conference-ID>

   The <layout> types are as follows:

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

   dual-view: This dual view option will present the video side-by-side a 32-bit BFCP conference identifier defined in 2 panels and not alter the aspect ratio of the streams.  This will
   require the focus to introduce blanking on parts of
   RFC4582 [5] section 5.1. that identifies the overall image
   as viewed by BFCP conference the participants.

   dual-view-crop:
   message belongs to.  This side-by-side layout option instructs identifier represents a conference instance
   within floor control.  When created within the focus
   to alter conferencing system,
   the aspect ratio of 'conference-ID' has a 1:1 mapping to the streams (alter-aspect-ratio=TRUE) so
   that blanking is not necessary. unique conference object
   Identifier (XCON-URI).

4.5.2.  <allow-floor-events>

   The focus handles <allow-floor-events> element represents a boolean action.  If set
   to TRUE, the cropping of focus is instructed to accept the streams.

   dual-view-2x1: This layout option instructs subscription to floor
   control events.  If set to FALSE, the focus is instructed to place one
   stream above reject
   the other, in essence with two rows and one column.  In subscription.  If this option the aspect ratio is not altered and blanking element is
   introduced.

   dual-view-2x1-crop: This layout option also instructs undefined, it has a default
   value of FALSE, causing the focus subscription to
   place one stream above the other, in essence with floor control events to
   be rejected.

   There are two rows methods which a conference participant subscribes
   himself to a floor control event.  One method is using an offer/
   answer exchange mechanism (RFC3264 [11]) using SIP INVITE and one
   column.  In this option BFCP
   parameters in the aspect ratio SDP (RFC4583 [12]).  The other method is altered a general
   authorization mechanism described in section 9 of RFC4582 [5] and the video
   streams are cropped.

   quad-view: Four equal-sized panels in a 2x2 layout is presented
   RFC5018 [13].  Future documentation may define additional connection
   mechanisms.

4.5.3.  <floor-request-handling>

   The <floor-request-handling> element defines the actions used by the
   conference focus to all participants.  Typically the aspect ratio of control floor requests.  This element defines the
   streams are maintained (alter-aspect-ratio= FALSE).

   multiple-3x3: Nine equal-sized panels in a 3x3 layout is presented by
   action that the focus is to all participants.  Typically the aspect ratio of the take when processing a particular request
   to a floor within a conference.  This element defines values of:





Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 18] 19]

Internet-Draft              Data Model Schema                 April               October 2007


   streams are preserved.

   multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is presented
   by


   o  "block": This action instructs the focus to all participants.  Typically deny the aspect ratio of floor
      request.  This action is the
   streams are preserved.

   multiple-5x1: default action taken in the absence
      of any other actions.
   o  "confirm": This option refers action instructs the focus to a 5x1 layout where one panel will
   occupy 4/9 of allow the mixed video stream while request.
      The focus then uses the others will each
   occupy 1/9 of defined floor algorithm to further allow
      or deny the stream.  Typically floor.  The algorithms used are outside the aspect ratio scope of
      this document.

   Note that this section discusses floor control information,
   therefore, the streams value "block" in a <floor-request-handling> element is preserved.

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

4.2.  <host-info> "block" value in the <join-handling> element
   (see Section 4.6).

4.5.4.  <conference-floor-policy>

   The <host-info> <conference-floor-policy> element contains is mandatory.  One or more
   <floor> elements can appear in the <conference-floor-policy> element.

   Each <floor> element has the following child elements:

   o  <media-label>: Every floor is identified for one or more mandatory
      <media-label> element.  If the <available-media> information about is
      included in the entity hosting conference document, the value of this element
      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;
   o  <algorithm>: A floor can be controlled using many algorithms; the conference.  This information is
      mandatory <algorithm> element MUST be set before to any of the conference
   activation, and is rarely changed during
      "moderator-controlled", "FCFS" or "random" values indicating the conference lifetime.
      algorithm.  The <host-info> element contains "Moderator-controlled" value indicates that the <display-text>, <web-page> and
   <uris> child elements.
      moderator of the conference controls the floor.  The <display-text> and <web-page> child
   elements are explained in [1]. "FCFS" value
      states for 'first-come-first-served' floor control.
   o  <max-floor-users>: The <uris> child element contains a
   sequence of <max-floor-users> 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 [1] to maintain backwards compatibility with this
   RFC.  Future extensions to the <uris>
      <floor> element may define new values.

4.3.  <conference-state> is optional and, if present, dictates the maximum
      number of users who can have the floor at one time.
   o  <moderator-id>: The <conference-state> element and optional <moderator-id> indicates the <user-count>, <active>, and
   <locked> child elements are explained in section 5.5 'User
      ID' of [1]. the moderator.  The
   <allow-conference-event-subscription> element represents 'User ID' is a boolean
   action.  If BFCP identifier defined
      in RFC4582 [5] section 5.1.  It MUST be set to TRUE, if the focus element
      <algorithm> is instructed to allow the
   subscription to conference state events, such as the SIP Event
   Package for Conference State [1].  If set to FALSE, the subscription "Moderator-controlled" value.  Note that
      RFC4582 [5] refers 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> moderator role as a 'floor chair'.

4.6.  <users>

   The <floor-information> <users> element has the <conference-ID>, <allow-
   floor-events>, <floor-request-handling>, is described in RFC4575 [1] and <conference-floor-
   policy> child elements.  Other elements from different namespaces MAY
   be present for contains the purposes of extensibility.  This element has its
   own XML namespace.  The absence of
   <join-handling>, <user-admission-policy>, and <allowed-users-list>
   defined in this namespace document and its <user> child elements
   from an XML document indicates defined in
   RFC4575[1].  Notice that the conference <users> element does not have a
   floor. the



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 19] 20]

Internet-Draft              Data Model Schema                 April               October 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


   attribute 'state' defined in RFC4575[1] for this element is undefined, it has a default
   value of FALSE, causing the subscription to floor control events because this
   attribute only applies to notifications mechanism.  The following
   sections describe these elements in more detail.  Other child
   elements and attributes can be rejected. used to extend <users> in the future.

4.6.1.  <join-handling>

   The <floor-request-handling> <join-handling> element defines the actions used by the
   conference focus to control floor requests. conference participation.  This element
   defines the action that the focus is to take when processing a
   particular request to a floor within join a conference.  This element defines values
   of:
   o  "block": This action instructs the focus to deny access to the floor
      request.
      conference.  This action is the default action taken in the
      absence of any other actions.
   o  "confirm": This action instructs the focus to allow 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 place 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 on a pending list (e.g., by parking the
   <conference-floor-policy> element.  Every floor is defined using call on a
      music-on-hold server), awaiting moderator input for further
      actions.
   o  "allow": This action instructs the
   'label' attribute.  If focus to accept the <available-media> information is included
   in conference
      join request and grant access to the conference document, within the value
      instructions specified in the transformations of this attribute MUST be equal
   to rule.
   o  "authenticate": This action instructs the 'label' value focus that the user has
      to provide a combination of username/password.
   o  "directed-operator": This action instructs the corresponding media stream <entry> in focus to direct the
   <available-media> container.
      user to an operator.

4.6.2.  <user-admission-policy>

   The number of those elements indicates
   how many floors <user-admission-policy> is an element that lets an organizer (or
   a participant with appropriate rights) choose a policy for the
   conference can have. that controls how users are allowed into the conference.
   The list of possible values are:

   o  "closedAuthenticated": A floor can 'closedAuthenticated' policy requires
      each conference participant to be used for one
   or more media types; in the mandatory <media-types> element can contain
   zero or more of allowed users list
      (listed under the <video>, <audio>, <application>, <data>
   ,<control>, <message>, and <text> elements indicating <allowed-users-list> XML element) with each
      participant being sufficiently (up to local policy) authenticated.
      Conference join requests for users not in the media allowed users list
      or participants not authenticated should be rejected unless a
      <join-handling> action of 'confirm' is selected in which case the floor.  One type of media can only appear once.  Other media
   types can be defined by extensions.

   A floor can
      user is placed on a pending list as indicated earlier.
   o  "openAuthenticated": An 'openAuthenticated' policy requires each
      conferencing participant to be controlled using many algorithms; the mandatory
   <algorithm> element MUST contain one and only one of sufficiently authenticated (as
      before) but does not restrict which participants can join the <moderator-
   controlled>, <FCFS>, and <random> elements indicating
      conference.  Typically this implies that anyone capable of
      authenticating with the algorithm.

   The <max-floor-users> child element in conferencing system may join the <floor> element is
      conference.



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 20] 21]

Internet-Draft              Data Model Schema                 April               October 2007


   optional and, if present, dictates


   o  "anonymous": An 'anonymous' policy allows any join requests in and
      is the maximum number least restrictive policy.

4.6.3.  <allowed-users-list>

   The <allowed-users-list> child element contains a list of users user URIs,
   PSTN phone numbers, roles, or domains (*@example.com) that the focus
   uses to determine who can have the floor at one time.  The optional <chair-id> indicates
   the BFCP UserID of join the moderator.  It MUST conference, who can be set if invited to
   join a conference, or who the attribute
   moderator-controlled is set focus needs to TRUE.

4.5.  <users> "refer to" the
   conference.  The <users> <allowed-users-list> element contains the <join-handling>, <user-admission-
   policy>, <allowed-users-list>, and <user> includes zero or more
   <target> child elements.

   The <join-handling> element defines the actions used by the
   conference focus to control conference participation.  This child element
   defines includes the action that mandatory
   'uri' attribute and the focus mandatory 'method' attribute.  The same 'uri'
   attribute with different method values can appear in the list more
   than once.

   The 'method' attribute is to take when processing a
   particular request to join a conference.  This element defines values
   of: list with the following values:

   o  "block": This action instructs  "dial-in": The value "dial-in" is used by the focus to deny access to determine
      who can join the conference.  This action is the default action taken in the
      absence
   o  "dial-out": The value "dial-out" contains a list of any other actions. resources that
      the focus will initiate a session with.
   o  "confirm": This action instructs  "refer": The value "refer" is used by the focus to place determine the
      participant on a pending list (e.g.,
      resources that the focus needs to "refer to" the conference.  In
      SIP, this is achieved by parking the call on focus sending a
      music-on-hold server), awaiting moderator input for further
      actions.
   o  "allow": This action instructs REFER request to
      those potential participants.  In a different paradigm, this could
      also mean that the focus sends an SMS or an email to accept the conference
      join request and grant access to referred
      user.  This list can be updated during the conference within lifetime so
      it can be used for mid-conference refers as well.

   The "refer" value differs from the
      instructions specified "dial-out" in the transformations of this rule.
   o  "IVR": This action instructs the focus that the user has resources
   on the "refer" value are expected to
      provide initiate the PIN code.
   o  "directed-operator": This action instructs session
   establishment toward the focus to direct the
      user to an operator.

   Note themselves.  It is also envisioned
   that placing different users will have different access rights to those lists
   and therefore a value of block for this separation between the two is needed.

4.6.4.  <user> and Its <user> Sub-elements

   The element does not
   guarantee that <user> is described in RFC5475[1] and describes a single
   participant is blocked from joining in the conference.
   Any other rule  The <user> element has an attribute
   'entity'.  Notice that might evaluate to TRUE the <user> element does not have the attribute
   'state' defined in RFC4575[1] for this participant that
   carried an action whose value was higher than "block" would
   automatically grant confirm/allow permission element because this attribute
   only applies to notifications mechanism.

   o  The attribute 'entity' contains a unique conference user
      identifier (XCON_USERID).  Other user identifiers can be
      associated with this conference user identifier and enable the
      conferencing system to correlate and map these multiple
      authenticated user identities 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 single global user identifier.



Novo, et al.               Expires May 3, 2008                 [Page 22]

Internet-Draft              Data Model Schema               October 2007


      Figure 4 illustrates an example using the conference.
   A 'closedAuthenticated' policy requires each conference participant
   to be user
      identifier in the allowed users list (listed under the <allowed-users-
   list> XML element) association 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 user identity defined for BFCP,
      SIP, and H323 user identity.  It should be
   rejected unless noted that a <join-handling> action of 'confirm'
      conferencing system is selected in
   which case the user free to structure such relationships as
      required and this information is placed on a pending list just included as indicated earlier.
   An 'openAuthenticated' policy requires each conferencing participant
   to a guideline that
      can be sufficiently authenticated (as before) but does not restrict used.


                                 +--------------+
                                 |  Conference  |
                                 |     User     |
                                 |  Identifier  |
                                 +--------------+
                                 |    John      |
                                 +------+-------+
                                        |
                                        |
                                        |
                  +---------------------+---------------------+
                  |                     |                     |
          +-------+--------+    +-------+-------+    +--------+-------+
          |  BFCP User ID  |    |  SIP User ID  |    |  H323 User ID  |
          +----------------+    +---------------+    +----------------+
          |   HK37ihdaj    |    |    123674     |    |     928373     |
          +----------------+    +---------------+    +----------------+


                    Figure 4: Conference Object Mapping

   The element <user> element contains the <display-text>, <associated-
   aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>,
   <allow-refer-users-dynamically>, <allow-invite-users-dynamically>,
   <allow-remove-users-dynamically>, and <endpoint>.  The following
   sections describe these elements in more detail.

4.6.4.1.  <display-text>

   The <display-text> child element is explained in RFC 4575 [1],
   section 5.6.1.

4.6.4.2.  <associated-aors>

   The <associated-aors> child element is explained in RFC 4575 [1],
   section 5.6.2.







Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 21] 23]

Internet-Draft              Data Model Schema                 April               October 2007


   which participants can join


4.6.4.3.  <provide-anonymity>

   The <provide-anonymity> element provides anonymity to the conference.  Typically user.  In
   this implies
   that anyone capable case, the focus provides to the rest of authenticating with the conferencing system
   may join participants an
   anonymous identity for that user, for example anonymousX.  This
   element only affects the conference.  An 'anonymous' policy allows any join
   requests in and way the user information is provided to the least restrictive in policies.
   other participants.  The following sections describe real information about the remaining elements user is still
   stored in more
   detail.  Other child elements the data model.  This can be used to extend <conference-
   description> in achieved by using the future.

4.5.1.  <allowed-users-list>

   The <allowed-users-list> child element contains
   <provide-anonymity> element.  It is 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 boolean transformation.  If set
   to
   join a conference, or who TRUE, the focus needs to "refer to" conference participants will see an anonymous identity
   for the
   conference. user.

4.6.4.4.  <roles>

   The <allowed-users-list> element includes zero or more
   <target> child elements.  This <roles> child element includes the mandatory
   'uri' attribute and the mandatory 'method' attribute.  The same 'uri'
   attribute with different method values can appear is explained in the list more
   than once. RFC 4575 [1], section
   5.6.3.

4.6.4.5.  <languages>

   The 'method' attribute <languages> child element is a list with the following
   values: "dial-in", "dial-out", and "refer". explained in RFC 4575 [1], section
   5.6.4.

4.6.4.6.  <cascaded-focus>

   The value "dial-in" <cascaded-focus> child element is
   used by the focus to determine who can join the conference. explained in RFC 4575 [1],
   section 5.6.5.

4.6.4.7.  <allow-refer-users-dynamically>

   The
   value "refer" <allow-refer-users-dynamically> element represents a boolean
   action.  If set to TRUE, a participant is used by allowed to instruct the
   focus to determine refer a user to the resources that conference without modifying the focus needs
   <allowed-users-list> (in SIP terms, a participant is allowed to send
   a REFER request to "refer to" the conference.  In SIP, this is
   achieved by focus which results in 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 user the referrer wishes to join the referred user.  This list can
   be updated during
   conference).  If set to FALSE, the conference lifetime so refer request is rejected.  If
   this element is undefined it can be used for mid-
   conference refers as well.

   The "refer" has a value differs from the "dial-out" in that of FALSE, causing the "dial-out"
   contains refer
   to be rejected.

4.6.4.8.  <allow-invite-users-dynamically>

   The <allow-invite-users-dynamically> element represents a list of resources that boolean
   action.  If set to TRUE, a participant is allowed to instruct the
   focus will initiate to invite a session
   with.  The resources on the "refer" value, on the other hand, are
   expected user to initiate the session establishment toward conference without modifying the focus
   themselves.  It
   <allowed-users-list> list (in SIP terms, a participant is also envisioned that difference users will have
   different access rights allowed to those lists and therefore
   send a separation
   between REFER request to the two is needed.

4.5.2.  <user>

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

   The following elements of <user> are defined in [1], 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 [1], section 5.6.  The
   attribute 'entity' contains a unique conference user identifier.
   Other user identifiers can be associated with this conference focus sending
   an INVITE request to the user the referrer wishes to join the
   conference).  If set to FALSE, the refer request is rejected.  If



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 22] 24]

Internet-Draft              Data Model Schema                 April               October 2007


   identifier and enable


   this element is undefined it has a value of FALSE, causing the conferencing system refer
   to correlate and map
   these multiple authenticated user identities be rejected.

4.6.4.9.  <allow-remove-users-dynamically>

   The <allow-remove-users-dynamically> element represents a boolean
   action.  If set to TRUE, a participant is allowed to instruct the
   focus to remove a single global user
   identifier.  Figure 4 illustrates an example using from the conference
   user identifier in association with without modifying the user identity defined for
   BFCP, SIP, and H323 user identity.  It should be noted that
   ruleset (in SIP terms, a
   conferencing system participant is free allowed to structure such relationships as
   required and this information is just included as send a guideline that
   can be used.


                                 +--------------+
                                 |  Conference  |
                                 |     User     |
                                 |  Identifier  |
                                 +--------------+
                                 |    John      |
                                 +------+-------+
                                        |
                                        |
                                        |
                  +---------------------+---------------------+
                  |                     |                     |
          +-------+--------+    +-------+-------+    +--------+-------+
          |  BFCP User ID  |    |  SIP User ID  |    |  H323 User ID  |
          +----------------+    +---------------+    +----------------+
          |   HK37ihdaj    |    |    123674     |    |     928373     |
          +----------------+    +---------------+    +----------------+


                    Figure 4: Conference Object Mapping

   The <provide-anonymity> element provides anonymity REFER
   request to the user.  In
   this case, the focus provides to the rest of which results in the participants focus sending an
   anonymous identity for that user, for example anonymousX.  This
   element only affects the way the user information is shown BYE
   request to the
   oher participants.  The real information about the user is still
   stored in the data model.  This can be achieved by using referrer wishes to leave the
   <provide-anonymity> element.  It is a boolean transformation. conference).  If
   set to TRUE, the conference participants will see an anonymous identity
   for FALSE, the user whose identity refer request is rejected.  If this element is present in
   undefined it has a value of FALSE, causing the conditions. refer to be rejected.

4.6.4.10.  <endpoint>

   The <endpoint> child element is defined in RFC4575[1].  It 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 RFC4575 [1]: <display-text>,
   <referred>, <status>, <joining-method>, <joining-info>,
   <disconnection-method>, <disconnection-info>, <media>, and <call-info>.  The <call-
   info>.  Notice that the <endpoint> element does not have the
   attribute 'state' defined in RFC4575[1] for this element because this
   attribute only applies to notifications mechanism.

   Besides the <endpoint>/<media> child elements defined in RFC 4575[1],
   the <endpoint>/<media> element has two other child elements: <to-mixer>, <to-
   mixer>, and <from-mixer> described in the



Novo, et al.            Expires October 19, 2007               [Page 23]

Internet-Draft              Data Model Schema                 April 2007 following section.

4.5.2.1. list:

   o  <from-mixer>, <to-mixer>

   Similar to the controls defined in the <available-media> element, <to-mixer>: These are controls that apply to a particular user appear at this place in
      user's media stream being sent from the
   data structure. mixer to the participants
      endpoint or to the mixer from the participants endpoint.  The <to-mixer> <to-
      mixer> element details properties associated with the incoming
      streams to the mixer. mixer (streams sent to the mixer from the
      participant).  The <from-mixer> element details properties
      associated with the outgoing streams from the
   mixer. mixer (sent from the
      mixer to the participant).  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> elements:





Novo, et al.               Expires May 3, 2008                 [Page 25]

Internet-Draft              Data Model Schema               October 2007


      *  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 this control
         is not specified, this user SHOULD NOT specify the floor
         option.

4.5.3.
      *  Controls that apply to a specific user would appear under the
         <controls> element.

4.7.  <sidebars-by-ref>

   The <sidebars-by-ref> element contains a set of <entry> child
   elements.  Each <entry> child  This element contains a <user> child is described in RFC4575 [1], 5.9.1.  Notice
   that the <sidebars-by-ref> element
   with a sidebar unique conference user identifier and a <display-text>
   child element.

4.5.4. does not have the attribute
   'state' defined in RFC4575[1] for this element because this attribute
   only applies to notifications mechanism.

4.8.  <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)  This
   element is described in RFC4575 [1], 5.9.2.  Notice that the body of
   <sidebars-by-val> element does not have the
   main conference document.





Novo, et al.            Expires October 19, 2007               [Page 24]

Internet-Draft              Data Model Schema                 April 2007 attribute 'state' defined
   in RFC4575[1] for this element because this attribute only applies to
   notifications mechanism.


5.  RELAX NG Schema

   In accordance with the XCON framework Centralized Conferencing Framework document
   [4], 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. format
   [14].

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

   start = element conference-info { conference-type }
   # CONFERENCE TYPE
   conference-type =



Novo, et al.               Expires May 3, 2008                 [Page 26]

Internet-Draft              Data Model Schema               October 2007


     attribute entity { text },
     attribute version { xsd:unsignedInt }?,
     attribute state { state-type }?,
     anyAttribute,
     conference-description-type,
     element host-info { host-type conference-info-urn* }?,
     element conference-state { conference-state-type }?,
     element floor-information { floor-information-type }?,
     element users { users-type },
     element sidebars-by-ref { sidebars-by-ref-type }?,
     element sidebars-by-val { sidebars-by-val-type }?,
     anyElement*
   # CONFERENCE DESCRIPTION TYPE
   conference-description-type =
     element conference-description {
       attribute xml:lang lang { xsd:language }?,
       attribute state { state-type }?,
       anyAttribute,
       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 conference-info-urn* }?,
       element service-uris { uris-type conference-info-urn* }?,
       element maximum-user-count { xsd:int }?,
       element available-media { conference-media-type }?,
       anyElement*



Novo, et al.            Expires October 19, 2007               [Page 25]

Internet-Draft              Data Model Schema                 April 2007
     }
   # CONFERENCE TIME
   conferencetime-type =
     anyAttribute,
     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 {



Novo, et al.               Expires May 3, 2008                 [Page 27]

Internet-Draft              Data Model Schema               October 2007


         xsd:dateTime { pattern = ".+T.+Z.*" }
       }?,
       element notify-end-of-conference { xsd:int }?,
       element allowed-extend-mixing-end-offset {
         allowed-extend-mixing-values xsd:boolean }?,
       anyElement*
     }*,
     anyElement*
   # ALLOWED EXTEND MIXING VALUES
   allowed-extend-mixing-values =
     xsd:string "allowed" | xsd:string "denied"
   # URIS TYPE
   uris-type =
     attribute state { state-type }?,
     (element entry { uri-type }*
      & element H323 { H323-type }*
      & element PSTN-ISDN { PSTN-type }*),
     anyElement*
   # SIP TYPE
   uri-type =
     (element uri { xsd:anyURI },
      element display-text { text }?,
      element purpose { text }?,
      anyElement*)*
   # H323 TYPE
   H323-type =
     element H.323-alias { text }?,
     element H.323-URI { xsd:anyURI }?,



Novo, et al.            Expires October 19, 2007               [Page 26]

Internet-Draft              Data Model Schema                 April 2007


     anyElement*
   # PSTN TYPE
   PSTN-type =
     attribute PIN-code { xsd:unsignedInt },
     attribute purpose { xsd:unsignedInt },
     (element phone-number { xsd:unsignedInt },
      anyElement*)+
   # CONFERENCE MEDIA TYPE
   conference-media-type =
     attribute state { state-type }?,
     anyAttribute,
     element entry { conference-medium-type }*,
     anyElement*
   # CONFERENCE MEDIUM TYPE
   conference-medium-type =
     attribute label { text },
     anyAttribute,
     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 =
     attribute state { state-type }?,
     anyAttribute,
     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 =
     attribute decision { decision-type },
     anyAttribute,
     element codec { codec-type }*,
     anyElement*
   # CODEC TYPE
   codec-type =
     attribute name { text },
     attribute policy { policy-type } },
     anyAttribute
   # DECISION TYPE
   decision-type =
     xsd:string "automatic" | xsd:string "moderator-controlled"
   # POLICY TYPE
   policy-type = xsd:string "allowed" | xsd:string "disallowed"
   # CONTROL TYPE



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 27] 28]

Internet-Draft              Data Model Schema                 April               October 2007


   policy-type = xsd:string "allowed" | xsd:string "disallowed"
   # CONTROL TYPE
   control-type =
     element
     anyAttribute,
     (element mute { xsd:boolean }
      | element pause-video { xsd:boolean }
      | 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 =
     (element display-text { text },
      element web-page { xsd:anyURI },
      element uris { uris-type },
      anyElement*)* anyElement*)
   # CONFERENCE STATE TYPE
   conference-state-type =
     anyAttribute,
     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 =
     anyAttribute,
     (element conference-ID { xsd:unsignedInt },
      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 =
     anyAttribute,
     element floor {
       attribute moderator-controlled { xsd:boolean },
       attribute label { text },
       anyAttribute,
       (element media-types {



Novo, et al.            Expires October 19, 2007               [Page 28]

Internet-Draft              Data Model Schema                 April 2007


          xsd:string "video"
          | xsd:string "audio"
          | xsd:string "application"
          | xsd:string "data"
          | xsd:string "control"
          | xsd:string "message"
          | xsd:string "text"
        },
       element media-label { xsd:nonNegativeInteger }+,
       (element algorithm {
          xsd:string "moderator-controlled"



Novo, et al.               Expires May 3, 2008                 [Page 29]

Internet-Draft              Data Model Schema               October 2007


          | xsd:string "FCFS"
          | xsd:string "random"
        },
        element max-floor-users { xsd:nonNegativeInteger },
        element chair-id moderator-id { xsd:anyURI text },
        anyElement*)*
     }+
   # USERS TYPE
   users-type =
     attribute state { state-type }?,
     anyAttribute,
     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" "confirm"
     | xsd:string "confirm" "allow"
     | xsd:string "IVR" "authenticate"
     | xsd:string "directed-operator"
   # USERLIST
   UserList =
     anyAttribute,
     element target { target-type }*,
     anyElement*
   # TARGET TYPE
   target-type =
     attribute uri { xsd:anyURI },
     attribute method { method-type } },
     anyAttribute
   # METHOD TYPE
   method-type =



Novo, et al.            Expires October 19, 2007               [Page 29]

Internet-Draft              Data Model Schema                 April 2007
     xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer"
   # USER TYPE
   user-type =
     attribute entity { xsd:anyURI },
     attribute state { state-type }?,
     anyAttribute,
     element display-text { text }?,
     element associated-aors { uris-type conference-info-urn* }?,
     element provide-anonymity { xsd:boolean }?,



Novo, et al.               Expires May 3, 2008                 [Page 30]

Internet-Draft              Data Model Schema               October 2007


     element roles { roles-type text }?,
     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 =
     attribute entity { text },
     attribute state { state-type }?,
     anyAttribute,
     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 }?,
     element src-id { text }?,
     element status { media-status-type }?,
     element to-mixer { mixer-type }?,
     element from-mixer { mixer-type }?,
     anyElement*
   # MIXER TYPE
   mixer-type =
     attribute state { state-type }?,



Novo, et al.            Expires October 19, 2007               [Page 30]

Internet-Draft              Data Model Schema                 April 2007
     anyAttribute,
     (element floor { xsd:boolean },
      element controls { controls-type })?,
     anyElement*
   # SIDEBARS-BY-REF TYPE
   sidebars-by-ref-type =
     attribute state { state-type }?,
     anyAttribute,
     element entry { uri-type conference-info-urn* }*,
     anyElement*
   # SIDEBARS-BY-VAL TYPE



Novo, et al.               Expires May 3, 2008                 [Page 31]

Internet-Draft              Data Model Schema               October 2007


   sidebars-by-val-type =
     attribute state { state-type }?,
     anyAttribute,
     element entry { conference-type }*,
     anyElement*
   # ROLES_TYPE
   roles-type =
     element entry { single-role-type }*,
     anyElement*
   # SINGLE ROLE TYPE
   single-role-type =
     xsd:string "administrator"
     | xsd:string "creator"
     | xsd:string "moderator"
     | xsd:string "participant"
     | xsd:string "observer" "none"
   # *********************************
   # EXTENSIBILITY OF THE SCHEMA
   # *********************************

   # EXTENSIBILITY ELEMENTS
   anyElement =
     element * {
       (attribute * { text }
        | text
        | anyElement)*
     }
   # EXTENSIBILITY ATTRIBUTES
   anyAttribute =
     attribute * - (entity
                    | version
                    | state
                    | xml:lang lang
                    | required-participant
                    | PIN-code
                    | purpose
                    | role
                    | type
                    | min
                    | max



Novo, et al.            Expires October 19, 2007               [Page 31]

Internet-Draft              Data Model Schema                 April 2007


                    | label
                    | decision
                    | name
                    | policy
                    | moderator-controlled
                    | uri
                    | method
                    | id
                    | domain
                    | local:*
                    | ns2:*) ns1:*) { text }*
   # *************************************************************
   # TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
   #  -  RFC4575 -
   # *************************************************************

   # WILDCARD FOR EVENT-PACKAGE NAMESPACE
   conference-info-urn =
     element ns1:* * - (ns2:* | local:*) {
       mixed {
         (attribute * { text }
          | conference-info-urn)*
       }
   # DEFINITION OF STATE TYPE
   state-type = "full" | "partial" | "deleted"
     }



Novo, et al.               Expires May 3, 2008                 [Page 32]

Internet-Draft              Data Model Schema               October 2007


   # DEFINITION OF ENDPOINT STATUS TYPE
   media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive"
   # ENDPOINT STATUS TYPE
   endpoint-status-type =
     "pending"
     | "dialing-out"
     | "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"


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



Novo, et al.            Expires October 19, 2007               [Page 32]

Internet-Draft              Data Model Schema                 April 2007
   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. urn:ietf:params:xml:ns:xcon-conference-info.

   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, 2007, at 10:30 AM in New York
   City and finishes the same day at 12:30 PM every week.  In this
   example, there are currently 3 participants in a conference, one
   administrator, one moderator, and one participant.  Note that
   sidebars are allowed in this conference and there is one sidebar in
   the conference.  Also note that there is one floor moderator for the
   audio and a different floor moderator for the video.

 <?xml version="1.0" encoding="UTF-8"?>
   <conference-info xmlns="urn:ietf:params:xml:ns:conference-schema"
       entity="conference123@example.com" state="full"> xmlns="urn:ietf:params:xml:ns:xcon-conference-info"
       entity="conference123@example.com">
       <!--
           CONFERENCE DESCRIPTION



Novo, et al.               Expires May 3, 2008                 [Page 33]

Internet-Draft              Data Model Schema               October 2007


       -->

       <conference-description xml:lang="en-us"> 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:20061103T140728Z
 UID:20061103T140728Z-345FDA-carol@example.com
 ORGANIZER:MAILTO:carol@example.com
 DTSTART:20071017T143000Z



Novo, et al.            Expires October 19, 2007               [Page 33]

Internet-Draft              Data Model Schema                 April 2007
 RRULE:FREQ=WEEKLY
 DTEND:20071217T163000Z
 END:VEVENT
 END:VCALENDAR</base>
                   <mixing-start-offset required-participant="moderator"
                      > 2007-10-17T14:29:00Z</mixing-start-offset>
                   <mixing-end-offset required-participant="participant"
                      > 2007-10-17T16:31:00Z</mixing-end-offset>
                   <must-join-before-offset
                      > 2007-10-17T15:30:00Z</must-join-before-offset>
               </entry>
           </conference-time>
           <!--
           CONFERENCE UNIQUE IDENTIFIERS
           -->
           <conf-uris state="full">
               <SIP>
           <conf-uris>
               <entry>
                   <uri>tel:+3585671234</uri>
                   <display-text>Conference Bridge</display-text>
                   <purpose>participation</purpose>
               </SIP>
               <SIP>
                   <uri>http://www.example.comlive.ram</uri>
               </entry>
               <entry>
                   <uri>http://www.example.com/live.ram</uri>
                   <purpose>streaming</purpose>
               </SIP>
               </entry>
           </conf-uris>



Novo, et al.               Expires May 3, 2008                 [Page 34]

Internet-Draft              Data Model Schema               October 2007


           <!--
             SERVICE URIS
           -->
           <service-uris state="full">
               <SIP>
           <service-uris>
               <entry>
                   <uri>http://www.example.com/formula1/</uri>
                   <purpose>web-page</purpose>
               </SIP>
               </entry>
           </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">



Novo, et al.            Expires October 19, 2007               [Page 34]

Internet-Draft              Data Model Schema                 April 2007
                   <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>
       </conference-description>
       <!--
           HOST INFO
         -->
       <host-info>
           <display-text>Formula1</display-text>



Novo, et al.               Expires May 3, 2008                 [Page 35]

Internet-Draft              Data Model Schema               October 2007


           <web-page>http://www.example.com/formula1/</web-page>
           <uris state="full">
               <SIP>
           <uris>
               <entry>
                   <uri>sip:alice@example.com</uri>
               </SIP>
               <SIP>
               </entry>
               <entry>
                   <uri>sip:carol@example.com</uri>
               </SIP>
               </entry>
           </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
         -->



Novo, et al.            Expires October 19, 2007               [Page 35]

Internet-Draft              Data Model Schema                 April 2007
       <floor-information>
           <conference-ID>567</conference-ID>
           <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>
                   <chair-id>sip:alice@example.com</chair-id>
               </floor>
               <floor moderator-controlled="true" label="10235">
                   <media-types>video</media-types>
               <floor>
                   <media-label>10234</media-label>
                   <media-label>10235</media-label>
                   <algorithm>moderator-controlled</algorithm>
                   <max-floor-users>1</max-floor-users>
                   <chair-id>sip:carol@example.com</chair-id>
                   <moderator-id>234</moderator-id>
               </floor>
           </conference-floor-policy>
       </floor-information>
       <!--
           USERS
         -->
       <users state="full">
       <users>
           <join-handling>allow</join-handling>
           <user-admission-policy
               >openAuthenticated</user-admission-policy>
           <!--
            ALLOWED USERS LIST
           -->
           <allowed-users-list>
               <target uri="sip:bob@example.com" method="dial-out"/>



Novo, et al.               Expires May 3, 2008                 [Page 36]

Internet-Draft              Data Model Schema               October 2007


               <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>
           <!--
             USER BOB
           -->
           <user entity="bob534" state="partial"> entity="bob534">
               <display-text>Bob Hoskins</display-text>
               <associated-aors state="full">
               <associated-aors>
                   <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>



Novo, et al.            Expires October 19, 2007               [Page 36]

Internet-Draft              Data Model Schema                 April 2007
               <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"> entity="sip:bob@example.com">
                   <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">



Novo, et al.               Expires May 3, 2008                 [Page 37]

Internet-Draft              Data Model Schema               October 2007


                       <label>10235</label>
                       <src-id>432424</src-id>
                   </media>
                   <!--
                       CALL INFO
                   -->
                   <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>

           <!--



Novo, et al.            Expires October 19, 2007               [Page 37]

Internet-Draft              Data Model Schema                 April 2007
               USER ALICE
           -->

           <user entity="alice334" state="full"> entity="alice334">
               <display-text>Alice Kay</display-text>
               <associated-aors state="full">
               <associated-aors>
                   <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"> entity="sip:alice@example.com">
                   <display-text>Alice's Desktop</display-text>
                   <status>connected</status>
                   <joining-method>dialed-in</joining-method>
                   <joining-info>



Novo, et al.               Expires May 3, 2008                 [Page 38]

Internet-Draft              Data Model Schema               October 2007


                       <when>2006-10-17T13:35:08Z</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>



Novo, et al.            Expires October 19, 2007               [Page 38]

Internet-Draft              Data Model Schema                 April 2007
                   <!--
                       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 CAROL
                   -->
           <user entity="carol233" state="full"> entity="carol233">
               <display-text>Carol More</display-text>
               <associated-aors state="full">
               <associated-aors>
                   <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



Novo, et al.               Expires May 3, 2008                 [Page 39]

Internet-Draft              Data Model Schema               October 2007


                   >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:carol@example.com" state="full"> entity="sip:carol@example.com">
                   <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>



Novo, et al.            Expires October 19, 2007               [Page 39]

Internet-Draft              Data Model Schema                 April 2007
                   </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">
       <sidebars-by-ref>



Novo, et al.               Expires May 3, 2008                 [Page 40]

Internet-Draft              Data Model Schema               October 2007


           <entry>
               <uri>sips:conference123;grid=40</uri>
               <uri>conf223</uri>
               <display-text>private with Bob</display-text>
           </entry>
       </sidebars-by-ref>
       <!--
            SIDEBARS BY VALUE
          -->
       <sidebars-by-val>
           <entry entity="conference123;grid=40"> entity="conf223">
               <users>
                   <user entity="bob534"/>
                   <user entity="carol233"/>
               </users>
           </entry>
       </sidebars-by-val>



Novo, et al.            Expires October 19, 2007               [Page 40]

Internet-Draft              Data Model Schema                 April 2007
   </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

   There are numerous security considerations for this document.  This
   section considers them.

8.1.  Authentication

   A malicious user can manipulate parts of the Conference Information
   Data Model privileges document giving themselves and others
   privileges to manipulate others
   privileges to manipulate the document.  It is very important that
   only authorized clients are able to manipulate the Conference
   Information Data Model document.

   The security considerations for authentication (section 10.1)
   described in the centralized conferencing framework [1] applies to
   this document.  The focus must ensure that only authorized entities
   are able to manipulate the data to access the information.

8.2.  Confidentiality

   Participants of a conference may not want to reveal some private
   information to other users.  The Conference Information Data Model
   contains sensitive data which should not be analyzed or given to
   anyone.  Confidentiality is provided through encryption.  Strong end-



Novo, et al.               Expires May 3, 2008                 [Page 41]

Internet-Draft              Data Model Schema               October 2007


   to-end authentication and encryption can be done using public keys,
   and end-to-end encryption can be done using private keys.  It is
   RECOMMENDED that the protocols that manipulated the conference
   information data model. model use a strong encryption for conference
   information protection.

8.3.  Integrity

   It is very important that the Conference Information Data Model can only
   be accessed or modified by those authorized clients are able to manipulate users.  Without
   integrity, the Conference Information Data Model document.  Any conference control protocol
   MUST provide authentication, confidentiality and integrity. could be modified,
   fooling the user into believing incorrect information.  Measures
   taken to ensure integrity include maintaining rigorous authentication
   practices.


9.  IANA Considerations

9.1.  Conference Relax NG Schema Registration


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

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

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

        and its last line is

     disconnection-type = "departed" | "booted" | "failed" | "busy"


9.2.  Conference Namespace Registration

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

9.3.  Conference Object Identifier Registration



    XCON_URI = "xcon" ":" [conf-object-id "@"] hostport
                              ; hostport as defined in RFC3261 host [ ":" port ]

    conf-object-id = 1*( unreserved / "+" / "=" / "/" )
                              ;


   host, port, and unreserved as are defined in RFC3986 RFC3986[15]




Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 41] 42]

Internet-Draft              Data Model Schema                 April               October 2007


9.4.  Conference User Identifier Registration



    XCON_USERID = "xcon_userid" ":" conf-object-id

    conf-object-id = 1*( unreserved / "+" / "=" / "/" )
                              ;


   unreserved as is defined in RFC3986 RFC3986[15]


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, Hisham Khartabil, Petri Koskelainen, Aki
   Niemi, and Jari Urpilainen Urpilainen, Rohan Mahy, and Henning Schulzrinne for their
   comments.  Also, We we would like to thank Mary Barnes, and Chris
   Boulton for letting us use the conference and user identifier
   information of their xcon drafts.  Last but not least, I would like
   to express my gratitude to all those reviewers for their invaluable
   contribution: Simon Pietro Romano, Lorenzo Miniero, Tobia Castaldi,
   Miguel Garcia, Mary Barnes, Srivatsa Srinivasan, Avshalom Houri, and
   Ben Campbell.


11.  References

11.1.  Normative References

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

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

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

11.2.  Informative References

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



Novo, et al.               Expires May 3, 2008                 [Page 43]

Internet-Draft              Data Model Schema               October 2007


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

   [6]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event



Novo, et al.            Expires October 19, 2007               [Page 42]

Internet-Draft              Data Model Schema                 April 2007
         Notification", RFC 3265, June 2002.

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

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

   [9]   Casner, S., "Media Type Registration of RTP Payload Formats",
         RFC 4855, February 2007.

   [10]  "IANA registry for RTP Payload Types"
         "http://www.iana.org/assignments/rtp-parameters".

   [11]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [12]  Camarillo, G., "Session Description Protocol (SDP) Format for
         Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
         November 2006.

   [13]  Camarillo, G., "Connection Establishment in the Binary Floor
         Control Protocol (BFCP)", RFC 5018, September 2007.

   [14]  "RELAX NG Home Page" "http://relaxng.org/".

   [15]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.


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" ns="urn:ietf:params:xml:ns:xcon-conference-info"
    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>



Novo, et al.               Expires May 3, 2008                 [Page 44]

Internet-Draft              Data Model Schema               October 2007


    </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> name="anyAttribute"/>
     <ref name="conference-description-type"/>
     <optional>
      <element name="host-info">
        <zeroOrMore>
         <ref name="host-type"/> name="conference-info-urn"/>
        </zeroOrMore>
      </element>
     </optional>
     <optional>
     <element name="conference-state">



Novo, et al.            Expires October 19, 2007               [Page 43]

Internet-Draft              Data Model Schema                 April 2007
       <ref name="conference-state-type"/>
     </element>
     </optional>
     <optional>
      <element name="floor-information">
       <ref name="floor-information-type"/>
      </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">



Novo, et al.               Expires May 3, 2008                 [Page 45]

Internet-Draft              Data Model Schema               October 2007


     <element name="conference-description">
      <optional>
       <attribute name="xml:lang"> name="lang">
        <data type="language"/>
       </attribute>
      </optional>
      <optional>
       <attribute name="state">
      <ref name="state-type"/>
       </attribute>
      </optional> name="anyAttribute"/>
      <optional>
       <element name="display-text">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="subject">
        <text/>



Novo, et al.            Expires October 19, 2007               [Page 44]

Internet-Draft              Data Model Schema                 April 2007
       </element>
      </optional>
      <optional>
       <element name="free-text">
        <text/>
       </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">
         <zeroOrMore>
          <ref name="uris-type"/> name="conference-info-urn"/>
         </zeroOrMore>
       </element>
      </optional>



Novo, et al.               Expires May 3, 2008                 [Page 46]

Internet-Draft              Data Model Schema               October 2007


      <optional>
       <element name="service-uris">
         <zeroOrMore>
          <ref name="uris-type"/> name="conference-info-urn"/>
         </zeroOrMore>
       </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"/>



Novo, et al.            Expires October 19, 2007               [Page 45]

Internet-Draft              Data Model Schema                 April 2007
      </zeroOrMore>
     </element>
    </define>
    <!--
           CONFERENCE TIME
       -->
    <define name="conferencetime-type">
     <ref name="anyAttribute"/>
     <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">



Novo, et al.               Expires May 3, 2008                 [Page 47]

Internet-Draft              Data Model Schema               October 2007


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



Novo, et al.            Expires October 19, 2007               [Page 46]

Internet-Draft              Data Model Schema                 April 2007
        </element>
       </optional>
       <optional>
        <element name="notify-end-of-conference">
         <data type="int"/>
        </element>
       </optional>
       <optional>
        <element name="allowed-extend-mixing-end-offset">
         <ref name="allowed-extend-mixing-values"/>
         <data type="boolean"/>
        </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
           CONFERENCE MEDIA TYPE
       -->
    <define name="uris-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"/>



Novo, et al.            Expires October 19, 2007               [Page 47]

Internet-Draft              Data Model Schema                 April 2007


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



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 48]

Internet-Draft              Data Model Schema                 April               October 2007


     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           PSTN TYPE
       -->
    <define name="PSTN-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>

    <!--
           CONFERENCE MEDIA TYPE
       -->
    <define name="conference-media-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">
     <attribute name="label">



Novo, et al.            Expires October 19, 2007               [Page 49]

Internet-Draft              Data Model Schema                 April 2007
      <text/>
     </attribute>
     <ref name="anyAttribute"/>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="type">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="status">
       <ref name="media-status-type"/>
      </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">
     <optional>
      <attribute name="state">
       <ref name="state-type"/>



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 50] 49]

Internet-Draft              Data Model Schema                 April               October 2007


      </attribute>
     </optional>


     </zeroOrMore>
    </define>
    <!--
           CONTROLS TYPE
       -->
    <define name="controls-type">
     <ref name="anyAttribute"/>
     <zeroOrMore>
      <element name="control">
       <ref name="control-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           MIX MODE TYPE
       -->
    <define name="mix-mode-type">
     <choice>
      <value type="string">moderator-controlled</value>
      <value type="string">FCFS</value>
      <value type="string">automatic</value>
     </choice>
    </define>
    <!--
           CODECS TYPE
       -->
    <define name="codecs-type">
     <attribute name="decision">
      <ref name="decision-type"/>
     </attribute>
     <ref name="anyAttribute"/>
     <zeroOrMore>
      <element name="codec">
       <ref name="codec-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CODEC TYPE
       -->
    <define name="codec-type">
     <attribute name="name">
      <text/>
     </attribute>
     <attribute name="policy">
      <ref name="policy-type"/>
     </attribute>
    </define>



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 51] 50]

Internet-Draft              Data Model Schema                 April               October 2007


      <text/>
     </attribute>
     <attribute name="policy">
      <ref name="policy-type"/>
     </attribute>
     <ref name="anyAttribute"/>
    </define>
    <!--
           DECISION TYPE
       -->
    <define name="decision-type">
     <choice>
      <value type="string">automatic</value>
      <value type="string">moderator-controlled</value>
     </choice>
    </define>
    <!--
           POLICY TYPE
       -->
    <define name="policy-type">
     <choice>
      <value type="string">allowed</value>
      <value type="string">disallowed</value>
     </choice>
    </define>
    <!--
           CONTROL TYPE
       -->
    <define name="control-type">
     <ref name="anyAttribute"/>
     <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>



Novo, et al.               Expires May 3, 2008                 [Page 51]

Internet-Draft              Data Model Schema               October 2007


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



Novo, et al.            Expires October 19, 2007               [Page 52]

Internet-Draft              Data Model Schema                 April 2007
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </choice>
    </define>
    <!--
           HOST TYPE
       -->
    <define name="host-type">
     <zeroOrMore>
      <element name="display-text">
       <text/>
      </element>
      <element name="web-page">
       <data type="anyURI"/>
      </element>
      <element name="uris">
       <ref name="uris-type"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           CONFERENCE STATE TYPE
       -->
    <define name="conference-state-type">
     <ref name="anyAttribute"/>
     <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>



Novo, et al.            Expires October 19, 2007               [Page 53]

Internet-Draft              Data Model Schema                 April 2007
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           FLOOR INFORMATION TYPE
       -->
    <define name="floor-information-type">
     <ref name="anyAttribute"/>



Novo, et al.               Expires May 3, 2008                 [Page 52]

Internet-Draft              Data Model Schema               October 2007


     <zeroOrMore>
      <element name="conference-ID">
       <data type="unsignedInt"/>
      </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="anyAttribute"/>
     <oneOrMore>
      <element name="floor">
       <attribute name="moderator-controlled">
        <data type="boolean"/>
       </attribute>
       <attribute name="label">
        <text/>
       </attribute>



Novo, et al.            Expires October 19, 2007               [Page 54]

Internet-Draft              Data Model Schema                 April 2007
       <ref name="anyAttribute"/>
       <zeroOrMore>
       <oneOrMore>
        <element name="media-types">
         <choice>
          <value type="string">video</value>
          <value type="string">audio</value>
          <value type="string">application</value>
          <value type="string">data</value>
          <value type="string">control</value>
          <value type="string">message</value>
          <value type="string">text</value>
         </choice> name="media-label">
         <data type="nonNegativeInteger"/>
        </element>
        </oneOrMore>
        <zeroOrMore>
        <element name="algorithm">
         <choice>
          <value type="string">moderator-controlled</value>
          <value type="string">FCFS</value>
          <value type="string">random</value>
         </choice>
        </element>



Novo, et al.               Expires May 3, 2008                 [Page 53]

Internet-Draft              Data Model Schema               October 2007


        <element name="max-floor-users">
         <data type="nonNegativeInteger"/>
        </element>
        <element name="chair-id">
         <data type="anyURI"/> name="moderator-id">
         <text/>
        </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> name="anyAttribute"/>
     <optional>
      <element name="join-handling">
       <ref name="join-handling-type"/>
      </element>
     </optional>
     <optional>



Novo, et al.            Expires October 19, 2007               [Page 55]

Internet-Draft              Data Model Schema                 April 2007
      <element name="user-admission-policy">
       <ref name="user-admission-policy-type"/>
      </element>
     </optional>
     <optional>
      <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>
    <!--



Novo, et al.               Expires May 3, 2008                 [Page 54]

Internet-Draft              Data Model Schema               October 2007


           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> type="string">allow</value>
      <value type="string">authenticate</value>
      <value type="string">directed-operator</value>
     </choice>
    </define>
    <!--
           USERLIST
       -->



Novo, et al.            Expires October 19, 2007               [Page 56]

Internet-Draft              Data Model Schema                 April 2007
    <define name="UserList">
     <ref name="anyAttribute"/>
     <zeroOrMore>
      <element name="target">
       <ref name="target-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           TARGET TYPE
       -->
    <define name="target-type">
     <attribute name="uri">
      <data type="anyURI"/>
     </attribute>
     <attribute name="method">
      <ref name="method-type"/>
     </attribute>
     <ref name="anyAttribute"/>
    </define>
    <!--



Novo, et al.               Expires May 3, 2008                 [Page 55]

Internet-Draft              Data Model Schema               October 2007


           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">
     <attribute name="entity">
      <data type="anyURI"/>
     </attribute>
     <optional>
      <attribute name="state">
     <ref name="state-type"/>
      </attribute>
     </optional> name="anyAttribute"/>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>



Novo, et al.            Expires October 19, 2007               [Page 57]

Internet-Draft              Data Model Schema                 April 2007
     <optional>
      <element name="associated-aors">
       <zeroOrMore>
        <ref name="uris-type"/> name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <optional>
      <element name="provide-anonymity">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="roles">
       <ref name="roles-type"/>
       <text/>
      </element>
     </optional>
     <optional>
      <element name="languages">
       <list>
        <data type="language"/>
       </list>
      </element>
     </optional>
     <optional>
      <element name="cascaded-focus">



Novo, et al.               Expires May 3, 2008                 [Page 56]

Internet-Draft              Data Model Schema               October 2007


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



Novo, et al.            Expires October 19, 2007               [Page 58]

Internet-Draft              Data Model Schema                 April 2007
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ENDPOINT TYPE
       -->
    <define name="endpoint-type">
     <attribute name="entity">
      <text/>
     </attribute>
     <optional>
      <attribute name="state">
     <ref name="state-type"/>
      </attribute>
     </optional> name="anyAttribute"/>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="referred">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <optional>



Novo, et al.               Expires May 3, 2008                 [Page 57]

Internet-Draft              Data Model Schema               October 2007


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



Novo, et al.            Expires October 19, 2007               [Page 59]

Internet-Draft              Data Model Schema                 April 2007
     </optional>
     <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">



Novo, et al.               Expires May 3, 2008                 [Page 58]

Internet-Draft              Data Model Schema               October 2007


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



Novo, et al.            Expires October 19, 2007               [Page 60]

Internet-Draft              Data Model Schema                 April 2007
      <element name="label">
       <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">
     <optional>
      <attribute name="state">
     <ref name="state-type"/>
      </attribute>
     </optional> name="anyAttribute"/>



Novo, et al.               Expires May 3, 2008                 [Page 59]

Internet-Draft              Data Model Schema               October 2007


     <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 October 19, 2007               [Page 61]

Internet-Draft              Data Model Schema                 April 2007
    </define>
    <!--
           SIDEBARS-BY-REF TYPE
       -->
    <define name="sidebars-by-ref-type">
     <optional>
      <attribute name="state">
     <ref name="state-type"/>
      </attribute>
     </optional> name="anyAttribute"/>
     <zeroOrMore>
      <element name="entry">
       <zeroOrMore>
        <ref name="uri-type"/> name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           SIDEBARS-BY-VAL TYPE
       -->
    <define name="sidebars-by-val-type">
     <optional>
      <attribute name="state">
     <ref name="state-type"/>
      </attribute>
     </optional> name="anyAttribute"/>
     <zeroOrMore>
      <element name="entry">
       <ref name="conference-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ROLES_TYPE
           SINGLE ROLE TYPE
       -->
    <define name="roles-type">
     <zeroOrMore>
      <element name="entry">
       <ref name="single-role-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/> name="single-role-type">
     <choice>
      <value type="string">administrator</value>



Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 62] 60]

Internet-Draft              Data Model Schema                 April               October 2007


     </zeroOrMore>
    </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> type="string">none</value>
     </choice>
    </define>
    <!--
           *********************************
           EXTENSIBILITY OF THE SCHEMA
           *********************************
       -->
    <!--
           EXTENSIBILITY ELEMENTS
       -->
    <define name="anyElement">
     <element>
      <anyName/>
      <zeroOrMore>
       <choice>
        <attribute>
         <anyName/>
        </attribute>
        <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>



Novo, et al.            Expires October 19, 2007               [Page 63]

Internet-Draft              Data Model Schema                 April 2007 ns="">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>
         <nsName ns=""/>
         <nsName ns="urn:ietf:params:xml:ns:conference-schema"/> ns="urn:ietf:params:xml:ns:xcon-conference-info"/>
        </except>



Novo, et al.               Expires May 3, 2008                 [Page 61]

Internet-Draft              Data Model Schema               October 2007


       </anyName>
       <text/>
      </attribute>
     </zeroOrMore>
    </define>
    <!--
           *************************************************************
           TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
           -  RFC4575 -
           *************************************************************
       -->
    <!--
           WILDCARD FOR EVENT-PACKAGE NAMESPACE
       -->
    <define name="conference-info-urn">
     <element>
      <anyName>
       <except>
      <nsName ns="urn:ietf:params:xml:ns:conference-info"/>
        <nsName ns="urn:ietf:params:xml:ns:conference-info-urn"/> ns=""/>
       </except>
      </anyName>
      <mixed>
      <zeroOrMore>
        <choice>
         <attribute>
          <anyName/>
         </attribute>
         <ref name="conference-info-urn"/>
        </choice>
       </zeroOrMore>
      </mixed>
     </element>
    </define>

    <!--
           DEFINITION OF STATE TYPE
       -->



Novo, et al.            Expires October 19, 2007               [Page 64]

Internet-Draft              Data Model Schema                 April 2007


    <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 May 3, 2008                 [Page 62]

Internet-Draft              Data Model Schema               October 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>

   </grammar>














Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 65] 63]

Internet-Draft              Data Model Schema                 April               October 2007


     <choice>
      <value>departed</value>
      <value>booted</value>
      <value>failed</value>
      <value>busy</value>
     </choice>
    </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 October 19, 2007               [Page 66]

Internet-Draft              Data Model Schema                 April 2007


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   Email: roni.even@polycom.co.il















Novo, et al.               Expires October 19, 2007 May 3, 2008                 [Page 67] 64]

Internet-Draft              Data Model Schema                 April               October 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 October 19, 2007 May 3, 2008                 [Page 68] 65]


----