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

A Common
                                                           March 3, 2007

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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on April 13, September 4, 2007.

Copyright Notice

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

Abstract

   This document collects, organizes, and describes the conference
   variables that have been introduced in various protocol drafts of the
   XCON and SIPPING working groups.  The goal of this document is to
   allow the conference control protocols to use a unified common
   conference information data model for XCON.  This document formally defines an Extensible Markup Language (XML) Schema that represents
   the common (XML)-based
   conference information in a data model for centralized conferencing server.
   (XCON).  A conference object, which can be manipulated using a
   conference control protocol, at a conference server represents a
   particular instantiation of this data model.  The conference
   information data model defined in this document is modeled as a series of elements, each of which
   contains a set an extension of children and attributes.
   (and thus, compatible with) the model specified in the Session
   Initiation Protocol (SIP) Event Package for Conference State.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  6
   3.  Common Conference Data  Overview . . . . . . . . . . . . . . . . . . . .  4
     3.1.  General . . . . . . .  6
     3.1.  Data Model Structure . . . . . . . . . . . . . . . . . .  4 .  6
     3.2.  Common  Conference Policies  . . . . . . . . . . . . . . . .  9
     3.3.  <conference-description> . . .  7
       3.2.1.  Role Definitions . . . . . . . . . . . . . . . 10
       3.3.1.  <conference-time> . . . .  8
         3.2.1.1.  Role in a Floor  . . . . . . . . . . . . . . 11
       3.3.2.  <conf-uris> . . .  8
         3.2.1.2.  Changing Roles . . . . . . . . . . . . . . . . . . 13
       3.3.3.  <service-uris>  9
   4.  Data Model Definition  . . . . . . . . . . . . . . . . . . . . 13
       3.3.4.  <maximum-user-count>  9
     4.1.  <conference-description> . . . . . . . . . . . . . . . . . 13
       3.3.5.  <maximum-streams>
       4.1.1.  <conference-time>  . . . . . . . . . . . . . . . . . . 13
       3.3.6.  <available-media> 14
       4.1.2.  <conf-uris>  . . . . . . . . . . . . . . . . . . 13
       3.3.7.  <controls> . . . 15
       4.1.3.  <service-uris> . . . . . . . . . . . . . . . . . . . 14
         3.3.7.1.  mute . 16
       4.1.4.  <maximum-user-count> . . . . . . . . . . . . . . . . . 16
       4.1.5.  <available-media>  . . . . . 14
         3.3.7.2.  pause-video . . . . . . . . . . . . . 16
         4.1.5.1.  <controls> . . . . . . 14
         3.3.7.3.  gain . . . . . . . . . . . . . . 17
           4.1.5.1.1.  mute . . . . . . . . . 15
     3.4.  <host-info> . . . . . . . . . . . . 17
           4.1.5.1.2.  pause-video  . . . . . . . . . . . 15
     3.5.  <conference-state> . . . . . . 17
           4.1.5.1.3.  gain . . . . . . . . . . . . . . 15
     3.6.  <floor-information> . . . . . . . 18
           4.1.5.1.4.  video-layout . . . . . . . . . . . . 15
     3.7.  <users> . . . . . 18
     4.2.  <host-info>  . . . . . . . . . . . . . . . . . . . . 16
       3.7.1.  <allowed-users-list> . . . 19
     4.3.  <conference-state> . . . . . . . . . . . . . . 17
       3.7.2.  <privileges-control-list> . . . . . . 19
     4.4.  <floor-information>  . . . . . . . . 18
         3.7.2.1.  <conference-rules> . . . . . . . . . . . 19
     4.5.  <users>  . . . . . 18
           3.7.2.1.1.  <condition> . . . . . . . . . . . . . . . . . 18
           3.7.2.1.2.  <pseudonymous> . . . 21
       4.5.1.  <allowed-users-list> . . . . . . . . . . . . . 19
           3.7.2.1.3.  <has-been-referred> . . . . 22
       4.5.2.  <user> . . . . . . . . . 19
           3.7.2.1.4.  <has-been-invited> . . . . . . . . . . . . . . 19
           3.7.2.1.5.  <has-been-in-conference> . 22
         4.5.2.1.  <from-mixer>, <to-mixer> . . . . . . . . . . 19
           3.7.2.1.6.  <is-in-conference> . . . 23
           4.5.2.1.1.  <floor>  . . . . . . . . . . . 19
           3.7.2.1.7.  <administrator> . . . . . . . . 23
       4.5.3.  <sidebars-by-ref>  . . . . . . . 19
           3.7.2.1.8.  <is-on-allowed-users-list-dial-out> . . . . . 20
           3.7.2.1.9.  <is-on-allowed-users-list-refer> . . . . . . 24
       4.5.4.  <sidebars-by-val>  . 20
           3.7.2.1.10. <participant-passcode> . . . . . . . . . . . . 20
           3.7.2.1.11. <administrators-passcode> . . . . . 24
   5.  RELAX NG Schema  . . . . . 20
         3.7.2.2.  <actions> . . . . . . . . . . . . . . . . . . 24
   6.  XML Schema Extensibility . . 21
     3.8.  <user> . . . . . . . . . . . . . . . . . 33
   7.  XML Example  . . . . . . . . . 22
       3.8.1.  from-mixer, to-mixer . . . . . . . . . . . . . . . . 33
   8.  Security Considerations  . 23
         3.8.1.1.  <floor> . . . . . . . . . . . . . . . . . . 42
   9.  IANA Considerations  . . . 23
     3.9.  <sidebars-by-ref> . . . . . . . . . . . . . . . . . . 42
     9.1.  Conference Relax NG Schema Registration  . . 24
     3.10. <sidebars-by-val> . . . . . . . 42
     9.2.  Conference Namespace Registration  . . . . . . . . . . . . . 24
   4.  RELAX NG schema  . . . . . . . . . . . . . . . . . . . . . . . 24
   5.  XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 48
   6.  XML example  . . . . . . . . . . 43
   10. Acknowledgements . . . . . . . . . . . . . . . 49
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 58
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . 43
   11. References . . . 58
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
   10. 43
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
     11.2. Informative References . . . . . . . 58
     10.1. Normative References . . . . . . . . . . . . . . 43
   Appendix A.  Appendix A.  Non-Normative RELAX NG Schema in XML
                Syntax  . . . . . 58
     10.2. Informative References . . . . . . . . . . . . . . . . . . 59 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 69
   Intellectual Property and Copyright Statements . . . . . . . . . . 61 71

1.  Introduction

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

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

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

   A conference object contains the core information that is utilized in any of a conference
   (capabilities,
   (i.e., capabilities, membership, roles, call control signalling, signaling,
   media,
   etc...) etc.) and specifies the set of rights, permissions who, and limitations
   pertaining to operations being performed on a certain Conference
   Object.

   This document gives an overview of the conference variables that have
   been introduced in various protocol drafts which way, can manipulate that
   information.

   Figure 1 shows logical functional elements of a conference server as
   defined by the XCON working group
   to date and proposes to create Conferencing Framework [1].  They are a unified common conference
   information data model for XCON.

   This document has been constructed in compliance with the XCON
   Framework [1]
   Conference Control Server, a Floor Control Server, a number of Foci,
   and a Notification Service.  A conference control protocol provides
   the Session Initiation Protocol (SIP) Event Package
   for Conference State [2].  It also incorporates data elements
   proposed in several XCON WG interface between a conference and SIPPING WG drafts.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", media control client, and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [3].

   This document uses the terminology defined in
   conference control server.  A floor control protocol (e.g., BFCP [7])
   provides the XCON Conferencing
   Framework [1] interface between a floor control client and the SIPPING Conferencing Framework [4].  In
   addition, it uses definitions from The Binary Floor Control Protocol
   [7].

3.  Common Conference Data

3.1.  General

   The conference object data model document is an XML [5] document that
   MUST be well formed and SHOULD be valid.  Conference object data
   model documents MUST be based on XML 1.0 and SHOULD be encoded using
   UTF-8. floor
   control server.  A Common Conference information document begins with call signaling protocol (e.g., SIP, H.323, PSTN,
   etc.) provides the root element
   tag <conference-info> of conference-type.  The <conference-info> has interface between a call signaling client and a
   Focus.  A notification protocol (e.g., SIP-based event notifications
   [8]) provides the attribute 'entity' that contains interface between the conference unique identifier
   that identifies conferencing client and the conference being described in
   Notification Service.  Within a conference, the document.

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

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

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

   !<conference-info>
        |
        |--!<conference-description>
        |     |--<display-text>
        |     |--<subject>
        |     |--<free-text>
        |     |--<keywords>
        |     |--<web-page>
        |     |--<security-level>
        |     |--<allow-sidebars>
        |     |--<conference-stage>
        |     |--<conference-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> object.

      ...............................................................
      . Conferencing Server                                         .
      .       +---------------------------------------------------+ .
      .       |       C o n f e r e n c e   o b j e c t           |      |--<SIP> .
      .     +-+--------------------------------------------------+| .
      .     |       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             ||| .
      .   |    |--<uri> +--------------------------------------------------+||| .
      .   | | Conference Information Data Model                |||| .
      .   |    |--<display-text> | +----------------------------------------------+ |||| .
      .   | |    |--<purpose> | Conference description  (times, duration)    |      |--<H323> |||| .
      .   | | +----------------------------------------------+ |||| .
      .   |    |--<H.323-alias> | +----------------------------------------------+ |||| .
      .   | |    |--<H.323-URI> | Host information                             |      |--<PSTN/ISDN> |||| .
      .   | | +----------------------------------------------+ |||| .
      .   |    |--<phone number> | +----------------------------------------------+ |||| .
      .   | |    |--<PIN-code> | Conference state                             | |||| .
      .   |    |--<purpose> | +----------------------------------------------+ |||| .
      .   | |    |--<rate> +----------------------------------------------+ |||| .
      .   | |      ... |     |--<service-uris> Floor information                            | |||| .
      .   |      |--<SIP> | +----------------------------------------------+ |||| .
      .   | |    |--<uri> +----------------------------------------------+ |||| .
      .   | | |    |--<display-text> Membership (users, roles, capacity)          | |||| .
      .   | |    |--<purpose> +----------------------------------------------+ |||| .
      .   | |      |--<H323> +----------------------------------------------+ |||| .
      .   | | |    |--<H.323-alias> Sidebars, Etc.                               | |||| .
      .   | |    |--<H.323-URI> +----------------------------------------------+ |||| .
      .   | |      |--<PSTN/ISDN> +----------------------------------------------+ |||| .
      .   | | |    |--<phone number> Etc.                                         | |||| .
      .   |      |--<BFCP> | +----------------------------------------------+ |||+ .
      .   | +--------------------------------------------------+|+  .
      .   +----^------------------^-------------^--------|------+   .
      .        |    |--<conference-ID>                  |             |      ...        |     |--<maximum-user-count>          .
      . +------v-------+ +--------v-----+ +-----v-+ +----v-------+  .
      . | Conference   |      |--<entry> | Floor        |      |--<entry> |       |      ... |     |--<maximum-streams>            |  .
      . |      |--<entry> Control      | |      |--<entry> Control      | |Foci   |      ... |Notification|  .
      . |     |--!<available-media> Server       | |      |--!<entry> Server       | |       |     |--<type> |Service     |  .
      . +-----^--------+ +---^----------+ +-^-----+ +------------+  .
      ........|..............|..............|..........|.............
              |Conference    |Binary Floor  |Call      |Notification
              |Control       |Control       |Signaling |Protocol
              |Protocol      |Protocol      |Protocol  |      |     |--<display-text>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>
        |     |      |     |--<mix-level>
        |     |      |     |--<codecs>
        |     |      |     |    |--<entry>
        |     |      |     |    |--<entry>
        |     |      |     |    ...
        |     |      |     |--<controls>
        |     |      |     |    |--<mute>
        |     |      |     |    |--<gain>
        |     |      |     |   ...

        |     |      |--<entry>
        |     |      |     |--<type>
        |     |      |     |--<display-text>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>
        |     |      |     |--<mix-level>
        |     |      |     |--<codecs>
        |     |      |     |    |--<entry>
        |     |      |     |    |--<entry>
        |     |      |     |    ...
        |     |      |     |--<controls>
        |     |      |     |    |--<pause-video>
        |     |      |     |   ...
        |     |      ...
        |
        |--!<host-info>
        |     |--<display-text>
        |     |--<web-page>
        |     |--!<uris>
        |     |     |--!<SIP>
        |     |     |    |--!<uri>
        |     |     |    |--<display-text>
        |     |     |    |--<purpose>
        |     |     |--<H323>
        |     |     |    |--<H.323-alias>
        |     |     |    |--<H.323-URI>
        |     |     |--<PSTN/ISDN>
        |     |     |    |--<phone number>
        |           ...
        |--!<conference-state>
        |     |--<allow-conference-state>
        |     |--<user-count>
        |     |--!<active>
        |     |--<locked>
        |
        |--<floor-information>
        |     |--<allow-floor-events>
        |     |--<floor-request-handling>
        |     |--<conference-floor-policy>
        |     |     |--<floor>
        |     |     |    |--<media-types>
        |     |     |    |--<algorithm>
        |     |     |    |--<max-floor-users>
        |     |     |    |--<moderator-uri>
        |     |     |    |--<moderator-uri>
        |     |     |   ...
        |     |     ...
        |
        |--!<users>
        |     |--<join-handling>
        |     |--<user-admission-policy>
        |     |--<allowed-users-list>
        |     |     |--<target>
        |     |     |-- ...
        |     |
        |     |--<privileges-control-list>
        |     |    |--<conference-rules>
        |     |    |     |--<entry>
        |     |    |     |     |--<condition>
        |     |    |     |     |     |--<identity>
        |     |    |     |     |     |     |
        |     |    |     |     |     |     ...
        |     |    |     |     |     |
        |     |    |     |     |     |--<validity>
        |     |    |     |     |     |     |--<from>
        |     |    |     |     |     |     |--<until>
        |     |    |     |     |
        |     |    |     |     |--<actions>
        |     |    |     |     |     |
        |     |    |     |     |     ...
        |     |    |    ...
        |     |
        |     |--!<user>
        |     |    |--<display-text>
        |     |    |--<associated-aors>
        |     |    |--<provide-anonymity>
        |     |    |--<roles>
        |     |    |    |
        |     |    |   ...
        |     |    |--<languages>
        |     |    |--<cascaded-focus>
        |     |    |--<sphere>
        |     |    |--<allow-refer-users-dynamically>
        |     |    |--<allow-invite-users-dynamically>
        |     |    |--<allow-remove-users-dynamically>
        |     |    |--!<endpoint>
        |     |    |      |--<display-text>
        |     |    |      |--<referred>
        |     |    |      |--<status>
        |     |    |      |--<joining-method>
        |     |    |      |--<joining-info>
        |     |    |      |--<disconnection-method>
        |     |    |      |--<disconnection-info>
        |     |    |      |--!<media>
        |     |    |      |    |--<type>
        |     |    |      |    |--<display-text>
        |     |    |      |    |--<label>
        |     |    |      |    |--<src-id>
        |     |    |      |    |--<status>
        |     |    |      |    |--<to-mixer>
        |     |    |      |    |      |--<floor>
        |     |    |      |    |      |--<controls>
        |     |    |      |    |      |      |--<mute>
        |     |    |      |    |      |      |--<gain>
        |     |    |      |    |      |     ...
        |     |    |      |    |--<from-mixer>
        |     |    |      |    |      |--<floor>
        |     |    |      |    |      |--<controls>
        |     |    |      |    |      |      |--<pause-video>
        |     |    |      |    |      |     ...
        |     |    |      |   ...
        |     |    |      |--<call-info>
        |     |    |      |    |--<sip>
        |     |    |      |    |   |--<display-text>
        |     |    |      |    |   |--<call-id>
        |     |    |      |    |   |--<from-tag>
        |     |    |      |    |   |--<to-tag>
        |          ...    ...
        |--<sidebars-by-ref>
        |     |--<entry>
        |     |     |-- <user>
        |     |     |-- <display-text>
        |     |--<entry>
        |     |     |-- <user>
        |     |     |-- <display-text>
        |     ...
        |--<sidebars-by-val>
        |     |--<entry>
        |     |     |
        |     |    ...
        |     |--<entry>
        |     |     |
        |     ...   ...

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

