[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-novo-xcon-common-data-model) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 RFC 6501

XCON                                                             O. Novo
Internet-Draft                                              G. Camarillo
Intended status: Standards Track                                Ericsson
Expires: May 1, 2009                                           D. Morgan
                                                    Fidelity Investments
                                                                 R. Even
                                                                 Polycom
                                                           J. Urpalainen
                                                                   Nokia
                                                        October 28, 2008


 Conference Information Data Model for Centralized Conferencing (XCON)
                draft-ietf-xcon-common-data-model-12.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 May 1, 2009.

Abstract

   This document defines an Extensible Markup Language (XML)-based
   conference information data model for centralized conferencing
   (XCON).  A conference information data model is designed to convey
   information about the conference and about participation in the
   conference.  The conference information data model defined in this
   document constitutes an extension of the data format specified in the



Novo, et al.               Expires May 1, 2009                  [Page 1]


Internet-Draft              Data Model Schema               October 2008


   Session Initiation Protocol (SIP) Event Package for Conference State.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Data Model Format  . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Data Model Namespace . . . . . . . . . . . . . . . . . . .  6
     3.3.  The Conference Object Identifier . . . . . . . . . . . . .  7
       3.3.1.  Conference Object URI Definition . . . . . . . . . . .  9
     3.4.  Data Model Structure . . . . . . . . . . . . . . . . . . .  9
   4.  Data Model Definition  . . . . . . . . . . . . . . . . . . . . 10
     4.1.  <conference-info>  . . . . . . . . . . . . . . . . . . . . 13
     4.2.  <conference-description> . . . . . . . . . . . . . . . . . 14
       4.2.1.  <language> . . . . . . . . . . . . . . . . . . . . . . 14
       4.2.2.  <display-text> . . . . . . . . . . . . . . . . . . . . 14
       4.2.3.  <subject>  . . . . . . . . . . . . . . . . . . . . . . 14
       4.2.4.  <free-text>  . . . . . . . . . . . . . . . . . . . . . 14
       4.2.5.  <keywords> . . . . . . . . . . . . . . . . . . . . . . 15
       4.2.6.  <allow-sidebars> . . . . . . . . . . . . . . . . . . . 15
       4.2.7.  <conference-time>  . . . . . . . . . . . . . . . . . . 15
       4.2.8.  <conf-uris>  . . . . . . . . . . . . . . . . . . . . . 16
       4.2.9.  <service-uris> . . . . . . . . . . . . . . . . . . . . 16
       4.2.10. <maximum-user-count> . . . . . . . . . . . . . . . . . 16
       4.2.11. <available-media>  . . . . . . . . . . . . . . . . . . 17
     4.3.  <host-info>  . . . . . . . . . . . . . . . . . . . . . . . 19
     4.4.  <conference-state> . . . . . . . . . . . . . . . . . . . . 19
       4.4.1.  <allow-conference-event-subscription>  . . . . . . . . 19
       4.4.2.  <user-count> . . . . . . . . . . . . . . . . . . . . . 19
       4.4.3.  <active> . . . . . . . . . . . . . . . . . . . . . . . 19
       4.4.4.  <locked> . . . . . . . . . . . . . . . . . . . . . . . 20
     4.5.  <floor-information>  . . . . . . . . . . . . . . . . . . . 20
       4.5.1.  <conference-ID>  . . . . . . . . . . . . . . . . . . . 20
       4.5.2.  <allow-floor-events> . . . . . . . . . . . . . . . . . 20
       4.5.3.  <floor-request-handling> . . . . . . . . . . . . . . . 20
       4.5.4.  <conference-floor-policy>  . . . . . . . . . . . . . . 21
     4.6.  <users>  . . . . . . . . . . . . . . . . . . . . . . . . . 22
       4.6.1.  <join-handling>  . . . . . . . . . . . . . . . . . . . 22
       4.6.2.  <user-admission-policy>  . . . . . . . . . . . . . . . 22
       4.6.3.  <allowed-users-list> . . . . . . . . . . . . . . . . . 23
       4.6.4.  <deny-users-list>  . . . . . . . . . . . . . . . . . . 24
       4.6.5.  <user> and Its <user> Sub-elements . . . . . . . . . . 24
         4.6.5.1.  <display-text> . . . . . . . . . . . . . . . . . . 25
         4.6.5.2.  <associated-aors>  . . . . . . . . . . . . . . . . 25
         4.6.5.3.  <provide-anonymity>  . . . . . . . . . . . . . . . 25
         4.6.5.4.  <roles>  . . . . . . . . . . . . . . . . . . . . . 26



Novo, et al.               Expires May 1, 2009                  [Page 2]


Internet-Draft              Data Model Schema               October 2008


         4.6.5.5.  <languages>  . . . . . . . . . . . . . . . . . . . 26
         4.6.5.6.  <cascaded-focus> . . . . . . . . . . . . . . . . . 26
         4.6.5.7.  <allow-refer-users-dynamically>  . . . . . . . . . 26
         4.6.5.8.  <allow-invite-users-dynamically> . . . . . . . . . 26
         4.6.5.9.  <allow-remove-users-dynamically> . . . . . . . . . 27
         4.6.5.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 27
     4.7.  <sidebars-by-ref>  . . . . . . . . . . . . . . . . . . . . 28
     4.8.  <sidebars-by-val>  . . . . . . . . . . . . . . . . . . . . 28
   5.  RELAX NG Schema  . . . . . . . . . . . . . . . . . . . . . . . 28
   6.  XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 39
   7.  XML Example  . . . . . . . . . . . . . . . . . . . . . . . . . 39
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 49
     8.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 49
     8.2.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 49
     8.3.  Integrity  . . . . . . . . . . . . . . . . . . . . . . . . 50
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 50
     9.1.  Relax NG Schema Registration . . . . . . . . . . . . . . . 50
     9.2.  XML Namespace Registration . . . . . . . . . . . . . . . . 50
     9.3.  Conference Object Identifier Registration  . . . . . . . . 51
     9.4.  Conference User Identifier Registration  . . . . . . . . . 52
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 53
     11.2. Informative References . . . . . . . . . . . . . . . . . . 53
   Appendix A.  Non-Normative RELAX NG Schema in XML Syntax . . . . . 54
   Appendix B.  Non-Normative W3C XML Schema  . . . . . . . . . . . . 81
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90
   Intellectual Property and Copyright Statements . . . . . . . . . . 92























Novo, et al.               Expires May 1, 2009                  [Page 3]


Internet-Draft              Data Model Schema               October 2008


1.  Introduction

   There is a core data set of conference information that is utilized
   in any conference, independent of the specific conference media.
   This core data set called the 'conference information data model' is
   defined in this document using an Extensible Markup Language (XML)-
   based.  The conference information data model defined in this
   document is logically represented by the conference object.

   Conference objects are a fundamental concept in Centralized
   Conferencing, as described in the Centralized Conferencing Framework
   [RFC5239].  A conference object contains data that represents a
   conference during each of its various stages (e.g., created/creation,
   reserved/reservation, active/activation, completed/completion).  A
   conference object can be manipulated using a conference control
   protocol at a conference server.  The conference object represents a
   particular instantiation of a conference information data model.
   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, 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 server
   as defined by the Centralized Conferencing Framework [RFC5239].  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
   [RFC4582]) 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 interface between a call
   signaling client and a Focus.  A notification protocol (e.g., SIP-
   based event notifications [RFC3265]) 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 May 1, 2009                  [Page 4]


Internet-Draft              Data Model Schema               October 2008


      ...............................................................
      . 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    |Floor         |Call      |Notification
              |Control       |Control       |Signaling |Protocol
              |Protocol      |Protocol      |Protocol  |
      ........v..............v..............v..........v.............
      .     C  o  n  f  e  r  e  n  c  i  n  g     C  l i  e  n  t  .
      ...............................................................

                 Figure 1: Conference Server Architecture



Novo, et al.               Expires May 1, 2009                  [Page 5]


Internet-Draft              Data Model Schema               October 2008


   The Session Initiation Protocol (SIP) Event Package for Conference
   State, specified in [RFC4575], already defines a data format for
   conferences.  However, that model is SIP specific and lacks elements
   related to some of the functionality defined by the Centralized
   Conferencing Framework [RFC5239] (e.g., floor control).  The data
   model defined in this document constitutes a superset of the data
   format defined in [RFC4575].  The result is a data format that
   supports more call signaling protocols besides SIP and that covers
   all the functionality defined in the Centralized Conferencing
   Framework [RFC5239].


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

   This document uses the terminology defined in the Centralized
   Conferencing Framework [RFC5239], the SIPPING conferencing framework
   [RFC4353] and the BFCP (Binary Floor Control Protocol) specification
   [RFC4582].  Readers of this document should be familiar with the
   terminology used in those documents.


3.  Overview

   The data model specified in this document is the result of extending
   the data format defined in [RFC4575] with new elements.  Examples of
   such extensions include scheduling elements, media control elements,
   floor control elements, non-SIP URIs, and addition of localization
   extensions to text elements.  This data model can be used by
   conference servers providing different types of basic conferences.
   It is expected that this data model can be further extended with new
   elements in the future in order to implement additional advanced
   features.

3.1.  Data Model Format

   A conference object document is an XML [W3C.REC-xml-20001006]
   document that MUST be well formed and SHOULD 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 elements defined in the data model.  This namespace



Novo, et al.               Expires May 1, 2009                  [Page 6]


Internet-Draft              Data Model Schema               October 2008


   is as follows:

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

3.3.  The Conference Object Identifier

   The conference object identifier (XCON-URI) can be viewed as a key to
   accessing a specific conference object.  It can be used, for
   instance, by the conference control protocol to access, manipulate
   and delete a conference object.  A conference object identifier is
   provided to the conferencing client by the conference notification
   service or through out-of-band mechanisms (e.g.  E-Mail).

   A 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 maintenance
   of these relationships, the conference object identifier acts as a
   top level identifier within the conferencing system for the purpose
   of identifying the interfaces for these other protocols.  This
   implicit binding provides a 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).



























Novo, et al.               Expires May 1, 2009                  [Page 7]


Internet-Draft              Data Model Schema               October 2008


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

                    Figure 2: Conference Object Mapping

   In Figure 2, the conference object identifier acts as the top level
   key in the identification process.  The call signaling protocols have
   an associated conference user identifier, often represented in the
   form of URIs.  The binary floor control protocol, as defined in
   [RFC4582], defines the 'conference ID' identifier which represents a
   conference instance within floor control.  When created within the
   conferencing system, the 'conference ID' has a 1:1 mapping to the
   unique conference object Identifier(XCON-URI).  Operations associated
   with the conference control protocols are directly associated with
   the conference object, thus the primary identifier associated with
   these protocols is the conference object identifier(XCON-URI).  The
   mappings between additional protocols/interface is not strictly 1:1
   and does allow for multiple occurrences.  For example, multiple call
   signaling protocols will each have a representation that is
   implicitly linked to the top level conference object identifier e.g.
   H323 and SIP URIs that represent a conference instance.  It should be
   noted that a conferencing system is free to structure such
   relationships as required and this information is just included as a
   guideline that can be used.

   Further elements can be added to the tree representation in Figure 2



Novo, et al.               Expires May 1, 2009                  [Page 8]


Internet-Draft              Data Model Schema               October 2008


   to enable a complete representation of a conference instance within a
   conferencing system.

3.3.1.  Conference Object URI Definition


   XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ]

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


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

3.4.  Data Model Structure

   The information in this data model is structured in the following
   manner.  All the information related to a conference is contained in
   a <conference-info> element.  The <conference-info> element contains
   the following child elements:

   o  The <conference-description> element describes the conference as a
      whole.  It has, for instance, information about the URI of the
      conference, maximum users allowed in the conference, media
      available in the conference, or the time the conference will
      start.
   o  The <host-info> element contains information about the entity
      hosting the conference (e.g., its URI).
   o  The <conference-state> element informs the subscribers about the
      changes in the overall conference information.
   o  The <floor-information> element contains information about the
      status of the different floors in the conference.
   o  The <users> element describes the membership information as a
      whole.  The <users> element contains a set of <user> child
      elements, each describing a single participant in the conference.
   o  If a participant in the main conference joins a sidebar, a new
      element is created in the conference referenced from the
      <sidebars-by-ref> element or under one of the <sidebars-by-val>
      elements.

   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 [RFC4575].  We describe them here because they are part of
   the basic structure of the data model.







Novo, et al.               Expires May 1, 2009                  [Page 9]


Internet-Draft              Data Model Schema               October 2008


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 "*"
   following an element indicates that the element is introduced and
   defined in this document.  That is, elements without a "*" have
   already been defined in [RFC4575].

   !<conference-info>
        |
        |--!<conference-description>
        |     |--<language>*
        |     |--<display-text>
        |     |--<subject>
        |     |--<free-text>
        |     |--<keywords>
        |     |--<allow-sidebars>*
        |     |--<conference-time>*
        |     |      |--<entry>*
        |     |      |    |--<base>*
        |     |      |    |--<mixing-start-offset>*
        |     |      |    |--<mixing-end-offset>*
        |     |      |    |--<can-join-after-offset>*
        |     |      |    |--<must-join-before-offset>*
        |     |      |    |--<request-user>*
        |     |      |    |--<notify-end-of-conference>*
        |     |      |    |--<allowed-extend-mixing-end-offset>*
        |     |           ...
        |     |--<conf-uris>
        |     |      |--<entry>
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |    |--<conference-password>*
        |     |      ...
        |     |--<service-uris>
        |     |      |--<entry>
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      ...
        |     |--<maximum-user-count>
        |     |      ...
        |     |--<available-media>
        |     |      |--!<entry>
        |     |      |     |--<display-text>
        |     |      |     |--<type>



Novo, et al.               Expires May 1, 2009                 [Page 10]


Internet-Draft              Data Model Schema               October 2008


        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<mute>*
        |     |      |     |    |--<gain>*
        |     |      |     |   ...
        |     |      |--<entry>
        |     |      |     |--<display-text>
        |     |      |     |--<type>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<pause-video>*
        |     |      |     |    |--<video-layout>*
        |     |      |     |   ...
        |     |      ...
        |
        |--<host-info>
        |     |--<display-text>
        |     |--<web-page>
        |     |--<uris>
        |     |     |--<entry>
        |     |     |    |--<uri>
        |     |     |    |--<display-text>
        |           ...
        |--<conference-state>
        |     |--<allow-conference-event-subscription>*
        |     |--<user-count>
        |     |--<active>
        |     |--<locked>
        |
        |--<floor-information>*
        |     |--<conference-ID>*
        |     |--<allow-floor-events>*
        |     |--<floor-request-handling>*
        |     |--<conference-floor-policy>*



