XCON O. Novo
Internet-Draft G. Camarillo
Expires: January 11, 2007 Ericsson
D. Morgan
Fidelity Investments
R. Even
Polycom
July 10, 2006
A Common Conference Information Data Model for Centralized Conferencing
(XCON)
draft-ietf-xcon-common-data-model-02.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 January 11, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
Novo, et al. Expires January 11, 2007 [Page 1]
Internet-Draft Common Conference Schema July 2006
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 conference information in a conferencing server. The
information is modeled as a series of elements, each of which
contains a set of children and attributes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Common Conference Data . . . . . . . . . . . . . . . . . . . . 4
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. <conference-description> . . . . . . . . . . . . . . . . . 11
3.2.1. <conference-time> . . . . . . . . . . . . . . . . . . 12
3.2.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 13
3.2.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 13
3.2.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 13
3.2.5. <maximum-streams> . . . . . . . . . . . . . . . . . . 14
3.2.6. <available-media> . . . . . . . . . . . . . . . . . . 14
3.2.7. <controls> . . . . . . . . . . . . . . . . . . . . . . 14
3.2.7.1. mute . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7.2. pause-video . . . . . . . . . . . . . . . . . . . 15
3.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 16
3.5. <security-mechanism> . . . . . . . . . . . . . . . . . . . 16
3.5.1. <methods> . . . . . . . . . . . . . . . . . . . . . . 17
3.5.2. <option-tags> . . . . . . . . . . . . . . . . . . . . 17
3.5.3. <feature-tags> . . . . . . . . . . . . . . . . . . . . 17
3.5.4. <bodies> . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. <floor-information> . . . . . . . . . . . . . . . . . . . 18
3.7. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7.1. <allowed-users-list> . . . . . . . . . . . . . . . . . 20
3.7.2. <privileges-control-list> . . . . . . . . . . . . . . 20
3.7.2.1. <data-access-rights> . . . . . . . . . . . . . . . 20
3.7.2.2. <conference-rules> . . . . . . . . . . . . . . . . 21
3.7.2.2.1. <condition> . . . . . . . . . . . . . . . . . 21
3.7.2.2.1.1. <external-list> . . . . . . . . . . . . . 22
3.7.2.2.1.2. <pseudonymous> . . . . . . . . . . . . . . 22
3.7.2.2.1.3. <has-been-referred> . . . . . . . . . . . 22
3.7.2.2.1.4. <has-been-invited> . . . . . . . . . . . . 22
3.7.2.2.1.5. <has-been-in-conference> . . . . . . . . . 22
3.7.2.2.1.6. <is-in-conference> . . . . . . . . . . . . 22
3.7.2.2.1.7. <administrator> . . . . . . . . . . . . . 23
3.7.2.2.1.8. <is-on-allowed-users-list-dial-out> . . . 23
3.7.2.2.1.9. <is-on-allowed-users-list-refer> . . . . . 23
3.7.2.2.1.10. <participant-passcode> . . . . . . . . . . 23
Novo, et al. Expires January 11, 2007 [Page 2]
Internet-Draft Common Conference Schema July 2006
3.7.2.2.1.11. <administrators-passcode> . . . . . . . . 24
3.7.2.2.2. <actions> . . . . . . . . . . . . . . . . . . 24
3.7.3. <user> . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7.3.1. from_mixer, to_mixer . . . . . . . . . . . . . . . 26
3.7.3.1.1. <floor> . . . . . . . . . . . . . . . . . . . 27
3.7.3.1.2. <gain> . . . . . . . . . . . . . . . . . . . . 27
3.8. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 28
3.9. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 28
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 42
6. XML example . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 53
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Normative References . . . . . . . . . . . . . . . . . . . 53
10.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 56
Novo, et al. Expires January 11, 2007 [Page 3]
Internet-Draft Common Conference Schema July 2006
1. Introduction
This document defines an Extensible Markup Language (XML) Schema that
represents the common conference information in a conferencing
server. The information is modeled as a series of elements, each of
which contains children and attributes.
The common conference information is a part of the Conference Object.
The Conference Object contains the XML schema, which is used to
represent the core information that is utilized in any conference
(capabilities,membership, roles, call control signalling, media,
etc...) and specifies the set of rights, permissions 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 of the XCON working group
to date and proposes to create a unified common conference
information data model for XCON.
This document has been constructed in compliance with the XCON
Framework [1] and the Session Initiation Protocol (SIP) Event Package
for Conference State [2]. It also incorporates data elements
proposed in several XCON WG and SIPPING WG drafts.
[Editors Note: This document is still in early stages of development
and is intended to trigger discussions.]
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [3].
This document uses the terminology defined in the XCON Conferencing
Framework [1] 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
Novo, et al. Expires January 11, 2007 [Page 4]
Internet-Draft Common Conference Schema July 2006
UTF-8.
A Common Conference information document begins with the root element
tag <conference-info> of conference-type. The <conference-info> has
the attribute 'entity' that contains the conference unique identifier
that identifies the conference being described in the document.
The <conference-info> element is comprised of <conference-
description>, <host-info>, <conference-state>, <security-mechanism>,
<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>,
<available-media>, and <users> child elements. Some of this
information can be represented using the conference-info-type schema
as defined in [2].
Changes in the state of the conference should be communicated to the
subscribers using a conference package subscribers (ex. A Session
Initiation Protocol (SIP) Event Package for Conference State).
Critical changes should be communicated to specific subscribers,
perhaps those with unique roles. The conference policy control
protocol msy be used to retrieve the conference state at any time.
The following non-normative diagram gives an example of the overall
hierarchy used in this format. The operator "!" preceding an element
indicates that this element is MANDATORY in the data model. The
operator "*" preceding an element indicates that this element is
introduced/proposed in this draft.
!<conference-info>
|
|--!<conference-description>
| |--<display-text>
| |--<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>
Novo, et al. Expires January 11, 2007 [Page 5]
Internet-Draft Common Conference Schema July 2006
| | | |--<notify-end-of-conference>
| | | |--<allowed-extend-mixing-end-offset>
| | ...
| |--<conf-uris>
| | |--<SIP>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | |--<H323>
| | | |--<H.323-alias>
| | | |--<H.323-URI>
| | |--<PSTN/ISDN>
| | | |--<phone number>
| | | |--<PIN-code>
| | | |--<purpose>
| | | |--<rate>*
| | ...
| |--<service-uris>
| | |--<SIP>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | |--<H323>
| | | |--<H.323-alias>
| | | |--<H.323-URI>
| | |--<PSTN/ISDN>
| | | |--<phone number>
| | |--<BFCP>
| | | |--<conference-ID>
| | ...
| |--<maximum-user-count>
| | |--<entry>
| | |--<entry>
| | ...
| |--<maximum-streams>
| | |--<entry>
| | |--<entry>
| | ...
| |--!<available-media>
| | |--!<entry>
| | | |--<type>
| | | |--<display-text>
| | | |--<status>
| | | |--<mixing-mode>
| | | |--<mix level>
| | | |--<controls>
| | | | |--<control>
| | | | | |--<display-text>
Novo, et al. Expires January 11, 2007 [Page 6]
Internet-Draft Common Conference Schema July 2006
| | | | | |--<value>
| | | | |--<control>
| | | | | |--<display-text>
| | | | | |--<value>
| | | | ...
| | | |--<codecs>
| | | | |--<entry>
| | | | |--<entry>
| | | | ...
| | |--<entry>
| | | |--<type>
| | | |--<display-text>
| | | |--<status>
| | | |--<mixing-mode>
| | | |--<mix level>
| | | |--<controls>
| | | | |--<control>
| | | | | |--<display-text>
| | | | | |--<value>
| | | | |--<control>
| | | | | |--<display-text>
| | | | | |--<value>
| | | | ...
| | | |--<codecs>
| | | | |--<entry>
| | | | |--<entry>
| | | | ...
| | ...
|
|--!<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>
Novo, et al. Expires January 11, 2007 [Page 7]
Internet-Draft Common Conference Schema July 2006
|
|--<security-mechanism>
| |--<entry-protocol=SIP>
| | |--<methods>
| | | |--<method>
| | | ...
| | |--<option-tags>
| | | |--<option-tag>
| | | ...
| | |--<feature-tags>
| | | |--<feature-tag>
| | | ...
| | |--<bodies>
| | | |--<body-disposition>
| | | | |--<body-format>
| | | ...
| |--<entry-protocol=H.323>*
| | |--<version>*
| |--<entry-protocol=H.320>*
| | |--<supported>*
| ...
|
|--<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>
| | |--<data-access-rights>
| | | |--<entry name=sidebars-by-ref>
| | | |--<entry name=sidebars-by-val>
| | | |--<entry name=conference-time>
| | | |--<entry name=mixing-start-offset>
Novo, et al. Expires January 11, 2007 [Page 8]
Internet-Draft Common Conference Schema July 2006
| | | ...
| | |
| | |--<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>
| | |--<floors>
| | | |--<entry>
| | | | |--<show-floor-holder>
| | | | |--<show-floor-requests>
| | | ...
| | |--<endpoint>
| | | |--<display-text>
| | | |--<referred>
| | | |--<status>
| | | |--<joining-method>
| | | |--<joining-info>
| | | |--<disconnection-method>
| | | |--<disconnection-info>
| | | |--<media>
| | | | |--<type>
| | | | |--<display-text>
| | | | |--<label>
Novo, et al. Expires January 11, 2007 [Page 9]
Internet-Draft Common Conference Schema July 2006
| | | | |--<src-id>
| | | | |--<status>
| | | | |--<to_mixer>
| | | | | |--<floor>
| | | | | |--<controls>
| | | | | | |--<control>
| | | | | | | |--<display-text>
| | | | | | | |--<value>
| | | | | | |--<control>
| | | | | | | |--<display-text>
| | | | | | | |--<value>
| | | | | | ...
| | | | |--<from_mixer>
| | | | | |--<floor>
| | | | | |--<controls>
| | | | | | |--<control>
| | | | | | | |--<display-text>
| | | | | | | |--<value>
| | | | | | |--<control>
| | | | | | | |--<display-text>
| | | | | | | |--<value>
| | | | | | ...
| | | | ...
| | | |--<call-info>
| | | | |--<sip>
| | | | | |--<display-text>
| | | | | |--<call-id>
| | | | | |--<from-tag>
| | | | | |--<to-tag>
| ... ...
|--<sidebars-by-ref>
| |--<entry>
| | |-- <user>
| | |-- <display-text>
| |--<entry>
| | |-- <user>
| | |-- <display-text>
| ...
|--<sidebars-by-val>
| |--<entry>
| | |
| | ...
| |--<entry>
| | |
| ... ...
The following sections describe these elements in detail. The full
Novo, et al. Expires January 11, 2007 [Page 10]
Internet-Draft Common Conference Schema July 2006
XML schema is provided in Section 4.
3.2. <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.
Novo, et al. Expires January 11, 2007 [Page 11]
Internet-Draft Common Conference Schema July 2006
The following sections describe the remaining elements in more
detail. Other child elements can be used to extend <conference-
description> in the future.
3.2.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
Novo, et al. Expires January 11, 2007 [Page 12]
Internet-Draft Common Conference Schema July 2006
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.2.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.2.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.2.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
Novo, et al. Expires January 11, 2007 [Page 13]
Internet-Draft Common Conference Schema July 2006
specific role allowed to join the conference [8].
3.2.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.2.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]. The <codecs> element
specifies the allowed codecs in the conference. It has an attribute
'decision' that specifies if the focus decides the common codec
automatically or needs the approvement of the moderator of the
conference (automatic, moderator-controlled). The <codecs> element
contains a <entry> elements. A <entry> element can have the
attribute 'name' and 'policy'. The 'name' attribute identifies a
codec, and the 'decision' attribute and the policy attribute contains
the policy for that codec (allowed, or disallowed).
The child elements <mixing-mode>, <mix level> describe a default
policy by which the mixer will build the outgoing stream from the
incoming streams. Notice that this policy is different that the
policy describe for the floors for each media. The <mix level> child
element describes the number of participants in audio media streams
or the number of sub-windows in video media streams (for instance, a
value of 4 in the <mix level> element for video stremas means 2x2
layout). The <mixing-mode> child element MUST contain one and only
one of the "Moderator-controlled", "FCFS", and "Automatic" values
indicating the default algorithm to be use with every media stream.
Next section explains the <controls> child element.
3.2.7. <controls>
The <controls> element contains the basic audio and video global
controls for a conferencing. It 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 of the data model to be used. In the <controls> element
Novo, et al. Expires January 11, 2007 [Page 14]
Internet-Draft Common Conference Schema July 2006
the schema is extensible, hence new control types can be added in a
future. Controls that apply at a different level than endpoint/
stream would appear at an appropriate place in the document. So,
moderator controls that affect all media output would go under the
<available-media> element.
3.2.7.1. mute
The 'mute' control is used in conjunction with a media stream to
cease transmission of associated media. It has a 'Boolean' value.
When muting, the control consists of the following attributes:
'type', 'name', 'enable'. And the following additional elements:
'label', and 'value'. The description of these elements are the
following:
type: The 'mute' control has a type of 'Boolean'.
name: The control is named 'mute'.
enable: The enable attribute specifies if access to the control is
available to the client. The value is of type 'boolean' and is set
to 'true' as default.
The Control also consists of the following additional elements:
display-text: Provides a Control label that can be rendered to the
client.
value: Provides a default value for the Control. For the Blue-Print
example the value is 'True'.
3.2.7.2. pause-video
The 'pause-video' control is used in conjunction with a media stream
to cease transmission of associated media. It has a 'Boolean' value.
The 'pause-video' control consists of the following attributes:
type: The 'pause-video' control has a type of 'Boolean'.
name: The control is named 'pause-video'.
default: Indicates the default value for the 'pause-video' control
when not set. The attribute type is 'Boolean' with a default value
of 'false. Setting the 'default' attribute to 'false' specifies that
media should be transported for the associated media stream. When
set to the value of 'true', media should not be transported for the
associated media stream.
Novo, et al. Expires January 11, 2007 [Page 15]
Internet-Draft Common Conference Schema July 2006
enable: The enable attribute specifies if access to the control is
available to the client. The value is of type 'boolean' and is set
to 'true' as default.
The Control also consists of the following additional elements:
display-text: Provides a Control label that can be rendered to the
client.
value: Provides a default value for the Control. For the Blue-Print
example the value is 'True'.
3.3. <host-info>
The <host-info> element contains information about the entity hosting
the conference. It contains the <display-text>, <web-page> child
elements. These child elements are explained in [2]. <host-info>
contains the <uris> child element as well. <uris> contains a sequence
of child elements: <SIP>, <H.323>, and <PSTN/ISDN>. The child
elements of <uris> are described in <conf-uris> section.
3.4. <conference-state>
The <conference-state> element and the <user-count>, <active>, and
<locked> child element are explained in section 5.5 of [2]. The
<allow-conference-state> element represents a boolean action. If set
to TRUE, the focus is instructed to allow the subscription to
conference state events, such as the SIP Event Package for Conference
State [2]. If set to FALSE, the subscription to conference state
events would be rejected. If this element is undefined it has a
value of TRUE, causing the subscription to conference state events to
be accepted.
3.5. <security-mechanism>
The <security-mechanism> contains a series of <entry-protocol> sub-
elements. The <entry-protocol> element has a single mandatory
attribute, 'name'. The 'name' attribute identifies a protocol the
policy of each protocol element is referring to. Each <entry-
protocol> sub-element contains the policy related to the usage of a
particular protocol.
The <entry-protocol> element has a series of child elements: methods,
option-tags, feature-tags, and bodies are defined for the SIP
protocol. These elements are described in the following sections.
H.323 protocol has a sub element <version> that says which version of
H.323 is supported. H.320 protocol has a sub element <supported>
that says if H.320 is supported or not.
Novo, et al. Expires January 11, 2007 [Page 16]
Internet-Draft Common Conference Schema July 2006
3.5.1. <methods>
The <methods> element contains a default-policy attribute and
<method> elements. The default-policy attribute contains the policy
for methods that are not listed as <method> elements. A <method>
element has two attributes: name and policy. The name attribute
identifies a method, and the policy attribute contains the policy for
that method (allowed or disallowed).
3.5.2. <option-tags>
The <option-tags> element contains a default-policy attribute and
<option-tag> elements. The default-policy attribute contains the
policy for option-tags that are not listed as <option-tag> elements.
An <option-tag> element has two attributes: name and policy. The
name attribute identifies a method, and the policy attribute contains
the policy for that method (mandatory, allowed, or disallowed).
3.5.3. <feature-tags>
The <feature-tags> element contains a default-policy attribute and
<feature-tag> elements. The default-policy attribute contains the
policy for feature-tags that are not listed as <feature-tag>
elements. A <feature-tag> element has two attributes: name and
policy. The name attribute identifies a method, and the policy
attribute contains the policy for that method (allowed, or
disallowed).
3.5.4. <bodies>
The <bodies> element contains a default-policy attribute, a default-
encryption attribute and <body-disposition> elements. The default-
policy attribute contains the policy for body dispositions that are
not listed as <body-disposition> elements. The default-encryption
attribute contains the encryption policy for body dispositions that
are not listed as <body-disposition> elements.
A <body-disposition> element can have a number of attributes: name,
policy, default-policy, and encryption. The name attribute
identifies a body-disposition, and the policy attribute contains the
policy for that body-disposition (allowed, or disallowed). The
default-policy attribute contains the policy for body formats that
are not listed as <body-format> elements. The encryption attribute
indicates whether or not encryption is allowed for a particular body
disposition.
A <body-disposition> element contains <body-format> elements. A
body-format element can have a two attributes: name and policy. The
Novo, et al. Expires January 11, 2007 [Page 17]
Internet-Draft Common Conference Schema July 2006
name attribute identifies a <body-format>, and the policy attribute
contains the policy for that body-format (allowed or disallowed).
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 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 <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 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
of 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. 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.
Novo, et al. Expires January 11, 2007 [Page 18]
Internet-Draft Common Conference Schema July 2006
A floor can be controlled using many algorithms; the mandatory
<Algorithm> element MUST contain one and only of the <Moderator-
controlled>, <FCFS>, and <Random> elements indicating the algorithm.
The <Max-floor-users> 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 <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> 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 define
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> element is a list of three elements:
'closedAuthenticated', 'openAuthenticated', and 'anonymous'. If the
<user-admission-policy> element is set to 'closedAuthenticated',
users must be specified (and authenticate). If the attribute is set
to 'openAuthenticated', users can be add after conference activation.
The following sections describe the remaining elements in more
Novo, et al. Expires January 11, 2007 [Page 19]
Internet-Draft Common Conference Schema July 2006
detail. Other child elements can be used to extend <conference-
description> 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, or domains (*@example.com) that the focus
uses to determine who can join the conference, who can invite 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
element. This child element includes the mandatory 'uri' attribute
and the mandatory 'method' attribute. 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. Value "dial-out" is used by the focus to determine
who to invite to 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 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 towards 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.
3.7.2. <privileges-control-list>
The <privileges-control-list> refers to a virtual set of rights,
permissions and limitations pertaining to operations. This element
contains the <data-access-rights> and the <conference-rules>.
3.7.2.1. <data-access-rights>
The <data-access-rights> element describes the read/write access
privileges for accessing the Conference Object as a whole. It is
partially described in [1]. The <data-access-rights> contains a list
of <entry> elements defined in the Conference Object. Every element
has three attributes: the attribute 'name', 'read-only', and the
attribute 'read-write'. When the conferencing server receives a
request for access to privacy-sensitive data it needs to match it
against the 'read-only' and the 'read-write' attributes. Each
Novo, et al. Expires January 11, 2007 [Page 20]
Internet-Draft Common Conference Schema July 2006
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 element is not defined in the
<data-access-rights> then 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.
3.7.2.2. <conference-rules>
The <conference-rules> element is a set of <entry> child elements
with specific authorization rules that indicate who is allowed to
subscribe to conference-information notifications, see floors,
request/grant floors, and so on.
Every <entry> element is represent by the 'id' attribute, each of
which identifies a rule inside the conference. It contains the
<condition> and <actions> sub elements.
3.7.2.2.1. <condition>
The <condition> element determines whether a particular privilege
applies to a user, a role, or domain.
The <condition> element has the <identity> and the <validity> child
element. These elements MUST NOT appear more than once in the
condition part of a single rule.
The <identity> element restricts matching of a rule either to a
single entity or a group of entities. The <identity> element has the
<one> and <many> child elements defined in Section 7.1 of [9]. 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 <external-list>, <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>.
Novo, et al. Expires January 11, 2007 [Page 21]
Internet-Draft Common Conference Schema July 2006
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 of [9].
3.7.2.2.1.1. <external-list>
The <external-list> element can be used to match those participants
that are part of a resource list that is created externally. The
<external-list> element contains a list of <except> elements and
allows to implement a simple blacklist mechanism. The <except>
element contains an identity.
3.7.2.2.1.2. <pseudonymous>
The <pseudonymous> element 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 and
providing a pseudonym in the signalling protocol (for example, using
the From-header of a SIP request).
The <pseudonymous> element can be combined with the <identity>
element to provide the focus with a rule on what to do when a
specific identity is authenticated and that identity is requesting
pseudonymity through the signalling protocol.
3.7.2.2.1.3. <has-been-referred>
The <has-been-referred> element can be used to match those
participants that the focus has referred to the conference.
3.7.2.2.1.4. <has-been-invited>
The <has-been-invited> element can be used to match those
participants that the focus has invited into the conference.
3.7.2.2.1.5. <has-been-in-conference>
The <has-been-in-conference> element can be used to match those
participants that have joined the conference in the past.
3.7.2.2.1.6. <is-in-conference>
The <is-in-conference> element can be used to match those
participants that are currently participating in the conference.
Novo, et al. Expires January 11, 2007 [Page 22]
Internet-Draft Common Conference Schema July 2006
3.7.2.2.1.7. <administrator>
The <administrator> element can be used to match those participants
that are administrators of a conference.
3.7.2.2.1.8. <is-on-allowed-users-list-dial-out>
The <is-on-allowed-users-list-dial-out> element can be used to match
those participants that are on the allowed-users-list with the method
dial-out.
3.7.2.2.1.9. <is-on-allowed-users-list-refer>
The <is-on-allowed-users-list-refer> element can be used to match
those participants that are on the allowed-users-list with the method
refer.
3.7.2.2.1.10. <participant-passcode>
The <participant-passcode> element can be used to match those
participants that have knowledge of a passcode for the conference
(PIN code).
A focus need not care if a user using a passcode to join 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 the
identity 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 this
case decides to challenge the identity for a passcode, if there is a
rule that allows users with a passcode knowledge to join. If no such
rule exists, the focus would not challenge for a passcode.
For PSTN users, the system can be set up for an IVR system to prompt
the user for a passcode before forwarding the request to the focus.
The focus does not need to care if there is an IVR system or not. It
can apply the same procedure as above. It checks if there are any
the rules allowing or denying the identity access. In this case, the
identity is the GW. If no rules exist for that identity but a
general passcode rule does, then the focus would challenge the GW/IVR
for the passcode.
A focus can challenge for the passcode using, for example, a HTTP
Digest challenge. The username, passcode and realm need to be
assigned and distributed is a manner that is outside the scope of
this document. Mutliple passcodes can be assigned to multiple users.
Novo, et al. Expires January 11, 2007 [Page 23]
Internet-Draft Common Conference Schema July 2006
3.7.2.2.1.11. <administrators-passcode>
In some cases, administrators of the conference are assigned a
different passcode than normal participants. The <administrator-
passcode> element can be used to match those key participants that
have knowledge on a key participant passcode for the conference.
Again, a focus need not care if a user using a passcode to join is
calling from a PSTN or an IP phone. It is important that the focus
has a unique identity for each user joining from a PSTN phone via a
gateway. It is not enough that one identity to be assigned to all
users joining from 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 the IP
signalling protocol header that usually carries the asserted identity
or a user.
3.7.2.2.2. <actions>
The <actions> element in the applied rule is a positive grant of
permission to the conference data model or the conferencing system.
The <actions> element has the following operations:
o The <allow-refer-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the
focus to refer a user to the conference without modifying the
allowed-users-list (in SIP terms, the identity is allowed to send
a REFER request to the focus which results in the focus sending a
REFER request to the user the referrer wishes to join the
conference). If set to FALSE, the refer request is rejected. If
this element is undefined it has a value of FALSE, causing the
refer to be rejected.
o The <allow-invite-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the
focus to invite a user to the conference without modifying the
allowed-users-list list (in SIP terms, the identity is allowed to
send a REFER request to the focus which results in the focus
sending an INVITE request to the user the referrer wishes to join
the conference). If set to FALSE, the refer request is rejected.
If this element is undefined it has a value of FALSE, causing the
refer to be rejected.
o The <allow-remove-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the
focus to remove a user from the conference without modifying the
ruleset (in SIP terms, the identity is allowed to send a REFER
request to the focus which results in the focus sending an BYE
request to the user the referrer wishes to leave the conference).
If set to FALSE, the refer request is rejected. If this element
is undefined it has a value of FALSE, causing the refer to be
Novo, et al. Expires January 11, 2007 [Page 24]
Internet-Draft Common Conference Schema July 2006
rejected.
o The <show-floor-holder> 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 has defined
values of:
* block: This action instructs the focus to deny the floor
request. This action is the default action taken in the
absence of any other actions.
* confirm: This action instructs the focus to allow the request.
The focus then uses the defined floor algorithm to further
allow of deny the floor. The algorithms used are outside the
scope of this document.
o Note that placing a value of block for this element does not
guarantee that a participant is blocked from joining the
conference. Any other rule that might resolve to true for this
participant that carried an action whose value was higher than
block would automatically grant confirm/allow permission to that
participant.
o The <show-floor-requests> element is of type boolean
transformation. If set to TRUE, the conference participant is
able to see the floor requests. If set to FALSE, the conference
participant is not able to see floor requests. If this element is
undefined, it has a value of FALSE, causing the floor requests to
not being seen by the conference participant.
o A rule can be set that provides anonymity to a specific identity.
In this case, the focus provides to the rest of the participants
an anonymous identity for that user, for example anonymous1. This
can be achieved by using the <provide-anonymity> element. It is a
boolean transformation. If set to TRUE, the conference
participants will see an anonymous identity for the user whose
identity is present in the conditions.
o The <read-write> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the element described
inside the 'element' attribute in the conference policy. If set
to FALSE, any modifications to the element are rejected.
o The <read-only> element represents a boolean action. If set to
TRUE, the identity is allowed to read the element described inside
the 'element' attribute in the conference policy. If set to
FALSE, any attempts to read the element are rejected.
3.7.3. <user>
The element <user> describes a single participant in the conference.
The following elements as well as the attributes of <user> are
defined in [2], section 5.6: <display-text>, <associated-aors>,
<roles>, <languages>, <cascaded-focus>, and <endpoint>.
Novo, et al. Expires January 11, 2007 [Page 25]
Internet-Draft Common Conference Schema July 2006
The <provide-anonymity> provides anonymity to the user. When a user
is defined then the role must be defined or set to "participant" by
default. This specification does not define the set of possible
conferencing roles nor the semantics associated with each.
The <sphere> element can be used to indicate the state (e.g., 'work',
'home', 'meeting', 'travel') the user is currently in. It is defined
in section 7.2 of [9].
The <allow-refer-users-dynamically>, <allow-invite-users-dynamically>
and <allow-remove-users-dynamically> elements are defined in the
previous section.
The <floors> element is a container of <entry> child elements, each
describing a floor that joins this participant in the conference.
The <entry> element has the <show-floor-holder> and the <show-floor-
requests> child element. The <entry> child elements is represent by
the 'id' attribute, each of which identifies a floor inside the
conference.
The <endpoint> element is under a <user> parent. This element can
provide the desired level of detail about the user's devices and
signaling sessions taking part in the conference and has the
following child elements defined in [2]: <display-text>, <referred>,
<status>, <joining-method>, <joining-info>, <disconnection-method>,
<disconnection-info>, <media>, and <call-info>. The <endpoint>
element has as well two other child elements: <to_mixer>, and
<from_mixer> child element described in the following section.
3.7.3.1. from_mixer, to_mixer
Similarly that the controls defined in the <available-media> element,
controls that apply to a particular user appear at this place in the
document. The <to_mixer> element details properties associated with
the incoming streams to the mixer. <from_mixer> element details
properties associated with the outgoing streams from the mixer. BOth
of these elements have the attribute 'name'. '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.
Every of these elements have the <floor> and <controls> child
elements. The <controls> child elements defined the same elements
described in section 3.2.7 and some new ones.
Novo, et al. Expires January 11, 2007 [Page 26]
Internet-Draft Common Conference Schema July 2006
3.7.3.1.1. <floor>
If a participant, for instance, needs to talk in the conference, it
first needs to get a floor from the moderator of the conference. The
floor control can be enabled or disabled by the moderator during the
conference creation stage. When the floor control is not enabled
then any participant can speak in the conference at any time. In
this conference very basic controls like muting or pausing the output
stream, changing the volume of the output stream are provided to end
participants. The <floor> element consists of the following
attributes:
floor_id: Uniquely identifies the floor within the context of this
template and has a value of '1'.
instances: Value of '1' implies only one occurrence of this floor at
any one time.
enable: A value of 'false' indicates that this floor is not enabled
by default.
value: A value of false specifies that the instance represented by
this template does not have control of the floor.
3.7.3.1.2. <gain>
The 'gain' control is used in conjunction with a media output stream
to indicate the amount of amplification of an audio stream. It has a
'Int' number value from -127 to 127. The control consists of the
following attributes:
type: The 'gain' control has a type of 'Int'.
name: The control is named 'gain'.
enable: The enable attribute specifies if access to the control is
available to the client.
The Control also consists of the following additional elements:
value: Indicates the default value for the 'gain' control when not
set.
display-text: Provides a Control label that can be rendered to the
client.
Novo, et al. Expires January 11, 2007 [Page 27]
Internet-Draft Common Conference Schema July 2006
3.8. <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 conference unique identifier and a <display-text>
child element. The <sidebars-by-ref> element is described in Section
5.9.1 of [2].
Notice that the <sidebars-by-ref> child element does not include the
attribute 'state' defined in [2].
3.9. <sidebars-by-val>
The <sidebars-by-val> element contains a set of <entry> child
elements each containing information about a single sidebar.
Notice as well that the <sidebars-by-val> and the <entry> child
element do not include the attribute 'state' defined in [2].
4. XML Schema
In accordance with the XCON framework document [1], 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. It also contains the variable
information part of the Conference Object.
This specification makes use of XML namespaces for identifying common
conference information documents and document fragments. The
namespace URI for elements defined by this specification is a URN:
urn:ietf:params:xml:ns:common-conference-schema.
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns="urn:ietf:params:xml:ns:common-conference-schema"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:compol="urn:ietf:params:xml:ns:common-policy"
xmlns:role="urn:ietf:params:xml:ns:role-schema"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:common-conference-schema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:conference-info" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\conference-info.xsd" />
<xs:import namespace="urn:ietf:params:xml:ns:common-policy" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\common-policy.xsd" />
<xs:import namespace="urn:ietf:params:xml:ns:role-schema" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\role-schema.xsd" />
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!--
CONFERENCE INFO
Novo, et al. Expires January 11, 2007 [Page 28]
Internet-Draft Common Conference Schema July 2006
-->
<xs:element name="conference-info" type="conference-type"/>
<!--
CONFERENCE TYPE
-->
<xs:complexType name="conference-type">
<xs:sequence>
<xs:element name="conference-description" type="conference-description-type"/>
<xs:element name="host-info" type="host-type"/>
<xs:element name="conference-state" type="conference-state-type"/>
<xs:element name="security-mechanism" type="security-mechanisms-type" minOccurs="0"/>
<xs:element name="floor-information" type="floor-information-type" minOccurs="0"/>
<xs:element name="users" type="users-type"/>
<xs:element name="sidebars-by-ref" type="sidebars-by-ref-type" minOccurs="0"/>
<xs:element name="sidebars-by-val" type="sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
CONFERENCE DESCRIPTION TYPE
-->
<xs:complexType name="conference-description-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="subject" type="xs:string" minOccurs="0"/>
<xs:element name="free-text" type="xs:string" minOccurs="0"/>
<xs:element name="keywords" type="info:keywords-type" minOccurs="0"/>
<xs:element name="webpage" type="xs:anyURI" minOccurs="0"/>
<xs:element name="security-level" type="SecurityLevel" minOccurs="0"/>
<xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/>
<xs:element name="conference-stage" type="conference-stage-type"/>
<xs:element name="conference-time" type="conferencetime-type" minOccurs="0"/>
<xs:element name="conf-uris" type="uris-type" minOccurs="0"/>
<xs:element name="service-uris" type="uris-type" minOccurs="0"/>
<xs:element name="maximum-user-count" type="maximum-user-count-type" minOccurs="0"/>
<xs:element name="available-media" type="conference-media-type"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
SECURITY LEVEL
-->
<xs:simpleType name="SecurityLevel">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
Novo, et al. Expires January 11, 2007 [Page 29]
Internet-Draft Common Conference Schema July 2006
<xs:enumeration value="high"/>
</xs:restriction>
</xs:simpleType>
<!--
CONFERENCE STAGE
-->
<xs:simpleType name="conference-stage-type">
<xs:restriction base="xs:string">
<xs:enumeration value="reserved"/>
<xs:enumeration value="started"/>
<xs:enumeration value="running"/>
<xs:enumeration value="ended"/>
</xs:restriction>
</xs:simpleType>
<!--
CONFERENCE TIME
-->
<xs:complexType name="conferencetime-type">
<xs:sequence>
<xs:element name="entry" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="base" type="xs:string"/>
<xs:element name="mixing-start-offset" type="xs:integer" minOccurs="0"/>
<xs:element name="mixing-stop-offset" type="xs:integer" minOccurs="0"/>
<xs:element name="can-join-after-offset" type="xs:integer" minOccurs="0"/>
<xs:element name="must-join-before-offset" type="xs:integer" minOccurs="0"/>
<xs:element name="request-users" type="xs:integer" minOccurs="0"/>
<xs:element name="notify-end-of-conference" type="xs:integer" minOccurs="0"/>
<xs:element name="allowed-extend-mixing-end-offset" type="xs:boolean" default="true" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
URIS TYPE
-->
<xs:complexType name="uris-type">
<xs:sequence>
<xs:element name="SIP" type="uri-type" maxOccurs="unbounded"/>
<xs:element name="H323" type="H323-type" maxOccurs="unbounded"/>
<xs:element name="PSTN-ISDN" type="PSTN-type" maxOccurs="unbounded"/>
<xs:element name="BFCP" type="BFCP-type" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
Novo, et al. Expires January 11, 2007 [Page 30]
Internet-Draft Common Conference Schema July 2006
SIP TYPE
-->
<xs:complexType name="uri-type">
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="purpose" type="xs:string" minOccurs="0"/>
<xs:element name="PIN-code" type="xs:integer" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
H323 TYPE
-->
<xs:complexType name="H323-type">
<xs:sequence>
<xs:element name="H.323-alias" type="xs:string" minOccurs="0"/>
<xs:element name="H.323-URI" type="xs:anyURI"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
PSTN TYPE
-->
<xs:complexType name="PSTN-type">
<xs:sequence>
<xs:element name="phone-number" type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="rate" type="xs:unsignedInt" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="PIN-code" type="xs:string" use="required"/>
<xs:attribute name="purpose" type="xs:string"/>
</xs:complexType>
<!--
BFCP TYPE
-->
<xs:complexType name="BFCP-type">
<xs:sequence>
<xs:element name="conference-id" type="xs:unsignedInt" minOccurs="0"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
MAXIMUM USER TYPE
-->
<xs:complexType name="maximum-user-count-type">
<xs:sequence>
Novo, et al. Expires January 11, 2007 [Page 31]
Internet-Draft Common Conference Schema July 2006
<xs:element name="entry" type="xs:unsignedInt" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="role" type="role:role-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE MEDIA TYPE
-->
<xs:complexType name="conference-media-type">
<xs:sequence>
<xs:element name="entry" type="conference-medium-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="label" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE MEDIUM TYPE
-->
<xs:complexType name="conference-medium-type">
<xs:sequence>
<xs:element name="type" type="xs:string"/>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="status" type="info:media-status-type" minOccurs="0"/>
<xs:element name="mixing-mode" type="mix-mode-type" minOccurs="0"/>
<xs:element name="mix level" type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="codecs" type="codecs-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="label" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
MIX MODE TYPE
-->
<xs:simpleType name="mix-mode-type">
<xs:restriction base="xs:string">
<xs:enumeration value="Moderator-controlled"/>
<xs:enumeration value="FCFS"/>
<xs:enumeration value="Automatic"/>
</xs:restriction>
</xs:simpleType>
<!--
CODECS TYPE
-->
<xs:complexType name="codecs-type">
<xs:sequence>
<xs:element name="entry" type="codec-type" maxOccurs="unbounded"/>
Novo, et al. Expires January 11, 2007 [Page 32]
Internet-Draft Common Conference Schema July 2006
</xs:sequence>
<xs:attribute name="decision" type="decision-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CODEC TYPE
-->
<xs:complexType name="codec-type">
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="policy" type="policy-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
DECISION TYPE
-->
<xs:simpleType name="decision-type">
<xs:restriction base="xs:string">
<xs:enumeration value="Automatic"/>
<xs:enumeration value="Moderator-controlled"/>
</xs:restriction>
</xs:simpleType>
<!--
POLICY TYPE
-->
<xs:simpleType name="policy-type">
<xs:restriction base="xs:string">
<xs:enumeration value="Allowed"/>
<xs:enumeration value="Disallowed"/>
</xs:restriction>
</xs:simpleType>
<!--
HOST TYPE
-->
<xs:complexType name="host-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
<xs:element name="uris" type="uris-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE STATE TYPE
-->
<xs:complexType name="conference-state-type">
<xs:sequence>
<xs:element name="allow-conference-state" type="xs:boolean" minOccurs="0"/>
Novo, et al. Expires January 11, 2007 [Page 33]
Internet-Draft Common Conference Schema July 2006
<xs:element name="user-count" type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="active" type="xs:boolean" minOccurs="0"/>
<xs:element name="locked" type="xs:boolean" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
SECURITY MECHANISMS TYPE
-->
<xs:complexType name="security-mechanisms-type">
<xs:sequence>
<xs:element name="entry-protocol" type="security-mechanism-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
SECURITY MECHANISM TYPE
-->
<xs:complexType name="security-mechanism-type">
<xs:sequence>
<xs:element name="methods" type="methods-type" minOccurs="0"/>
<xs:element name="option-tags" type="option-tags-type" minOccurs="0"/>
<xs:element name="feature-tags" type="feature-tags-type" minOccurs="0"/>
<xs:element name="bodies" type="bodies-type" minOccurs="0"/>
<xs:element name="version" type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="supported" type="xs:boolean" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
METHODS TYPE
-->
<xs:complexType name="methods-type">
<xs:sequence>
<xs:element name="method" type="codec-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="default-policy" type="policy-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
OPTION TAGS TYPE
-->
<xs:complexType name="option-tags-type">
<xs:sequence>
Novo, et al. Expires January 11, 2007 [Page 34]
Internet-Draft Common Conference Schema July 2006
<xs:element name="option-tag" type="codec-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="default-policy" type="default-policy-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
DEFAULT POLICY TYPE
-->
<xs:simpleType name="default-policy-type">
<xs:restriction base="xs:string">
<xs:enumeration value="Allowed"/>
<xs:enumeration value="Disallowed"/>
<xs:enumeration value="Mandatory"/>
</xs:restriction>
</xs:simpleType>
<!--
FEATURE TAGS TYPE
-->
<xs:complexType name="feature-tags-type">
<xs:sequence>
<xs:element name="feature-tag" type="codec-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="default-policy" type="policy-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
BODIES TYPE
-->
<xs:complexType name="bodies-type">
<xs:sequence>
<xs:element name="body-disposition" type="body-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="default-policy" type="policy-type" use="required"/>
<xs:attribute name="default-encryption" type="policy-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
BODY TYPE
-->
<xs:complexType name="body-type">
<xs:sequence>
<xs:element name="body-format" type="codec-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
Novo, et al. Expires January 11, 2007 [Page 35]
Internet-Draft Common Conference Schema July 2006
<xs:attribute name="policy" type="policy-type" use="required"/>
<xs:attribute name="default-policy" type="policy-type" use="required"/>
<xs:attribute name="encryption" type="policy-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
FLOOR INFORMATION TYPE
-->
<xs:complexType name="floor-information-type">
<xs:sequence>
<xs:element name="allow-floor-events" type="xs:boolean" maxOccurs="unbounded"/>
<xs:element name="floor-request-handling" type="floor-request-type" maxOccurs="unbounded"/>
<xs:element name="conference-floor-policy" type="Conference-floor-policy" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
FLOOR REQUEST TYPE
-->
<xs:simpleType name="floor-request-type">
<xs:restriction base="xs:string">
<xs:enumeration value="block"/>
<xs:enumeration value="confirm"/>
</xs:restriction>
</xs:simpleType>
<!--
CONFERENCE FLOOR POLICY
-->
<xs:complexType name="Conference-floor-policy">
<xs:sequence>
<xs:element name="Floor" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="Media-types">
<xs:complexType>
<xs:sequence>
<xs:element name="Video" minOccurs="0"/>
<xs:element name="Audio" minOccurs="0"/>
<xs:element name="Application" minOccurs="0"/>
<xs:element name="Data" minOccurs="0"/>
<xs:element name="Control" minOccurs="0"/>
<xs:element name="Message" minOccurs="0"/>
<xs:element name="Text" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Novo, et al. Expires January 11, 2007 [Page 36]
Internet-Draft Common Conference Schema July 2006
<xs:element name="Algorithm">
<xs:complexType>
<xs:sequence>
<xs:element name="Moderator-controlled" minOccurs="0"/>
<xs:element name="FCFS" minOccurs="0"/>
<xs:element name="Random" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Max-floor-users" type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:element name="Moderator-URI" type="xs:anyURI" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="moderator-controlled" type="xs:boolean" default="false"/>
<xs:attribute name="label" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
USERS TYPE
-->
<xs:complexType name="users-type">
<xs:sequence>
<xs:element name="join-handling" type="join-handling-type" minOccurs="0"/>
<xs:element name="user-admission-policy" type="user-admission-policy-type"/>
<xs:element name="user-must-be-specified" type="xs:boolean" minOccurs="0"/>
<xs:element name="allowed-users-list" type="UserList" minOccurs="0"/>
<xs:element name="privileges-control-list" type="privileges-control-list-type" minOccurs="0"/>
<xs:element name="user" type="user-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
USERS ADMISSION POLICY
-->
<xs:simpleType name="user-admission-policy-type">
<xs:restriction base="xs:string">
<xs:enumeration value="closedAuthenticated"/>
<xs:enumeration value="openAuthenticated"/>
<xs:enumeration value="anonymous"/>
</xs:restriction>
</xs:simpleType>
<!--
JOIN HANDLING TYPE
-->
<xs:simpleType name="join-handling-type">
Novo, et al. Expires January 11, 2007 [Page 37]
Internet-Draft Common Conference Schema July 2006
<xs:restriction base="xs:string">
<xs:enumeration value="block"/>
<xs:enumeration value="allow"/>
<xs:enumeration value="confirm"/>
<xs:enumeration value="IVR"/>
<xs:enumeration value="directed-operator"/>
</xs:restriction>
</xs:simpleType>
<!--
USERLIST
-->
<xs:complexType name="UserList">
<xs:sequence>
<xs:element name="target" type="Target" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
TARGET
-->
<xs:complexType name="Target">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="method" type="xs:methodType" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!--
METHOD TYPE
-->
<xs:complexType name="methodType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0">
<xs:element name="dial-in" type="xs:string"/>
<xs:element name="dial-out" type="xs:string"/>
<xs:element name="refer" type="xs:string"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!--
PRIVILEGES CONTROL LIST TYPE
-->
Novo, et al. Expires January 11, 2007 [Page 38]
Internet-Draft Common Conference Schema July 2006
<xs:complexType name="privileges-control-list-type">
<xs:sequence>
<xs:element name="data-access-rights" type="data-access-rights-type" maxOccurs="unbounded"/>
<xs:element name="conference-rules" type="conference-rules-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
DATA ACCESS RIGHTS TYPE
-->
<xs:complexType name="data-access-rights-type">
<xs:sequence>
<xs:element name="entry" type="entry-rights-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
ENTRY RIGHTS TYPE
-->
<xs:complexType name="entry-rights-type">
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="read-only" type="role:role-type" use="required"/>
<xs:attribute name="read-write" type="role:role-type" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE RULES TYPE
-->
<xs:complexType name="conference-rules-type">
<xs:sequence>
<xs:element name="entry" type="conference-rule-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE RULE TYPE
-->
<xs:complexType name="conference-rule-type">
<xs:sequence>
<xs:element name="condition" type="condition-type" maxOccurs="unbounded"/>
<xs:element name="action" type="action-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONDITION TYPE
-->
Novo, et al. Expires January 11, 2007 [Page 39]
Internet-Draft Common Conference Schema July 2006
<xs:complexType name="condition-type">
<xs:sequence>
<xs:element name="identity" type="identity-type"/>
<xs:element name="validity" type="compol:validityType"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
IDENTITY TYPE
-->
<xs:complexType name="identity-type">
<xs:sequence>
<xs:element name="identity" type="identityType" maxOccurs="unbounded"/>
<xs:element name="validity" type="compol:validityType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
ROLES IDENTITY TYPE
-->
<xs:complexType name="identityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0">
<xs:element name="one" type="compol:oneType"/>
<xs:element name="many" type="compol:manyType"/>
<xs:element name="external-list" type="xs:string"/>
<xs:element name="pseudonymous" type="xs:string"/>
<xs:element name="has-been-referred" type="xs:string"/>
<xs:element name="has-been-invited" type="xs:string"/>
<xs:element name="has-been-in-conference" type="xs:string"/>
<xs:element name="is-in-conference" type="xs:string"/>
<xs:element name="administrator" type="xs:string"/>
<xs:element name="is-on-allowed-users-list-dial-out" type="xs:string"/>
<xs:element name="is-on-allowed-users-list-refer" type="xs:string"/>
<xs:element name="participant-passcode" type="xs:string"/>
<xs:element name="administrator-passcode" type="xs:string"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!--
ACTION TYPE
-->
<xs:complexType name="action-type">
<xs:complexContent>
<xs:restriction base="xs:anyType">
Novo, et al. Expires January 11, 2007 [Page 40]
Internet-Draft Common Conference Schema July 2006
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="allow-refer-users-dynamically" type="xs:boolean"/>
<xs:element name="allow-invite-users-dynamically" type="xs:boolean"/>
<xs:element name="allow-remove-users-dynamically" type="xs:boolean"/>
<xs:element name="show-floor-holder" type="floor-request-type"/>
<xs:element name="show-floor-request" type="xs:boolean"/>
<xs:element name="provide-anonymity" type="xs:boolean"/>
<xs:element name="read-only" type="role:role-type"/>
<xs:element name="read-write" type="role:role-type"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!--
USER TYPE
-->
<xs:complexType name="user-type">
<xs:sequence>
<xs:element name="user" type="one-user-type" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="info:state-type" use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
ONE USER TYPE
-->
<xs:complexType name="one-user-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string" minOccurs="0"/>
<xs:element name="associated-aors" type="info:uris-type" minOccurs="0"/>
<xs:element name="provide-anonymity" type="xs:boolean" minOccurs="0"/>
<xs:element name="roles" type="role:role-type" minOccurs="0"/>
<xs:element name="languages" type="info:user-languages-type" minOccurs="0"/>
<xs:element name="cascaded-focus" type="xs:anyURI" minOccurs="0"/>
<xs:element name="sphere" type="compol:sphereType" minOccurs="0"/>
<xs:element name="allow-refer-users-dynamically" type="xs:boolean"/>
<xs:element name="allow-invite-users-dynamically" type="xs:boolean"/>
<xs:element name="allow-remove-users-dynamically" type="xs:boolean"/>
<xs:element name="floors" type="show-floors-type"/>
<xs:element name="endpoint" type="info:endpoint-type" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="state" type="info:state-type" use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
Novo, et al. Expires January 11, 2007 [Page 41]
Internet-Draft Common Conference Schema July 2006
SHOW FLOORS TYPE
-->
<xs:complexType name="show-floors-type">
<xs:sequence>
<xs:element name="entry" type="show-floor-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
SHOW FLOOR TYPE
-->
<xs:complexType name="show-floor-type">
<xs:sequence>
<xs:element name="show-floor-holder" type="xs:boolean" minOccurs="0"/>
<xs:element name="show-floor-request" type="xs:boolean"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
SIDEBARS-BY-REF TYPE
-->
<xs:complexType name="sidebars-by-ref-type">
<xs:sequence>
<xs:element name="entry" type="info:uri-type" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
SIDEBARS-BY-VAL TYPE
-->
<xs:complexType name="sidebars-by-val-type">
<xs:sequence>
<xs:element name="entry" type="conference-type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:schema>
5. 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 accomplished by defining elements, child elements and
attributes that are specific to the desired application domain. Each
Novo, et al. Expires January 11, 2007 [Page 42]
Internet-Draft Common Conference Schema July 2006
extension MUST define its own namespace. Points of extension MUST be
defined in the schema, and SHOULD be done using the <any
namespace="##other"> construct.
Elements or attributes from unknown namespaces MUST be ignored.
6. XML example
The following is an example of a common conference information
document. The conference starts on October 17, 2006, at 10:30 AM in
New York City and finishes the same day at 12:30 PM every week. In
this example, there are currently 3 participants in a conference, one
administrator, one moderator, and one participant. Note that
sidebars are allowed in this conference and there is one sidebar in
the conference. Also note that there is one floor moderator for the
audio and a different floor moderator for the video.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:common-conference-schema"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:sesspol="urn:ietf:params:xml:ns:sessionpolicy"
xmlns:compol="urn:ietf:params:xml:ns:common-policy"
entity="sips:conference@example.com">
<!--
CONFERENCE DESCRIPTION
-->
<info:conference-description xml:lang="en-us">
<info:display-text>Discussion of the best moments in Formula-1\\
racing</info:display-text>
<info:subject> Sports:Formula-1</info:subject>
<info:free-text>This is a conference example</info:free-text>
<info:keywords>Formula-1, cars</info:keywords>
<web-page>http://www.example.com/users/alice/formula-1\\
</web-page>
<security-level>low</security-level>
<allow-sidebars>true</allow-sidebars>
<conference-stage>running</conference-stage>
<!--
CONFERENCE TIME
-->
<conference-time>
<entry>
<base>
BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
Novo, et al. Expires January 11, 2007 [Page 43]
Internet-Draft Common Conference Schema July 2006
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20051103T140728Z
UID:carol at example.com
ORGANIZER:MAILTO:carol at example.com
DTSTART:20061017T143000Z
RRULE:FREQ=WEEKLY
DTEND:20061017T163000Z
</base>
<mixing-start-offset required-participant="moderator">
20061017T142900Z</mixing-start-offset>
<mixing-end-offset required-participant="participant">
20061017T163100Z</mixing-end-offset>
<must-join-before-offset>
20061017T15300Z</must-join-before-offset>
</entry>
</conference-time>
<!--
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>
<!--
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>
<!--
MAXIMUM USER COUNT
-->
<maximum-user-count>
<entry role = "administrator">2</entry>
<entry role = "moderator">5</entry>
<entry role = "participant">150</entry>
</maximum-user-count>
Novo, et al. Expires January 11, 2007 [Page 44]
Internet-Draft Common Conference Schema July 2006
<!--
AVAILABLE MEDIA
-->
<info:available-media>
<info:entry label="10234">
<info:display-text>main audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
<mixing-mode>automatic</mixing-mode>
<mix level>3</mix level>
<codecs decision="automatic">
<codec name="PCMU" policy="allowed"/>
</codecs>
</info:entry>
<info:entry label="10235">
<info:display-text>main video</info:display-text>
<info:type>video</info:type>
<mixing-mode>automatic</mixing-mode>
<mix level>4</mix level>
<info:status>sendrecv</info:status>
<sesspol:codecs decision="automatic">
<sesspol:codec name="H.263" policy="allowed"/>
</sesspol:codecs>
</info:entry>
</info:available-media>
</info:conference-description>
<!--
HOST INFO
-->
<info:host-info>
<info:display-text>Formula1</info:display-text>
<info:web-page>http://www.example.com/users/formula-1/\\
</info:web-page>
<info:uris>
<info:SIP>
<info:uri>sip:alice@example.com</info:uri>
</info:SIP>
<info:SIP>
<info:uri>sip:carol@example.com</info:uri>
</info:SIP>
</info:uris>
</info:host-info>
<!--
CONFERENCE STATE
-->
<info:conference-state>
<allow-conference-state>true \\
</allow-conference-state>
Novo, et al. Expires January 11, 2007 [Page 45]
Internet-Draft Common Conference Schema July 2006
<info:user-count>3</info:user-count>
<info:active>true</info:active>
<info:locked>false</info:locked>
</info:conference-state>
<!--
SECURITY MECHANISM
-->
<security-mechanism>
<entry-protocol name="SIP">
<sesspol:methods default-policy="allowed">
<sesspol:method name="MESSAGE" policy="disallowed"/>
</sesspol:methods>
<sesspol:option-tags default-policy="disallowed">
<sesspol:option-tag name="100rel" policy="mandatory"/>
<sesspol:option-tag name="preconditions" policy="allowed"/>
</sesspol:option-tags>
<sesspol:feature-tags default-policy="disallowed">
<sesspol:feature-tag name="video" policy="allowed"/>
</sesspol:feature-tags>
<sesspol:bodies default-policy="allowed" \\
default-encryption="allowed">
<sesspol:body-disposition name="session" policy="allowed" \\
encryption="disallowed" default-policy="disallowed">
<sesspol:body-format name="application/sdp" \\
policy="allowed"/>
</sesspol:body-disposition>
</sesspol:bodies>
</entry-protocol>
</security-mechanism>
<!--
FLOOR INFORMATION
-->
<floor-information>
<allow-floor-events>true</allow-floor-events>
<floor-request-handling>1 </floor-request-handling>
<conference-floor-policy>
<floor moderator-controlled="true" label="10234">
<media-types>audio</media-types>
<algorithm>Moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<moderator-uri>sip:alice@example.com \\
</moderator-uri>
</floor>
<floor moderator-controlled="true" label="10235">
<media-types>video</media-types>
<algorithm>Moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<moderator-uri>sip:carol@example.com \\
Novo, et al. Expires January 11, 2007 [Page 46]
Internet-Draft Common Conference Schema July 2006
</moderator-uri>
</floor>
</conference-floor-policy>
</floor-information>
<!--
USERS
-->
<users>
<join-handling>allow</join-handling>
<!--
ALLOWED USERS LIST
-->
<allowed-users-list>
<target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:alice@example.com" method="dial-out"/>
<target uri="sip:carol@example.com" method="dial-out"/>
<target uri="sip:john@example.com" method="refer"/>
</allowed-users-list>
<!--
PRIVILEGES CONTROL LIST
-->
<privileges-control-list>
<data-access-rights>
<conference-description read-only= "observer"/>
<security-level read-only= "administrator"/>
<allow-sidebars read-only= "creator" \\
read-write= "creator"/>
<conference-time read-only= "administrator"/>
<maximum-user-count read-write= "creator"/>
<codecs read-only= "creator" read-write= "creator"/>
<host-info read-write= "creator"/>
<conference-state read-write= "creator"/>
<security-mechanism read-only= "creator"/>
<floor-information read-only= "administrator"/>
<allowed-users-list read-only= "administrator"/>
<privileges-control-list read-only= "creator"/>
<conditions read-only= "creator"/>
<validity read-only= "creator"/>
<allow-conference-state read-only= "observer"/>
<sidebars-by-ref read-only= "observer"\\
read-write= "creator"/>
<sidebars-by-val read-only= "observer"\\
read-write= "creator"/>
</data-access-rights>
<conference-rules>
<entry id="1">
<conditions>
<compol:identity>
Novo, et al. Expires January 11, 2007 [Page 47]
Internet-Draft Common Conference Schema July 2006
<compol:domain>example.com</compol:domain>
</compol:identity>
<compol:validity>
<compol:from>20061017T143000Z</compol:from>
<compol:to>20061017T163000Z</compol:to>
</compol:validity>
</conditions>
<compol:actions>
<compol:allow-conference-state>true\\
</compol:allow-conference-state>
</compol:actions>
</entry>
<entry id="2">
<conditions>
<compol:identity>
<compol:uri>bob@example.com</compol:uri>
</compol:identity>
</conditions>
<compol:actions>
<join-handling>block</join-handling>
</compol:actions>
</entry>
</conference-rules>
</privileges-control-list>
<!--
USER
-->
<info:user entity="sip:bob@example.com">
<info:display-text>Bob Hoskins</display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob@example.com</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<provide-anonymity>false</provide-anonymity>
<info:roles>
<info:entry>participant</info:entry>
</info:roles>
<info:languages>en</info:languages>
<sphere value="work"/>
<allow-refer-users-dynamically>false\\
</allow-refer-users-dynamically>
<allow-invite-users-dynamically>false\\
</allow-invite-users-dynamically>
<allow-remove-users-dynamically>false\\
</allow-remove-users-dynamically>
<floors>
Novo, et al. Expires January 11, 2007 [Page 48]
Internet-Draft Common Conference Schema July 2006
<entry id="1">
<show-floor-holder>false</show-floor-holder>
<show-floor-requests>false \\
</show-floor-requests>
</entry>
</floors>
<!--
ENDPOINTS
-->
<info:endpoint entity="sip:bob@example.com">
<info:display-text>Bob's Laptop</info:display-text>
<info:referred>
<info:when>20061017T140000Z</info:when>
<info:reason>expert required</info:reason>
<info:by>sip:alice@example.com</info:by>
</info:referred>
<info:status>connected</info:status>
<info:joining-method>dialed-out</info:joining-method>
<info:joining-info>
<info:when>20061017T140000Z</info:when>
<info:reason>invitation</info:reason>
<info:by>sip:alice@example.com</info:by>
</info:joining-info>
<!--
MEDIA
-->
<info:media id="1">
<info:label>10235</info:label>
<info:src-id>432424</info:src-id>
</info:media>
<!--
CALL INFO
-->
<info:call-info>
<info:sip>
<info:display-text>full info</info:display-text>
<info:call-id>hsjh8980vhsb78</info:call-id>
<info:from-tag>vav738dvbs</info:from-tag>
<info:to-tag>8954jgjg8432</info:to-tag>
</info:sip>
</info:call-info>
</info:endpoint>
</info:user>
<!--
USER
-->
<info:user entity="sip:alice@example.com">
<info:display-text>Alice Kay</info:display-text>
Novo, et al. Expires January 11, 2007 [Page 49]
Internet-Draft Common Conference Schema July 2006
<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>
<provide-anonymity>false</provide-anonymity>
<info:roles>
<info:entry>moderator</info:entry>
</info:roles>
<info:languages>en</info:languages>
<sphere value="work"/>
<allow-refer-users-dynamically>true\\
</allow-refer-users-dynamically>
<allow-invite-users-dynamically>true\\
</allow-invite-users-dynamically>
<allow-remove-users-dynamically>true\\
</allow-remove-users-dynamically>
<!--
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>
<!--
MEDIA
-->
<info:media id="1">
<info:label>10235</info:label>
<info:src-id>432424</info:src-id>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>10234</info:label>
<info:src-id>532535</info:src-id>
<info:status>sendrecv</info:status>
</info:media>
<!--
CALL INFO
-->
<info:call-info>
<info:sip>
Novo, et al. Expires January 11, 2007 [Page 50]
Internet-Draft Common Conference Schema July 2006
<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>
<provide-anonymity>false</provide-anonymity>
<info:roles>
</info:entry>administrator</info:entry>
</info:roles>
<info:languages>en</info:languages>
<sphere value="work"/>
<allow-refer-users-dynamically>true\\
</allow-refer-users-dynamically>
<allow-invite-users-dynamically>true\\
</allow-invite-users-dynamically>
<allow-remove-users-dynamically>true\\
</allow-remove-users-dynamically>
<!--
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>
<!--
MEDIA
-->
<info:media id="1">
<info:label>10235</info:label>
Novo, et al. Expires January 11, 2007 [Page 51]
Internet-Draft Common Conference Schema July 2006
<info:src-id>432424</info:src-id>
<info:status>sendrecv</info:status>
</info:media>
<info:media id="2">
<info:label>10234</info:label>
<info:src-id>532535</info:src-id>
<info:status>sendrecv</info:status>
</info:media>
<!--
CALL INFO
-->
<info:call-info>
<info:sip>
<info:display-text>full info</info:display-text>
<info:call-id>wevb12562321894</info:call-id>
<info:from-tag>asw456wedf</info:from-tag>
<info:to-tag>2365dfrt3497</info:to-tag>
</info:sip>
</info:call-info>
</info:endpoint>
</info:user>
</users>
<!--
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 VALUE
-->
<info:sidebars-by-val>
<info:entry entity="sips:conference@example.com;grid=40">
<info:users>
<info:user entity="sip:bob@example.com"/>
<info:user entity="sip:carol@example.com"/>
</info:users>
</info:entry>
</info:sidebars-by-val>
</info:conference-info>
Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters. Two backslash
Novo, et al. Expires January 11, 2007 [Page 52]
Internet-Draft Common Conference Schema July 2006
characters mark where the lines folding has taken place. These
backslash would not appear in the actual XML data model.
7. Security Considerations
A malicious user can manipulate parts of the Conference Information
Data Model privileges document giving themselves and others
privileges to manipulate the data model. It is very important that
only authorized clients are able to manipulate the Conference
Information Data Model document. Any conference control protocol
MUST provide authentication, confidentiality and integrity.
8. IANA Considerations
9. Acknowledgements
This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. I
would like to thanks Orit Levin, Adam Roach, Mary Barnes, Chris
Boulton, Umesh Chandra, Orit Levin, and Jari Urpilainen for their
comments. Also, I would like to thanks Hisham Khartabil, Petri
Koskelainen, and Aki Niemi to let us use the policy information of
their cpcp drafts in this document.
10. References
10.1. Normative References
[1] Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing", draft-barnes-xcon-framework-02 (work
in progress), February 2005.
[2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.
[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",
draft-ietf-sipping-conferencing-framework-05 (work in progress),
Novo, et al. Expires January 11, 2007 [Page 53]
Internet-Draft Common Conference Schema July 2006
May 2005.
[5] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium
FirstEdition http://www.w3.org/TR/2000/REC-xml-20001006,
October 2000.
[6] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
10.2. Informative References
[7] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-06 (work in progress), December 2005.
[8] Levin, O., "Centralized Conference Control Protocol",
draft-levin-xcon-cccp-04 (work in progress), January 2006.
[9] Schulzrinne, H., "Common Policy: An XML Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-10 (work in progress),
May 2006.
[10] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-mmusic-sdp-bfcp-03 (work in progress),
December 2005.
Novo, et al. Expires January 11, 2007 [Page 54]
Internet-Draft Common Conference Schema July 2006
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
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
Novo, et al. Expires January 11, 2007 [Page 55]
Internet-Draft Common Conference Schema July 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Novo, et al. Expires January 11, 2007 [Page 56]