3.2.  Common Conference Policies

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

   The set of rights describes the read/write access privileges for the
   conference object data model as a whole.  Every element of the data
   model SHOULD has defined two attributes: the attribute 'read-only',
   and the attribute 'read-write'.  These attributes describes the read/
   write access privileges for accessing the Conference Object as a
   whole.  It is partially described in [1].  When the conferencing
   server receives a request for access privacy-sensitive data it needs
   to match it against the 'read-only' and the 'read-write' attributes.
   Each attribute of each individual element is evaluated and as a
   result it is determined if the user can access that element.  The
   attributes specify the minimum subscriber's role that can access or
   modify the element of the conference.  Subscribers with a lower role
   cannot access or modify the element.  If an attribute is not defined
   in some element, the 'read-only' attribute MUST be interpreted as a
   "participant" and the 'read-write' attribute MUST be interpreted as
   an "administrator" by default.  It is possible to defined only one of
   the attributes of the element, the other attribute SHOULD be
   interpreted by default.  This draft does not define the set of
   possible conferencing roles.

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

   This document defines a more specific right mechanism in Section
   3.7.2, beyond the 'read-only' and 'read-write' attributes.

   The permissions and limits are specified as an integral part of the
   data model, with elements containing the allowed ranges for other
   elements (e.g., maximum number of participants) and lists of clients
   allowed to perform certain operations on a conference object.

3.3.  <conference-description>

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

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

   The child element <web-page> is an optional element that points to a
   URI with additional information about the conference.  The child
   elements <security-level> and <allow-sidebars> describe the
   capabilities of the conference.

   The <conference-stage> is a mandatory element that give the stage of
   the conference.  This element can have 4 values: reserved, started,
   running, and ended.  At the reserved stage the conference exists only
   in the conference control server.  There is no running focus and
   there are no subscribers or notifications.  The information is
   accessible only via the conference control protocol.  At the started
   stage, there are no users yet in the conference, still it is possible
   to subscribe to the conference state.  The running stage starts when
   the first user joins the conference.  In the ended stage, there are
   no users connected to the conference, the conference information is
   only in the conference server for recurring conference or for CDR.
   At this stage a user can get information only from the conference
   control protocol.  For instance, The Session Initiation Protocol
   (SIP) Event Package for Conference State [2] is only applicable in
   the start and running stage.

   The <conference-time> child element has information related to
   conference time and duration of the conference.  Other elements from
   different namespaces MAY be present for the purposes of
   extensibility.  The <conf-uris> and <service-uris> are used to
   describe the conference-related identifiers.  The <maximum-user-
   count> child element indicates the number of users that can be
   invited to the conference.  The <maximum-streams> child element
   indicates the number of streams that can be for every media type.
   The <available-media> child element is used to describe the media
   characteristics of the conference.

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

3.3.1.  <conference-time>

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

   Every <entry> element contains a <mixing-start-offset> child element
   that specifies when conference media mixing starts before the
   conference starts, <mixing-end-offset> child element that specifies
   the time a conference media mixing stops after the conference stops.
   The <mixing-end-offset> child element expresses the offset as signed
   integers representing seconds before/after DTEND field.  The <mixing-
   start-offset> child element expresses the offset as signed integers
   representing seconds before/after DTSTART field.  If the <mixing-
   start-offset> element is not present, it indicates that the
   conference media mixing starts immediately.  If the <mixing-end-
   offset> element is not present, it indicates that the conference
   occurrence is not bounded. <mixing-start-offset> and <mixing-end-
   offset> elements both have the mandatory 'require-participant'
   attribute.  This attribute has one of 4 values: 'none',
   'administrator', 'moderator', and 'participant'.  For mixing start
   offset, this attribute allows a privileged user to define when media
   mixing starts based on the latter of the mixing start time, and the
   time the first participant, administrator, or moderator arrives.  If
   the value is set to 'none', mixing starts according to the mixing
   start time.  For mixing end offset, this attribute allows a
   privileged user to define when media mixing ends based on the earlier
   of the mixing end offset, and the time the last participant, or
   moderator leaves.  If the value is set to 'none', mixing stops
   according to the mixing end offset.  If the conference policy was
   modified so that last privileged user is now a normal conference
   participant, and the conference requires a privileged user to
   continue; that conference MUST terminate.

   An administrator can indicate the time when users can join a
   conference by populating the <can-join-after-offset> element.
   Similarly, an administrator can define the time after which new users
   are not allowed to join the conference anymore.  This is done by
   populating the <must-join-before-offset> element expressing the
   offset as signed integers representing seconds before/after DTSTART
   field.

   The <base> child element specifies the iCalendar object of the
   conference.  The iCalendar object components are defined in [6].

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

   The <notify-end-of-conference> element defines in seconds when the
   system has to send a notification when the end of the conference is
   near.  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 near.  The <notify-end-of-conference> child element
   expresses the offset as signed integers representing seconds before/
   after DTSTART field.  The <allowed-extend-mixing-end-offset> refers
   to the possibility to extend the conference.  It has two values:
   allowed, denied.

3.3.2.  <conf-uris>

   The <conf-uris> contains the identifiers to be used in order to
   access the conference by different signaling means.  It contains a
   sequence of child elements: <SIP>, <H.323>, and <PSTN/ISDN>.  The
   <SIP> element contains the <uri>, <display-text>, and <purpose>.
   <uri>, <display-text>, and <purpose> are described in [2].  The
   <H.323> element includes either a <H.323-alias> or a <H.323-URI>
   child elements.  The <PSTN/ISDN> has an attribute 'PIN code' with the
   PIN code of the conference if used and a 'purpose' attribute that
   describes to the user which phone number to use. <PSTN/ISDN> element
   may include 1 or more <phone number> child elements and the call rate
   as well.

3.3.3.  <service-uris>

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

3.3.4.  <maximum-user-count>

   The <maximum-user-count> contains the overall number of users allowed
   to join the conference.  It contains a sequence of <entry> child
   elements.  An <entry> element MAY contain the number of users with a
   specific role allowed to join the conference.

3.3.5.  <maximum-streams>

   The <maximum-streams> contains the maximum number of streams that are
   permitted to be involved in a conference.  It contains a sequence of
   <entry> child elements.  An <entry> element MAY contain the number of
   streams of every specific type of stream, for instance, audio or
   video.  The minimum value permitted is "1" and the maximum value
   permitted is "128".  This element is optional.

3.3.6.  <available-media>

   The <available-media> has the 'label' attribute that is the media
   stream identifier assigned by the conferencing server.  This element
   contains a sequence of <entry> child elements of conference-medium-
   type.  Each <entry> element contains the <type>, <display-text>,
   <status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child
   elements.  The attribute 'label' and the <type>, <display-text>, and
   <status> elements are described in [2].
      ........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
   The <codecs> element
   specifies the allowed codecs Session Initiation Protocol (SIP) Event Package for Conference
   State, specified in the conference.  It has an attribute
   'decision' RFC 4575 [2], already defines a data model for
   conferences.  However, that specifies if the focus decides the common codec
   automatically or needs the approvement of the moderator model is SIP specific and lacks elements
   related to some of the
   conference (automatic, moderator-controlled).  The <codecs> element
   contains a <entry> elements.  A <entry> element can have functionality defined by the
   attribute 'name' and 'policy'. XCON conferencing
   framework [1] (e.g., floor control).  The 'name' attribute identifies a
   codec, and the 'decision' attribute and the policy attribute contains data model defined in this
   document extends the policy for that codec (allowed, or disallowed). one defined in RFC 4575 [2].  The child elements <mixing-mode>, <mix-level> describe result is a default
   policy by which the mixer will build the outgoing stream from the
   incoming streams.  Notice
   data model that this policy is different supports more call signaling protocols besides SIP
   and that covers all the
   policy describe for functionality defined in the floors for each media. XCON
   conferencing framework [1].

2.  Terminology

   The <mix-level> child
   element describes the number of participants key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in audio media streams
   or the number of sub-windows this
   document are to be interpreted as described in video media streams (for instance, a
   value of 4 RFC 2119 [3].

   This document uses the terminology defined in the <mix-level> element for video stremas means 2x2
   layout).  The <mixing-mode> child element MUST contain one and only
   one of XCON Conferencing
   Framework [1], the "Moderator-controlled", "FCFS", SIP conferencing framework [4] and "Automatic" values
   indicating the default algorithm BFCP
   (Binary Floor Control Protocol) specification [7].  Readers of this
   document are supposed to be use familiar with every media stream.
   Next section explains the <controls> child element.

3.3.7.  <controls> terminology used in
   those documents.

3.  Overview

   The <controls> element contains the basic audio and video global
   controls for a conferencing.  It data model defined in this document is expected that for most of the
   basic conferencing, these controls are sufficient.  If the conference
   server wants to support more advanced control, then it is recommended
   extension result of extending
   the data model to be used.  In the <controls> element
   the schema is extensible, hence defined in RFC 4575 [2] with new control types elements, which carry
   information such as non-SIP URIs or floor-control-related parameters.
   This data model can be added in a
   future.  Similarly, controls that apply to a especific users would
   appear under the <users>/<user>/<endpoint> element.  So, moderator
   controls that affect all media output would go under the <available-
   media> element.

3.3.7.1.  mute

   The 'mute' control is used in conjunction with a audio stream to
   cease transmission by conference servers providing different
   types of associated media. basic conferences.  It has a 'Boolean' value.
   If this control is not specify, the access to the control is not
   available to the client and media SHOULD not expected that this data model can
   be transported for further extended with new elements in the
   associated media stream.

3.3.7.2.  pause-video

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

   If
   implement advanced features.

3.1.  Data Model Structure

   The information in this control data model is not specify, structured in the access to following
   manner.  All the control is not
   available information related to a conference is contained in
   a <conference-info> element.  The <conference-info> element contains
   the client and media SHOULD not be transported for the
   associated media stream.

3.3.7.3.  gain following child elements:
   o  The 'gain' control is used in conjunction with <conference-description> element describes the conference as a media output stream
   to indicate
      whole.  It has, for instance, information about the amount of amplification URI of an audio stream.  It has a
   'Int' number value from -127 to 127.  If this control is not specify, the access to
      conference, maximum users allowed in the control is not conference, media
      available to in the client.

3.4.  <host-info> conference, or the time the conference will
      start.
   o  The <host-info> element contains information about the entity
      hosting the conference.  It contains conference (e.g., its URI).

   o  The <conference-state> element informs the <display-text>, <web-page> child
   elements.  These child elements are explained subscribers about the
      changes in [2]. <host-info>
   contains the <uris> child overall conference information.
   o  The <floor-information> element as well. <uris> contains a sequence
   of child elements: <SIP>, <H.323>, and <PSTN/ISDN>.  The child
   elements information about the
      status of <uris> are described the different floors in <conf-uris> section.

3.5.  <conference-state> the conference.
   o  The <conference-state> <users> element and describes the <user-count>, <active>, and
   <locked> child element are explained in section 5.5 of [2]. membership information as a
      whole.  The
   <allow-conference-state> <users> element represents contains a boolean action.  If set
   to TRUE, the focus is instructed to allow the subscription to
   conference state events, such as of <user> child
      elements, each describing a single participant in the SIP Event Package for Conference
   State [2]. conference.
   o  If set to FALSE, a participant in the subscription to main conference state
   events would be rejected.  If this joins a sidebar, a new
      element is undefined it has a
   value of TRUE, causing created in the subscription to conference state events to
   be accepted.

3.6.  <floor-information>

   The <floor-information> element has the <allow-floor-events>, <floor-
   request-handling>, and the <conference-floor-policy> child elements.
   Other elements referenced from different namespaces MAY be present for the
   purposes
      <sidebars-by-ref> element or under one of extensibility. the <sidebars-by-val>
      elements.