Novo, et al.               Expires May 1, 2009                 [Page 11]


Internet-Draft              Data Model Schema               October 2008


        |     |     |--<floor>*
        |     |     |    |--!<media-label>*
        |     |     |    |--!<algorithm>*
        |     |     |    |--<max-floor-users>*
        |     |     |    |--<moderator-id>*
        |     |     |   ...
        |     |     ...
        |
        |--!<users>
        |     |--<join-handling>*
        |     |--<user-admission-policy>*
        |     |--<allowed-users-list>*
        |     |     |--<target>*
        |     |     |
        |     |     |--<persistent-list>*
        |     |     |     |--<user>*
        |     |     |     |     |-- <email>*
        |     |
        |     |--<deny-users-list>*
        |     |
        |     |--<user>
        |     |    |--<display-text>
        |     |    |--<associated-aors>
        |     |    |--<provide-anonymity>*
        |     |    |--<roles>
        |     |    |    |
        |     |    |   ...
        |     |    |--<languages>
        |     |    |--<cascaded-focus>
        |     |    |--<allow-refer-users-dynamically>*
        |     |    |--<allow-invite-users-dynamically>*
        |     |    |--<allow-remove-users-dynamically>*
        |     |    |--!<endpoint>
        |     |    |      |--<display-text>
        |     |    |      |--<referred>
        |     |    |      |--<status>
        |     |    |      |--<joining-method>
        |     |    |      |--<joining-info>
        |     |    |      |--<disconnection-method>
        |     |    |      |--<disconnection-info>
        |     |    |      |--<media>
        |     |    |      |    |--<type>
        |     |    |      |    |--<display-text>
        |     |    |      |    |--<label>
        |     |    |      |    |--<src-id>
        |     |    |      |    |--<status>
        |     |    |      |    |--<to-mixer>*
        |     |    |      |    |      |--<floor>*



Novo, et al.               Expires May 1, 2009                 [Page 12]


Internet-Draft              Data Model Schema               October 2008


        |     |    |      |    |      |--<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].  The <conference-
   info> attributes are described in [RFC4575].  Note that the
   <conference-info> element does not have the attributes 'state' and
   'version' defined in [RFC4575] for this element because these
   attributes only apply to notification mechanisms.




Novo, et al.               Expires May 1, 2009                 [Page 13]


Internet-Draft              Data Model Schema               October 2008


   In addition, [RFC4575] defines an 'entity' attribute that contains
   the conference object identifier (XCON-URI) that identifies the
   conference being described in the document.

   The <conference-info> element contains the <conference-description>,
   <host-info>, <conference-state>, <floor-information>, <users>,
   <sidebars-by-ref>, and <sidebars-by-val> child elements.  All these
   elements, except <floor-information>, are defined in [RFC4575].  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],
   describes the conference as a whole.  It should have an extra
   attribute 'lang' to specify the language used in the contents of this
   element.  It is comprised of <language>, <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.  <language>

   The <language> element indicates the predominant language that is
   expected to be employed within a conference.  This element is not
   enforcing the language of the conference, but only informs the
   participants about the desirable language that they should use in the
   conference.  Participants are free to switch to other languages if
   they like.

4.2.2.  <display-text>

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

4.2.3.  <subject>

   The <subject> element is described in section 5.3 of [RFC4575].

4.2.4.  <free-text>

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







Novo, et al.               Expires May 1, 2009                 [Page 14]


Internet-Draft              Data Model Schema               October 2008


4.2.5.  <keywords>

   The <keywords> element is described in section 5.3 of [RFC4575].

4.2.6.  <allow-sidebars>

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

4.2.7.  <conference-time>

   The <conference-time> element contains the information related to
   conference time and duration of a conference.  The <conference-time>
   element contains one or more <entry> elements each defining the time
   information specifying a single conference occurrence.

   Every <entry> element contains the following child elements:

   o  <base>: The <base> child element specifies the iCalendar object of
      the conference.  The iCalendar object components are defined in
      [RFC2445].
   o  <mixing-start-offset>: The <mixing-start-offset> child element
      specifies when the conference media mixing starts before the
      conference starts.  If the <mixing-start-offset> element is not
      present, it indicates that the conference media mixing starts
      immediately.  The <mixing-start-offset> has the mandatory
      'required-participant' attribute.  This attribute contains one of
      the following values: "none", "administrator", "moderator",
      "user", "observer", and "participant".  The roles semantic
      definition is out of the scope of this document and is subject to
      future policy documents.  More values can be specified in the
      future.  The 'required-participant' attribute allows a privileged
      user to define when media mixing starts based on the latter of the
      mixing start time, and the time the first participant arrives.  If
      the value is set to "none'", mixing starts according to the mixing
      start time.
   o  <mixing-end-offset>: The <mixing-end-offset> child element that
      specifies the time a conference media mixing stops after the
      conference stops.  If the <mixing-end-offset> element is not
      present, it indicates that the conference occurrence is not
      bounded.  The <mixing-end-offset> element has the mandatory
      'required-participant' attribute.  This attribute contains one of
      the following values: "none", "administrator", "moderator",
      "observer", "user", and "participant".  More values can be
      specified in the future.  The 'required-participant' attribute
      allows a privileged user to define when media mixing ends based on
      the earlier of the <mixing-end-offset>, and the time the last
      participant leaves.  If the value is set to "none", mixing stops



Novo, et al.               Expires May 1, 2009                 [Page 15]


Internet-Draft              Data Model Schema               October 2008


      according to the <mixing-end-offset>.  If the conference policy
      was modified so that last privileged user is now a normal
      conference participant, and the conference requires a privileged
      user to continue; that conference MUST terminate.
   o  <can-join-after-offset>: An administrator can indicate the time
      when users can join a conference by populating the <can-join-
      after-offset> element.
   o  <must-join-before-offset>: An administrator can define the time
      after which new users are not allowed to join the conference
      anymore.
   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.
   o  <notify-end-of-conference>: The <notify-end-of-conference> element
      defines in seconds when the system has to send a notification when
      the end of the conference is approaching.  If the <notify-end-of-
      conference> element is not present, it indicates that the system
      does not notify the users when the end of the conference is
      approaching.
   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.8.  <conf-uris>

   The <conf-uris> contains the identifiers to be used in order to
   access the conference by different signaling means.  This document
   describes a new element, <conference-password>.  This element
   contains the password(s) of the conference, for instance, PSTN
   conference will store the 'PIN code' in this element.  All the other
   <conf-uris> child element are described in section 5.3.1 of
   [RFC4575].  Future extensions to this schema may define new values
   and register them with IANA.

4.2.9.  <service-uris>

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

4.2.10.  <maximum-user-count>

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




Novo, et al.               Expires May 1, 2009                 [Page 16]


Internet-Draft              Data Model Schema               October 2008