3.2.  Conference Policies

   Conference policies specify who, and in which way, information in a
   conference object can be manipulate.  This element data model has its own XML namespace.
   The absence of this namespace no strict
   separation between conference membership and media information, and
   its related policies.  Policy-related elements from an XML document
   indicates that and attributes appear
   with the conference does not have a floor.

   The <allow-floor-events> element represents a boolean action.  If set
   to TRUE, the focus they apply to.

   [Editor's Note: The Policies section is instructed still under discussion.  For
   more details refer to accept the subscription to floor
   control events.  If XCON mailing list. ]

   The set to FALSE, of rights describes the focus is instructed to reject read/write access privileges for the subscription.  If this element is undefined, it has
   conference object data model as a value whole.  Every element of
   FALSE, causing the subscription to floor control events to be
   rejected.

   The <floor-request-handling> element defines data
   model SHOULD define two attributes: the actions used by attribute 'read-only', and
   the
   conference focus to control floor requests.  This element defines attribute 'read-write'.  These attributes describes the
   action that read/
   write access privileges for accessing the focus is to take when processing a particular request
   to a floor within Conference Object as a conference.  This element defines values of:
   o  block: This action instructs the focus to deny the floor request.
   whole.  This action is the default action taken partially described in [1].  When the absence of any
      other actions.
   o  confirm: This action instructs the focus conferencing
   server receives a request to allow the request.
      The focus then uses the defined floor algorithm access privacy-sensitive data it needs
   to further allow
      of deny match it against the floor.  The algorithms used are outside 'read-only' and the scope of
      this document.

   Note that placing a value 'read-write' attributes.
   Each attribute of block for this each individual element does not
   guarantee that is evaluated and as a participant
   result it is blocked from joining determined if the conference.
   Any other rule that might evaluate to true for this participant that
   carried an action whose value was higher than block would
   automatically grant confirm/allow permission to requestor can access that participant. element.
   The <conference-floor-policy> element is mandatory and contains attributes specify the
   required boolean attribute minimum requestor's role that indicates if the floor is moderator
   controlled or not.  One or more <Floor> elements can appear in access
   or modify the
   <conference-floor-policy> element.  Every floor is element of the conference.  Requestors with a role with
   lower privileges as defined using in Section 3.2.1 cannot access or modify
   the
   'label' attribute. element.

   If the <available-media> information an attribute is included not defined in some element, the conference document, 'read-only'
   attribute MUST be interpreted as a "participant" role and the value of this 'read-
   write' attribute MUST be equal interpreted as an "administrator" role by
   default.  It is possible to the 'label' value defined only one of the corresponding media stream <entry> in the
   <available-media> container.  The number attributes of those elements indicates
   how many floors the conference can have.  A floor can
   element, the other attribute SHOULD be interpreted by default.  The
   next section defines conferencing roles that are used for one
   or more media types; the mandatory <Media-types> element can contain
   zero or more of the <Video>, <Audio>, <Application>, <Data>
   ,<Control>, <Message>, and <text> elements indicating the media of to represent
   participants within a Conference Object.  Additional roles may be
   defined in the floor.  One type of media can only appear once.  Other media
   types future, as necessary, with their corresponding schema
   extensions, as appropriate.

   However, it can also be defined by extensions.

   A floor the case that conflicts can be controlled using many algorithms; occur given a
   hierarchy of elements.  In that case, the mandatory
   <Algorithm> lower-level element MUST contain one
   privileges predominate over the upper-level privileges element.

   The policies and only rights are an integral part of the <Moderator-
   controlled>, <FCFS>, and <Random> data model, with
   elements indicating the algorithm.

   The <Max-floor-users> element in the <Floor> element is optional and,
   if present, dictates containing the allowed ranges for other elements (e.g.,
   maximum number of users who can have the
   floor at one time.  The optional <Moderator-URI> indicates the URI of
   the moderator.  It MUST be set if the attribute moderator-controlled
   is set to "true".

3.7.  <users>

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

   The <join-handling> element defines the actions used by the
   conference focus lists of end-points allowed to control
   perform certain operations on a conference participation. object.

3.2.1.  Role Definitions

   This element section defines the action that the focus is to take when processing five logical roles for a
   particular request Conference System to join
   represent participants within a conference.  This element defines values
   of:
   o  block: This action instructs Conference Object.  In hierarchical
   order they are: "administrator", "creator", "moderator",
   "participant", and "observer".  A set of semantics associated with
   each role is out of the focus to deny access scope of this document.  A Conference System
   MAY choose not to support a particular role.  As well, additional
   roles may be defined in the future, as necessary, with their
   corresponding schema extensions.

   These five roles have an intrinsic hierarchical order within a
   specific conference.  This action  By hierarchical order, it is implied that the
   "administrator" by default action taken in the
      absence of any other actions.
   o  confirm: This action instructs the focus to place the participant
      on SHOULD have higher privileges than a pending list (e.g.,
   "creator", which by parking the call on default SHOULD have higher privileges than a music-on-hold
      server), awaiting moderator input for further actions.
   o  allow: This action instructs
   "moderator" and so on.  For example, the focus to accept "administrator" SHOULD have
   the conference
      join request and grant access ability to the make changes to all conference within variables during
   instantiation and full lifecycle of the
      instructions specified in Conference Object.  The
   "creator" is the transformations 'owner' of this rule.
   o  IVR: This action instructs the focus that the user conference and has various privileges
   which SHOULD allow them to define
      the PIN code.
   o  directed-operator: This action instructs modify the focus conference variables up to direct the
      user to an operator.

   Note
   time the conference is instantiated.  The "moderator" is a logical
   entity that placing will manage the conference.  The "participant" is a value of block for this element does not
   guarantee
   logical entity with generic privileges that will be attending a participant
   conference.  The "observer" is blocked a logical entity which can only
   receive media streams from joining the conference.
   Any other rule  All Conference Systems
   MUST have a role defined as "participant".

   Each user participating in a conference instance is an entity that might evaluate
   can assume one or more roles.  Any entity can be allocated to true for this participant that
   carried an action whose value was higher than block would
   automatically grant confirm/allow permission to that participant.

   The <user-admission-policy> element is
   appropriate logical role.  A role can also be assumed in conjunction
   with the users identity within the Conference System as a list result of three elements:
   'closedAuthenticated', 'openAuthenticated', and 'anonymous'.  If
   an identity assertion transaction on the
   <user-admission-policy> element Conference System.  If no
   roles are defined for an entity, they SHOULD by default be a
   "participant" but local policy MAY define an alternative.

3.2.1.1.  Role in a Floor

   Floor control in centralized conferencing is set to 'closedAuthenticated',
   users must described in the Binary
   Floor Control Protocol (BFCP) [7].  Floors can be specified (and authenticate).  If in the attribute is set
   to 'openAuthenticated', users
   Conference System or created dynamically.  Users can be add after added or
   deleted from a floor when the conference activation. is active.

   A floor chair is a logical entity that manages a floor (grants,
   denies, or revokes a floor).  The following sections describe the remaining elements floor chair is usually in more
   detail.  Other child elements can be used to extend <conference-
   description> an
   "administrator", "moderator", or "creator" role.  A floor participant
   is a logical entity that requests floors, and possibly information
   about them from a floor control server.  They are usually in the future.

3.7.1.  <allowed-users-list>

   The <allowed-users-list> child element contains a list of user URIs,
   PSTN phone numbers, roles,
   "participant" or domains (*@example.com) that the focus
   uses to determine who can join even a "moderator" role [7].

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

3.2.1.2.  Changing Roles

   Users can invite to join change roles during a conference, or who the focus needs to "refer to" the conference.
   The <allowed-users-list> element includes zero or more <target> child
   element.  This child element includes the mandatory 'uri' attribute
   and the mandatory 'method' attribute.  The same 'uri' attribute with
   different method values can appear be done in two
   ways: First, the list more than once.  The
   'method' attribute is a list with the following values: "dial-in",
   "dial-out, and "refer".  The value "dial-in" is used by the focus to
   determine who user can join the conference.  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 new floor in a different
   paradigm, this could also mean that the focus sends an SMS or role.
   Second, an
   email to the referred user. "administrator" or "creator" can dynamically change that
   user's role.  This list can be updated accomplished before the conference is
   instantiated, or during the conference, using an appropriate
   conference lifetime so it can control protocol.  A logical entity whose role has been
   changed will typically have access to the media streams associated
   with that role.

4.  Data Model Definition

   A conference object document is an XML [5] document that MUST be used for mid-conference refers as
   well.

   The "refer" value differs from well
   formed and SHOULD be valid.  Conference object data model documents
   MUST be based on XML 1.0 and SHOULD be encoded using UTF-8.

   A conference object document begins with the "dial-out" root element tag
   <conference-info>, which is defined in [2].  The <conference-info>
   element has an 'entity' attribute that the dial-out contains a list of resources conference object
   identifier (ID) that identifies the focus will initiate a session
   with.  The resources on conference being described in the "refer" value, on
   document.

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

   The following non-normative diagram shows the focus
   themselves.  It is also envisioned structure of conference
   object documents.  The operator "!" preceding an element indicates
   that difference users will have
   different access rights to those lists and therefore a separation
   between the two element is needed.

3.7.2.  <privileges-control-list> mandatory in the data model.  The <privileges-control-list> refers to a virtual set of rights
   pertaining to operations.  This operator "*"
   following an element contains indicates that the <conference-
   rules> element.

3.7.2.1.  <conference-rules> element is introduced and
   defined in this document.  That is, elements without a "*" have
   already been defined in RFC 4575 [2].

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

        |     |--!<available-media>
        |     |      |--!<entry>
        |     |      |     |--<type>
        |     |      |     |--<display-text>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<mix-level>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<entry>*
        |     |      |     |    |--<entry>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<mute>*
        |     |      |     |    |--<gain>*
        |     |      |     |   ...
        |     |      |--<entry>
        |     |      |     |--<type>
        |     |      |     |--<display-text>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<mix-level>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<entry>*
        |     |      |     |    |--<entry>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<pause-video>*
        |     |      |     |    |--<video-layout>*
        |     |      |     |   ...
        |     |      ...
        |
        |--<host-info>
        |     |--<display-text>
        |     |--<web-page>
        |     |--!<uris>
        |     |     |--!<entry>
        |     |     |    |--!<uri>
        |     |     |    |--<display-text>
        |     |     |--<H323>*
        |     |     |    |--<H.323-alias>*
        |     |     |    |--<H.323-URI>*
        |     |     |--<PSTN-ISDN>*
        |     |     |    |--<phone number>*
        |           ...
        |--<conference-state>
        |     |--<allow-conference-event-subscription>*
        |     |--<user-count>
        |     |--!<active>
        |     |--<locked>
        |
        |--<floor-information>*
        |     |--<allow-floor-events>*
        |     |--<floor-request-handling>*
        |     |--<conference-floor-policy>*
        |     |     |--<floor>*
        |     |     |    |--<media-types>*
        |     |     |    |--<algorithm>*
        |     |     |    |--<max-floor-users>*
        |     |     |    |--<chair-id>*
        |     |     |    |--<chair-id>*
        |     |     |   ...
        |     |     ...
        |
        |--!<users>
        |     |--<join-handling>*
        |     |--<user-admission-policy>*
        |     |--<allowed-users-list>*
        |     |     |--<target>*
        |     |     |-- ...
        |     |
        |     |
        |     |--!<user>
        |     |    |--<display-text>
        |     |    |--<associated-aors>
        |     |    |--<provide-anonymity>*
        |     |    |--<roles>
        |     |    |    |
        |     |    |   ...
        |     |    |--<languages>
        |     |    |--<cascaded-focus>
        |     |    |--<allow-refer-users-dynamically>*
        |     |    |--<allow-invite-users-dynamically>*
        |     |    |--<allow-remove-users-dynamically>*
        |     |    |--!<endpoint>
        |     |    |      |--<display-text>
        |     |    |      |--<referred>
        |     |    |      |--<status>
        |     |    |      |--<joining-method>
        |     |    |      |--<joining-info>
        |     |    |      |--<disconnection-method>
        |     |    |      |--<disconnection-info>
        |     |    |      |--!<media>
        |     |    |      |    |--<type>
        |     |    |      |    |--<display-text>
        |     |    |      |    |--<label>
        |     |    |      |    |--<src-id>
        |     |    |      |    |--<status>
        |     |    |      |    |--<to-mixer>*
        |     |    |      |    |      |--<floor>*
        |     |    |      |    |      |--<controls>*
        |     |    |      |    |      |      |--<mute>*
        |     |    |      |    |      |      |--<gain>*
        |     |    |      |    |      |     ...
        |     |    |      |    |--<from-mixer>*
        |     |    |      |    |      |--<floor>*
        |     |    |      |    |      |--<controls>*
        |     |    |      |    |      |      |--<pause-video>*
        |     |    |      |    |      |     ...
        |     |    |      |   ...
        |     |    |      |--<call-info>
        |     |    |      |    |--<sip>
        |     |    |      |    |   |--<display-text>
        |     |    |      |    |   |--<call-id>
        |     |    |      |    |   |--<from-tag>
        |     |    |      |    |   |--<to-tag>
        |          ...    ...
        |--<sidebars-by-ref>
        |     |--<entry>
        |     |     |-- <user>
        |     |     |-- <display-text>
        |     |--<entry>
        |     |     |-- <user>
        |     |     |-- <display-text>
        |     ...
        |--<sidebars-by-val>
        |     |--<entry>
        |     |     |
        |     |    ...
        |     |--<entry>
        |     |     |
        |     ...   ...

   The <conference-rules> element is a set of <entry> child following sections describe these elements
   with specific authorization rules that indicate who in detail.  The full
   Relax NG schema is allowed to
   subscribe to conference-information notifications, see floors,
   request/grant floors, and so on.

   Every <entry> element provided Section 5.

4.1.  <conference-description>

   The <conference-description> element, which is represent by defined in [2],
   describes the 'id' attribute, each of
   which identifies conference as a rule inside the conference. whole.  It contains the
   <condition> and <actions> sub elements.

3.7.2.1.1.  <condition>

   The <condition> element determines whether a particular privilege
   applies SHOULD have an extra
   attribute 'xml:lang' to a user, a role, or domain.

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

   The <identity> element restricts matching of a rule either to a
   single entity or a group contents of entities.  The <identity>
   this element has the
   <one> and <many> child elements as defined in Section 7.1 of [8].  The
   absence of the <identity> element in a <condition> element indicates
   that the privilege applies to all unauthenticated identities.

   The <identity> element has other child elements.  These child
   elements are <pseudonymous>, <has-been-referred>, <has-been-invited>,
   <has-been-in-conference>, <is-in-conference>, <administrator>, <is-
   on-allowed-users-list-dial-out>, <is-on-allowed-users-list-refer>,
   <participant-passcode>, and <administrator-passcode>.

   The <validity> element expresses the validity period of the rule with
   a starting and an ending time.  The <validity> element and its child
   elements ,<from> and <until>, are defined in section 7.3 2.12 of [8].

3.7.2.1.2.  <pseudonymous>

   The <pseudonymous> element [5].  It is used to match participants that have
   provided an authenticated identity to the conference focus, but have
   requested pseudonymity in the conference itself.  A user requests
   pseudonymity by authenticating himself to the conference focus comprised of
   <display-text>, <subject>, <free-text>, <keywords>, <allow-sidebars>,
   <conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>,
   and
   providing a pseudonym <available-media>.

   The <display-text>, <subject>, <free-text> and <keywords> elements
   are defined in [2].  They are used to describe the signalling protocol (for example, using
   the From-header of a SIP request). conference's
   content.

   The <pseudonymous> child element can be combined with <allow-sidebars> describes the <identity>
   element to provide capabilities of the focus with a rule on what
   conference.

   The <conference-time> child element contains information related to do when a
   specific identity is authenticated
   conference time and that identity is requesting
   pseudonymity through duration of the signalling protocol.

3.7.2.1.3.  <has-been-referred> conference.  The <has-been-referred> element can be <conf-uris> and
   <service-uris> are used to match those
   participants that the focus has referred to describe the conference.

3.7.2.1.4.  <has-been-invited> conference-related
   identifiers.  The <has-been-invited> <maximum-user-count> child element indicates the
   number of users that can be used to match those
   participants that the focus has invited into to the conference.

3.7.2.1.5.  <has-been-in-conference>  The <has-been-in-conference>
   <available-media> child element can be is used to match those
   participants that have joined describe the conference in media
   characteristics of the past.

3.7.2.1.6.  <is-in-conference> conference.

   The <is-in-conference> element can following sections describe these elements in more detail.  Other
   child elements MAY be used to match those
   participants that are currently participating defined in the conference.

3.7.2.1.7.  <administrator> future to extend the
   <conference-description> element.

4.1.1.  <conference-time>

   The <administrator> <conference-time> element can be used contains the information related to match those participants
   that are administrators
   conference time and duration of a conference.

3.7.2.1.8.  <is-on-allowed-users-list-dial-out>  The <is-on-allowed-users-list-dial-out> <conference-time>
   element contains one or more <entry> elements each defining the time
   information specifying a single conference occurrence.

   Every <entry> element contains a <mixing-start-offset> child element can be used to match
   those participants
   that are on specifies when conference media mixing starts before the allowed-users-list with
   conference starts, <mixing-end-offset> child element that specifies
   the time a conference media mixing stops after the conference stops.
   The <mixing-end-offset> child element expresses the offset as signed
   integers representing seconds before/after DTEND field.  The <mixing-
   start-offset> child element expresses the offset as signed integers
   representing seconds before/after DTSTART field.  If the method
   dial-out.

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

   The <is-on-allowed-users-list-refer> <mixing-
   start-offset> element can be used to match
   those participants is not present, it indicates that are on the allowed-users-list with
   conference media mixing starts immediately.  If the method
   refer.

3.7.2.1.10.  <participant-passcode>

   The <participant-passcode> <mixing-end-
   offset> element can be used to match those
   participants is not present, it indicates that have knowledge of a passcode for the conference
   (PIN code).

   A focus need not care if a user using a passcode to join
   occurrence is calling
   from a PSTN or an IP phone.  For example: Using a SIP phone, a SIP
   INVITE request arrives directly at the focus.  The focus examines not bounded. <mixing-start-offset> and <mixing-end-
   offset> elements both have the
   identity mandatory 'require-participant'
   attribute.  This attribute has one of 4 values: "none",
   "administrator", "moderator", and discovers that there are no rules allowing this identity
   to join.  The focus also determines that there are no rules
   explicitly prohibiting this identity from joining.  The focus in "participant".  For <mixing-start-
   offset>, this
   case decides to challenge the identity for a passcode, if there is a
   rule that attribute allows users with a passcode knowledge to join.  If no such
   rule exists, the focus would not challenge for a passcode.

   For PSTN users, the system can be set up for an IVR system to prompt
   the privileged user for a passcode before forwarding the request to define when media
   mixing starts based on the focus.
   The focus does not need to care if there is an IVR system or not.  It
   can apply latter of the same procedure as above.  It checks if there are any mixing start time, and the rules allowing or denying
   time the identity access.  In this case, first participant, administrator, or moderator arrives.  If
   the
   identity value is set to "none'", mixing starts according to the GW.  If no rules exist for that identity but mixing
   start time.  For <mixing-end-offset>, this attribute allows a
   general passcode rule does, then
   privileged user to define when media mixing ends based on the focus would challenge earlier
   of the <mixing-end-offset>, and the GW/IVR
   for time the passcode.

   A focus can challenge for last participant, or
   moderator leaves.  If the passcode using, for example, a HTTP
   Digest challenge.  The username, passcode and realm need to be
   assigned and distributed is a manner that value is outside the scope of
   this document.  Mutliple passcodes can be assigned set to "none", mixing stops
   according to multiple users.

3.7.2.1.11.  <administrators-passcode>

   In some cases, administrators of the <mixing-end-offset>.  If the conference are assigned a
   different passcode than normal participants.  The <administrator-
   passcode> element can be used to match those key participants policy was
   modified so that
   have knowledge on last privileged user is now a key participant passcode for normal conference
   participant, and the conference.

   Again, a focus need not care if conference requires a privileged user using a passcode to
   continue; that conference MUST terminate.

   An administrator can indicate the time when users can join is
   calling from a PSTN or
   conference by populating the <can-join-after-offset> element.
   Similarly, an IP phone.  It is important that administrator can define the focus
   has a unique identity for each user joining from a PSTN phone via a
   gateway.  It is time after which new users
   are not enough that one identity to be assigned allowed to all
   users joining from join the same gateway since administrators have more
   control over conference duration.  It might be required that a
   gateway maps the telephone number of the PSTN phone into anymore.  This is done by
   populating the IP
   signalling protocol header that usually carries <must-join-before-offset> element expressing the asserted identity
   or a user.

3.7.2.2.  <actions>
   offset as signed integers representing seconds before/after DTSTART
   field.

   The <actions> <base> child element in specifies the applied rule is a positive grant iCalendar object of
   permission to the conference data model or the conferencing system.
   conference.  The <actions> element has the following operations:
   o iCalendar object components are defined in [6].

   The <allow-refer-users-dynamically> <entry> element represents a boolean
      action.  If set to TRUE, also contains the identity <request-user> child element.
   It is allowed to instruct the
      focus to refer a user possible to define the conference without modifying the
      allowed-users-list (in SIP terms, time when users or resources on the identity
   <allowed-users-list> is allowed to send
      a REFER request requested to join the focus which results in conference by using the focus sending a
      REFER request to
   <request-users> element.  This element expresses the user offset as signed
   integers representing seconds before/after DTSTART field.

   The <notify-end-of-conference> element defines in seconds when the referrer wishes
   system has to join send a notification when the
      conference).  If set to FALSE, end of the refer request conference is rejected.
   approaching.  If
      this the <notify-end-of-conference> element is undefined not
   present, it has a value indicates that the system does not notify the users when
   the end of FALSE, causing the
      refer to be rejected.
   o conference is approaching.  The <allow-invite-users-dynamically> <notify-end-of-
   conference> child element represents a boolean
      action.  If set expresses the offset as signed integers
   representing seconds before/after DTSTART field.  The <allowed-
   extend-mixing-end-offset> refers to TRUE, the identity is allowed possibility to instruct extend the
      focus
   conference.  It has two values: "allowed", "denied".

4.1.2.  <conf-uris>

   The <conf-uris> contains the identifiers to invite a user be used in order to
   access the conference without modifying by different signaling means.  It contains a
   sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>.  The
   <entry> element refers to the
      allowed-users-list list (in SIP terms, protocol.  It keeps the identity same name
   that is allowed to
      send a REFER request defined in [2] to maintain backwards compatibility with this
   RFC.  The <entry> element contains the focus <uri>, <display-text>, and
   <purpose> which results are described in [2].  The currently defined
   <purpose> values to be used with the focus
      sending <conf-uris> are:
   o  participation: Accessing a URI with this <purpose> will bring the
      party into the conference
   o  streaming: Accessing a URI with this <purpose> will commence
      streaming the conference, but not allow active participation
   The <H.323> element includes either a <H.323-alias> or a <H.323-URI>
   child elements.  The <PSTN-ISDN> has an INVITE request to attribute 'PIN code' with the user
   PIN code of the referrer wishes conference if used and a 'purpose' attribute that
   describes to join the conference).  If set user which phone number to FALSE, the refer request is rejected.
      If this use.  The <PSTN-ISDN>
   element is undefined it has may include one or more <phone number> child elements.

4.1.3.  <service-uris>

   The <service-uris> describes auxiliary services available for the
   conference.  It contains a value sequence of FALSE, causing the
      refer to be rejected.
   o child elements: <entry>,
   <H.323>, <PSTN-ISDN>, and <BFCP>.  The <allow-remove-users-dynamically> <entry> child element represents a boolean
      action.  If set contains
   <uri>, <display-text>, and <purpose>.  The purpose will be used to TRUE,
   describe the identity is allowed service.  The currently defined <purpose> values to instruct be
   used with the
      focus to remove a user from <service-uris> are:
   o  web-page: Indicates the web page containing the additional
      information about the conference without modifying
   o  recording: Indicates the
      ruleset (in SIP terms, link at which the identity is allowed to send recorded conference
      context can be retrieved
   o  event: Indicates the URI at which a REFER
      request subscription to the focus which results in conference
      event package may be requested.  This would typically be the focus sending an BYE
      request
      conference URI of the main conference
   Future extensions to this schema may define new values and register
   them with IANA.  These elements are described in [2]. <H.323>, and
   <PSTN-ISDN> child elements are described in the user <conf-uris> section.

4.1.4.  <maximum-user-count>

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

4.1.5.  <available-media>

   The <available-media> has the refer request 'label' attribute that is rejected.  If this the media
   stream identifier assigned by the conferencing server.  This element
      is undefined it has
   contains a value sequence of FALSE, causing the refer to be
      rejected.
   o  The <show-floor-holder> <entry> child elements of conference-medium-
   type.  Each <entry> element defines contains the actions used by <type>, <display-text>,
   <status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child
   elements.  The attribute 'label' and the
      conference focus to control floor requests.  This <type>, <display-text>, and
   <status> elements are described in [2].  The <codecs> element defines
   specifies the action that allowed codecs in the focus is to take when processing a particular
      request to a floor within a conference.  This element  It has defined
      values of:

      *  block: This action instructs an attribute
   'decision' that specifies if the focus to deny the floor
         request.  This action is decides the default action taken in common codec
   automatically or needs the
         absence approval of any other actions.
      *  confirm: This action instructs the focus to allow the request.
         The focus then uses the defined floor algorithm to further
         allow moderator of deny the floor.
   conference ("automatic", "moderator-controlled").  The algorithms used are outside the
         scope of this document.
   o  Note that placing a value of block for this <codecs>
   element does not
      guarantee that contains <entry> elements.  A <entry> element can have the
   attribute 'name' and 'policy'.  The 'name' attribute identifies a participant is blocked from joining
   codec, and the
      conference.  Any other rule that might resolve to true 'decision' attribute contains the policy for this
      participant that carried an action whose value was higher than
      block would automatically grant confirm/allow permission to that
      participant.
   o
   codec (allowed, or disallowed).

   The <show-floor-requests> element is of type boolean
      transformation.  If set to TRUE, child elements <mixing-mode> and <mix-level> describe a default
   policy by which the conference participant is
      able to see mixer will build the floor requests.  If set to FALSE, outgoing stream from the conference
      participant is not able to see floor requests.  If
   incoming streams.  Notice that this element policy is
      undefined, it has different than the
   policy describing the floors for each media.  The <mix-level> child
   element describes the number of participants in audio media streams
   or the number of sub-windows in video media streams (for instance, a
   value of FALSE, causing the floor requests to
      not being seen by "4" in the conference participant.
   o  A rule can be set that provides anonymity to <mix-level> element for video streams implies a specific identity.
      In this case,
   2x2 layout).  The <mixing-mode> child element MUST contain one and
   only one of the focus provides "Moderator-controlled", "FCFS", and "Automatic"
   values indicating the default algorithm to be use with every media
   stream.  The next section explains the rest of <controls> child element.

4.1.5.1.  <controls>

   The <controls> element contains the participants
      an anonymous identity basic audio and video global
   controls for a conference.  It is expected that user, for example anonymous1.  This
      can be achieved by using the <provide-anonymity> element.  It is a
      boolean transformation. majority of
   the basic conferences, these controls are sufficient.  If set to TRUE, the
   conference
      participants will see server wants to support more advanced controls, then it is
   recommended that an anonymous identity for extension of the user whose
      identity is present in data model be used.  In the conditions.
   o  The <read-write>
   <controls> element represents a boolean action.  If set to
      TRUE, the identity schema is allowed to modify the element described
      inside the 'element' attribute extensible, hence new control types
   can be added in the conference policy.  If set
      to FALSE, any modifications future.  Similarly, controls that apply to a
   specific user would appear under the element are rejected.
   o <users>/<user>/<endpoint>
   element.  So moderator controls that affect all media output would go
   under the <available-media> element.

4.1.5.1.1.  mute

   The <read-only> element represents 'mute' control is used in conjunction with an audio stream to
   cease transmission of associated media.  It has a boolean action. "boolean" value.
   If set to
      TRUE, the identity this control is allowed not specified, access to read the element described inside the 'element' attribute in the conference policy.  If set to
      FALSE, any attempts control is not
   available to read the element are rejected.

3.8.  <user>

   The element <user> describes a single participant in client and media SHOULD NOT be transported for the conference.
   associated media stream.

4.1.5.1.2.  pause-video

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

   The <provide-anonymity> provides anonymity conjunction with a video stream
   to the user.  When cease transmission of associated media.  It has a user "boolean" value.
   If this control is defined then the role must be defined or set not specified, access to "participant" by
   default.  This specification does the control is not define
   available to the set of possible
   conferencing roles nor client and media SHOULD NOT be transported for the semantics
   associated with each. media stream.

4.1.5.1.3.  gain

   The <sphere> element can be 'gain' control is used in conjunction with a media output stream
   to indicate the state (e.g., 'work',
   'home', 'meeting', 'travel') the user is currently in. amount of amplification of an audio stream.  It has a
   "int" number value.  If this control is defined
   in section 7.2 of [8].

   The <allow-refer-users-dynamically>, <allow-invite-users-dynamically>
   and <allow-remove-users-dynamically> elements are defined in not specified, access to the
   previous section.
   control is not available to the client.

4.1.5.1.4.  video-layout

   The <endpoint> element 'video-layout' control is under used in conjunction with a <user> parent.  This element video stream
   to specify how the video streams (participants) are viewed by each
   participant.  Only one layout type can
   provide 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 desired level behalf of detail about the user's devices and
   signaling sessions taking part in the conference and has missing input streams.  If unspecified, the
   following child elements defined in [2]: <display-text>, <referred>,
   <status>, <joining-method>, <joining-info>, <disconnection-method>,
   <disconnection-info>, <media>, and <call-info>. <video-
   layout> default type SHOULD be "single-view".

   The <endpoint>
   element has <layout> types are as well two other child elements: <to-mixer>, and <from-
   mixer> child element described in follows:

   single-view: Only one stream is presented by the following section.

3.8.1.  from-mixer, to-mixer

   Similarly that focus to all
   participants in one panel.

   dual-view: This dual view option will present the controls defined video side-by-side
   in 2 panels and not alter the <available-media> element,
   controls that apply aspect ratio of the streams.  This will
   require the focus to a particular user appear at this place in introduce blanking on parts of the
   document.  The <to-mixer> element details properties associated with overall image
   as viewed by the incoming streams participants.

   dual-view-crop: This side-by-side layout option instructs the focus
   to alter the mixer. <from-mixer> element details
   properties associated with aspect ratio of the outgoing streams from (alter-aspect-ratio=TRUE) so
   that blanking is not necessary.  The focus handles the mixer.  Both cropping of these elements have
   the attribute 'name'.  'Name' attribute has streams.

   dual-view-2x1: This layout option instructs the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn".  The
   "VideoOut" and "AudioOut" media streams detail properties associated
   with focus to place one
   stream above the outgoing video other, in essence with two rows and audio from one column.  In
   this option the mixer.  The "VideoIn" aspect ratio is not altered and
   "AudioIn" media blanking is
   introduced.

   dual-view-2x1-crop: This layout option also instructs the focus to
   place one stream details properties associated above the other, in essence with two rows and one
   column.  In this option the
   incoming video aspect ratio is altered and audio to the mixer.  More values can be defined video
   streams are cropped.

   quad-view: Four equal-sized panels in a 2x2 layout is presented by
   the future.

   Every focus to all participants.  Typically the aspect ratio of these elements have the <floor> and <controls> child
   elements.

3.8.1.1.  <floor>

   The <floors> element describes a floor that joins this participant
   streams are maintained (alter-aspect-ratio= FALSE).

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

   multiple-4x4: Sixteen equal-sized panels in a participant, for instance, needs 4x4 layout is presented
   by the focus to talk in all participants.  Typically the
   conference, it first needs aspect ratio of the
   streams are preserved.

   multiple-5x1: This option refers to get a floor from 5x1 layout where one panel will
   occupy 4/9 of the moderator mixed video stream while the others will each
   occupy 1/9 of the
   conference.

   The <floor> element has a 'Boolen' value.  A value stream.  Typically the aspect ratio of 'false'
   indicates that this user does not hold the floor in this moment.  If
   this control streams
   is not specify, this user SHOULD not specify preserved.

   automatic: This option allows the floor
   option.

3.9.  <sidebars-by-ref>

   The <sidebars-by-ref> element contains focus to add panels as streams are
   added up to a set limit of <entry> child
   elements.  Each <entry> child "panels".

4.2.  <host-info>

   The <host-info> element contains a <user> child element
   with a sidebar information about the entity hosting
   the conference.  This information is set before the conference unique identifier
   activation, and a <display-text>
   child element.  The <sidebars-by-ref> element is described in Section
   5.9.1 of [2].

   Notice that rarely changed during the <sidebars-by-ref> child conference lifetime.
   The <host-info> element does not include contains the
   attribute 'state' defined <display-text>, <web-page> and
   <uris> child elements.  The <display-text> and <web-page> child
   elements are explained in [2].

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

   Notice as well that the <sidebars-by-val> elements: <entry>, <H.323>, and the <PSTN-ISDN>.  The
   <entry> child element do not include the attribute 'state' defined in [2].

4.  RELAX NG schema

   In accordance with the XCON framework document [1], refers to the Conference
   Object is a logical representation of a conference instance.  The
   common conference information schema contains core information that
   is utilized in any conference. SIP protocol.  It also contains the variable
   information part of the Conference Object.

   This specification defines some document fragments keeps the same name
   that is defined in RELAX NG
   format.

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

    <!--
        CONFERENCE TYPE
    -->

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

    <!--
        CONFERENCE DESCRIPTION TYPE
    -->
    <define name="conference-description-type">
        <element name="conference-description">
            <ref name="role-type"/>
            <optional>
                <element name="display-text">
                    <text/>
                </element>
                <element name="subject">
                    <text/>
                </element>
                <element name="free-text">
                    <text/>
                </element>
                <element name="keywords">
                    <list>
                        <data type="string"/>
                    </list>
                </element>
                <element name="webpage">
                    <data type="anyURI"/>
                </element>
                <element name="security-level">
                    <ref name="SecurityLevel"/>
                </element>
                <element name="allow-sidebars">
                    <data type="boolean"/>
                </element>
                <element name="conference-stage">
                    <ref name="conference-stage-type"/>
                </element>
                <element name="conference-time">
                    <ref name="conferencetime-type"/>
                </element>
                <element name="conf-uris">
                    <ref name="uris-type"/>
                </element>
                <element name="service-uris">
                    <ref name="uris-type"/>
                </element>
                <element name="maximum-user-count">
                    <ref name="maximum-user-count-type"/>
                </element>
                <element name="maximum-streams">
                    <ref name="maximum-streams-type"/>
                </element>
                <element name="available-media">
                    <ref name="conference-media-type"/>
                </element>
            </optional>
            <xs:any/>
        </element>
    </define>

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

    <!--
        CONFERENCE STAGE
    -->
    <define name="conference-stage-type">
        <choice>
            <value type="string">reserved</value>
            <value type="string">started</value>
            <value type="string">running</value>
            <value type="string">ended</value>
        </choice>
    </define>

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

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

    <!-- [2] to maintain backwards compatibility with this
   RFC.  Future extensions to the <uris> element may define new values.

4.3.  <conference-state>

   The <conference-state> element and the <user-count>, <active>, and
   <locked> child elements are explained in section 5.5 of [2].  The
   <allow-conference-event-subscription> element represents a boolean
   action.  If set to TRUE, the focus is instructed to allow the
   subscription to conference state events, such as the SIP TYPE
    -->
    <define name="uri-type">
        <ref name="role-type"/>
        <oneOrMore>
            <element name="uri">
                <data type="anyURI"/>
            </element>
            <zeroOrMore>
                <element name="display-text">
                    <text/>
                </element>
                <element name="purpose">
                    <text/>
                </element>
                <element name="PIN-code">
                    <data type="int"/>
                </element>
            </zeroOrMore>
        </oneOrMore>
    </define>

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

    <!--
        PSTN TYPE
    -->
    <define name="PSTN-type">
        <ref name="role-type"/>
        <attribute name="PIN-code">
            <text/>
        </attribute>
        <attribute name="purpose">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="phone-number">
                <data type="unsignedInt"/>
            </element>
            <element name="rate">
                <data type="unsignedInt"/>
            </element>
        </zeroOrMore>
    </define>
    <!-- Event
   Package for Conference State [2].  If set to FALSE, the subscription
   to conference state events would be rejected.  If this element is
   undefined it has a default value of TRUE, causing the subscription to
   conference state events to be accepted.

4.4.  <floor-information>

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

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

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

   The <floor-request-handling> element defines the actions used by the
   conference focus to control floor requests.  This element defines the
   action that the focus is to take when processing a particular request
   to a floor within a conference.  This element defines values of:
   o  "block": This action instructs the focus to deny the floor
      request.  This action is the default action taken in the absence
      of any other actions.
   o  "confirm": This action instructs the focus to allow the request.
      The focus then uses the defined floor algorithm to further allow
      or deny the floor.  The algorithms used are outside the scope of
      this document.

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

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

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

   The <max-floor-users> child element in the <floor> element is
   optional and, if present, dictates the maximum number of users who
   can have the floor at one time.  The optional <chair-id> indicates
   the BFCP TYPE
    -->
    <define name="BFCP-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="conference-id">
                <data type="unsignedInt"/>
            </element>
        </zeroOrMore>
    </define>

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

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

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

    <!-- UserID of the moderator.  It MUST be set if the attribute
   moderator-controlled is set to TRUE.

4.5.  <users>

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

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

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

   The <user-admission-policy> is an element that lets an organizer (or
   a participant with appropriate rights) choose a policy for the
   conference that controls how users are allowed into the conference.
   A 'closedAuthenticated' policy requires each conference participant
   to be in the allowed users list (listed under the <allowed-users-
   list> XML element) with each participant being sufficiently (up to
   local policy) authenticated.  Conference join requests for users not
   in the allowed users list or participants not authenticated should be
   rejected unless a <join-handling> action of 'confirm' is selected in
   which case the user is placed on a pending list as indicated earlier.
   An 'openAuthenticated' policy requires each conferencing participant
   to be sufficiently authenticated (as before) but does not restrict
   which participants can join the conference.  Typically this implies
   that anyone capable of authenticating with the conferencing system
   may join the conference.  An 'anonymous' policy allows any join
   requests in and is the least restrictive in policies.

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

4.5.1.  <allowed-users-list>

   The <allowed-users-list> child element contains a list of user URIs,
   PSTN phone numbers, roles, or domains (*@example.com) that the focus
   uses to determine who can join the conference, who can be invited to
   join a conference, or who the focus needs to "refer to" the
   conference.  The <allowed-users-list> element includes zero or more
   <target> child elements.  This child element includes the mandatory
   'uri' attribute and the mandatory 'method' attribute.  The same 'uri'
   attribute with different method values can appear in the list more
   than once.  The 'method' attribute is a list with the following
   values: "dial-in", "dial-out", and "refer".  The value "dial-in" is
   used by the focus to determine who can join the conference.  The
   value "refer" is used by the focus to determine the resources that
   the focus needs to "refer to" the conference.  In SIP, this is
   achieved by the focus sending a REFER request to those potential
   participants.  In a different paradigm, this could also mean that the
   focus sends an SMS or an email to the referred user.  This list can
   be updated during the conference lifetime so it can be used for mid-
   conference refers as well.

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

4.5.2.  <user>

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

   The following elements of <user> are defined in [2], section 5.6:
   <display-text>, <associated-aors>, <roles>, <languages>, <cascaded-
   focus>, and <endpoint>. <user> has two attributes: 'entity' and
   'state'.  The attribute 'state' is defined in [2], section 5.6.  The
   attribute 'entity' contains a unique conference user identifier.
   Other user identifiers can be associated with this conference user
   identifier and enable the conferencing system to correlate and map
   these multiple authenticated user identities to a single global user
   identifier.

   The <provide-anonymity> element provides anonymity to the user.  In
   this case, the focus provides to the rest of the participants an
   anonymous identity for that user, for example anonymousX.  This can
   be achieved by using the <provide-anonymity> element.  It is a
   boolean transformation.  If set to TRUE, the conference participants
   will see an anonymous identity for the user whose identity is present
   in the conditions.

   The <endpoint> child element can provide the desired level of detail
   about the user's devices and their signaling sessions taking part in
   the conference and has the following child elements defined in RFC
   4575 [2]: <display-text>, <referred>, <status>, <joining-method>,
   <joining-info>, <disconnection-method>, <disconnection-info>,
   <media>, and <call-info>.  The <endpoint>/<media> element has two
   other child elements: <to-mixer>, and <from-mixer> described in the
   following section.

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

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

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

4.5.2.1.1.  <floor>

   The <floor> element describes a floor that joins this participant in
   the conference.  If a participant, for instance, needs to talk in the
   conference, it first needs to get the floor from the chair of the
   conference.

   The <floor> element has a "Boolean" value.  A value of FALSE
   indicates that this user does not hold the floor in this moment.  If
   this control is not specified, this user SHOULD NOT specify the floor
   option.

4.5.3.  <sidebars-by-ref>

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

4.5.4.  <sidebars-by-val>

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

5.  RELAX NG Schema

   In accordance with the XCON framework document [1], the Conference
   Object is a logical representation of a conference instance.  The
   conference information schema contains core information that is
   utilized in any conference.  It also contains the variable
   information part of the Conference Object.

   This specification defines some document fragments in RELAX NG
   format.

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

   start = element conference-info { conference-type }
   # CONFERENCE MEDIA TYPE
    -->
    <define name="conference-media-type">
        <ref name="role-type"/>
        <attribute name="label">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="entry">
                <ref name="conference-medium-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
   conference-type =
     attribute entity { text },
     attribute version { xsd:unsignedInt }?,
     attribute state { state-type }?,
     role-type,
     conference-description-type,
     element host-info { host-type }?,
     element conference-state { conference-state-type }?,
     element floor-information { floor-information-type }?,
     element users { users-type },
     element sidebars-by-ref { sidebars-by-ref-type }?,
     element sidebars-by-val { sidebars-by-val-type }?,
     anyElement*
   # CONFERENCE MEDIUM DESCRIPTION TYPE
    -->
    <define name="conference-medium-type">
        <ref name="role-type"/>
        <attribute name="label">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="type">
                <text/>
            </element>
            <element name="display-text">
                <text/>
            </element>
            <element name="status">
                <ref name="media-status-type"/>
            </element>
            <element name="mixing-mode">
                <ref name="mix-mode-type"/>
            </element>
            <element name="mix-level">
                <data type="unsignedInt"/>
            </element>
            <element name="codecs">
                <ref name="codecs-type"/>
            </element>
            <element name="controls">
                <ref name="control-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        MIX MODE
   conference-description-type =
     element conference-description {
       role-type,
       attribute xml:lang { xsd:language }?,
       attribute state { state-type }?,
       element display-text { text }?,
       element subject { text }?,
       element free-text { text }?,
       element keywords {
         list { xsd:string* }
       }?,
       element allow-sidebars { xsd:boolean }?,
       element conference-time { conferencetime-type }?,
       element conf-uris { uris-type }?,
       element service-uris { uris-type }?,
       element maximum-user-count { xsd:int }?,
       element available-media { conference-media-type }?,
       anyElement*
     }
   # CONFERENCE TIME
   conferencetime-type =
     role-type,
     element entry {
       element base { text }?,
       element mixing-start-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" },
         attribute required-participant { single-role-type },
         anyAttribute
       }?,
       element mixing-end-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" },
         attribute required-participant { single-role-type },
         anyAttribute
       }?,
       element can-join-after-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" }
       }?,
       element must-join-before-offset {
         xsd:dateTime { pattern = ".+T.+Z.*" }
       }?,
       element notify-end-of-conference { xsd:int }?,
       element allowed-extend-mixing-end-offset {
         allowed-extend-mixing-values
       }?,
       anyElement*
     }*,
     anyElement*
   # ALLOWED EXTEND MIXING VALUES
   allowed-extend-mixing-values =
     xsd:string "allowed" | xsd:string "denied"
   # URIS TYPE
    -->
    <define name="mix-mode-type">
        <choice>
            <value type="string">Moderator-controlled</value>
            <value type="string">FCFS</value>
            <value type="string">"Automatic</value>
        </choice>
    </define>
    <!--
        CODECS
   uris-type =
     role-type,
     attribute state { state-type }?,
     (element entry { uri-type }*
      & element H323 { H323-type }*
      & element PSTN-ISDN { PSTN-type }*),
     anyElement*
   # SIP TYPE
    -->
    <define name="codecs-type">
        <ref name="role-type"/>
        <attribute name="decision">
            <ref name="decision-type"/>
        </attribute>
        <zeroOrMore>
            <element name="entry">
                <ref name="codec-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        CODEC
   uri-type =
     role-type,
     (element uri { xsd:anyURI },
      element display-text { text }?,
      element purpose { text }?,
      anyElement*)*
   # H323 TYPE
    -->
    <define name="codec-type">
        <ref name="role-type"/>
        <attribute name="name">
            <text/>
        </attribute>
        <attribute name="policy">
            <ref name="policy-type"/>
        </attribute>
    </define>

    <!--
        DECISION
   H323-type =
     role-type,
     element H.323-alias { text }?,
     element H.323-URI { xsd:anyURI }?,
     anyElement*
   # PSTN TYPE
    -->
    <define name="decision-type">
        <choice>
            <value type="string">Automatic</value>
            <value type="string">Moderator-controlled</value>
        </choice>
    </define>

    <!--
        POLICY
   PSTN-type =
     role-type,
     attribute PIN-code { xsd:unsignedInt },
     attribute purpose { xsd:unsignedInt },
     (element phone-number { xsd:unsignedInt },
      anyElement*)+
   # BFCP TYPE
    -->
    <define name="policy-type">
        <choice>
            <value type="string">Allowed</value>
            <value type="string">Disallowed</value>
        </choice>
    </define>
    <!--
        CONTROL
   BFCP-type =
     role-type,
     (element conference-ID { xsd:unsignedInt },
      anyElement*)*
   # MAXIMUM USER TYPE
    -->
    <define name="control-type">
        <choice>
            <value type="string">integer</value>
            <value type="string">real</value>
            <value type="string">boolean</value>
        </choice>
    </define>

    <!--
        HOST
   maximum-user-count-type =
     role-type,
     anyAttribute,
     (element entry {
        xsd:unsignedInt,
        attribute role { single-role-type }
      },
      anyElement*)+
   # CONFERENCE MEDIA TYPE
    -->
    <define name="host-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="web-page">
                <data type="anyURI"/>
            </element>
            <element name="uris">
                <ref name="uris-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
   conference-media-type =
     role-type,
     attribute state { state-type }?,
     element entry { conference-medium-type }*,
     anyElement*
   # CONFERENCE STATE MEDIUM TYPE
    -->
    <define name="conference-state-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="allow-conference-state">
                <data type="boolean"/>
            </element>
            <element name="user-count">
                <data type="unsignedInt"/>
            </element>
            <element name="active">
                <data type="boolean"/>
            </element>
            <element name="locked">
                <data type="boolean"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        FLOOR INFORMATION
   conference-medium-type =
     role-type,
     attribute label { text },
     element display-text { text }?,
     element type { text }?,
     element status { media-status-type }?,
     element mixing-mode { mix-mode-type }?,
     element mix-level { xsd:unsignedInt }?,
     element codecs { codecs-type }?,
     element controls { controls-type }?,
     anyElement*
   # CONTROLS TYPE
    -->

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

    <!--
        FLOOR REQUEST
   controls-type =
     role-type,
     attribute state { state-type }?,
     element control { control-type }*,
     anyElement*
   # MIX MODE TYPE
    -->

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

    <!--
        CONFERENCE FLOOR POLICY
    -->

    <define name="Conference-floor-policy">
        <ref name="role-type"/>
        <attribute name="moderator-controlled">
            <data type="boolean"/>
        </attribute>
        <attribute name="label">
            <text/>
        </attribute>
        <oneOrMore>
            <element name="Floor">
                <zeroOrMore>
                    <element name="Media-types">
                        <ref name="role-type"/>
                        <zeroOrMore>
                            <element name="Video">
                                <empty/>
                            </element>
                            <element name="Audio">
                                <empty/>
                            </element>
                            <element name="Application">
                                <empty/>
                            </element>
                            <element name="Data">
                                <empty/>
                            </element>
                            <element name="Control">
                                <empty/>
                            </element>
                            <element name="Message">
                                <empty/>
                            </element>
                            <element name="Text">
                                <empty/>
                            </element>
                        </zeroOrMore>
                    </element>
                    <element name="Algorithm">
                        <ref name="role-type"/>
                        <zeroOrMore>
                            <element name="Moderator-controlled">
                                <empty/>
                            </element>
                            <element name="FCFS">
                                <empty/>
                            </element>
                            <element name="Random">
                                <empty/>
                            </element>
                        </zeroOrMore>
                    </element>
                    <element name="Max-floor-users">
                        <data type="nonNegativeInteger"/>
                    </element>
                    <element name="Moderator-URI">
                        <data type="anyURI"/>
                    </element>
                </zeroOrMore>
            </element>
        </oneOrMore>
    </define>

    <!--
        USERS
   mix-mode-type =
     xsd:string "moderator-controlled"
     | xsd:string "FCFS"
     | xsd:string "automatic"
   # CODECS TYPE
    -->
    <define name="users-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="join-handling">
                <ref name="join-handling-type"/>
            </element>
            <element name="user-admission-policy">
                <ref name="user-admission-policy-type"/>
            </element>
            <element name="user-must-be-specified">
                <data type="boolean"/>
            </element>
            <element name="allowed-users-list">
                <ref name="UserList"/>
            </element>
            <element name="privileges-control-list">
                <ref name="privileges-control-list-type"/>
            </element>
            <element name="user">
                <ref name="user-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        USERS ADMISSION POLICY
    -->
    <define name="user-admission-policy-type">
        <choice>
            <value type="string">closedAuthenticated</value>
            <value type="string">openAuthenticated</value>
            <value type="string">anonymous</value>
        </choice>
    </define>
    <!--
        JOIN HANDLING
   codecs-type =
     role-type,
     attribute decision { decision-type },
     element codec { codec-type }*,
     anyElement*
   # CODEC TYPE
    -->
    <define name="join-handling-type">
        <choice>
            <value type="string">block</value>
            <value type="string">allow</value>
            <value type="string">confirm</value>
            <value type="string">IVR</value>
            <value type="string">directed-operator</value>
        </choice>
    </define>

    <!--
        USERLIST
    -->
    <define name="UserList">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="target">
                <ref name="Target"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        TARGET
    -->
    <define name="Target">
        <ref name="role-type"/>
        <attribute name="uri">
            <data type="anyURI"/>
        </attribute>
        <attribute name="method">
            <ref name="method-type"/>
        </attribute>
    </define>
    <!--
        METHOD
   codec-type =
     role-type,
     attribute name { text },
     attribute policy { policy-type }
   # DECISION TYPE
    -->
    <define name="method-type">
        <choice>
            <value type="string">dial-in</value>
            <value type="string">dial-out</value>
            <value type="string">refer</value>
        </choice>
    </define>
    <!--
        PRIVILEGES
   decision-type =
     xsd:string "automatic" | xsd:string "moderator-controlled"
   # POLICY TYPE
   policy-type = xsd:string "allowed" | xsd:string "disallowed"
   # CONTROL LIST TYPE
    -->
    <define name="privileges-control-list-type">
        <ref name="role-type"/>
        <oneOrMore>
            <element name="conference-rules">
                <ref name="conference-rules-type"/>
            </element>
        </oneOrMore>
    </define>
    <!--
        CONFERENCE RULES
   control-type =
     element mute { xsd:boolean }
     | element pause-video { xsd:boolean }
     | element gain {
         xsd:int { minInclusive = "-127" maxInclusive = "127" }
       }
     | element video-layout {
         xsd:string "single-view"
         | xsd:string "dual-view"
         | xsd:string "dual-view-crop"
         | xsd:string "dual-view-2x1"
         | xsd:string "dual-view-2x1-crop"
         | xsd:string "quad-view"
         | xsd:string "multiple-3x3"
         | xsd:string "multiple-4x4"
         | xsd:string "multiple-5x1"
         | xsd:string "automatic"
       }
     | anyElement*
   # HOST TYPE
    -->
    <define name="conference-rules-type">
        <ref name="role-type"/>
        <attribute name="id">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="entry">
                <ref name="conference-rule-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
   host-type =
     role-type,
     (element display-text { text },
      element web-page { xsd:anyURI },
      element uris { uris-type },
      anyElement*)*
   # CONFERENCE RULE STATE TYPE
    -->
    <define name="conference-rule-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="condition">
                <ref name="condition-type"/>
            </element>
            <element name="action">
                <ref name="action-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        CONDITION
   conference-state-type =
     role-type,
     element allow-conference-event-subscription { xsd:boolean }?,
     element user-count { xsd:unsignedInt }?,
     element active { xsd:boolean }?,
     element locked { xsd:boolean }?,
     anyElement*
   # FLOOR INFORMATION TYPE
    -->
    <define name="condition-type">
        <ref name="role-type"/>
        <element name="identity">
            <ref name="identity-type"/>
        </element>
        <element name="validity">
            <ref name="validityType"/>
        </element>
    </define>
    <!--
        IDENTITY
   floor-information-type =
     role-type,
     (element conference-ID { BFCP-type },
      element allow-floor-events { xsd:boolean },
      element floor-request-handling { floor-request-type },
      element conference-floor-policy { Conference-floor-policy },
      anyElement*)*
   # FLOOR REQUEST TYPE
    -->
    <define name="identity-type">
        <ref name="role-type"/>
        <element name="identity">
            <ref name="identityType"/>
        </element>
        <element name="validity">
            <ref name="validityType"/>
        </element>
    </define>

    <!--
        ROLES IDENTITY
   floor-request-type = xsd:string "block" | xsd:string "confirm"
   # CONFERENCE FLOOR POLICY
   Conference-floor-policy =
     role-type,
     element floor {
       attribute moderator-controlled { xsd:boolean },
       attribute label { text },
       anyAttribute,
       (element media-types {
          role-type,
          (xsd:string "video"
           | xsd:string "audio"
           | xsd:string "application"
           | xsd:string "data"
           | xsd:string "control"
           | xsd:string "message"
           | xsd:string "text")
        },
        element algorithm {
          role-type,
          (xsd:string "moderator-controlled"
           | xsd:string "FCFS"
           | xsd:string "random")
        },
        element max-floor-users { xsd:nonNegativeInteger },
        element chair-id { xsd:anyURI },
        anyElement*)*
     }+
   # USERS TYPE
    -->
    <define name="identityType">
        <choice>
            <element name="one">
                <ref name="oneType"/>
            </element>
            <element name="many">
                <ref name="manyType"/>
            </element>
            <element name="pseudonymous">
                <text/>
            </element>
            <element name="has-been-referred">
                <text/>
            </element>
            <element name="has-been-invited">
                <text/>
            </element>
            <element name="has-been-in-conference">
                <text/>
            </element>
            <element name="is-in-conference">
                <text/>
            </element>
            <element name="administrator">
                <text/>
            </element>
            <element name="is-on-allowed-users-list-dial-out">
                <text/>
            </element>
            <element name="is-on-allowed-users-list-refer">
                <text/>
            </element>
            <element name="participant-passcode">
                <text/>
            </element>
            <element name="administrator-passcode">
                <text/>
            </element>
        </choice>
    </define>
    <!--
        ACTION
   users-type =
     attribute state { state-type }?,
     role-type,
     element join-handling { join-handling-type }?,
     element user-admission-policy { user-admission-policy-type }?,
     element user-must-be-specified { xsd:boolean }?,
     element allowed-users-list { UserList }?,
     element user { user-type }*,
     anyElement*
   # USERS ADMISSION POLICY
   user-admission-policy-type =
     xsd:string "closedAuthenticated"
     | xsd:string "openAuthenticated"
     | xsd:string "anonymous"
   # JOIN HANDLING TYPE
   join-handling-type =
     xsd:string "block"
     | xsd:string "allow"
     | xsd:string "confirm"
     | xsd:string "IVR"
     | xsd:string "directed-operator"
   # USERLIST
   UserList =
     role-type,
     element target { target-type }*,
     anyElement*
   # TARGET TYPE
    -->
    <define name="action-type">
        <choice>
            <element name="allow-refer-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-invite-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-remove-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="show-floor-holder">
                <ref name="floor-request-type"/>
            </element>
            <element name="show-floor-request">
                <data type="boolean"/>
            </element>
            <element name="provide-anonymity">
                <data type="boolean"/>
            </element>
            <element name="read-only">
                <ref name="single-role-type"/>
            </element>
            <element name="read-write">
                <ref name="single-role-type"/>
            </element>
        </choice>
    </define>

    <!--
        USER
   target-type =
     role-type,
     attribute uri { xsd:anyURI },
     attribute method { method-type }
   # METHOD TYPE
    -->
    <define name="user-type">
        <ref name="role-type"/>
        <attribute name="state">
            <ref name="state-type"/>
        </attribute>
        <zeroOrMore>
            <element name="user">
                <ref name="one-user-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
        ONE
   method-type =
     xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer"
   # USER TYPE
    -->
    <define name="one-user-type">
        <ref name="role-type"/>
        <attribute name="entity">
            <data type="anyURI"/>
        </attribute>
        <attribute name="state">
            <ref name="state-type"/>
        </attribute>
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="associated-aors">
                <ref name="uris-type"/>
            </element>
            <element name="provide-anonymity">
                <data type="boolean"/>
            </element>
            <element name="roles">
                <ref name="single-role-type"/>
            </element>
            <element name="languages">
                <list>
                    <data type="language"/>
                </list>
            </element>
            <element name="cascaded-focus">
                <data type="anyURI"/>
            </element>
            <element name="sphere">
                <ref name="sphereType"/>
            </element>
            <element name="allow-refer-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-invite-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="allow-remove-users-dynamically">
                <data type="boolean"/>
            </element>
            <element name="endpoint">
                <ref name="endpoint-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
   user-type =
     role-type,
     attribute entity { xsd:anyURI },
     attribute state { state-type }?,
     element display-text { text }?,
     element associated-aors { uris-type }?,
     element provide-anonymity { xsd:boolean }?,
     element roles { roles-type }?,
     element languages {
       list { xsd:language }
     }?,
     element cascaded-focus { xsd:anyURI }?,
     element allow-refer-users-dynamically { xsd:boolean }?,
     element allow-invite-users-dynamically { xsd:boolean }?,
     element allow-remove-users-dynamically { xsd:boolean }?,
     element endpoint { endpoint-type }*,
     anyElement*
   # ENDPOINT TYPE
    -->
    <define name="endpoint-type">
        <ref name="role-type"/>
        <attribute name="entity">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="referred">
                <ref name="execution-type"/>
            </element>
            <element name="status">
                <ref name="endpoint-status-type"/>
            </element>
            <element name="joining-method">
                <ref name="joining-type"/>
            </element>
            <element name="joining-info">
                <ref name="execution-type"/>
            </element>
            <element name="disconnection-method">
                <ref name="disconnection-type"/>
            </element>
            <element name="disconnection-info">
                <ref name="execution-type"/>
            </element>
            <element name="media">
                <ref name="media-type"/>
            </element>
            <element name="call-info">
                <ref name="call-type"/>
            </element>
        </zeroOrMore>
    </define>

    <!--
        MEDIA TYPE
    -->
    <define name="media-type">
        <attribute name="id">
            <text/>
        </attribute>
        <zeroOrMore>
            <element name="display-text">
                <text/>
            </element>
            <element name="type">
                <text/>
            </element>
            <element name="label">
                <text/>
            </element>
            <element name="src-id">
                <text/>
            </element>
            <element name="status">
                <ref name="media-status-type"/>
            </element>
            <element name="to-mixer">
                <ref name="mixer-type"/>
            </element>
            <element name="from-mixer">
                <ref name="mixer-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
   endpoint-type =
     role-type,
     attribute entity { text },
     attribute state { state-type }?,
     element display-text { text }?,
     element referred { conference-info-urn* }?,
     element status { endpoint-status-type }?,
     element joining-method { joining-type }?,
     element joining-info { conference-info-urn* }?,
     element disconnection-method { disconnection-type }?,
     element disconnection-info { conference-info-urn* }?,
     element media { media-type }*,
     element call-info { conference-info-urn* }?,
     anyElement*
   # MEDIA TYPE
   media-type =
     attribute id { xsd:int },
     attribute state { state-type }?,
     anyAttribute,
     element display-text { text }?,
     element type { text }?,
     element label { text }?,
     element src-id { text }?,
     element status { media-status-type }?,
     element to-mixer { mixer-type }?,
     element from-mixer { mixer-type }?,
     anyElement*
   # MIXER TYPE
    -->
    <define name="mixer-type">
        <ref name="role-type"/>
        <optional>
            <element name="floor">
                <data type="boolean"/>
            </element>
            <element name="controls">
                <ref name="control-type"/>
            </element>
        </optional>
    </define>

    <!--
   mixer-type =
     role-type,
     attribute state { state-type }?,
     (element floor { xsd:boolean },
      element controls { controls-type })?,
     anyElement*
   # SIDEBARS-BY-REF TYPE
    -->
    <define name="sidebars-by-ref-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="entry">
                <ref name="uri-type"/>
            </element>
        </zeroOrMore>
    </define>
    <!--
   sidebars-by-ref-type =
     role-type,
     attribute state { state-type }?,
     element entry { uri-type }*,
     anyElement*
   # SIDEBARS-BY-VAL TYPE
    -->
    <define name="sidebars-by-val-type">
        <ref name="role-type"/>
        <zeroOrMore>
            <element name="entry">
                <ref name="conference-type"/>
            </element>
        </zeroOrMore>
    </define>

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

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

    <!--
       MEDIA STATUS TYPE
    -->

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

    <!--
        EXECUTION TYPE
    -->

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

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

    <!--
        SIP DIALOG ID TYPE
    -->

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

    <!--
        DISCONNECTION TYPE
    -->

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

    <!--
        JOINING TYPE
    -->

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

    <!--
       ENDPOINT STATUS TYPE
    -->

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

    <!--
   # *************************************************************

   # WILDCARD FOR EVENT-PACKAGE NAMESPACE
   conference-info-urn =
     element * - ns1:*  {
       mixed {
         (attribute * { text }
          | conference-info-urn)*
       }
     }
   # DEFINITION OF STATE TYPE
    -->

    <define name="state-type">
        <choice>
            <value type="string">full</value>
            <value type="string">partial</value>
            <value type="string">deleted</value>
        </choice>
    </define>
    <!--
        ***********************************************
   state-type = "full" | "partial" | "deleted"
   # DEFINITION OF ENDPOINT STATUS TYPE DEFINED IN THE ROLE DOCUMENT
        ***********************************************
    -->

    <!--
        ROLE
   media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive"
   # ENDPOINT STATUS TYPE
    -->
    <define name="role-type">
        <attribute name="read-only">
            <ref name="single-role-type"/>
        </attribute>

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

    <!--
        SINGLE ROLE
   endpoint-status-type =
     "pending"
     | "dialing-out"
     | "dialing-in"
     | "alerting"
     | "on-hold"
     | "connected"
     | "muted-via-focus"
     | "disconnecting"
     | "disconnected"
   # JOINING TYPE
    -->

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

    <!--
        ************************************************************
   joining-type = "dialed-in" | "dialed-out" | "focus-owner"
   # DISCONNECTION TYPE
   disconnection-type = "departed" | "booted" | "failed" | "busy"
   # ******************************************
   # TYPE DEFINED IN THE COMMON POLICY DOCUMENT
        ************************************************************
    -->

    <!--
       VALIDITY TYPE
    -->

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

    <!--
        ONE TYPE
    -->
    <define name="oneType">
        <attribute name="id">
            <data type="anyURI"/>
        </attribute>
    </define>

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

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

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

</grammar>

5.
   # ******************************************

   # WILDCARD FOR COMMON-POLICY NAMESPACE
   common-policy =
     element * - ns2:*  {
       mixed {
         (attribute * { text }
          | common-policy)*
       }
     }

6.  XML Schema Extensibility

   The Common Conference Information Data Model defined in this document is
   meant to be extensible toward specific application domains.  Such
   an extension is
   extensions are accomplished by defining elements, child elements and
   attributes that are specific to the desired application domain.  Each
   extension MUST define its own namespace.  Points of extension MUST be
   defined in  The
   IETF MAY extend the schema, and SHOULD be done using data model schema with extension elements from
   the <anyName>/
   <except> construct. same namespace, but other instances are free to extend it from
   other than urn:ietf:params:xml:ns:conference-schema.

   Elements or attributes from unknown namespaces MUST be ignored.

6.

7.  XML example Example

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

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

      <conference-description xml:lang="en-us">
        <info:display-text>Discussion
          <display-text>Discussion of Formula-1 racing<
        /info:display-text>
        <info:subject> Sports:Formula-1</info:subject>
        <info:free-text>This racing</display-text>
          <subject> Sports:Formula-1</subject>
          <free-text>This is a conference example</info:free-text>
        <info:keywords>Formula-1, cars</info:keywords>
        <web-page>http://www.example.com/users/alice/formula-1<
        /web-page> example</free-text>
          <keywords>Formula-1, cars</keywords>
          <webpage>http://www.example.com/users/formula-1</webpage>
          <security-level>low</security-level>
          <allow-sidebars>true</allow-sidebars>
          <conference-stage>running</conference-stage>
          <!--
          CONFERENCE TIME
          -->
          <conference-time>
              <entry>
                  <base>BEGIN:VCALENDAR
                      PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
                      VERSION:2.0
                      BEGIN:VEVENT
                      DTSTAMP:20051103T140728Z
                      UID:carol at example.com
                      ORGANIZER:MAILTO:carol at example.com
                      DTSTART:20061017T143000Z
                      RRULE:FREQ=WEEKLY
                      DTEND:20061017T163000Z</base>

                  <mixing-start-offset required-participant="moderator">
          20061017T142900Z</mixing-start-offset> required-participant="moderator"
                      > 2006-10-17T14:29:00Z</mixing-start-offset>
                  <mixing-end-offset required-participant="participant">
           20061017T163100Z</mixing-end-offset>
          <must-join-before-offset>
           20061017T15300Z</must-join-before-offset> required-participant="participant"
                      > 2006-10-17T16:31:00Z</mixing-end-offset>
                  <must-join-before-offset
                      > 2006-10-17T15:30:00Z</must-join-before-offset>
              </entry>
          </conference-time>
          <!--
          CONFERENCE UNIQUE IDENTIFIERS
          -->
        <info:conf-uris>
         <info:SIP>
          <info:uri>tel:+3585671234</info:uri>
          <info:display-text>Conference Bridge</info:display-text>
          <info:purpose>participation</info:purpose>
         </info:SIP>
         <info:SIP>
          <info:uri>http://www.example.com/54634/live.ram</info:uri>
          <info:purpose>streaming</info:purpose>
         </info:SIP>
        </info:conf-uris>
          <conf-uris state="full">
              <SIP>
                  <uri>tel:+3585671234</uri>
                  <display-text>Conference Bridge</display-text>
                  <purpose>participation</purpose>
              </SIP>
              <SIP>
                  <uri>http://www.example.comlive.ram</uri>
                  <purpose>streaming</purpose>
              </SIP>
          </conf-uris>
          <!--
            SERVICE URIS
          -->
        <info:service-uris>
         <info:SIP>
          <info:uri>http://www.example.com/formula1/</info:uri>
          <info:purpose>web-page</info:purpose>
         </info:SIP>
        </info:service-uris>
          <service-uris state="full">
              <SIP>
                  <uri>http://www.example.com/formula1/</uri>
                  <purpose>web-page</purpose>
              </SIP>
          </service-uris>
          <!--
            MAXIMUM USER COUNT
          -->
          <maximum-user-count>
              <entry role = "administrator">2</entry> role="administrator">2</entry>
              <entry role = "moderator">5</entry> role="moderator">5</entry>
              <entry role = "participant">150</entry> role="participant">150</entry>
          </maximum-user-count>
          <!--
            AVAILABLE MEDIA
          -->
        <info:available-media>
         <info:entry
          <available-media>
              <entry label="10234">
          <info:display-text>main audio</info:display-text>
          <info:type>audio</info:type>
          <info:status>sendrecv</info:status>
                  <display-text>main audio</display-text>
                  <type>audio</type>
                  <status>sendrecv</status>
                  <mixing-mode>automatic</mixing-mode>
                  <mix-level>3</mix-level>
                  <codecs decision="automatic">
                      <codec name="PCMU" policy="allowed"/>
                  </codecs>
         </info:entry>
         <info:entry
              </entry>
              <entry label="10235">
          <info:display-text>main video</info:display-text>
          <info:type>video</info:type>
                  <display-text>main video</display-text>
                  <type>video</type>
                  <status>sendrecv</status>
                  <mixing-mode>automatic</mixing-mode>
                  <mix-level>4</mix-level>
          <info:status>sendrecv</info:status>
          <sesspol:codecs
                  <codecs decision="automatic">
           <sesspol:codec
                      <codec name="H.263" policy="allowed"/>
          </sesspol:codecs>
         </info:entry>
        </info:available-media>
       </info:conference-description>
                  </codecs>
              </entry>
          </available-media>
      </conference-description>
      <!--
          HOST INFO
        -->
       <info:host-info>
        <info:display-text>Formula1</info:display-text>
        <info:web-page>http://www.example.com/formula-1/<
        /info:web-page>
        <info:uris>
         <info:SIP>
          <info:uri>sip:alice@example.com</info:uri>
         </info:SIP>
         <info:SIP>
          <info:uri>sip:carol@example.com</info:uri>
         </info:SIP>
        </info:uris>
       </info:host-info>
      <host-info>
          <display-text>Formula1</display-text>
          <web-page>http://www.example.com/formula1/</web-page>
          <uris state="full">
              <SIP>
                  <uri>sip:alice@example.com</uri>
              </SIP>
              <SIP>
                  <uri>sip:carol@example.com</uri>
              </SIP>
          </uris>
      </host-info>
      <!--
          CONFERENCE STATE
        -->
       <info:conference-state>
        <allow-conference-state>true<
        /allow-conference-state>
        <info:user-count>3</info:user-count>
        <info:active>true</info:active>
        <info:locked>false</info:locked>
       </info:conference-state>
      <conference-state>
          <allow-conference-state>true</allow-conference-state>
          <user-count>3</user-count>
          <active>true</active>
          <locked>false</locked>
      </conference-state>
      <!--
          FLOOR INFORMATION
        -->
      <floor-information>
          <allow-floor-events>true</allow-floor-events>
      <floor-request-handling>1 </floor-request-handling>
          <floor-request-handling>confirm</floor-request-handling>
          <conference-floor-policy>
              <floor moderator-controlled="true" label="10234">
                  <media-types>audio</media-types>
        <algorithm>Moderator-controlled</algorithm>
                  <algorithm>moderator-controlled</algorithm>
                  <max-floor-users>1</max-floor-users>
        <moderator-uri>sip:alice@example.com<
       /moderator-uri>
                  <moderator-uri>sip:alice@example.com</moderator-uri>
              </floor>
              <floor moderator-controlled="true" label="10235">
                  <media-types>video</media-types>
        <algorithm>Moderator-controlled</algorithm>
                  <algorithm>moderator-controlled</algorithm>
                  <max-floor-users>1</max-floor-users>
        <moderator-uri>sip:carol@example.com<
        /moderator-uri>
                  <moderator-uri>sip:carol@example.com</moderator-uri>
              </floor>
          </conference-floor-policy>
      </floor-information>
      <!--
          USERS
        -->
       <users>
      <users state="full">
          <join-handling>allow</join-handling>
          <!--
           ALLOWED USERS LIST
          -->
          <allowed-users-list>
              <target uri="sip:bob@example.com" method="dial-out"/>
              <target uri="sip:alice@example.com" method="dial-out"/>
              <target uri="sip:carol@example.com" method="dial-out"/>
              <target uri="sip:john@example.com" method="refer"/>
          </allowed-users-list>
          <!--
            PRIVILEGES CONTROL LIST
          -->
          <privileges-control-list>
              <conference-rules>
                  <entry id="1">
           <conditions>
            <compol:identity>
             <compol:domain>example.com</compol:domain>
            </compol:identity>
            <compol:validity>
             <compol:from>20061017T143000Z</compol:from>
             <compol:to>20061017T163000Z</compol:to>
            </compol:validity>
           </conditions>
           <compol:actions>
            <compol:allow-conference-state>true<
            /compol:allow-conference-state>
           </compol:actions>
                      <condition>
                          <identity>
                              <many domain="example.com"/>
                          </identity>
                          <validity>
                              <to>2006-10-17T16:30:00Z</to>
                              <from>2006-10-17T14:30:00Z</from>
                          </validity>
                      </condition>
                      <action>
                          <allow-invite-users-dynamically
                              >true</allow-invite-users-dynamically>
                      </action>
                  </entry>
                  <entry id="2">
           <conditions>
            <compol:identity>
             <compol:uri>bob@example.com</compol:uri>
            </compol:identity>
           </conditions>
           <compol:actions>
            <join-handling>block</join-handling>
           </compol:actions>
                      <condition>
                          <identity>
                              <one id="bob@example.com"/>
                          </identity>
                      </condition>
                      <action>
                          <show-floor-holder>block</show-floor-holder>
                      </action>
                  </entry>
              </conference-rules>
          </privileges-control-list>
          <!--
            USER
          -->
        <info:user entity="sip:bob@example.com">
         <info:display-text>Bob
          <user entity="bob534" state="partial">
              <display-text>Bob Hoskins</display-text>
         <info:associated-aors>
          <info:entry>
           <info:uri>mailto:bob@example.com</info:uri>
           <info:display-text>email</info:display-text>
          </info:entry>
         </info:associated-aors>
              <associated-aors state="full">
                  <SIP>
                      <uri>mailto:bob@example.com</uri>
                      <display-text>email</display-text>
                  </SIP>
              </associated-aors>
              <provide-anonymity>false</provide-anonymity>
         <info:roles>
          <info:entry>participant</info:entry>
         </info:roles>
         <info:languages>en</info:languages>
              <roles>
                  <entry>participant</entry>
              </roles>
              <languages>en</languages>
              <sphere value="work"/>
         <allow-refer-users-dynamically>false<
         /allow-refer-users-dynamically>
         <allow-invite-users-dynamically>false<
         /allow-invite-users-dynamically>
         <allow-remove-users-dynamically>false<
         /allow-remove-users-dynamically>
              <allow-refer-users-dynamically
                  >false</allow-refer-users-dynamically>
              <allow-invite-users-dynamically
                  >false</allow-invite-users-dynamically>
              <allow-remove-users-dynamically
                  >false</allow-remove-users-dynamically>
              <!--
                  ENDPOINTS
              -->
         <info:endpoint entity="sip:bob@example.com">
          <info:display-text>Bob's Laptop</info:display-text>
          <info:referred>
           <info:when>20061017T140000Z</info:when>
           <info:reason>expert required</info:reason>
           <info:by>sip:alice@example.com</info:by>
          </info:referred>
          <info:status>connected</info:status>
          <info:joining-method>dialed-out</info:joining-method>
          <info:joining-info>
           <info:when>20061017T140000Z</info:when>
           <info:reason>invitation</info:reason>
           <info:by>sip:alice@example.com</info:by>
          </info:joining-info>
              <endpoint entity="sip:bob@example.com" state="full">
                  <display-text>Bob's Laptop</display-text>
                  <referred>
                      <when>2006-10-17T14:00:00Z</when>
                      <reason>expert required</reason>
                      <by>sip:alice@example.com</by>
                  </referred>
                  <status>connected</status>
                  <joining-method>dialed-out</joining-method>
                  <joining-info>
                      <when>2006-10-17T14:00:00Z</when>
                      <reason>invitation</reason>
                      <by>sip:alice@example.com</by>
                  </joining-info>

                  <!--
                      MEDIA
                  -->
          <info:media
                  <media id="1">
           <info:label>10235</info:label>
           <info:src-id>432424</info:src-id>
          </info:media>
                      <label>10235</label>
                      <src-id>432424</src-id>
                  </media>
                  <!--
                      CALL INFO
                  -->
          <info:call-info>
           <info:sip>
            <info:display-text>full info</info:display-text>
            <info:call-id>hsjh8980vhsb78</info:call-id>
            <info:from-tag>vav738dvbs</info:from-tag>
            <info:to-tag>8954jgjg8432</info:to-tag>
           </info:sip>
          </info:call-info>
         </info:endpoint>
        </info:user>
                  <call-info>
                      <sip>
                          <display-text>full info</display-text>
                          <call-id>hsjh8980vhsb78</call-id>
                          <from-tag>vav738dvbs</from-tag>
                          <to-tag>8954jgjg8432</to-tag>
                      </sip>
                  </call-info>
              </endpoint>
          </user>

          <!--
              USER
          -->
        <info:user entity="sip:alice@example.com">
         <info:display-text>Alice Kay</info:display-text>
         <info:associated-aors>
          <info:entry>
           <info:uri>mailto:alice@example.com</info:uri>
           <info:display-text>email</info:display-text>
          </info:entry>
         </info:associated-aors>

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

          <!--
                  -->
          <user entity="carol233" state="full">
              <display-text>Carol More</display-text>
              <associated-aors state="full">
                  <SIP>
                      <uri>mailto:carol@example.com</uri>
                      <display-text>email</display-text>
                  </SIP>
              </associated-aors>
              <provide-anonymity>false</provide-anonymity>
         <info:roles>
          </info:entry>administrator</info:entry>
         </info:roles>
         <info:languages>en</info:languages>
              <roles>
                  <entry>administrator</entry>
              </roles>
              <languages>en</languages>
              <sphere value="work"/>
         <allow-refer-users-dynamically>true<
         /allow-refer-users-dynamically>
         <allow-invite-users-dynamically>true<
         /allow-invite-users-dynamically>
         <allow-remove-users-dynamically>true<
         /allow-remove-users-dynamically>
              <allow-refer-users-dynamically
                  >true</allow-refer-users-dynamically>
              <allow-invite-users-dynamically
                  >true</allow-invite-users-dynamically>
              <allow-remove-users-dynamically
                  >true</allow-remove-users-dynamically>
              <!--
                  ENDPOINTS
              -->
         <info:endpoint entity="sip:carol@example.com">
          <info:display-text>Carol's Computer</info:display-text>
          <info:status>connected</info:status>
          <info:joining-method>dialed-in</info:joining-method>
          <info:joining-info>
           <info:when>20061017T133005Z</info:when>
           <info:reason>invitation</info:reason>
           <info:by>sip:conference@example.com</info:by>
          </info:joining-info>
              <endpoint entity="sip:carol@example.com" state="full">
                  <display-text>Carol's Computer</display-text>
                  <status>connected</status>
                  <joining-method>dialed-in</joining-method>
                  <joining-info>
                      <when>2006-10-17T13:30:05Z</when>
                      <reason>invitation</reason>
                      <by>sip:conference@example.com</by>
                  </joining-info>
                  <!--
                      MEDIA
                  -->
          <info:media
                  <media id="1">
           <info:label>10235</info:label>
           <info:src-id>432424</info:src-id>
           <info:status>sendrecv</info:status>
          </info:media>
          <info:media
                      <label>10235</label>
                      <src-id>432424</src-id>
                      <status>sendrecv</status>
                  </media>
                  <media id="2">
           <info:label>10234</info:label>
           <info:src-id>532535</info:src-id>
           <info:status>sendrecv</info:status>
          </info:media>
                      <label>10234</label>
                      <src-id>532535</src-id>
                      <status>sendrecv</status>
                  </media>
                  <!--
                      CALL INFO
                  -->
          <info:call-info>
           <info:sip>
            <info:display-text>full info</info:display-text>
            <info:call-id>wevb12562321894</info:call-id>
            <info:from-tag>asw456wedf</info:from-tag>
            <info:to-tag>2365dfrt3497</info:to-tag>
           </info:sip>
          </info:call-info>
         </info:endpoint>
        </info:user>
                  <call-info>
                      <sip>
                          <display-text>full info</display-text>
                          <call-id>wevb12562321894</call-id>
                          <from-tag>asw456wedf</from-tag>
                          <to-tag>2365dfrt3497</to-tag>
                      </sip>
                  </call-info>
              </endpoint>
          </user>
      </users>
      <!--
           SIDEBARS BY REFERENCE
         -->
       <info:sidebars-by-ref>
        <info:entry>
         <info:uri>sips:conference@example.com;grid=40</info:uri>
         <info:display-text>private with Bob</info:display-text>
        </info:entry>
       </info:sidebars-by-ref>
      <sidebars-by-ref state="full">
          <entry>
              <uri>sips:conference123;grid=40</uri>
              <display-text>private with Bob</display-text>
          </entry>
      </sidebars-by-ref>
      <!--
           SIDEBARS BY VALUE
         -->
       <info:sidebars-by-val>
        <info:entry entity="sips:conference@example.com;grid=40">
         <info:users>
          <info:user entity="sip:bob@example.com"/>
          <info:user entity="sip:carol@example.com"/>
         </info:users>
        </info:entry>
       </info:sidebars-by-val>
      </info:conference-info>
      <sidebars-by-val>
          <entry entity="conference123;grid=40">
              <users>
                  <user entity="bob534"/>
                  <user entity="carol233"/>
              </users>
          </entry>
      </sidebars-by-val>
  </conference-info>

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