4.2.11.  <available-media>

   The <available-media> element consists of a sequence of <entry> child
   elements.  Each <entry> element contain the 'label' attribute that is
   the media stream identifier assigned by the conferencing server.  The
   attribute 'label' is described in [RFC4575], section 5.3.4.  Each
   <entry> element contains the following child elements:

   o  The <type> element is described in section 5.3.4 of [RFC4575].
   o  The <display-text> element is described in section 5.3.4 of
      [RFC4575].
   o  The <status> element is described in section 5.3.4 of [RFC4575].
   o  The child element <mixing-mode> describes a default policy by
      which the mixer will build the outgoing stream from the incoming
      streams.  Note that this policy is different than the policy
      describing the floors for each media.  The <mixing-mode> child
      element MUST contain one and only one of the "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,
      controls the media stream policy.  The "FCFS" value indicates a
      'first-come-first-served' policy.
   o  The <codecs> element specifies the allowed codecs in the
      conference.  It has an attribute 'decision' that specifies if the
      focus decides the common codec automatically or needs the approval
      of the moderator of the conference ("automatic", "moderator-
      controlled").  The <codecs> element contains <codec> elements.  A
      <codec> element can have the attribute 'name' and 'policy'.  The
      'name' attribute is a codec identifier assigned by the
      conferencing server.  The 'policy' attribute contains the policy
      for that codec (allowed, or disallowed).  The <codec> element has
      the child element <subtype> which stores the codec's name.  The
      possible values of this element are the values of the 'subtype'
      column of the RTP Payload Format media types per [RFC4855] defined
      in IANA [IANA].  It is expected that future conferencing
      specifications will define corresponding schema extensions, as
      appropriate.
   o  The <controls> element contains the basic audio and video global
      control elements for a conference.  It is expected that for the
      majority of the basic conferences, these controls are sufficient.
      If the conference server wants to support more advanced controls,
      then it is recommended that an extension to the data model be
      used.  In the <controls> element the schema is extensible, hence
      new control types can be added in the future.  So moderator
      controls that affect all media output would go under the
      <available-media> element.  The following controls elements are
      defined for <controls>:




Novo, et al.               Expires May 1, 2009                 [Page 17]


Internet-Draft              Data Model Schema               October 2008


      *  The <mute> element is used in conjunction with an audio stream
         to cease transmission of associated media.  That means that for
         the entire duration where mute is applicable, all current and
         future participants of the conference are muted and will not
         receive any audio.  It has a "boolean" value.  If this control
         is not specified, access to the control is not available to the
         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 control is not specified, the access
         to the control is not available to the client.
      *  The <gain> element is used in conjunction with a media output
         stream to indicate the amount of amplification of an audio
         stream.  The value is an integer number that ranges from -127
         to 127.  If this control is not specified, access to the
         control is not available to the client.
      *  The <video-layout> element is used in conjunction with a video
         stream to specify how the video streams (of participants) are
         viewed by each participant.  Only one layout type can be
         specified for each output stream.  If there are fewer
         participants than panels in the specified layout, then blanking
         (black screen) MAY be mixed into the stream on the behalf of
         the missing input streams.  If unspecified, the <video-layout>
         default type SHOULD be "single-view".  The <video-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 focus to
            all participants in one panel.
         +  dual-view: This dual view option will present the video
            side-by-side in 2 panels and not alter the aspect ratio of
            the streams.  This will require the focus to introduce
            blanking on parts of the overall image as viewed by the
            participants.
         +  dual-view-crop: This side-by-side layout option instructs
            the focus to alter the aspect ratio of the streams (alter-
            aspect-ratio=TRUE) so that blanking is not necessary.  The
            focus handles the cropping of the streams.
         +  dual-view-2x1: This layout option instructs the focus to
            place one stream above the other, in essence with two rows
            and one column.  In this option the aspect ratio is not
            altered and blanking is introduced.
         +  dual-view-2x1-crop: This layout option also instructs the
            focus to place one stream above the other, in essence with
            two rows and one column.  In this option the aspect ratio is
            altered and the video streams are cropped.
         +  quad-view: Four equal-sized panels in a 2x2 layout is
            presented by the focus to all participants.  Typically the
            aspect ratio of the streams are maintained (alter-aspect-



Novo, et al.               Expires May 1, 2009                 [Page 18]


Internet-Draft              Data Model Schema               October 2008


            ratio= FALSE).
         +  multiple-3x3: Nine equal-sized panels in a 3x3 layout is
            presented by the focus to all participants.  Typically the
            aspect ratio of the streams are preserved.
         +  multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is
            presented by the focus to all participants.  Typically the
            aspect ratio of the streams are preserved.
         +  multiple-5x1: This option refers to a 5x1 layout where one
            panel will occupy 4/9 of the mixed video stream while the
            others will each occupy 1/9 of the stream.  Typically the
            aspect ratio of the streams is preserved.
         +  automatic: This option allows the focus to add panels as
            streams are added.

4.3.  <host-info>

   The <host-info> element contains information about the entity hosting
   the conference.  This information is set before conference
   activation, and is rarely changed during the conference lifetime.
   The <host-info> element and its child elements are described in
   [RFC4575], section 5.4.  Future extensions to the <host-info> element
   may define new values.

4.4.  <conference-state>

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

4.4.2.  <user-count>

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

4.4.3.  <active>

   The <active> child element is explained in [RFC4575], section 5.5.2.




Novo, et al.               Expires May 1, 2009                 [Page 19]


Internet-Draft              Data Model Schema               October 2008


4.4.4.  <locked>

   The <locked> child element is explained in [RFC4575], section 5.5.3.

4.5.  <floor-information>

   The <floor-information> element contains the <conference-ID>, <allow-
   floor-events>, <floor-request-handling>, and <conference-floor-
   policy> child elements.  Other elements from different namespaces MAY
   be present for the purposes of extensibility.  The absence of this
   element from an XML document indicates that the conference does not
   have a floor.

4.5.1.  <conference-ID>

   The <conference-ID> represents a conference instance within floor
   control.  When created within the conferencing system, the
   'conference-ID' can be represented by the unique conference object
   Identifier (XCON-URI).  When BFCP serves as the floor control
   protocol, the <conference-ID> is a 32-bit BFCP conference identifier
   defined in [RFC4582] section 5.1 and there is a 1:1 mapping to the
   XCON-URI.

4.5.2.  <allow-floor-events>

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

   There are two methods which a conference participant subscribes
   himself to a floor control event.  One method is using an offer/
   answer exchange mechanism ([RFC3264]) using SIP INVITE and BFCP
   parameters in the SDP ([RFC4583]).  The other method is a general
   authorization mechanism described in section 9 of [RFC4582] and in
   [RFC5018].  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 control floor requests.  This element defines the
   action that the focus is to take when processing a particular request
   to a floor within a conference.  This element defines values of:





Novo, et al.               Expires May 1, 2009                 [Page 20]


Internet-Draft              Data Model Schema               October 2008


   o  "block": This action instructs the focus to deny the floor
      request.  This action is the default action taken in the absence
      of any other actions.
   o  "confirm": This action instructs the focus to allow the request.
      The focus then uses the defined floor algorithm to further allow
      or deny the floor.  The algorithms used are outside the scope of
      this document.

   Note that this section discusses floor control information,
   therefore, the value "block" in a <floor-request-handling> element is
   not related with the "block" value in the <join-handling> element
   (see Section 4.6).

4.5.4.  <conference-floor-policy>

   The <conference-floor-policy> element has one or more <floor> child
   elements.  Every <floor> child elements has an attribute 'id' which
   uniquely identifies a floor or floors within a conference.  In the
   case of BFCP [RFC4582], the 'id' attribute corresponds to the
   floor-id identifier defined in [RFC4582] section 5.2.2.

   o  <media-label>: Every floor is identified for one or more mandatory
      <media-label> element.  If the <available-media> information is
      included in the 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
      mandatory <algorithm> element MUST be set to any of the
      "moderator-controlled", "FCFS" or "random" values indicating the
      algorithm.  The "Moderator-controlled" value indicates that the
      moderator of the conference controls the floor.  The "FCFS" value
      states for 'first-come-first-served' floor control.
   o  <max-floor-users>: The <max-floor-users> child element in the
      <floor> element is optional and, if present, dictates the maximum
      number of users who can have the floor at one time.
   o  <moderator-id>: The optional <moderator-id> indicates the 'User
      ID' of the moderator(s).  It MUST be set if the element
      <algorithm> is set to "Moderator-controlled" value.  When the
      floor is created within the conferencing system, the XCON-User
      identifier MAY be used as the moderator-id.  In the case of BFCP
      as the floor control protocol, the <moderator-id> is defined in
      [RFC4582] section 3.  Note that [RFC4582] refers to the moderator
      role as a 'floor chair'.






Novo, et al.               Expires May 1, 2009                 [Page 21]


Internet-Draft              Data Model Schema               October 2008


4.6.  <users>

   The <users> element is described in [RFC4575] and contains the <join-
   handling>, <user-admission-policy>, <allowed-users-list> and <deny-
   users-list> defined in this document and <user> child elements
   defined in [RFC4575].  Note that the <users> element does not have
   the attribute 'state' defined in [RFC4575] for this element because
   this attribute only applies to notifications mechanism.  The
   following sections describe these elements in more detail.  Other
   child elements and attributes can be used to extend <users> in the
   future.

4.6.1.  <join-handling>

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

4.6.2.  <user-admission-policy>

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

   o  "closedAuthenticated": A 'closedAuthenticated' policy requires
      each conference participant to be in the allowed users list
      (listed under the <allowed-users-list> XML element) with each
      participant being sufficiently (up to local policy) authenticated.
      Conference join requests for users not in the allowed users list
      or participants not authenticated should be rejected unless a
      <join-handling> action of 'confirm' is selected in which case the



Novo, et al.               Expires May 1, 2009                 [Page 22]


Internet-Draft              Data Model Schema               October 2008


      user is placed on a pending list as indicated earlier.
   o  "openAuthenticated": An 'openAuthenticated' policy requires each
      conferencing participant to be sufficiently authenticated (as
      before) but does not restrict which participants can join the
      conference.  Typically this implies that anyone capable of
      authenticating with the conferencing system may join the
      conference.
   o  "anonymous": An 'anonymous' policy allows any join requests in and
      is the least restrictive policy.

4.6.3.  <allowed-users-list>

   The <allowed-users-list> child element contains a list of user URIs
   (e.g.  SIP URI, xcon-userid defined in Section 4.6.5), roles (defined
   in Section 4.6.5.4), or domains (e.g.: *@example.com) that the focus
   uses to determine who can join the conference, who can be invited to
   join a conference, or who the focus needs to "refer to" the
   conference.  The <allowed-users-list> element includes zero or more
   <target> child elements.  This child element includes the mandatory
   'uri' attribute and the mandatory 'method' attribute.  The same 'uri'
   attribute with different method values can appear in the list more
   than once.

   The 'method' attribute is a list with the following values:

   o  "dial-in": The value "dial-in" is used by the focus to determine
      who can join the conference.
   o  "dial-out": The value "dial-out" contains a list of resources that
      the focus will initiate a session with.
   o  "refer": The value "refer" is used by the focus to determine the
      resources that the focus needs to "refer to" the conference.  In
      SIP, this is achieved by the focus sending a REFER request to
      those potential participants.  In a different paradigm, this could
      also mean that the focus sends an SMS or an email to the referred
      user.  This list can be updated during the conference lifetime so
      it can be used for mid-conference refers as well.

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

   The <allowed-users-list> element has a <persistent-list> child
   element as well.  Some chatroom systems allow -- and some require --
   registration of detailed information about a user before they are
   allowed to join a chatroom.  The <persistent-list> child element
   stores persistent information about users who are not actively part



Novo, et al.               Expires May 1, 2009                 [Page 23]


Internet-Draft              Data Model Schema               October 2008


   of an ongoing chatroom session.  The <persistent-list> element stores
   the following information:

   o  user: The <user> element stores the name, nickname, the conference
      user identifier (XCON-USERID) and email address of a user.  It has
      three attributes: 'name', 'nickname' and 'id' and an <email>
      element.  Future extensions to this schema may define new elements
      for the <user> element.

   Future extensions to this schema may define new elements for the
   <target> element.

4.6.4.  <deny-users-list>

   The <deny-users-list> child element contains a list of user URIs
   (e.g.  SIP URI, xcon-userid defined in Section 4.6.5), roles (defined
   in Section 4.6.5.4), or domains (e.g.: *@example.com) that the focus
   uses to determine who has been 'banned' from the conference.  Such
   banned users are prevented from re-joining the chatroom until they
   have been un-banned.

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

   The element <user> is described in [RFC4575] and describes a single
   participant in the conference.  The <user> element has an attribute
   'entity'.  Note that the <user> element does not have the attribute
   'state' defined in [RFC4575] for this element because this attribute
   only applies to notifications mechanism.

   The attribute 'entity' contains a unique conference user identifier
   (XCON-USERID) within the scope of a conferencing system.  The URI
   format of this identifier is as follow:


    XCON-USERID = "xcon-userid" ":" conf-user-id

    conf-user-id = 1*(unreserved)

   [unreserved is defined in RFC3986]

   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 a single global user
   identifier.  Figure 4 illustrates an example using the conference
   user identifier in association with the user identity defined for
   BFCP, SIP, and H323 user identity.  It should be noted that a
   conferencing system is free to structure such relationships as
   required and this information is just included as a guideline that



Novo, et al.               Expires May 1, 2009                 [Page 24]


Internet-Draft              Data Model Schema               October 2008


   can be used.


                         +----------------+
                         |   Conference   |
                         |      User      |
                         |   Identifier   |
                         +----------------+
                         |xcon-userid:John|
                         +-------+--------+
                                 |
                                 |
                                 |
          +----------------------+-------------------------+
          |                      |                         |
  +-------+--------+ +-----------+-----------+ +-----------+-----------+
  |  BFCP User ID  | |      SIP User URI     | |     H323 User URI     |
  +----------------+ +-----------------------+ +-----------------------+
  |      543       | |sip:851221@example.com | |h323:taeduk@example.com|
  +----------------+ +-----------------------+ +-----------------------+


                     Figure 4: Conference User 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.5.1.  <display-text>

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

4.6.5.2.  <associated-aors>

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

4.6.5.3.  <provide-anonymity>

   The <provide-anonymity> element provides anonymity to the user.  In
   this case, the focus provides to the rest of the participants an
   anonymous identity for that user, for example anonymousX, or it does
   not provide any information for that user such that other users can
   not see he is a participant in the conference.  This element only
   affects the way the user information is provided to the other



Novo, et al.               Expires May 1, 2009                 [Page 25]


Internet-Draft              Data Model Schema               October 2008


   participants.  The real information about the user is still stored in
   the data model.  This can be achieved by using the <provide-
   anonymity> element.  This element has three values: 'private', 'semi-
   private' and 'hidden'.  The 'private' value specifies that this user
   is completely anonymous in the conference. 'semi-private' value
   specifies that this user is anonymous to all users with equal or
   lesser permissions in the conference. 'hidden' value specifies that
   other users can not see this participant in the conference.

4.6.5.4.  <roles>

   A role provides the context for the set of conference operations that
   a participant can perform.  This element can contain one of the
   following values: "administrator", "moderator", "user",
   "participant", "observer", and "none".  The roles semantic definition
   is out of the scope of this document and is subject to future policy
   documents.  This element can be extended with new roles in future
   documents.

4.6.5.5.  <languages>

   The <languages> child element is explained in [RFC4575], section
   5.6.4.

4.6.5.6.  <cascaded-focus>

   The <cascaded-focus> child element is explained in [RFC4575], section
   5.6.5.

4.6.5.7.  <allow-refer-users-dynamically>

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

4.6.5.8.  <allow-invite-users-dynamically>

   The <allow-invite-users-dynamically> element represents a boolean
   action.  If set to TRUE, a participant is allowed to instruct the
   focus to invite a user to the conference without modifying the
   <allowed-users-list> list (in SIP terms, a participant is allowed to
   send a REFER request to the focus which results in the focus sending



Novo, et al.               Expires May 1, 2009                 [Page 26]


Internet-Draft              Data Model Schema               October 2008


   an INVITE request to the user the referrer wishes to join the
   conference).  If set to FALSE, the refer request is rejected.  If
   this element is undefined it has a value of FALSE, causing the refer
   to be rejected.

4.6.5.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 user from the conference without modifying the
   ruleset (in SIP terms, a participant is allowed to send a REFER
   request to the focus which results in the focus sending an BYE
   request to the user the referrer wishes to leave the conference).  If
   set to FALSE, the refer request is rejected.  If this element is
   undefined it has a value of FALSE, causing the refer to be rejected.

4.6.5.10.  <endpoint>

   The <endpoint> child element is defined in [RFC4575].  It can provide
   the desired level of detail about the user's devices and their
   signaling sessions taking part in the conference.  The <endpoint>
   element in this document does not defined the 'state' attribute
   defined in [RFC4575] for the same element since the 'state' attribute
   only applies to notification mechanisms.

   The <endpoint> element has the following child elements: <display-
   text>, <referred>, <status>, <joining-method>, <joining-info>,
   <disconnection-method>, <disconnection-info>, <media>, <floor>,and
   <call-info>.  All the <endpoint> child elements are defined in
   [RFC4575] with the exception of the <floor> element.

   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 an attribute 'id' which uniquely
   identifies a floor or floors within a conference.  The 'id' attribute
   corresponds to the floor-id identifier defined in [RFC4582] section
   5.2.2.  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.

   Besides the <floor> element, the <endpoint>/<media> element has two
   other child elements defined in this document, the <to-mixer>, and
   the <from-mixer>:






Novo, et al.               Expires May 1, 2009                 [Page 27]


Internet-Draft              Data Model Schema               October 2008


   o  <from-mixer>, <to-mixer>: These are controls that apply to a
      user's media stream being sent from the mixer to the participants
      endpoint or to the mixer from the participants endpoint.  The <to-
      mixer> element details properties associated with the incoming
      streams to the mixer (streams sent to the mixer from the
      participant).  The <from-mixer> element details properties
      associated with the outgoing streams from the 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.  The <to-mixer> and <from-mixer> elements have the
      <controls> child element:
      *  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.  This element is described in [RFC4575], 5.9.1.  Note that
   the <sidebars-by-ref> element does not have the attribute 'state'
   defined in [RFC4575] 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.  This
   element is described in [RFC4575], 5.9.2.  Note that the <sidebars-
   by-val> element does not have the attribute 'state' defined in
   [RFC4575] for this element because this attribute only applies to
   notifications mechanism.


5.  RELAX NG Schema

   In accordance with the Centralized Conferencing Framework document
   [RFC5239], 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.

   The normative schema is backwards compatible with the [RFC5239], in
   other words, valid [RFC5239] instance documents are also valid
   according to this RELAX NG schema [RELAX].  In addition to



Novo, et al.               Expires May 1, 2009                 [Page 28]


Internet-Draft              Data Model Schema               October 2008


   approximately similar RELAX NG [RELAX] definitions of the [RFC5239],
   this schema contains extension elements in the
   "urn:ietf:params:xml:ns:xcon-conference-info" namespace.

 default namespace = "urn:ietf:params:xml:ns:conference-info"
 namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info"

 start = element conference-info { conference-type }
 # CONFERENCE TYPE
 conference-type =
   attribute entity { text }
   & anyAttribute
   & conference-description-type?
   & element host-info { host-type }?
   & element conference-state { conference-state-type }?
   & element users { users-type }?
   & element sidebars-by-ref { uris-type }?
   & element sidebars-by-val { sidebars-by-val-type }?
   & element xcon:floor-information { floor-information-type }?
   & anyElement*
 # CONFERENCE DESCRIPTION TYPE
 conference-description-type =
   element conference-description {
     attribute xml:lang { xsd:language }?
     & anyAttribute
     & element display-text { text }?
     & element subject { text }?
     & element free-text { text }?
     & element keywords {
         list { xsd:string* }
       }?
     & element conf-uris { uris-type }?
     & element service-uris { uris-type }?
     & element maximum-user-count { xsd:int }?
     & element available-media { conference-media-type }?
     & element xcon:language { xsd:language }?
     & element xcon:allow-sidebars { xsd:boolean }?
     & element xcon:conference-time { conferencetime-type }?
     & anyElement*
   }
 # HOST TYPE
 host-type =
   element display-text { text }?
   & element web-page { xsd:anyURI }?
   & element uris { uris-type }?
   & anyElement*
   & anyAttribute
 # CONFERENCE STATE TYPE



Novo, et al.               Expires May 1, 2009                 [Page 29]


Internet-Draft              Data Model Schema               October 2008


 conference-state-type =
   anyAttribute
   & element user-count { xsd:unsignedInt }?
   & element active { xsd:boolean }?
   & element locked { xsd:boolean }?
   & element xcon:allow-conference-event-subscription { xsd:boolean }?
   & anyElement*
 # CONFERENCE MEDIA TYPE
 conference-media-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 xcon:mixing-mode { mixing-mode-type }?
   & element xcon:codecs { codecs-type }?
   & element xcon:controls { control-type }?
   & anyElement*
 # URIs TYPE
 uris-type =
   anyAttribute
   & element entry { uri-type }*
   & anyElement*
 # URI TYPE
 uri-type =
   element uri { xsd:anyURI }
   & element display-text { text }?
   & element purpose { text }?
   & element modified { execution-type }?
   & element xcon:conference-password { text }?
   & anyElement*
   & anyAttribute
 # USERS TYPE
 users-type =
   anyAttribute
   & element user { user-type }*
   & element xcon:join-handling { join-handling-type }?
   & element xcon:user-admission-policy { user-admission-policy-type }?
   & element xcon:allowed-users-list { allowed-users-list-type }?
   & element xcon:deny-users-list { deny-user-list-type }?
   & anyElement*
 # USER TYPE
 user-type =



Novo, et al.               Expires May 1, 2009                 [Page 30]


Internet-Draft              Data Model Schema               October 2008


   attribute entity { xsd:anyURI }
   & anyAttribute
   & element display-text { text }?
   & element associated-aors { uris-type }?
   & element roles {
       element entry { single-role-type }+
     }?
   & element languages {
       list { xsd:language }
     }?
   & element cascaded-focus { xsd:anyURI }?
   & element endpoint { endpoint-type }*
   & element xcon:provide-anonymity { provide-anonymity-type }?
   & element xcon:allow-refer-users-dynamically { xsd:boolean }?
   & element xcon:allow-invite-users-dynamically { xsd:boolean }?
   & element xcon:allow-remove-users-dynamically { xsd:boolean }?
   & anyElement*
 # ENDPOINT TYPE
 endpoint-type =
   attribute entity { text }
   & anyAttribute
   & element display-text { text }?
   & element referred { execution-type }?
   & element status { endpoint-status-type }?
   & element joining-method { joining-type }?
   & element joining-info { execution-type }?
   & element disconnection-method { disconnection-type }?
   & element disconnection-info { execution-type }?
   & element media { media-type }*
   & element call-info { call-type }?
   & element xcon:floor {
       attribute id { text },
       anyAttribute,
       xsd:boolean
     }*
   & anyElement*
 # ENDPOINT STATUS TYPE
 endpoint-status-type =
   "pending"
   | "dialing-out"
   | "dialing-in"
   | "alerting"
   | "on-hold"
   | "connected"
   | "muted-via-focus"
   | "disconnecting"
   | "disconnected"
   | free-text-extension



Novo, et al.               Expires May 1, 2009                 [Page 31]


Internet-Draft              Data Model Schema               October 2008


 # JOINING TYPE
 joining-type =
   "dialed-in" | "dialed-out" | "focus-owner" | free-text-extension
 # DISCONNECTION TYPE
 disconnection-type =
   "departed" | "booted" | "failed" | "busy" | free-text-extension
 # EXECUTION TYPE
 execution-type =
   element when { xsd:dateTime }?
   & element reason { text }?
   & element by { xsd:anyURI }?
   & anyAttribute
 # CALL TYPE
 call-type =
   element sip { sip-dialog-id-type }
   & anyElement*
   & anyAttribute
 # SIP DIALOG ID TYPE
 sip-dialog-id-type =
   element display-text { text }?
   & element call-id { text }
   & element from-tag { text }
   & element to-tag { text }
   & anyElement*
   & anyAttribute
 # MEDIA TYPE
 media-type =
   attribute id { xsd:int }
   & anyAttribute
   & element display-text { text }?
   & element type { text }?
   & element label { text }?
   & element src-id { text }?
   & element status { media-status-type }?
   & element xcon:to-mixer { mixer-type }?
   & element xcon:from-mixer { mixer-type }?
   & anyElement*
 # MEDIA STATUS TYPE
 media-status-type =
   "recvonly"
   | "sendonly"
   | "sendrecv"
   | "inactive"
   | free-text-extension
 # SIDEBARS-BY-VAL TYPE
 sidebars-by-val-type =
   anyAttribute
   & element entry { conference-type }*



Novo, et al.               Expires May 1, 2009                 [Page 32]


Internet-Draft              Data Model Schema               October 2008


   & anyElement*
 # CONFERENCE TIME
 conferencetime-type =
   anyAttribute
   & element xcon:entry {
       element xcon:base { text },
       element xcon:mixing-start-offset {
         time-type,
         attribute required-participant { single-role-type },
         anyAttribute
       }?,
       element xcon:mixing-end-offset {
         time-type,
         attribute required-participant { single-role-type },
         anyAttribute
       }?,
       element xcon:can-join-after-offset { time-type }?,
       element xcon:must-join-before-offset { time-type }?,
       element xcon:request-user { time-type }?,
       element xcon:notify-end-of-conference { xsd:int }?,
       element xcon:allowed-extend-mixing-end-offset { xsd:boolean }?,
       anyElement*
     }*
 # TIME TYPE
 time-type = xsd:dateTime { pattern = ".+T.+Z.*" }
 # SINGLE ROLE TYPE
 single-role-type =
   xsd:string "none"
   | xsd:string "administrator"
   | xsd:string "moderator"
   | xsd:string "user"
   | xsd:string "observer"
   | xsd:string "participant"
   | free-text-extension
 # MIXING MODE TYPE
 mixing-mode-type =
   xsd:string "moderator-controlled"
   | xsd:string "FCFS"
   | xsd:string "automatic"
   | free-text-extension
 # CODECS TYPE
 codecs-type =
   attribute decision { decision-type }
   & anyAttribute
   & element xcon:codec { codec-type }*
   & anyElement*
 # CODEC TYPE
 codec-type =



Novo, et al.               Expires May 1, 2009                 [Page 33]


Internet-Draft              Data Model Schema               October 2008


   attribute name { text }
   & attribute policy { policy-type }
   & anyAttribute
   & element xcon:subtype { text }?
   & anyElement*
 # DECISION TYPE
 decision-type =
   xsd:string "automatic"
   | xsd:string "moderator-controlled"
   | free-text-extension
 # POLICY TYPE
 policy-type =
   xsd:string "allowed" | xsd:string "disallowed" | free-text-extension
 # CONTROL TYPE
 control-type =
   anyAttribute
   & element xcon:mute { xsd:boolean }?
   & element xcon:pause-video { xsd:boolean }?
   & element xcon:gain { gain-type }?
   & element xcon:video-layout { video-layout-type }?
   & anyElement*
 # GAIN TYPE
 gain-type = xsd:int { minInclusive = "-127" maxInclusive = "127" }
 # VIDEO LAYOUT TYPE
 video-layout-type =
   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"
   | free-text-extension
 # FLOOR INFORMATION TYPE
 floor-information-type =
   anyAttribute
   & element xcon:conference-ID { xsd:unsignedLong }?
   & element xcon:allow-floor-events { xsd:boolean }?
   & element xcon:floor-request-handling { floor-request-type }?
   & element xcon:conference-floor-policy { conference-floor-policy }?
   & anyElement*
 # FLOOR REQUEST TYPE
 floor-request-type =
   xsd:string "block" | xsd:string "confirm" | free-text-extension
 # CONFERENCE FLOOR POLICY



Novo, et al.               Expires May 1, 2009                 [Page 34]


Internet-Draft              Data Model Schema               October 2008


 conference-floor-policy =
   anyAttribute
   & element xcon:floor {
       attribute id { text }
       & anyAttribute
       & element xcon:media-label { xsd:nonNegativeInteger }+
       & element xcon:algorithm { algorithm-type }?
       & element xcon:max-floor-users { xsd:nonNegativeInteger }?
       & element xcon:moderator-id { xsd:nonNegativeInteger }?
       & anyElement*
     }+
 # ALGORITHM POLICY
 algorithm-type =
   xsd:string "moderator-controlled"
   | xsd:string "FCFS"
   | xsd:string "random"
   | free-text-extension
 # USERS ADMISSION POLICY
 user-admission-policy-type =
   xsd:string "closedAuthenticated"
   | xsd:string "openAuthenticated"
   | xsd:string "anonymous"
   | free-text-extension
 # JOIN HANDLING TYPE
 join-handling-type =
   xsd:string "block"
   | xsd:string "confirm"
   | xsd:string "allow"
   | xsd:string "authenticate"
   | xsd:string "directed-operator"
   | free-text-extension
 # DENY USERLIST
 deny-user-list-type =
   anyAttribute
   & element xcon:target {
       attribute uri { xsd:anyURI },
       anyAttribute
     }*
   & anyElement*
 # ALLOWED USERS LIST TYPE
 allowed-users-list-type =
   anyAttribute
   & element xcon:target { target-type }*
   & element xcon:persistent-list { persistent-list-type }?
   & anyElement*
 # PERSISTENT LIST TYPE
 persistent-list-type =
   element xcon:user {



Novo, et al.               Expires May 1, 2009                 [Page 35]


Internet-Draft              Data Model Schema               October 2008


     attribute name { text }
     & attribute nickname { text }
     & attribute id { text }
     & anyAttribute
     & element xcon:e-mail { text }*
     & anyElement*
   }*
   & anyElement*
 # TARGET TYPE
 target-type =
   attribute uri { xsd:anyURI },
   attribute method { method-type },
   anyAttribute
 # METHOD TYPE
 method-type =
   xsd:string "dial-in"
   | xsd:string "dial-out"
   | xsd:string "refer"
   | free-text-extension
 # ANONYMITY TYPE
 provide-anonymity-type =
   "private" | "semi-private" | "hidden" | free-text-extension
 # MIXER TYPE
 mixer-type =
   attribute name { mixer-name-type }
   & anyAttribute
   & element xcon:controls { control-type }*
   & anyElement*
 # MIXER NAME TYPE
 mixer-name-type =
   "VideoIn" | "VideoOut" | "AudioOut" | "AudioIn" | free-text-extension

 # FREE TEXT EXTENSION
 # (re-define this as <notAllowed>,
 #  if extensions beyond this spec are not used)

 free-text-extension = text

 # *********************************
 # EXTENSIBILITY OF THE SCHEMA
 # *********************************

 # EXTENSIBILITY ELEMENTS
 # (re-define this as <empty/>,
 #  if extensions beyond this spec are not used)

 anyElement =
   element * - (conference-description



Novo, et al.               Expires May 1, 2009                 [Page 36]


Internet-Draft              Data Model Schema               October 2008


                | host-info
                | conference-state
                | users
                | sidebars-by-ref
                | sidebars-by-val
                | display-text
                | subject
                | free-text
                | keywords
                | conf-uris
                | service-uris
                | maximum-user-count
                | available-media
                | web-page
                | uris
                | uri
                | user-count
                | active
                | locked
                | entry
                | type
                | status
                | purpose
                | modified
                | user
                | associated-aors
                | roles
                | languages
                | cascaded-focus
                | endpoint
                | referred
                | joining-method
                | joining-info
                | disconnection-method
                | disconnection-info
                | media
                | call-info
                | when
                | reason
                | by
                | sip
                | call-id
                | from-tag
                | to-tag
                | label
                | src-id
                | xcon:conference-password
                | xcon:mixing-mode



Novo, et al.               Expires May 1, 2009                 [Page 37]


Internet-Draft              Data Model Schema               October 2008


                | xcon:codecs
                | xcon:controls
                | xcon:language
                | xcon:allow-sidebars
                | xcon:allow-conference-event-subscription
                | xcon:to-mixer
                | xcon:provide-anonymity
                | xcon:allow-refer-users-dynamically
                | xcon:allow-invite-users-dynamically
                | xcon:allow-remove-users-dynamically
                | xcon:from-mixer
                | xcon:join-handling
                | xcon:user-admission-policy
                | xcon:allowed-users-list
                | xcon:deny-users-list
                | xcon:floor-information
                | xcon:conference-time
                | xcon:provide-anonymity
                | xcon:floor
                | xcon:entry
                | xcon:mixing-start-offset
                | xcon:mixing-end-offset
                | xcon:can-join-after-offset
                | xcon:must-join-before-offset
                | xcon:request-user
                | xcon:notify-end-of-conference
                | xcon:allowed-extend-mixing-end-offset
                | xcon:codec
                | xcon:subtype
                | xcon:mute
                | xcon:pause-video
                | xcon:gain
                | xcon:video-layout
                | xcon:conference-ID
                | xcon:allow-floor-events
                | xcon:floor-request-handling
                | xcon:conference-floor-policy
                | xcon:media-label
                | xcon:algorithm
                | xcon:max-floor-users
                | xcon:moderator-id
                | xcon:target
                | xcon:persistent-list
                | xcon:e-mail
                | xcon:user) { anyExtension }
 anyExtension =
   (attribute * { text }
    | any)*



Novo, et al.               Expires May 1, 2009                 [Page 38]


Internet-Draft              Data Model Schema               October 2008


 any =
   element * {
     (attribute * { text }
      | text
      | any)*
   }

 # EXTENSIBILITY ATTRIBUTES
 # (re-define this as <empty/>,
 #  if extensions beyond this spec are not used)

 anyAttribute =
   attribute * - (xml:lang
                  | entity
                  | required-participant
                  | label
                  | decision
                  | name
                  | policy
                  | uri
                  | method
                  | id
                  | nickname) { text }*


6.  XML Schema Extensibility

   The Conference Information Data Model defined in this document is
   meant to be extensible toward specific application domains.  Such
   extensions are accomplished by defining elements, child elements and
   attributes that are specific to the desired application domain.  The
   IETF MAY extend the data model schema with unqualified attributes or
   extension elements from the "urn:ietf:params:xml:ns:" "sub-namespace"
   in the future.  Other instances are free to define extension elements
   or attributes under other namespaces.

   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.  Sidebars are
   allowed in this conference and ,consequently, there is one sidebar in
   the conference.  In addition, Alice and Carol are using a floor in



Novo, et al.               Expires May 1, 2009                 [Page 39]


Internet-Draft              Data Model Schema               October 2008


   the main conference to manage the audio and video resources.  At the
   moment, Alice is assigned to use the floor.

<?xml version="1.0" encoding="UTF-8"?>
<conference-info
        xmlns="urn:ietf:params:xml:ns:conference-info"
        xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
        entity="conference123@example.com">
        <!--
            CONFERENCE DESCRIPTION
        -->
        <conference-description xml:lang="en-us">
            <display-text>Discussion of Formula-1 racing</display-text>
            <subject>Sports:Formula-1</subject>
            <free-text>This is a conference example</free-text>
            <keywords>Formula-1 cars</keywords>
            <!--
                CONFERENCE UNIQUE IDENTIFIERS
            -->
            <conf-uris>
                <entry>
                    <uri>tel:+3585671234</uri>
                    <display-text>Conference Bridge</display-text>
                    <purpose>participation</purpose>
                    <xcon:conference-password
                     >5678</xcon:conference-password>
                </entry>
                <entry>
                    <uri>http://www.example.com/live.ram</uri>
                    <purpose>streaming</purpose>
                </entry>
            </conf-uris>
            <!--
                SERVICE URIS
            -->
            <service-uris>
                <entry>
                    <uri>mailto:bob@example.com</uri>
                    <display-text>email</display-text>
                </entry>
            </service-uris>
            <!--
                MAXIMUM USER COUNT
            -->
            <maximum-user-count>50</maximum-user-count>
            <!--
                AVAILABLE MEDIA
            -->



Novo, et al.               Expires May 1, 2009                 [Page 40]


Internet-Draft              Data Model Schema               October 2008


            <available-media>
                <entry label="10234">
                    <display-text>main audio</display-text>
                    <type>audio</type>
                    <status>sendrecv</status>
                    <xcon:mixing-mode>automatic</xcon:mixing-mode>
                    <xcon:codecs decision="automatic">
                        <xcon:codec name="122" policy="allowed">
                           <xcon:subtype>PCMU</xcon:subtype>
                        </xcon:codec>
                    </xcon:codecs>
                    <xcon:controls>
                        <xcon:mute>true</xcon:mute>
                        <xcon:gain>50</xcon:gain>
                    </xcon:controls>
                </entry>
                <entry label="10235">
                    <display-text>main video</display-text>
                    <type>video</type>
                    <status>sendrecv</status>
                    <xcon:mixing-mode>automatic</xcon:mixing-mode>
                    <xcon:codecs decision="automatic">
                        <xcon:codec name="123" policy="allowed">
                           <xcon:subtype>H.263</xcon:subtype>
                        </xcon:codec>
                    </xcon:codecs>
                    <xcon:controls>
                        <xcon:video-layout
                          >single-view</xcon:video-layout>
                    </xcon:controls>
                </entry>
            </available-media>

            <xcon:language>En-us</xcon:language>

            <xcon:allow-sidebars>true</xcon:allow-sidebars>
            <!--
                CONFERENCE TIME
            -->

            <xcon:conference-time>
                <xcon:entry>
                    <xcon:base>BEGIN:VCALENDAR
  PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
  VERSION:2.0
  BEGIN:VEVENT
  DTSTAMP:20071003T140728Z
  UID:20071003T140728Z-345FDA-carol@example.com



Novo, et al.               Expires May 1, 2009                 [Page 41]


Internet-Draft              Data Model Schema               October 2008


  ORGANIZER:MAILTO:carol@example.com
  DTSTART:20071017T143000Z
  RRULE:FREQ=WEEKLY
  DTEND:20071217T163000Z
  END:VEVENT
  END:VCALENDAR</xcon:base>
                    <xcon:mixing-start-offset
                        required-participant="moderator"
                       >2007-10-17T14:29:00Z</xcon:mixing-start-offset>
                    <xcon:mixing-end-offset
                        required-participant="participant"
                       >2007-10-17T16:31:00Z</xcon:mixing-end-offset>
                    <xcon:must-join-before-offset
                       >2007-10-17T15:30:00Z
                       </xcon:must-join-before-offset>
                </xcon:entry>
            </xcon:conference-time>

        </conference-description>
        <!--
            HOST INFO
        -->
        <host-info>
            <display-text>Formula1</display-text>
            <web-page>http://www.example.com/formula1/</web-page>
            <uris>
                <entry>
                    <uri>sip:alice@example.com</uri>
                </entry>
                <entry>
                    <uri>sip:carol@example.com</uri>
                </entry>
            </uris>
        </host-info>
        <!--
            CONFERENCE STATE
        -->
        <conference-state>
            <user-count>3</user-count>
            <active>true</active>
            <locked>false</locked>
            <xcon:allow-conference-event-subscription
              >true</xcon:allow-conference-event-subscription>

       </conference-state>
        <!--
            USERS
        -->



Novo, et al.               Expires May 1, 2009                 [Page 42]


Internet-Draft              Data Model Schema               October 2008


        <users>
            <!--
                USER BOB
            -->
            <user entity="bob534">
                <display-text>Bob Hoskins</display-text>
                <associated-aors>
                    <entry>
                        <uri>mailto:bob@example.com</uri>
                        <display-text>email</display-text>
                    </entry>
                </associated-aors>
                <roles>
                    <entry>participant</entry>
                </roles>
                <languages>en-us</languages>

                <!--
                    ENDPOINTS
                -->
                <endpoint entity="sip:bob@example.com">
                    <display-text>Bob's Laptop</display-text>
                    <referred>
                        <when>2007-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>2007-10-17T14:00:00Z</when>
                        <reason>invitation</reason>
                        <by>sip:alice@example.com</by>
                    </joining-info>
                    <!--
                        MEDIA
                    -->
                    <media id="1">
                        <type>video</type>
                        <label>10235</label>
                        <src-id>432424</src-id>
                        <status>sendrecv</status>
                        <xcon:to-mixer name="VideoIn">
                            <xcon:controls>
                                <xcon:video-layout
                                   >single-view</xcon:video-layout>
                            </xcon:controls>
                        </xcon:to-mixer>



Novo, et al.               Expires May 1, 2009                 [Page 43]


Internet-Draft              Data Model Schema               October 2008


                    </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>
                <xcon:provide-anonymity
                 >semi-private</xcon:provide-anonymity>
                 <xcon:allow-refer-users-dynamically
                    >false</xcon:allow-refer-users-dynamically>
                <xcon:allow-invite-users-dynamically
                    >false</xcon:allow-invite-users-dynamically>
                <xcon:allow-remove-users-dynamically
                    >false</xcon:allow-remove-users-dynamically>
            </user>

            <!--
                USER ALICE
            -->
            <user entity="alice334">
                <display-text>Alice Kay</display-text>
                <associated-aors>
                    <entry>
                        <uri>mailto:alice@example.com</uri>
                        <display-text>email</display-text>
                    </entry>
                </associated-aors>
                <roles>
                    <entry>moderator</entry>
                </roles>
                <languages>en-us</languages>
                <!--
                    ENDPOINTS
                -->
                <endpoint entity="sip:alice@example.com">
                    <display-text>Alice's Desktop</display-text>
                    <status>connected</status>
                    <joining-method>dialed-in</joining-method>
                    <joining-info>
                        <when>2007-10-17T13:35:08Z</when>
                        <reason>invitation</reason>



Novo, et al.               Expires May 1, 2009                 [Page 44]


Internet-Draft              Data Model Schema               October 2008


                        <by>sip:conference@example.com</by>
                    </joining-info>
                    <!--
                        MEDIA
                    -->
                    <media id="1">
                        <type>video</type>
                        <label>10235</label>
                        <src-id>432424</src-id>
                        <status>sendrecv</status>
                        <xcon:to-mixer name="VideoIn">
                         <xcon:controls>
                            <xcon:video-layout
                              >single-view</xcon:video-layout>
                         </xcon:controls>
                        </xcon:to-mixer>
                    </media>
                    <media id="2">
                        <type>audio</type>
                        <label>10234</label>
                        <src-id>532535</src-id>
                        <status>sendrecv</status>
                        <xcon:to-mixer name="VideoIn">
                          <xcon:controls>
                            <xcon:gain>50</xcon:gain>
                          </xcon:controls>
                        </xcon:to-mixer>
                        <xcon:from-mixer name="VideoOut">
                          <xcon:controls>
                              <xcon:gain>50</xcon:gain>
                          </xcon:controls>
                        </xcon:from-mixer>
                    </media>
                    <!--
                        CALL INFO
                    -->
                    <call-info>
                        <sip>
                            <display-text>full info</display-text>
                            <call-id>truy45469123478</call-id>
                            <from-tag>asd456cbgt</from-tag>
                            <to-tag>3456jgjg1234</to-tag>
                        </sip>
                    </call-info>
                    <xcon:floor id="345">true</xcon:floor>
                </endpoint>
                <xcon:provide-anonymity>private</xcon:provide-anonymity>
                <xcon:allow-refer-users-dynamically



Novo, et al.               Expires May 1, 2009                 [Page 45]


Internet-Draft              Data Model Schema               October 2008


                    >true</xcon:allow-refer-users-dynamically>
                <xcon:allow-invite-users-dynamically
                    >true</xcon:allow-invite-users-dynamically>
                <xcon:allow-remove-users-dynamically
                    >true</xcon:allow-remove-users-dynamically>
            </user>

            <!--
                USER CAROL
            -->
            <user entity="carol233">
                <display-text>Carol More</display-text>
                <associated-aors>
                    <entry>
                        <uri>mailto:carol@example.com</uri>
                        <display-text>email</display-text>
                    </entry>
                </associated-aors>
                <roles>
                    <entry>administrator</entry>
                </roles>
                <languages>en-us</languages>
                <!--
                    ENDPOINTS
                -->
                <endpoint entity="sip:carol@example.com">
                    <display-text>Carol's Computer</display-text>
                    <status>connected</status>
                    <joining-method>dialed-in</joining-method>
                    <joining-info>
                        <when>2007-10-17T13:30:05Z</when>
                        <reason>invitation</reason>
                        <by>sip:conference@example.com</by>
                    </joining-info>
                    <!--
                        MEDIA
                    -->
                    <media id="1">
                        <type>video</type>
                        <label>10235</label>
                        <src-id>432424</src-id>
                        <status>sendrecv</status>
                        <xcon:to-mixer name="VideoIn">
                            <xcon:controls>
                                <xcon:video-layout
                              >single-view</xcon:video-layout>
                         </xcon:controls>
                        </xcon:to-mixer>



Novo, et al.               Expires May 1, 2009                 [Page 46]


Internet-Draft              Data Model Schema               October 2008


                    </media>
                    <media id="2">
                        <type>audio</type>
                        <label>10234</label>
                        <src-id>532535</src-id>
                        <status>sendrecv</status>
                        <xcon:to-mixer name="VideoIn">
                            <xcon:controls>
                                <xcon:gain>50</xcon:gain>
                            </xcon:controls>
                        </xcon:to-mixer>
                        <xcon:from-mixer name="VideoOut">
                            <xcon:controls>
                                <xcon:gain>50</xcon:gain>
                          </xcon:controls>
                        </xcon:from-mixer>
                    </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>

                    <xcon:floor id="345">false</xcon:floor>
                </endpoint>

                <xcon:provide-anonymity>private</xcon:provide-anonymity>
                <xcon:allow-refer-users-dynamically
                    >true</xcon:allow-refer-users-dynamically>
                <xcon:allow-invite-users-dynamically
                    >true</xcon:allow-invite-users-dynamically>
                <xcon:allow-remove-users-dynamically
                    >true</xcon:allow-remove-users-dynamically>

            </user>

            <xcon:join-handling>allow</xcon:join-handling>
            <xcon:user-admission-policy
               >openAuthenticated</xcon:user-admission-policy>
            <!--
                ALLOWED USERS LIST
            -->



Novo, et al.               Expires May 1, 2009                 [Page 47]


Internet-Draft              Data Model Schema               October 2008


            <xcon:allowed-users-list>
                <xcon:target uri="sip:bob@example.com"
                    method="dial-out"/>
                <xcon:target uri="sip:alice@example.com"
                    method="dial-out"/>
                <xcon:target uri="sip:carol@example.com"
                    method="dial-out"/>
                <xcon:target uri="sip:john@example.com"
                    method="refer"/>
            </xcon:allowed-users-list>
            <!--
                DENY USERS LIST
            -->
            <xcon:deny-users-list>
                <xcon:target uri="sip:charlie@example.com"/>
            </xcon:deny-users-list>
        </users>
        <!--
            SIDEBARS BY REFERENCE
        -->
        <sidebars-by-ref>
            <entry>
                <uri>conf223</uri>
                <display-text>private with Bob</display-text>
            </entry>
        </sidebars-by-ref>
        <!--
            SIDEBARS BY VALUE
        -->
        <sidebars-by-val>
            <entry entity="conf223">
                <users>
                    <user entity="bob534"/>
                    <user entity="carol233"/>
                </users>
            </entry>
        </sidebars-by-val>
        <!--
            FLOOR INFORMATION
        -->
        <xcon:floor-information>
            <xcon:conference-ID>567</xcon:conference-ID>
            <xcon:allow-floor-events>true</xcon:allow-floor-events>
            <xcon:floor-request-handling
             >confirm</xcon:floor-request-handling>

            <xcon:conference-floor-policy>
                <xcon:floor id="345">



Novo, et al.               Expires May 1, 2009                 [Page 48]


Internet-Draft              Data Model Schema               October 2008


                    <xcon:media-label>10234</xcon:media-label>
                    <xcon:media-label>10235</xcon:media-label>
                    <xcon:algorithm
                     >moderator-controlled</xcon:algorithm>
                    <xcon:max-floor-users>1</xcon:max-floor-users>
                    <xcon:moderator-id>234</xcon:moderator-id>
                </xcon:floor>
            </xcon:conference-floor-policy>
        </xcon:floor-information>

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

   Different conferencing protocols will support different types of
   authentication mechanisms.  Since a variety of signaling protocols
   are possible, a variety of authentication mechanism may need to be
   mapped from the different protocols.

   Futhermore, users may use different namespaces to access to a
   conference.  So a mapping database has to specify the acceptable
   range of namespace for a user.  Doing so, a users will not access the
   same conference twice using a different namespace.

   The security considerations for authentication (section 10.1)
   described in the centralized conferencing framework [RFC4575] 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-
   to-end authentication and encryption can be done using public keys,
   and end-to-end encryption can be done using private keys.  It is



Novo, et al.               Expires May 1, 2009                 [Page 49]


Internet-Draft              Data Model Schema               October 2008


   RECOMMENDED that the protocols that manipulated the conference
   information data model use a strong encryption for conference
   information protection.

8.3.  Integrity

   A conferencing system may maintain a mapping database between the
   conference object identifiers and the identifiers associated with
   each of the complementary centralized conferencing protocols, as well
   as, a mapping between the conference user identifiers and the
   identifiers associated with each user in a conference.  This mapping
   database contains sensitive data.  It is RECOMMENDED that the mapping
   database has integrity when it is established, the integrity has to
   be protected, and the database has to be maintained to ensure changes
   in namespaces are accurately reflected.


9.  IANA Considerations

9.1.  Relax NG Schema Registration


  This specification registers a schema. The schema can be found
  as the sole content of Section 5.

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

     Registrant Contact: IETF XCON working group,
        <xcon@ietf.org>, Oscar Novo
        <Oscar.Novo@ericsson.com>

     Relax NG Schema:  The Relax NG schema to be registered is contained
        in Section 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.  XML Namespace Registration









Novo, et al.               Expires May 1, 2009                 [Page 50]


Internet-Draft              Data Model Schema               October 2008


   This section registers a new XML namespace.

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

      Registrant Contact: IETF XCON working group,
         <xcon@ietf.org>, Oscar Novo
         <Oscar.Novo@ericsson.com>

       XML:

         BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
           "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml">
         <head>
           <meta http-equiv="content-type"
                 content="text/html;charset=iso-8859-1"/>
           <title> Centralized Conferencing Namespace</title>
         </head>
         <body>
           <h1>Namespace for Centralized Conferencing</h1>
           <h2>urn:ietf:params:xml:ns:xcon-conference-info</h2>
         <p>See <a href="[URL of published RFC]">RFCXXXX
             [NOTE TO IANA/RFC-EDITOR:
              Please replace XXXX with the RFC number of this
             specification.]</a>.</p>
         </body>
         </html>
         END

9.3.  Conference Object Identifier Registration



 The IANA is requested to register the following URI scheme
 under the Permanent URI Schemes register.

 XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] [RFC xxxx]

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


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

   [Note to the RFC Editor: replace xxxx with the number this RFC gets
   assigned.]