7.

8.  Security Considerations

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

8.

9.  IANA Considerations

9.

9.1.  Conference Relax NG Schema Registration

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

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

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

        and its last line is

     }

9.2.  Conference Namespace Registration

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

10.  Acknowledgements

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

10.

11.  References

10.1.

11.1.  Normative References

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

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

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

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

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

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

10.2.

11.2.  Informative References

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

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

   [9]  Camarillo, G.,

   [8]  Roach, A., "Session Description Protocol (SDP) Format for
        Binary Floor Control Initiation Protocol  (BFCP) Streams",
        draft-ietf-mmusic-sdp-bfcp-03 (work (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

Appendix A.  Appendix A.  Non-Normative RELAX NG Schema in progress), December 2005. XML Syntax

   <?xml version="1.0" encoding="UTF-8"?>
   <grammar ns="urn:ietf:params:xml:ns:conference-schema"
    xmlns="http://relaxng.org/ns/structure/1.0"
    xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
    datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
    <start>
     <element name="conference-info">
      <ref name="conference-type"/>
     </element>
    </start>
    <!--
           CONFERENCE TYPE
       -->
    <define name="conference-type">
     <attribute name="entity">
      <text/>
     </attribute>
     <optional>
      <attribute name="version">
       <data type="unsignedInt"/>
      </attribute>
     </optional>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <ref name="role-type"/>
     <ref name="conference-description-type"/>
     <optional>
      <element name="host-info">
       <ref name="host-type"/>
      </element>
     </optional>
     <optional>
      <element name="conference-state">
       <ref name="conference-state-type"/>
      </element>
     </optional>
     <optional>
      <element name="floor-information">
       <ref name="floor-information-type"/>
      </element>
     </optional>
     <element name="users">
      <ref name="users-type"/>
     </element>
     <optional>
      <element name="sidebars-by-ref">
       <ref name="sidebars-by-ref-type"/>
      </element>
     </optional>
     <optional>
      <element name="sidebars-by-val">
       <ref name="sidebars-by-val-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CONFERENCE DESCRIPTION TYPE
       -->
    <define name="conference-description-type">
     <element name="conference-description">
      <ref name="role-type"/>
      <optional>
       <attribute name="xml:lang">
        <data type="language"/>
       </attribute>
      </optional>
      <optional>
       <attribute name="state">
        <ref name="state-type"/>
       </attribute>
      </optional>
      <optional>
       <element name="display-text">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="subject">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="free-text">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="keywords">
        <list>
         <zeroOrMore>
          <data type="string"/>
         </zeroOrMore>
        </list>
       </element>
      </optional>
      <optional>
       <element name="allow-sidebars">
        <data type="boolean"/>
       </element>
      </optional>
      <optional>
       <element name="conference-time">
        <ref name="conferencetime-type"/>
       </element>
      </optional>
      <optional>
       <element name="conf-uris">
        <ref name="uris-type"/>
       </element>
      </optional>
      <optional>
       <element name="service-uris">
        <ref name="uris-type"/>
       </element>
      </optional>
      <optional>
       <element name="maximum-user-count">
        <data type="int"/>
       </element>
      </optional>
      <optional>
       <element name="available-media">
        <ref name="conference-media-type"/>
       </element>
      </optional>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </element>
    </define>
    <!--
           CONFERENCE TIME
       -->
    <define name="conferencetime-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="entry">
       <optional>
        <element name="base">
         <text/>
        </element>
       </optional>
       <optional>
        <element name="mixing-start-offset">
         <data type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
         <attribute name="required-participant">
          <ref name="single-role-type"/>
         </attribute>
         <ref name="anyAttribute"/>
        </element>
       </optional>
       <optional>
        <element name="mixing-end-offset">
         <data type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
         <attribute name="required-participant">
          <ref name="single-role-type"/>
         </attribute>
         <ref name="anyAttribute"/>
        </element>
       </optional>
       <optional>
        <element name="can-join-after-offset">
         <data type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
        </element>
       </optional>
       <optional>
        <element name="must-join-before-offset">
         <data type="dateTime">
          <param name="pattern">.+T.+Z.*</param>
         </data>
        </element>
       </optional>
       <optional>
        <element name="notify-end-of-conference">
         <data type="int"/>
        </element>
       </optional>
       <optional>
        <element name="allowed-extend-mixing-end-offset">
         <ref name="allowed-extend-mixing-values"/>
        </element>
       </optional>
       <zeroOrMore>
        <ref name="anyElement"/>
       </zeroOrMore>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ALLOWED EXTEND MIXING VALUES
       -->
    <define name="allowed-extend-mixing-values">
     <choice>
      <value type="string">allowed</value>
      <value type="string">denied</value>
     </choice>
    </define>
    <!--
           URIS TYPE
       -->
    <define name="uris-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <interleave>
      <zeroOrMore>
       <element name="entry">
        <ref name="uri-type"/>
       </element>
      </zeroOrMore>
      <zeroOrMore>
       <element name="H323">
        <ref name="H323-type"/>
       </element>
      </zeroOrMore>
      <zeroOrMore>
       <element name="PSTN-ISDN">
        <ref name="PSTN-type"/>
       </element>
      </zeroOrMore>
     </interleave>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           SIP TYPE
       -->
    <define name="uri-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="uri">
       <data type="anyURI"/>
      </element>
      <optional>
       <element name="display-text">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="purpose">
        <text/>
       </element>
      </optional>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           H323 TYPE
      -->
    <define name="H323-type">
     <ref name="role-type"/>
     <optional>
      <element name="H.323-alias">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="H.323-URI">
       <data type="anyURI"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           PSTN TYPE
       -->
    <define name="PSTN-type">
     <ref name="role-type"/>
     <attribute name="PIN-code">
      <data type="unsignedInt"/>
     </attribute>
     <attribute name="purpose">
      <data type="unsignedInt"/>
     </attribute>
     <oneOrMore>
      <element name="phone-number">
       <data type="unsignedInt"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </oneOrMore>
    </define>
    <!--
           BFCP TYPE
       -->
    <define name="BFCP-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="conference-ID">
       <data type="unsignedInt"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           MAXIMUM USER TYPE
       -->
    <define name="maximum-user-count-type">
     <ref name="role-type"/>
     <ref name="anyAttribute"/>
     <oneOrMore>
      <element name="entry">
       <data type="unsignedInt"/>
       <attribute name="role">
        <ref name="single-role-type"/>
       </attribute>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </oneOrMore>
    </define>
    <!--
           CONFERENCE MEDIA TYPE
       -->
    <define name="conference-media-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="entry">
       <ref name="conference-medium-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CONFERENCE MEDIUM TYPE
       -->
    <define name="conference-medium-type">
     <ref name="role-type"/>
     <attribute name="label">
      <text/>
     </attribute>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="type">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="status">
       <ref name="media-status-type"/>
      </element>
     </optional>
     <optional>
      <element name="mixing-mode">
       <ref name="mix-mode-type"/>
      </element>
     </optional>
     <optional>
      <element name="mix-level">
       <data type="unsignedInt"/>
      </element>
     </optional>
     <optional>
      <element name="codecs">
       <ref name="codecs-type"/>
      </element>
     </optional>
     <optional>
      <element name="controls">
       <ref name="controls-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CONTROLS TYPE
       -->
    <define name="controls-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="control">
       <ref name="control-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           MIX MODE TYPE
       -->
    <define name="mix-mode-type">
     <choice>
      <value type="string">moderator-controlled</value>
      <value type="string">FCFS</value>
      <value type="string">automatic</value>
     </choice>
    </define>
    <!--
           CODECS TYPE
       -->
    <define name="codecs-type">
     <ref name="role-type"/>
     <attribute name="decision">
      <ref name="decision-type"/>
     </attribute>
     <zeroOrMore>
      <element name="codec">
       <ref name="codec-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           CODEC TYPE
       -->
    <define name="codec-type">
     <ref name="role-type"/>
     <attribute name="name">
      <text/>
     </attribute>
     <attribute name="policy">
      <ref name="policy-type"/>
     </attribute>
    </define>
    <!--
           DECISION TYPE
       -->
    <define name="decision-type">
     <choice>
      <value type="string">automatic</value>
      <value type="string">moderator-controlled</value>
     </choice>
    </define>
    <!--
           POLICY TYPE
       -->
    <define name="policy-type">
     <choice>
      <value type="string">allowed</value>
      <value type="string">disallowed</value>
     </choice>
    </define>
    <!--
           CONTROL TYPE
       -->
    <define name="control-type">
     <choice>
      <element name="mute">
       <data type="boolean"/>
      </element>
      <element name="pause-video">
       <data type="boolean"/>
      </element>
      <element name="gain">
       <data type="int">
        <param name="minInclusive">-127</param>
        <param name="maxInclusive">127</param>
       </data>
      </element>
      <element name="video-layout">
       <choice>
        <value type="string">single-view</value>
        <value type="string">dual-view</value>
        <value type="string">dual-view-crop</value>
        <value type="string">dual-view-2x1</value>
        <value type="string">dual-view-2x1-crop</value>
        <value type="string">quad-view</value>
        <value type="string">multiple-3x3</value>
        <value type="string">multiple-4x4</value>
        <value type="string">multiple-5x1</value>
        <value type="string">automatic</value>
       </choice>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </choice>
    </define>
    <!--
           HOST TYPE
       -->
    <define name="host-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="display-text">
       <text/>
      </element>
      <element name="web-page">
       <data type="anyURI"/>
      </element>
      <element name="uris">
       <ref name="uris-type"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           CONFERENCE STATE TYPE
       -->
    <define name="conference-state-type">
     <ref name="role-type"/>
     <optional>
      <element name="allow-conference-event-subscription">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="user-count">
       <data type="unsignedInt"/>
      </element>
     </optional>
     <optional>
      <element name="active">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="locked">
       <data type="boolean"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           FLOOR INFORMATION TYPE
       -->
    <define name="floor-information-type">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="conference-ID">
       <ref name="BFCP-type"/>
      </element>
      <element name="allow-floor-events">
       <data type="boolean"/>
      </element>
      <element name="floor-request-handling">
       <ref name="floor-request-type"/>
      </element>
      <element name="conference-floor-policy">
       <ref name="Conference-floor-policy"/>
      </element>
      <zeroOrMore>
       <ref name="anyElement"/>
      </zeroOrMore>
     </zeroOrMore>
    </define>
    <!--
           FLOOR REQUEST TYPE
       -->
    <define name="floor-request-type">
     <choice>
      <value type="string">block</value>
      <value type="string">confirm</value>
     </choice>
    </define>
    <!--
           CONFERENCE FLOOR POLICY
       -->
    <define name="Conference-floor-policy">
     <ref name="role-type"/>
     <oneOrMore>
      <element name="floor">
       <attribute name="moderator-controlled">
        <data type="boolean"/>
       </attribute>
       <attribute name="label">
        <text/>
       </attribute>
       <ref name="anyAttribute"/>
       <zeroOrMore>
        <element name="media-types">
         <ref name="role-type"/>
         <choice>
          <value type="string">video</value>
          <value type="string">audio</value>
          <value type="string">application</value>
          <value type="string">data</value>
          <value type="string">control</value>
          <value type="string">message</value>
          <value type="string">text</value>
         </choice>
        </element>
        <element name="algorithm">
         <ref name="role-type"/>
         <choice>
          <value type="string">moderator-controlled</value>
          <value type="string">FCFS</value>
          <value type="string">random</value>
         </choice>
        </element>
        <element name="max-floor-users">
         <data type="nonNegativeInteger"/>
        </element>
        <element name="chair-id">
         <data type="anyURI"/>
        </element>
        <zeroOrMore>
         <ref name="anyElement"/>
        </zeroOrMore>
       </zeroOrMore>
      </element>
     </oneOrMore>
    </define>
    <!--
           USERS TYPE
       -->
    <define name="users-type">
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <ref name="role-type"/>
     <optional>
      <element name="join-handling">
       <ref name="join-handling-type"/>
      </element>
     </optional>
     <optional>
      <element name="user-admission-policy">
       <ref name="user-admission-policy-type"/>
      </element>
     </optional>
     <optional>
      <element name="user-must-be-specified">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="allowed-users-list">
       <ref name="UserList"/>
      </element>
     </optional>
     <zeroOrMore>
      <element name="user">
       <ref name="user-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           USERS ADMISSION POLICY
       -->
    <define name="user-admission-policy-type">
     <choice>
      <value type="string">closedAuthenticated</value>
      <value type="string">openAuthenticated</value>
      <value type="string">anonymous</value>
     </choice>
    </define>
    <!--
           JOIN HANDLING TYPE
       -->
    <define name="join-handling-type">
     <choice>
      <value type="string">block</value>
      <value type="string">allow</value>
      <value type="string">confirm</value>
      <value type="string">IVR</value>
      <value type="string">directed-operator</value>
     </choice>
    </define>
    <!--
           USERLIST
       -->
    <define name="UserList">
     <ref name="role-type"/>
     <zeroOrMore>
      <element name="target">
       <ref name="target-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           TARGET TYPE
       -->
    <define name="target-type">
     <ref name="role-type"/>
     <attribute name="uri">
      <data type="anyURI"/>
     </attribute>
     <attribute name="method">
      <ref name="method-type"/>
     </attribute>
    </define>
    <!--
           METHOD TYPE
       -->
    <define name="method-type">
     <choice>
      <value type="string">dial-in</value>
      <value type="string">dial-out</value>
      <value type="string">refer</value>
     </choice>
    </define>
    <!--
           USER TYPE
       -->
    <define name="user-type">
     <ref name="role-type"/>
     <attribute name="entity">
      <data type="anyURI"/>
     </attribute>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="associated-aors">
       <ref name="uris-type"/>
      </element>
     </optional>
     <optional>
      <element name="provide-anonymity">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="roles">
       <ref name="roles-type"/>
      </element>
     </optional>
     <optional>
      <element name="languages">
       <list>
        <data type="language"/>
       </list>
      </element>
     </optional>
     <optional>
      <element name="cascaded-focus">
       <data type="anyURI"/>
      </element>
     </optional>
     <optional>
      <element name="allow-refer-users-dynamically">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="allow-invite-users-dynamically">
       <data type="boolean"/>
      </element>
     </optional>
     <optional>
      <element name="allow-remove-users-dynamically">
       <data type="boolean"/>
      </element>
     </optional>
     <zeroOrMore>
      <element name="endpoint">
       <ref name="endpoint-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ENDPOINT TYPE
       -->
    <define name="endpoint-type">
     <ref name="role-type"/>
     <attribute name="entity">
      <text/>
     </attribute>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="referred">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <optional>
      <element name="status">
       <ref name="endpoint-status-type"/>
      </element>
     </optional>
     <optional>
      <element name="joining-method">
       <ref name="joining-type"/>
      </element>
     </optional>
     <optional>
      <element name="joining-info">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <optional>
      <element name="disconnection-method">
       <ref name="disconnection-type"/>
      </element>
     </optional>
     <optional>
      <element name="disconnection-info">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <zeroOrMore>
      <element name="media">
       <ref name="media-type"/>
      </element>
     </zeroOrMore>
     <optional>
      <element name="call-info">
       <zeroOrMore>
        <ref name="conference-info-urn"/>
       </zeroOrMore>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           MEDIA TYPE
       -->
    <define name="media-type">
     <attribute name="id">
      <data type="int"/>
     </attribute>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <ref name="anyAttribute"/>
     <optional>
      <element name="display-text">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="type">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="label">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="src-id">
       <text/>
      </element>
     </optional>
     <optional>
      <element name="status">
       <ref name="media-status-type"/>
      </element>
     </optional>
     <optional>
      <element name="to-mixer">
       <ref name="mixer-type"/>
      </element>
     </optional>
     <optional>
      <element name="from-mixer">
       <ref name="mixer-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           MIXER TYPE
       -->
    <define name="mixer-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <optional>
      <element name="floor">
       <data type="boolean"/>
      </element>
      <element name="controls">
       <ref name="controls-type"/>
      </element>
     </optional>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           SIDEBARS-BY-REF TYPE
       -->
    <define name="sidebars-by-ref-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="entry">
       <ref name="uri-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           SIDEBARS-BY-VAL TYPE
       -->
    <define name="sidebars-by-val-type">
     <ref name="role-type"/>
     <optional>
      <attribute name="state">
       <ref name="state-type"/>
      </attribute>
     </optional>
     <zeroOrMore>
      <element name="entry">
       <ref name="conference-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ROLES_TYPE
       -->
    <define name="roles-type">
     <zeroOrMore>
      <element name="entry">
       <ref name="single-role-type"/>
      </element>
     </zeroOrMore>
     <zeroOrMore>
      <ref name="anyElement"/>
     </zeroOrMore>
    </define>
    <!--
           ROLE TYPE
       -->
    <define name="role-type">
     <optional>
      <attribute name="read-only">
       <ref name="single-role-type"/>
      </attribute>
     </optional>
     <optional>
      <attribute name="write-only">
       <ref name="single-role-type"/>
      </attribute>
     </optional>
     <ref name="anyAttribute"/>
    </define>
    <!--
           SINGLE ROLE TYPE
       -->
    <define name="single-role-type">
     <choice>
      <value type="string">administrator</value>
      <value type="string">creator</value>
      <value type="string">moderator</value>
      <value type="string">participant</value>
      <value type="string">observer</value>
     </choice>
    </define>
    <!--
           *********************************
           EXTENSIBILITY OF THE SCHEMA
           *********************************
       -->
    <!--
           EXTENSIBILITY ELEMENTS
       -->
    <define name="anyElement">
     <element>
      <anyName/>
      <zeroOrMore>
       <choice>
        <attribute>
         <anyName/>
        </attribute>
        <text/>
        <ref name="anyElement"/>
       </choice>
      </zeroOrMore>
     </element>
    </define>
    <!--
           EXTENSIBILITY ATTRIBUTES
       -->
    <define name="anyAttribute">
     <zeroOrMore>
      <attribute>
       <anyName>
        <except>
         <name ns="">entity</name>
         <name ns="">version</name>
         <name ns="">state</name>
         <name ns="">xml:lang</name>
         <name ns="">required-participant</name>
         <name ns="">PIN-code</name>
         <name ns="">purpose</name>
         <name ns="">role</name>
         <name ns="">type</name>
         <name ns="">min</name>
         <name ns="">max</name>
         <name ns="">label</name>
         <name ns="">decision</name>
         <name ns="">name</name>
         <name ns="">policy</name>
         <name ns="">moderator-controlled</name>
         <name ns="">uri</name>
         <name ns="">method</name>
         <name ns="">id</name>
         <name ns="">domain</name>
         <name ns="">read-only</name>
         <name ns="">write-only</name>
         <nsName ns=""/>
         <nsName ns="urn:ietf:params:xml:ns:conference-schema"/>
        </except>
       </anyName>
       <text/>
      </attribute>
     </zeroOrMore>
    </define>
    <!--
           *************************************************************
           TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
           *************************************************************
       -->
    <!--
           WILDCARD FOR EVENT-PACKAGE NAMESPACE
       -->
    <define name="conference-info-urn">
     <element>
      <anyName>
       <except>
        <nsName ns="urn:ietf:params:xml:ns:conference-info-urn"/>
        <nsName ns=""/>
       </except>
      </anyName>
      <mixed>
       <zeroOrMore>
        <choice>
         <attribute>
          <anyName/>
         </attribute>
         <ref name="conference-info-urn"/>
        </choice>
       </zeroOrMore>
      </mixed>
     </element>
    </define>
    <!--
           DEFINITION OF STATE TYPE
       -->
    <define name="state-type">
     <choice>
      <value>full</value>
      <value>partial</value>
      <value>deleted</value>
     </choice>
    </define>
    <!--
           DEFINITION OF ENDPOINT STATUS TYPE
       -->
    <define name="media-status-type">
     <choice>
      <value>recvonly</value>
      <value>sendonly</value>
      <value>sendrecv</value>
      <value>inactive</value>
     </choice>
    </define>
    <!--
           ENDPOINT STATUS TYPE
       -->
    <define name="endpoint-status-type">
     <choice>
      <value>pending</value>
      <value>dialing-out</value>
      <value>dialing-in</value>
      <value>alerting</value>
      <value>on-hold</value>
      <value>connected</value>
      <value>muted-via-focus</value>
      <value>disconnecting</value>
      <value>disconnected</value>
     </choice>
    </define>
    <!--
           JOINING TYPE
       -->
    <define name="joining-type">
     <choice>
      <value>dialed-in</value>
      <value>dialed-out</value>
      <value>focus-owner</value>
     </choice>
    </define>
    <!--
           DISCONNECTION TYPE
       -->
    <define name="disconnection-type">
     <choice>
      <value>departed</value>
      <value>booted</value>
      <value>failed</value>
      <value>busy</value>
     </choice>
    </define>
    <!--
           ******************************************
           TYPE DEFINED IN THE COMMON POLICY DOCUMENT
           ******************************************
       -->
    <!--
           WILDCARD FOR COMMON-POLICY NAMESPACE
       -->
    <define name="common-policy">
     <element>
      <anyName>
       <except>
        <nsName ns="urn:ietf:params:xml:ns:common-policy"/>
        <nsName ns=""/>
       </except>
      </anyName>
      <mixed>
       <zeroOrMore>
        <choice>
         <attribute>
          <anyName/>
         </attribute>
         <ref name="common-policy"/>
        </choice>
       </zeroOrMore>
      </mixed>
     </element>
    </define>
   </grammar>

Authors' Addresses

   Oscar Novo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Oscar.Novo@ericsson.com

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com

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

   Email: Dave.Morgan@fmr.com
   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   Email: roni.even@polycom.co.il

Full Copyright Statement

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

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

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