Novo, et al.               Expires May 1, 2009                 [Page 51]


Internet-Draft              Data Model Schema               October 2008


    Subject: Request for XCON-URI Registration
    Person & email address to contact for further information:
         Oscar Novo <oscar novo_at_ericsson.com>
    Specification: RFC XXXX
    Author/Change Controller: IESG
    Comments:
        Identifies the Conference

9.4.  Conference User Identifier Registration



   The IANA is requested to register the following URI scheme
    under the Permanent URI Schemes register.

    XCON-USERID = "xcon-userid" ":" conf-user-id  [ RFC xxxx ]

    conf-user-id = 1*(unreserved)


   unreserved is defined in RFC3986[RFC3986]

   [Note to the RFC Editor: replace xxxx with the number this RFC gets
   assigned.]



    Subject: Request for XCON-USERID Registration
    Person & email address to contact for further information:
         Oscar Novo <oscar novo_at_ericsson.com>
    Specification: RFC XXXX
    Author/Change Controller: IESG
    Comments:
        Identifies the User in the conference


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, Rohan Mahy, Jonathan Lennox, and Henning Schulzrinne for their
   comments.  Also, 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, we would like
   to express our gratitude to all those reviewers for their invaluable



Novo, et al.               Expires May 1, 2009                 [Page 52]


Internet-Draft              Data Model Schema               October 2008


   contribution: Simon Pietro Romano, Lorenzo Miniero, Tobia Castaldi,
   Miguel Garcia, Mary Barnes, Srivatsa Srinivasan, Avshalom Houri,
   Pierre Tane, and Ben Campbell.


11.  References

11.1.  Normative References

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

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

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

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

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

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", RFC 5239, June 2008.

11.2.  Informative References

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

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

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

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

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




Novo, et al.               Expires May 1, 2009                 [Page 53]


Internet-Draft              Data Model Schema               October 2008


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

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

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

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


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-info"
           xmlns="http://relaxng.org/ns/structure/1.0"
           xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
           datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
           <start>
            <element name="conference-info">
             <ref name="conference-type"/>
            </element>
           </start>
           <!--
               CONFERENCE TYPE
           -->
           <define name="conference-type">
            <interleave>
            <attribute name="entity">
             <text/>
            </attribute>
            <ref name="anyAttribute"/>
            <optional>
             <ref name="conference-description-type"/>
            </optional>
            <optional>
             <element name="host-info">
              <ref name="host-type"/>
             </element>
            </optional>



Novo, et al.               Expires May 1, 2009                 [Page 54]


Internet-Draft              Data Model Schema               October 2008


            <optional>
             <element name="conference-state">
              <ref name="conference-state-type"/>
             </element>
            </optional>
            <optional>
             <element name="users">
              <ref name="users-type"/>
             </element>
            </optional>
            <optional>
             <element name="sidebars-by-ref">
              <ref name="uris-type"/>
             </element>
            </optional>
            <optional>
             <element name="sidebars-by-val">
              <ref name="sidebars-by-val-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:floor-information">
              <ref name="floor-information-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               CONFERENCE DESCRIPTION TYPE
           -->
           <define name="conference-description-type">
            <element name="conference-description">
             <interleave>
             <optional>
              <attribute name="xml:lang">
               <data type="language"/>
              </attribute>
             </optional>
             <ref name="anyAttribute"/>
             <optional>
              <element name="display-text">
               <text/>
              </element>
             </optional>
             <optional>



Novo, et al.               Expires May 1, 2009                 [Page 55]


Internet-Draft              Data Model Schema               October 2008


              <element name="subject">
               <text/>
              </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="conf-uris">
               <ref name="uris-type"/>
              </element>
             </optional>
             <optional>
              <element name="service-uris">
                 <ref name="uris-type"/>
              </element>
             </optional>
             <optional>
              <element name="maximum-user-count">
               <data type="int"/>
              </element>
             </optional>
             <optional>
              <element name="available-media">
               <ref name="conference-media-type"/>
              </element>
             </optional>
             <optional>
              <element name="xcon:language">
               <data type="language"/>
              </element>
             </optional>
             <optional>
              <element name="xcon:allow-sidebars">
               <data type="boolean"/>
              </element>
             </optional>



Novo, et al.               Expires May 1, 2009                 [Page 56]


Internet-Draft              Data Model Schema               October 2008


             <optional>
              <element name="xcon:conference-time">
               <ref name="conferencetime-type"/>
              </element>
             </optional>
             <zeroOrMore>
              <ref name="anyElement"/>
             </zeroOrMore>
             </interleave>
            </element>
           </define>
           <!--
               HOST TYPE
           -->
           <define name="host-type">
            <interleave>
            <optional>
             <element name="display-text">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="web-page">
              <data type="anyURI"/>
             </element>
            </optional>
            <optional>
             <element name="uris">
              <ref name="uris-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            <ref name="anyAttribute"/>
            </interleave>
           </define>
           <!--
               CONFERENCE STATE TYPE
           -->
           <define name="conference-state-type">
            <interleave>
            <ref name="anyAttribute"/>
            <optional>
             <element name="user-count">
              <data type="unsignedInt"/>
             </element>
            </optional>



Novo, et al.               Expires May 1, 2009                 [Page 57]


Internet-Draft              Data Model Schema               October 2008


            <optional>
             <element name="active">
              <data type="boolean"/>
             </element>
            </optional>
            <optional>
             <element name="locked">
              <data type="boolean"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:allow-conference-event-subscription">
              <data type="boolean"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               CONFERENCE MEDIA TYPE
           -->
           <define name="conference-media-type">
            <interleave>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="entry">
              <ref name="conference-medium-type"/>
             </element>
            </zeroOrMore>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               CONFERENCE MEDIUM TYPE
           -->
           <define name="conference-medium-type">
            <interleave>
            <attribute name="label">
             <text/>
            </attribute>
            <ref name="anyAttribute"/>
            <optional>
             <element name="display-text">
              <text/>



Novo, et al.               Expires May 1, 2009                 [Page 58]


Internet-Draft              Data Model Schema               October 2008


             </element>
            </optional>
            <optional>
             <element name="type">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="status">
              <ref name="media-status-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:mixing-mode">
              <ref name="mixing-mode-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:codecs">
              <ref name="codecs-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:controls">
              <ref name="control-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               URIs TYPE
           -->
           <define name="uris-type">
            <interleave>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="entry">
              <ref name="uri-type"/>
             </element>
            </zeroOrMore>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>



Novo, et al.               Expires May 1, 2009                 [Page 59]


Internet-Draft              Data Model Schema               October 2008


           <!--
               URI TYPE
           -->
           <define name="uri-type">
            <interleave>
            <element name="uri">
             <data type="anyURI"/>
            </element>
            <optional>
             <element name="display-text">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="purpose">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="modified">
              <ref name="execution-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:conference-password">
              <text/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            <ref name="anyAttribute"/>
           </interleave>

           </define>
           <!--
               USERS TYPE
           -->
           <define name="users-type">
            <interleave>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="user">
              <ref name="user-type"/>
             </element>
            </zeroOrMore>
            <optional>
             <element name="xcon:join-handling">



Novo, et al.               Expires May 1, 2009                 [Page 60]


Internet-Draft              Data Model Schema               October 2008


              <ref name="join-handling-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:user-admission-policy">
              <ref name="user-admission-policy-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:allowed-users-list">
              <ref name="allowed-users-list-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:deny-users-list">
              <ref name="deny-user-list-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               USER TYPE
           -->
           <define name="user-type">
            <interleave>
            <attribute name="entity">
             <data type="anyURI"/>
            </attribute>
            <ref name="anyAttribute"/>
            <optional>
             <element name="display-text">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="associated-aors">
               <ref name="uris-type"/>
             </element>
            </optional>
            <optional>
             <element name="roles">
              <oneOrMore>
               <element name="entry">
                <ref name="single-role-type"/>
               </element>



Novo, et al.               Expires May 1, 2009                 [Page 61]


Internet-Draft              Data Model Schema               October 2008


              </oneOrMore>
             </element>
            </optional>
            <optional>
             <element name="languages">
              <list>
               <data type="language"/>
              </list>
             </element>
            </optional>
            <optional>
             <element name="cascaded-focus">
              <data type="anyURI"/>
             </element>
            </optional>
            <zeroOrMore>
             <element name="endpoint">
              <ref name="endpoint-type"/>
             </element>
            </zeroOrMore>
            <optional>
             <element name="xcon:provide-anonymity">
              <ref name="provide-anonymity-type"/>
             </element>
            </optional>
           <optional>
             <element name="xcon:allow-refer-users-dynamically">
              <data type="boolean"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:allow-invite-users-dynamically">
              <data type="boolean"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:allow-remove-users-dynamically">
              <data type="boolean"/>
             </element>
            </optional>
             <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               ENDPOINT TYPE
           -->



Novo, et al.               Expires May 1, 2009                 [Page 62]


Internet-Draft              Data Model Schema               October 2008


           <define name="endpoint-type">
            <interleave>
            <attribute name="entity">
             <text/>
            </attribute>
            <ref name="anyAttribute"/>
            <optional>
             <element name="display-text">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="referred">
               <ref name="execution-type"/>
             </element>
            </optional>
            <optional>
             <element name="status">
              <ref name="endpoint-status-type"/>
             </element>
            </optional>
            <optional>
             <element name="joining-method">
              <ref name="joining-type"/>
             </element>
            </optional>
            <optional>
             <element name="joining-info">
               <ref name="execution-type"/>
             </element>
            </optional>
            <optional>
             <element name="disconnection-method">
              <ref name="disconnection-type"/>
             </element>
            </optional>
            <optional>
             <element name="disconnection-info">
              <ref name="execution-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <element name="media">
              <ref name="media-type"/>
             </element>
            </zeroOrMore>
            <optional>
             <element name="call-info">



Novo, et al.               Expires May 1, 2009                 [Page 63]


Internet-Draft              Data Model Schema               October 2008


              <ref name="call-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <element name="xcon:floor">
              <attribute name="id">
               <text/>
              </attribute>
              <ref name="anyAttribute"/>
              <data type="boolean"/>
             </element>
            </zeroOrMore>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               ENDPOINT STATUS TYPE
           -->
           <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>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               JOINING TYPE
           -->
           <define name="joining-type">
            <choice>
             <value>dialed-in</value>
             <value>dialed-out</value>
             <value>focus-owner</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               DISCONNECTION TYPE
           -->



Novo, et al.               Expires May 1, 2009                 [Page 64]


Internet-Draft              Data Model Schema               October 2008


           <define name="disconnection-type">
            <choice>
             <value>departed</value>
             <value>booted</value>
             <value>failed</value>
             <value>busy</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               EXECUTION TYPE
           -->
           <define name="execution-type">
            <interleave>
            <optional>
             <element name="when">
              <data type="dateTime"/>
             </element>
            </optional>
            <optional>
             <element name="reason">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="by">
              <data type="anyURI"/>
             </element>
            </optional>
            <ref name="anyAttribute"/>
            </interleave>
           </define>
           <!--
               CALL TYPE
           -->
           <define name="call-type">
            <interleave>
             <element name="sip">
              <ref name="sip-dialog-id-type"/>
             </element>
             <zeroOrMore>
              <ref name="anyElement"/>
             </zeroOrMore>
             <ref name="anyAttribute"/>
            </interleave>
           </define>
           <!--
               SIP DIALOG ID TYPE



Novo, et al.               Expires May 1, 2009                 [Page 65]


Internet-Draft              Data Model Schema               October 2008


           -->
           <define name="sip-dialog-id-type">
            <interleave>
            <optional>
            <element name="display-text">
             <text/>
            </element>
            </optional>
            <element name="call-id">
             <text/>
            </element>
            <element name="from-tag">
             <text/>
            </element>
            <element name="to-tag">
             <text/>
            </element>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            <ref name="anyAttribute"/>
            </interleave>
           </define>
           <!--
               MEDIA TYPE
           -->
           <define name="media-type">
            <interleave>
            <attribute name="id">
             <data type="int"/>
            </attribute>
            <ref name="anyAttribute"/>
            <optional>
             <element name="display-text">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="type">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="label">
              <text/>
             </element>
            </optional>
            <optional>



Novo, et al.               Expires May 1, 2009                 [Page 66]


Internet-Draft              Data Model Schema               October 2008


             <element name="src-id">
              <text/>
             </element>
            </optional>
            <optional>
             <element name="status">
              <ref name="media-status-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:to-mixer">
              <ref name="mixer-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:from-mixer">
              <ref name="mixer-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               MEDIA STATUS TYPE
           -->
           <define name="media-status-type">
            <choice>
             <value>recvonly</value>
             <value>sendonly</value>
             <value>sendrecv</value>
             <value>inactive</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               SIDEBARS-BY-VAL TYPE
           -->
           <define name="sidebars-by-val-type">
            <interleave>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="entry">
              <ref name="conference-type"/>
             </element>
            </zeroOrMore>
            <zeroOrMore>



Novo, et al.               Expires May 1, 2009                 [Page 67]


Internet-Draft              Data Model Schema               October 2008


             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               CONFERENCE TIME
           -->
           <define name="conferencetime-type">
            <interleave>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="xcon:entry">
              <element name="xcon:base">
               <text/>
              </element>
              <optional>
               <element name="xcon:mixing-start-offset">
                 <ref name="time-type"/>
                 <attribute name="required-participant">
                  <ref name="single-role-type"/>
                 </attribute>
                <ref name="anyAttribute"/>
               </element>
              </optional>
              <optional>
               <element name="xcon:mixing-end-offset">
                <ref name="time-type"/>
                <attribute name="required-participant">
                 <ref name="single-role-type"/>
                </attribute>
                <ref name="anyAttribute"/>
               </element>
              </optional>
              <optional>
               <element name="xcon:can-join-after-offset">
                <ref name="time-type"/>
               </element>
              </optional>
              <optional>
               <element name="xcon:must-join-before-offset">
                <ref name="time-type"/>
               </element>
              </optional>
              <optional>
               <element name="xcon:request-user">
                <ref name="time-type"/>
               </element>
              </optional>



Novo, et al.               Expires May 1, 2009                 [Page 68]


Internet-Draft              Data Model Schema               October 2008


              <optional>
               <element name="xcon:notify-end-of-conference">
                <data type="int"/>
               </element>
              </optional>
              <optional>
               <element name="xcon:allowed-extend-mixing-end-offset">
                <data type="boolean"/>
               </element>
              </optional>
              <zeroOrMore>
               <ref name="anyElement"/>
              </zeroOrMore>
             </element>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               TIME TYPE
           -->
           <define name="time-type">
             <data type="dateTime">
               <param name="pattern">.+T.+Z.*</param>
             </data>
           </define>
           <!--
               SINGLE ROLE TYPE
           -->
           <define name="single-role-type">
            <choice>
             <value type="string">none</value>
             <value type="string">administrator</value>
             <value type="string">moderator</value>
             <value type="string">user</value>
             <value type="string">observer</value>
             <value type="string">participant</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               MIXING MODE TYPE
           -->
           <define name="mixing-mode-type">
            <choice>
             <value type="string">moderator-controlled</value>
             <value type="string">FCFS</value>
             <value type="string">automatic</value>
             <ref name="free-text-extension"/>



Novo, et al.               Expires May 1, 2009                 [Page 69]


Internet-Draft              Data Model Schema               October 2008


            </choice>
           </define>
           <!--
               CODECS TYPE
           -->
           <define name="codecs-type">
            <interleave>
            <attribute name="decision">
             <ref name="decision-type"/>
            </attribute>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="xcon:codec">
              <ref name="codec-type"/>
             </element>
            </zeroOrMore>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               CODEC TYPE
           -->
           <define name="codec-type">
            <interleave>
            <attribute name="name">
             <text/>
            </attribute>
            <attribute name="policy">
             <ref name="policy-type"/>
            </attribute>
            <ref name="anyAttribute"/>
            <optional>
             <element name="xcon:subtype">
              <text/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               DECISION TYPE
           -->
           <define name="decision-type">
            <choice>



Novo, et al.               Expires May 1, 2009                 [Page 70]


Internet-Draft              Data Model Schema               October 2008


             <value type="string">automatic</value>
             <value type="string">moderator-controlled</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               POLICY TYPE
           -->
           <define name="policy-type">
            <choice>
             <value type="string">allowed</value>
             <value type="string">disallowed</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               CONTROL TYPE
           -->
           <define name="control-type">
            <interleave>
            <ref name="anyAttribute"/>
            <optional>
             <element name="xcon:mute">
              <data type="boolean"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:pause-video">
              <data type="boolean"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:gain">
              <ref name="gain-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:video-layout">
              <ref name="video-layout-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               GAIN TYPE



Novo, et al.               Expires May 1, 2009                 [Page 71]


Internet-Draft              Data Model Schema               October 2008


           -->
           <define name="gain-type">
             <data type="int">
               <param name="minInclusive">-127</param>
               <param name="maxInclusive">127</param>
             </data>
           </define>
           <!--
               VIDEO LAYOUT TYPE
           -->
           <define name="video-layout-type">
              <choice>
               <value type="string">single-view</value>
               <value type="string">dual-view</value>
               <value type="string">dual-view-crop</value>
               <value type="string">dual-view-2x1</value>
               <value type="string">dual-view-2x1-crop</value>
               <value type="string">quad-view</value>
               <value type="string">multiple-3x3</value>
               <value type="string">multiple-4x4</value>
               <value type="string">multiple-5x1</value>
               <value type="string">automatic</value>
               <ref name="free-text-extension"/>
              </choice>
           </define>
           <!--
               FLOOR INFORMATION TYPE
           -->
           <define name="floor-information-type">
            <interleave>
            <ref name="anyAttribute"/>
            <optional>
             <element name="xcon:conference-ID">
              <data type="unsignedLong"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:allow-floor-events">
              <data type="boolean"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:floor-request-handling">
              <ref name="floor-request-type"/>
             </element>
            </optional>
            <optional>
             <element name="xcon:conference-floor-policy">



Novo, et al.               Expires May 1, 2009                 [Page 72]


Internet-Draft              Data Model Schema               October 2008


              <ref name="conference-floor-policy"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               FLOOR REQUEST TYPE
           -->
           <define name="floor-request-type">
            <choice>
             <value type="string">block</value>
             <value type="string">confirm</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               CONFERENCE FLOOR POLICY
           -->
           <define name="conference-floor-policy">
            <interleave>
            <ref name="anyAttribute"/>
            <oneOrMore>
             <element name="xcon:floor">
              <interleave>
              <attribute name="id">
               <text/>
              </attribute>
              <ref name="anyAttribute"/>
              <oneOrMore>
               <element name="xcon:media-label">
                <data type="nonNegativeInteger"/>
               </element>
              </oneOrMore>
              <optional>
               <element name="xcon:algorithm">
                <ref name="algorithm-type"/>
               </element>
              </optional>
              <optional>
               <element name="xcon:max-floor-users">
                <data type="nonNegativeInteger"/>
               </element>
              </optional>
              <optional>
               <element name="xcon:moderator-id">



Novo, et al.               Expires May 1, 2009                 [Page 73]


Internet-Draft              Data Model Schema               October 2008


                <data type="nonNegativeInteger"/>
               </element>
              </optional>
              <zeroOrMore>
               <ref name="anyElement"/>
              </zeroOrMore>
              </interleave>
             </element>
            </oneOrMore>
            </interleave>
           </define>
           <!--
               ALGORITHM POLICY
           -->
           <define name="algorithm-type">
            <choice>
             <value type="string">moderator-controlled</value>
             <value type="string">FCFS</value>
             <value type="string">random</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               USERS ADMISSION POLICY
           -->
           <define name="user-admission-policy-type">
            <choice>
             <value type="string">closedAuthenticated</value>
             <value type="string">openAuthenticated</value>
             <value type="string">anonymous</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               JOIN HANDLING TYPE
           -->
           <define name="join-handling-type">
            <choice>
             <value type="string">block</value>
             <value type="string">confirm</value>
             <value type="string">allow</value>
             <value type="string">authenticate</value>
             <value type="string">directed-operator</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--
               DENY USERLIST



Novo, et al.               Expires May 1, 2009                 [Page 74]


Internet-Draft              Data Model Schema               October 2008


           -->
           <define name="deny-user-list-type">
            <interleave>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="xcon:target">
              <attribute name="uri">
               <data type="anyURI"/>
              </attribute>
              <ref name="anyAttribute"/>
             </element>
            </zeroOrMore>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               ALLOWED USERS LIST TYPE
           -->
           <define name="allowed-users-list-type">
            <interleave>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="xcon:target">
              <ref name="target-type"/>
             </element>
            </zeroOrMore>
            <optional>
             <element name="xcon:persistent-list">
              <ref name="persistent-list-type"/>
             </element>
            </optional>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               PERSISTENT LIST TYPE
           -->
           <define name="persistent-list-type">
            <interleave>
              <zeroOrMore>
               <element name="xcon:user">
                <interleave>
                <attribute name="name">
                 <text/>



Novo, et al.               Expires May 1, 2009                 [Page 75]


Internet-Draft              Data Model Schema               October 2008


                </attribute>
                <attribute name="nickname">
                 <text/>
                </attribute>
                <attribute name="id">
                 <text/>
                </attribute>
                <ref name="anyAttribute"/>
                <zeroOrMore>
                 <element name="xcon:e-mail">
                  <text/>
                 </element>
                </zeroOrMore>
                <zeroOrMore>
                 <ref name="anyElement"/>
                </zeroOrMore>
                </interleave>
               </element>
             </zeroOrMore>
             <zeroOrMore>
              <ref name="anyElement"/>
             </zeroOrMore>
            </interleave>
           </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>
           <!--
               METHOD TYPE
           -->
           <define name="method-type">
            <choice>
             <value type="string">dial-in</value>
             <value type="string">dial-out</value>
             <value type="string">refer</value>
             <ref name="free-text-extension"/>
            </choice>
           </define>
           <!--



Novo, et al.               Expires May 1, 2009                 [Page 76]


Internet-Draft              Data Model Schema               October 2008


               ANONYMITY TYPE
           -->
           <define name="provide-anonymity-type">
              <choice>
               <value>private</value>
               <value>semi-private</value>
               <value>hidden</value>
               <ref name="free-text-extension"/>
              </choice>
           </define>
           <!--
               MIXER TYPE
           -->
           <define name="mixer-type">
            <interleave>
            <attribute name="name">
             <ref name="mixer-name-type"/>
            </attribute>
            <ref name="anyAttribute"/>
            <zeroOrMore>
             <element name="xcon:controls">
              <ref name="control-type"/>
             </element>
            </zeroOrMore>
            <zeroOrMore>
             <ref name="anyElement"/>
            </zeroOrMore>
            </interleave>
           </define>
           <!--
               MIXER NAME TYPE
           -->
           <define name="mixer-name-type">
             <choice>
              <value>VideoIn</value>
              <value>VideoOut</value>
              <value>AudioOut</value>
              <value>AudioIn</value>
              <ref name="free-text-extension"/>
             </choice>
           </define>
           <!--
               FREE TEXT EXTENSION
               (re-define this as <notAllowed>,
                if extensions beyond this spec are not used)
           -->
           <define name="free-text-extension">
            <text/>



Novo, et al.               Expires May 1, 2009                 [Page 77]


Internet-Draft              Data Model Schema               October 2008


           </define>

           <!--
            *********************************
            EXTENSIBILITY OF THE SCHEMA
            *********************************
           -->
           <!--
               EXTENSIBILITY ELEMENTS
               (re-define this as <empty/>,
                if extensions beyond this spec are not used)
           -->
           <define name="anyElement">
            <element>
             <anyName>
              <except>
               <name>conference-description</name>
               <name>host-info</name>
               <name>conference-state</name>
               <name>users</name>
               <name>sidebars-by-ref</name>
               <name>sidebars-by-val</name>
               <name>display-text</name>
               <name>subject</name>
               <name>free-text</name>
               <name>keywords</name>
               <name>conf-uris</name>
               <name>service-uris</name>
               <name>maximum-user-count</name>
               <name>available-media</name>
               <name>web-page</name>
               <name>uris</name>
               <name>uri</name>
               <name>user-count</name>
               <name>active</name>
               <name>locked</name>
               <name>entry</name>
               <name>type</name>
               <name>status</name>
               <name>purpose</name>
               <name>modified</name>
               <name>user</name>
               <name>associated-aors</name>
               <name>roles</name>
               <name>languages</name>
               <name>cascaded-focus</name>
               <name>endpoint</name>
               <name>referred</name>



Novo, et al.               Expires May 1, 2009                 [Page 78]


Internet-Draft              Data Model Schema               October 2008


               <name>joining-method</name>
               <name>joining-info</name>
               <name>disconnection-method</name>
               <name>disconnection-info</name>
               <name>media</name>
               <name>call-info</name>
               <name>when</name>
               <name>reason</name>
               <name>by</name>
               <name>sip</name>
               <name>call-id</name>
               <name>from-tag</name>
               <name>to-tag</name>
               <name>label</name>
               <name>src-id</name>
               <name>xcon:conference-password</name>
               <name>xcon:mixing-mode</name>
               <name>xcon:codecs</name>
               <name>xcon:controls</name>
               <name>xcon:language</name>
               <name>xcon:allow-sidebars</name>
               <name>xcon:allow-conference-event-subscription</name>
               <name>xcon:to-mixer</name>
               <name>xcon:provide-anonymity</name>
               <name>xcon:allow-refer-users-dynamically</name>
               <name>xcon:allow-invite-users-dynamically</name>
               <name>xcon:allow-remove-users-dynamically</name>
               <name>xcon:from-mixer</name>
               <name>xcon:join-handling</name>
               <name>xcon:user-admission-policy</name>
               <name>xcon:allowed-users-list</name>
               <name>xcon:deny-users-list</name>
               <name>xcon:floor-information</name>
               <name>xcon:conference-time</name>
               <name>xcon:provide-anonymity</name>
               <name>xcon:floor</name>
               <name>xcon:entry</name>
               <name>xcon:mixing-start-offset</name>
               <name>xcon:mixing-end-offset</name>
               <name>xcon:can-join-after-offset</name>
               <name>xcon:must-join-before-offset</name>
               <name>xcon:request-user</name>
               <name>xcon:notify-end-of-conference</name>
               <name>xcon:allowed-extend-mixing-end-offset</name>
               <name>xcon:codec</name>
               <name>xcon:subtype</name>
               <name>xcon:mute</name>
               <name>xcon:pause-video</name>



Novo, et al.               Expires May 1, 2009                 [Page 79]


Internet-Draft              Data Model Schema               October 2008


               <name>xcon:gain</name>
               <name>xcon:video-layout</name>
               <name>xcon:conference-ID</name>
               <name>xcon:allow-floor-events</name>
               <name>xcon:floor-request-handling</name>
               <name>xcon:conference-floor-policy</name>
               <name>xcon:media-label</name>
               <name>xcon:algorithm</name>
               <name>xcon:max-floor-users</name>
               <name>xcon:moderator-id</name>
               <name>xcon:target</name>
               <name>xcon:persistent-list</name>
               <name>xcon:e-mail</name>
               <name>xcon:user</name>
              </except>
             </anyName>
             <ref name="anyExtension"/>
            </element>
           </define>

           <define name="anyExtension">
            <zeroOrMore>
             <choice>
              <attribute>
               <anyName/>
              </attribute>
              <ref name="any"/>
             </choice>
            </zeroOrMore>
           </define>

           <define name="any">
            <element>
             <anyName/>
             <zeroOrMore>
              <choice>
               <attribute>
                <anyName/>
               </attribute>
               <text/>
               <ref name="any"/>
              </choice>
             </zeroOrMore>
           </element>
           </define>

           <!--
               EXTENSIBILITY ATTRIBUTES



Novo, et al.               Expires May 1, 2009                 [Page 80]


Internet-Draft              Data Model Schema               October 2008


               (re-define this as <empty/>,
                if extensions beyond this spec are not used)
           -->

           <define name="anyAttribute">
            <zeroOrMore>
             <attribute>
              <anyName>
               <except>
                <name ns="http://www.w3.org/XML/1998/namespace">lang
                </name>
                <name ns="">entity</name>
                <name ns="">required-participant</name>
                <name ns="">label</name>
                <name ns="">decision</name>
                <name ns="">name</name>
                <name ns="">policy</name>
                <name ns="">uri</name>
                <name ns="">method</name>
                <name ns="">id</name>
                <name ns="">nickname</name>
               </except>
              </anyName>
             </attribute>
            </zeroOrMore>
           </define>
          </grammar>


Appendix B.  Non-Normative W3C XML Schema

   The non-normative W3C XML schema defines extension elements in the
   "urn:ietf:params:xml:ns:xcon-conference-info" namespace.  Note that
   <xs:any> extensions in this schema are stricter than in the normative
   RELAX NG schema [RELAX], and the normative RELAX NG schema [RELAX]
   allows unordered child elements unlike this schema (and the [RFC4575]
   schema).  Also note that this schema allows also otherwise valid
   extension elements to appear in the non-allowed positions.  Likewise
   the cardinalities of these extension elements can not be constrained
   with this schema.

<?xml version="1.0" encoding="UTF-8"?>
  <xs:schema
     xmlns="urn:ietf:params:xml:ns:xcon-conference-info"
     xmlns:info="urn:ietf:params:xml:ns:conference-info"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     attributeFormDefault="unqualified" elementFormDefault="qualified"
     targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info">



Novo, et al.               Expires May 1, 2009                 [Page 81]


Internet-Draft              Data Model Schema               October 2008


    <xs:import namespace="urn:ietf:params:xml:ns:conference-info"
      schemaLocation="rfc4575.xsd"/>

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

    <xs:element name="conference-password" type="xs:string"/>
    <xs:element name="mixing-mode" type="mixing-mode-type"/>
    <xs:element name="codecs" type="codecs-type"/>
    <xs:element name="controls" type="controls-type"/>
    <xs:element name="language" type="xs:language"/>
    <xs:element name="allow-sidebars" type="xs:boolean"/>
    <xs:element name="conference-time" type="conference-time-type"/>
    <xs:element name="allow-conference-event-subscription"
      type="xs:boolean"/>
    <xs:element name="to-mixer" type="mixer-type"/>
    <xs:element name="provide-anonymity"
      type="provide-anonymity-type"/>
    <xs:element name="allow-refer-users-dynamically"
      type="xs:boolean"/>
    <xs:element name="allow-invite-users-dynamically"
      type="xs:boolean"/>
    <xs:element name="allow-remove-users-dynamically"
      type="xs:boolean"/>
    <xs:element name="from-mixer" type="mixer-type"/>
    <xs:element name="join-handling" type="join-handling-type"/>
    <xs:element name="user-admission-policy"
      type="user-admission-policy-type"/>
    <xs:element name="allowed-users-list"
      type="allowed-users-list-type"/>
    <xs:element name="deny-users-list" type="deny-users-list-type"/>
    <xs:element name="floor-information" type="floor-information-type"/>

    <!-- CONFERENCE TIME -->

    <xs:complexType name="conference-time-type">
      <xs:sequence>
        <xs:element name="entry"
          minOccurs="0" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="base"
                type="xs:string" minOccurs="1"/>
              <xs:element name="mixing-start-offset" minOccurs="0">
                <xs:complexType>
                  <xs:simpleContent>
                    <xs:extension base="time-type">
                     <xs:attribute name="required-participant"



Novo, et al.               Expires May 1, 2009                 [Page 82]


Internet-Draft              Data Model Schema               October 2008


                       type="role-type" use="required"/>
                      <xs:anyAttribute namespace="##any"
                        processContents="lax"/>
                    </xs:extension>
                  </xs:simpleContent>
                </xs:complexType>
              </xs:element>
              <xs:element name="mixing-end-offset" minOccurs="0">
                <xs:complexType>
                  <xs:simpleContent>
                    <xs:extension base="time-type">
                      <xs:attribute name="required-participant"
                        type="role-type" use="required"/>
                      <xs:anyAttribute namespace="##any"
                        processContents="lax"/>
                    </xs:extension>
                  </xs:simpleContent>
                </xs:complexType>
              </xs:element>
              <xs:element name="can-join-after-offset" type="time-type"
                minOccurs="0"/>
              <xs:element name="must-join-before-offset" type="time-type"
                minOccurs="0"/>
              <xs:element name="request-user" type="time-type" minOccurs="0" />
              <xs:element name="notify-end-of-conference"
                type="xs:integer" minOccurs="0"/>
              <xs:element name="allowed-extend-mixing-end-offset"
                type="xs:boolean" minOccurs="0"/>
              <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- TIME TYPE -->

     <xs:simpleType name="time-type">
      <xs:restriction base="xs:dateTime">
        <xs:pattern value=".+T.+Z.*"/>
       </xs:restriction>
     </xs:simpleType>

    <!-- ROLE-TYPE -->



Novo, et al.               Expires May 1, 2009                 [Page 83]


Internet-Draft              Data Model Schema               October 2008


    <xs:simpleType name="role-type">
     <xs:restriction base="xs:string">
      <xs:pattern value="none"/>
      <xs:pattern value="administrator"/>
      <xs:pattern value="moderator"/>
      <xs:pattern value="user"/>
      <xs:pattern value="observer"/>
      <xs:pattern value="participant"/>
      <xs:pattern value=".+"/>
     </xs:restriction>
    </xs:simpleType>

    <!-- MIXING MODE TYPE -->

    <xs:simpleType name="mixing-mode-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="moderator-controlled"/>
        <xs:pattern value="FCFS"/>
        <xs:pattern value="automatic"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- CODECS TYPE -->

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

    <!-- CODEC TYPE -->

    <xs:complexType name="codec-type">
      <xs:sequence>
        <xs:element name="subtype" type="xs:string" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="name"
        type="xs:string" use="required"/>
      <xs:attribute name="policy"
        type="policy-type" use="required"/>



Novo, et al.               Expires May 1, 2009                 [Page 84]


Internet-Draft              Data Model Schema               October 2008


      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- DECISION TYPE -->

    <xs:simpleType name="decision-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="automatic"/>
        <xs:pattern value="moderator-controlled"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- POLICY TYPE -->

     <xs:simpleType name="policy-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="allowed"/>
        <xs:pattern value="disallowed"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
     </xs:simpleType>

    <!-- CONTROL TYPE -->

    <xs:complexType name="controls-type">
      <xs:sequence>
        <xs:element name="mute"
          type="xs:boolean" minOccurs="0"/>
        <xs:element name="pause-video"
          type="xs:boolean" minOccurs="0"/>
        <xs:element name="gain"
          type="gain-type" minOccurs="0"/>
        <xs:element name="video-layout"
          type="video-layout-type" default="single-view" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- GAIN TYPE -->

    <xs:simpleType name="gain-type">
      <xs:restriction base="xs:integer">
        <xs:minInclusive value="-127"/>
        <xs:maxInclusive value="127"/>
      </xs:restriction>



Novo, et al.               Expires May 1, 2009                 [Page 85]


Internet-Draft              Data Model Schema               October 2008


    </xs:simpleType>

    <!-- VIDEO LAYOUT TYPE -->

    <xs:simpleType name="video-layout-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="single-view"/>
        <xs:pattern value="dual-view"/>
        <xs:pattern value="dual-view-crop"/>
        <xs:pattern value="dual-view-2x1"/>
        <xs:pattern value="dual-view-2x1-crop"/>
        <xs:pattern value="quad-view"/>
        <xs:pattern value="multiple-3x3"/>
        <xs:pattern value="multiple-4x4"/>
        <xs:pattern value="multiple-5x1"/>
        <xs:pattern value="automatic"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- FLOOR INFORMATION TYPE -->

    <xs:complexType name="floor-information-type">
      <xs:sequence>
        <xs:element name="conference-ID"
          type="xs:unsignedLong" minOccurs="0"/>
        <xs:element name="allow-floor-events"
          type="xs:boolean" default="false" minOccurs="0"/>
        <xs:element name="floor-request-handling"
          type="floor-request-handling-type" minOccurs="0"/>
        <xs:element name="conference-floor-policy"
          type="conference-floor-policy" minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- FLOOR REQUEST TYPE -->

    <xs:simpleType name="floor-request-handling-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="block"/>
        <xs:pattern value="confirm"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>




Novo, et al.               Expires May 1, 2009                 [Page 86]


Internet-Draft              Data Model Schema               October 2008


    <!-- CONFERENCE FLOOR POLICY -->

    <xs:complexType name="conference-floor-policy">
      <xs:sequence>
        <xs:element name="floor" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="media-label"
                type="xs:string" minOccurs="1" maxOccurs="unbounded"/>
              <xs:element name="algorithm"
                type="algorithm-type" minOccurs="0"/>
              <xs:element name="max-floor-users"
                type="xs:nonNegativeInteger" minOccurs="0"/>
              <xs:element name="moderator-id"
                type="xs:nonNegativeInteger" minOccurs="0"/>
                <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="id" type="xs:string" use="required"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- ALGORITHM TYPE -->

    <xs:simpleType name="algorithm-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="moderator-controlled"/>
        <xs:pattern value="FCFS"/>
        <xs:pattern value="random"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- USER ADMISSION POLICY TYPE -->

    <xs:simpleType name="user-admission-policy-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="closedAuthenticated"/>
        <xs:pattern value="openAuthenticated"/>
        <xs:pattern value="anonymous"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>




Novo, et al.               Expires May 1, 2009                 [Page 87]


Internet-Draft              Data Model Schema               October 2008


    <!-- JOIN HANDLING TYPE -->

    <xs:simpleType name="join-handling-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="block"/>
        <xs:pattern value="confirm"/>
        <xs:pattern value="allow"/>
        <xs:pattern value="authenticate"/>
        <xs:pattern value="directed-operator"/>
        <xs:pattern value=".+"/>
       </xs:restriction>
    </xs:simpleType>

   <!-- DENY USER LIST TYPE -->

    <xs:complexType name="deny-users-list-type">
      <xs:sequence>
        <xs:element name="target" minOccurs="0" maxOccurs="unbounded">
          <xs:complexType>
            <xs:attribute name="uri" use="required" type="xs:anyURI"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>
        </xs:element>
        <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

     <!-- ALLOWED USERS LIST TYPE -->

    <xs:complexType name="allowed-users-list-type">
      <xs:sequence>
        <xs:element name="target" type="target-type"
          minOccurs="0" maxOccurs="unbounded">
        </xs:element>
        <xs:element name="persistent-list"
          type="persistent-list-type"
          minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- PERSISTENT LIST TYPE -->

    <xs:complexType name="persistent-list-type">



Novo, et al.               Expires May 1, 2009                 [Page 88]


Internet-Draft              Data Model Schema               October 2008


      <xs:sequence>
        <xs:element name="user" minOccurs="0" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="email" type="xs:string"
                minOccurs="0" maxOccurs="unbounded"/>
              <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="name"
              use="required" type="xs:anyURI"/>
            <xs:attribute name="nickname"
              use="required" type="xs:string"/>
            <xs:attribute name="id"
              use="required" type="xs:string"/>
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:complexType>
        </xs:element>
        <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- TARGET TYPE -->

    <xs:complexType name="target-type">
      <xs:attribute name="uri" use="required"
        type="xs:anyURI"/>
      <xs:attribute name="method" use="required"
        type="method-type"/>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <!-- METHOD TYPE -->

    <xs:simpleType name="method-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="dial-in"/>
        <xs:pattern value="dial-out"/>
        <xs:pattern value="refer"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- ANONYMITY TYPE -->

    <xs:simpleType name="provide-anonymity-type">



Novo, et al.               Expires May 1, 2009                 [Page 89]


Internet-Draft              Data Model Schema               October 2008


      <xs:restriction base="xs:string">
        <xs:pattern value="private"/>
        <xs:pattern value="semi-private"/>
        <xs:pattern value="hidden"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>

    <!-- MIXER TYPE -->

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

    <!-- MIXER NAME TYPE -->

    <xs:simpleType name="mixer-name-type">
      <xs:restriction base="xs:string">
        <xs:pattern value="VideoIn"/>
        <xs:pattern value="VideoOut"/>
        <xs:pattern value="AudioOut"/>
        <xs:pattern value="AudioIn"/>
        <xs:pattern value=".+"/>
      </xs:restriction>
    </xs:simpleType>

  </xs:schema>



Authors' Addresses

   Oscar Novo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Oscar.Novo@ericsson.com




Novo, et al.               Expires May 1, 2009                 [Page 90]


Internet-Draft              Data Model Schema               October 2008


   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


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   Email: roni.even@polycom.co.il


   Jari Urpalainen
   Nokia
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   Phone: +358 7180 37686
   Email: jari.urpalainen@nokia.com
















Novo, et al.               Expires May 1, 2009                 [Page 91]


Internet-Draft              Data Model Schema               October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Novo, et al.               Expires May 1, 2009                 [Page 92]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/