XCON O. Novo
Internet-Draft G. Camarillo
Expires: March 29, 2006 Ericsson
D. Morgan
Fidelity Investments
September 25, 2005
A Common Conference Information Data Model for Centralized Conferencing
(XCON)
draft-novo-xcon-common-data-model-00.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 March 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document collects, organizes, and describes the conference
variables that have been introduced in various protocol drafts of the
XCON and SIPPING working groups. The goal of this document is to
allow the conference control protocols to use a unified common
conference information data model for XCON. This document formally
Novo, et al. Expires March 29, 2006 [Page 1]
Internet-Draft Common Conference Schema September 2005
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Common Conference Data . . . . . . . . . . . . . . . . . . . . 3
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. <conference-description> . . . . . . . . . . . . . . . . . 9
3.2.1. <conference-time> . . . . . . . . . . . . . . . . . . 10
3.2.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 10
3.2.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 10
3.2.5. <available-media> . . . . . . . . . . . . . . . . . . 10
3.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 11
3.5. <security-mechanism> . . . . . . . . . . . . . . . . . . . 11
3.6. <floor-information> . . . . . . . . . . . . . . . . . . . 11
3.7. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7.1. <dial-out-list> . . . . . . . . . . . . . . . . . . . 12
3.7.2. <refer-list> . . . . . . . . . . . . . . . . . . . . . 12
3.7.3. <privileges-control-list> . . . . . . . . . . . . . . 12
3.7.3.1. <data-access-rights> . . . . . . . . . . . . . . . 12
3.7.3.2. <conference-rules> . . . . . . . . . . . . . . . . 13
3.7.3.2.1. <condition> . . . . . . . . . . . . . . . . . 13
3.7.3.2.2. <actions> . . . . . . . . . . . . . . . . . . 14
3.7.4. <user> . . . . . . . . . . . . . . . . . . . . . . . . 14
3.8. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 15
3.9. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 15
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 16
6. XML example . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Novo, et al. Expires March 29, 2006 [Page 2]
Internet-Draft Common Conference Schema September 2005
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 two sections: the "Common Conference
Information" section and the "Conference Template" section. The
common conference information section 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.
[Editors Note: This document is still in early stages of development
and is intended to trigger discussions. It is not intended to
provide a complete schema description at this stage, but rather
explore a potential schema to accommodate the proposals made so far.]
This document has been constructed in compliance with the XCON
Framework [1] and the Session Initiation Protocol (SIP) Event Package
for Conference State [5]. It also incorporates data elements
proposed in several XCON WG and SIPPING WG drafts.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
This document uses the terminology defined in the XCON Conferencing
Framework [1] and the SIPPING Conferencing Framework [3]. In
addition, it uses definitions from The Binary Floor Control Protocol
[6].
3. Common Conference Data
Novo, et al. Expires March 29, 2006 [Page 3]
Internet-Draft Common Conference Schema September 2005
3.1. General
The conference object data model document is an XML [4] document that
MUST be well formed and SHOULD be valid. Conference object data
model documents MUST be based on XML 1.0 and SHOULD be encoded using
UTF-8.
A 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 URI that
identifies the conference being described in the document. The
<conference-info> element has the <version> element. This attribute
is explained in section 5 of this draft.
The <conference-info> element is comprised of <conference-
description>, <host-info>, <conference-state>, <security-mechanism>,
<Floor Information>, <users>, <sidebars-by-ref> and <sidebars-by-val>
child elements. A common conference document must at least include
the <conference-description>, <host-info>, <conference-state> and
<users> child elements. Some of this information can be represented
using the conference-info-type schema as defined in [5].
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 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>
|--!*<version>
|
|--!<conference-description>
| |--<display-text>
| |--<subject>
| |--<free-text>
| |--<keywords>
| |--<web-page>
| |--<security-level>
| |--<allow-sidebars>
| |--<conference-time>
| | |--<entry>
| | | |--*<recurrence>
Novo, et al. Expires March 29, 2006 [Page 4]
Internet-Draft Common Conference Schema September 2005
| | | |--<mixing-start-time>
| | | |--<mixing-stop-time>
| | | |--<can-join-after>
| | | |--<must-join-before>
| | | |--<request-user>
| | ...
| |--<conf-uris>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | ...
| |--<service-uris>
| | |--<entry>
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | ...
| |--<maximum-user-count>
| | |--<entry>
| | | |--<count>
| | |--<entry>
| | | |--<count>
| | ...
| |--!<available-media>
| | |--!<entry>
| | | |--<type>
| | | |--<display-text>
| | | |--<status>
| | | |--<codecs>
| | | | |--<entry>
| | | | |--<entry>
| | | | ...
| | |--<entry>
| | | |--<type>
| | | |--<display-text>
| | | |--<status>
| | | |--<codecs>
| | | | |--<entry>
| | | | |--<entry>
| | | | ...
| | ...
|
|--!<host-info>
Novo, et al. Expires March 29, 2006 [Page 5]
Internet-Draft Common Conference Schema September 2005
| |--<display-text>
| |--<web-page>
| |--!<uris>
| | |--!<entry>
| | | |--!<uri>
| | | |--<description>
| | |--<entry>
| | | |--<uri>
| | | |--<description>
| ...
|--!<conference-state>
| |--<allow-conference-state>
| |--<user-count>
| |--!<active>
| |--<locked>
|
|--<security-mechanism>
| |--<entry-protocol>
| | |--<methods>
| | | |--<method>
| | | ...
| | |--<option-tags>
| | | |--<option-tag>
| | | ...
| | |--<feature-tags>
| | | |--<feature-tag>
| | | ...
| | |--<bodies>
| | | |--<body-disposition>
| | | | |--<body-format>
| | | ...
| ...
|
|--<floor-information>
| |--<allow-floor-events>
| |--<floor-request-handling>
| |--<conference-floor-policy>
| | |--<floor>
| | | |--<media-types>
| | | |--<algorithm>
| | | |--<max-floor-users>
| | | |--<moderator-uri>
| | ...
|
|--!<users>
| |--<join-handling>
| |--<dial-out-list>
| | |--<target>
Novo, et al. Expires March 29, 2006 [Page 6]
Internet-Draft Common Conference Schema September 2005
| | |-- ...
| | |--<external>
| | |-- ...
| |
| |--<refer-list>
| | |--<target>
| | |-- ...
| | |--<external>
| | |-- ...
| |
| |--<privileges-control-list>
| | |--<data-access-rights>
| | | |--<display-text>
| | | |--<conference-description>
| | | |--<display-text>
| | | |--<conference-time>
| | | ...
| | | |--<sidebars-by-ref>
| | | |--<sidebars-by-val>
| | | |--<conference-time>
| | | |--<mixing-start-time>
| | | |--<user>
| | |
| | |--<conference-rules>
| | | |--<entry>
| | | | |--<condition>
| | | | | |--<identity>
| | | | | | |
| | | | | | ...
| | | | | |
| | | | | |--<validity>
| | | | | | |--<from>
| | | | | | |--<until>
| | | | |
| | | | |--<actions>
| | | | | |
| | | | | ...
| | | ...
| |
| |--!<user>
| | |--<display-text>
| | |--<associated-aors>
| | |--<roles>
| | | |--<provide-anonymity>
| | | ...
| | |--<languages>
| | |--<cascaded-focus>
| | |--<authorization-mechanism>
Novo, et al. Expires March 29, 2006 [Page 7]
Internet-Draft Common Conference Schema September 2005
| | |--<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>
| | | | | |--<label>
| | | | | |--<src-id>
| | | | | |--<status>
| | | | ...
| | | |--<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>
| | |--<conference-time>
| | | |-- <entry>
| | | | |--<mixing-start-time>
| | | | |--<mixing-stop-time>
| | | | |--<can-join-after>
| | | | |--<must-join-before>
| | | | |--<request-user>
| | | ...
| | |--<users>
Novo, et al. Expires March 29, 2006 [Page 8]
Internet-Draft Common Conference Schema September 2005
| | | |-- <user>
| | | |-- <user>
| | | ...
| |--<entry>
| | |--<conference-time>
| | | |--<entry>
| | | | |--<mixing-start-time>
| | | | |--<mixing-stop-time>
| | | | |--<can-join-after>
| | | | |--<must-join-before>
| | | | |--<request-user>
| | | ...
| | |--<users>
| | | |--<user>
| | | |--<user>
| | | |--<user>
| ... ...
The following sections describe these elements in detail. The full
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 [4]. It is comprised of <display-text>, <subject>, <free-
text>, <keywords>, <web-page>, <security-level>, <allow-sidebars>,
<conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>,
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 [5].
The child element <web-page> is an optional element that points to a
URI with additional information about the conference. These elements
are described in [7]. The child elements <security-level> and
<allow-sidebars> describe the capabilities of the conference. These
elements are described in [7].
The <conference-time> child element has information related to
conference time and duration of the conference. The <conf-uris> and
<service-uris> are used to describe the conference-related URIs. The
<maximum-user-count> child element indicates the number of users that
can be invited to the conference. The <available-media> child
element is used to describe the media characteristics of the
Novo, et al. Expires March 29, 2006 [Page 9]
Internet-Draft Common Conference Schema September 2005
conference.
The following sections describe the remaining elements in more
detail. Other child elements can be used to extend <conference-
description> in the future.
3.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-time>, <mixing-stop-
time>, <can-join-after>, <must-join-before>, and <request-user>.
These elements are explained in section 4.3.3 of [7].
The <entry> element also contains the <recurrence> child element.
This element MAY be used if a conference is scheduled or active at
multiple time. It is envisioned that this element be populated by
ical.
3.2.2. <conf-uris>
The <conf-uris> contains the URI to be used in order to access the
conference by different signaling means. It contains a sequence of
<entry> child elements, each containing <uri>, <display-text>, and
<purpose>. These elements are described in [5].
3.2.3. <service-uris>
The <service-uris> describes auxiliary services available for the
conference. It contains a sequence of <entry> child elements, each
containing <uri>, <display-text>, and <purpose>. These elements are
described in [5].
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 <count> sub-element
that provides the number of users with a specific role allowed to
join the conference.
3.2.5. <available-media>
The <available-media> has the 'label' attribute that is the media
stream identifier assigned by the conferencing server. This element
Novo, et al. Expires March 29, 2006 [Page 10]
Internet-Draft Common Conference Schema September 2005
contains a sequence of <entry> child elements of conference-medium-
type. Each <entry> element contains the <type>, <display-text>,
<status>, and <codecs> child elements. The attribute 'label' and the
<type>, <display-text>, and <status> elements are described in [5].
The <codecs> element has a child element as explain in section 7.1.1
of [8].
3.3. <host-info>
The <host-info> element contains information about the entity hosting
the conference. It contains the <display-text>, <web-page>, and
<uris> child elements. These child elements are explained in [5].
3.4. <conference-state>
The <conference-state> element and the <user-count>, <active>, and
<locked> child element are explained in section 5.5 of [5]. The
<allow-conference-state> is described in section 4.3.7.2 of [7].
3.5. <security-mechanism>
The <security-mechanism> element has a single mandatory attribute,
'name'. The 'name' attribute identifies a protocol the policy of
each protocol element is referring to. It contains a series of
<entry-protocol> sub-elements. Each <entry-protocol> sub-element
contains the policy related to the usage of a particular protocol.
[Editors Note: The <security-mechanism> element only has defined the
feature for the SIP protocol. Discussion about other protocols
(PSTN, HTML, Jabber, H.323, etc...) are in the XCON WG mailing list.]
The <entry-protocol> element has a series of child elements: methods,
option-tags, feature-tags, and bodies. These elements are described
in sections 6.1, 6.2,6.3, and 6.4 of [8].
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. The <conference-floor-policy> element,
its attributes, and the <conference-floor-policy> child element are
described in Section 18.8 of [9]. The <allow-floor-events>, and
<floor-request-handling> are described in section 4.3.7.2 of [7].
This draft extends the <conference-floor-policy> element with a new
attribute 'label'. The 'label' attribute identifies the media that
the floor is controlling.
Novo, et al. Expires March 29, 2006 [Page 11]
Internet-Draft Common Conference Schema September 2005
3.7. <users>
The <users> element contains the <join-handling>, <dial-out-list>,
<refer-list>, <privileges-control-list> and <user> child elements.
The <join-handling> element is described in section 4.3.7.2 of [7].
The following sections describe the remaining elements in more
detail. Other child elements can be used to extend <conference-
description> in the future.
3.7.1. <dial-out-list>
The <dial-out-list> child element contains a list of user URIs, a
role, or domain (*@example.com) that the focus uses to determine who
to invite to join a conference. The <dial-out-list> element includes
zero or more <target> child element and zero or more <external> child
element. Those two child elements includes the mandatory 'uri'
attribute. The use of the <external> and <target> elements are
described in section 4.3.4 of [7].
3.7.2. <refer-list>
The <refer-list> child element contains a list of resources that the
focus needs to refer to the conference. The <refer-list> is
identical to the <dial-out-list> element and is described in section
4.3.5 of [7].
3.7.3. <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.3.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 elements defined in the Conference Object. Every element has two
attributes: the attribute '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 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
Novo, et al. Expires March 29, 2006 [Page 12]
Internet-Draft Common Conference Schema September 2005
'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.3.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. It is partially described in [7]
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.3.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 is already defined in Section 7.1 of [10].
This draft explains the <id>, <domain>, <any-identity> and <except>
child elements of the <identity> element and gives some examples.
The absence of the <identity> element in a <condition> element
indicates that the privilege applies to all unauthenticated
identities.
Other child elements of the <identity> element defined in [7] are the
<external-list> (Section 4.3.7.1.4.2), <pseudonymous> (Section
4.3.7.1.5), <has-been-referred> (Section 4.3.7.1.6), <has-been-
invited> (Section 4.3.7.1.7), <has-been-in-conference> (Section
4.3.7.1.8), <is-in-conference> (Section 4.3.7.1.9), <key-participant>
(Section 4.3.7.1.10), <is-on-dialout-list> (Section 4.3.7.1.11), <is-
on-refer-list> (Section 4.3.7.1.12), <floor-id> (Section 4.3.7.1.13),
<participant-passcode> (Section 4.3.7.1.14), and <key-participant-
passcode> (Section 4.3.7.1.15) child elements.
The <validity> element expresses the validity period of the rule with
Novo, et al. Expires March 29, 2006 [Page 13]
Internet-Draft Common Conference Schema September 2005
a starting and a ending time. The <validity> element and its child
elements ,<from> and <until>, are defined in section 7.3 of [10].
3.7.3.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 defined in [7]:
<allow-refer-users-dynamically> defined in section 4.3.7.2.4, <allow-
invite-users-dynamically> defined in section 4.3.7.2.5, <allow-
remove-users-dynamically> defined in section 4.3.7.2.6, <show-floor-
holder> defined in section 4.3.7.3.4, <show-floor-requests> defined
in section 4.3.7.3.5, <provide-anonymity> defined in section
4.3.7.3.6,
There are defined the following operations as well in this document:
<read-write>
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.
<read-only>
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.4. <user>
The element <user> describes a single participant in the conference.
The following elements as well as the attributes of <user> are
defined in [5], section 5.6: <display-text>, <associated-aors>,
<roles>, <languages>, <cascaded-focus>, <endpoint>, <display-text>,
<referred>, <status>, <joining-method>, <joining-info>,
<disconnection-method>, <disconnection-info>, <media>, <label>,
<src-id>, <call-info>, <display-text>, <call-id>, <to-tag>, <from-
tag>.
Note that the <media> child element of the <endpoint> does not have
the child elements <display-text> and <type> as is defined in [5].
This elements are not included in <media> because they are already
defined in the <available-media> element.
Novo, et al. Expires March 29, 2006 [Page 14]
Internet-Draft Common Conference Schema September 2005
The <provide-anonymity> is a child element of <roles> and provides
anonymity to a specific identity. It is defined in 4.3.7.3.6 of [7].
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 <authorization-mechanism> element defines how the participants
should be authenticated. It can also be set to none. The password
associated with each user in the Digest authentication is included in
the optional 'Password' attribute. This attribute is ignored if
authentication is set to "none". This element is defined in [9].
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 [10].
The <allow-refer-users-dynamically>, <allow-invite-users-dynamically>
and <allow-remove-users-dynamically> elements are defined in section
4.3.7.2 of [7].
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. They are described in section 4.3.7.3 of
[7]. The <entry> child elements is represent by the 'id' attribute,
each of which identifies a floor inside the conference.
[Editors Note: The <call-info> element only has defined the <sip>
child element. Discussion about other sub elements (PSTN, HTML,
Jabber, H.323, etc...) in the XCON WG mailing list.]
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 URI and a <display-text> child element.
The <sidebars-by-ref> element is described in Section 5.9.1 of [5].
Notice that the <sidebars-by-ref> child element does not include the
attribute 'state' defined in [5].
3.9. <sidebars-by-val>
The <sidebars-by-val> element contains a set of <entry> child
elements each containing information about a single sidebar. Each
<entry> has the OPTIONAL <conference-time> child element and the
<users> child elements. The <conference-time> child element has
information related to conference time and duration of the
Novo, et al. Expires March 29, 2006 [Page 15]
Internet-Draft Common Conference Schema September 2005
conference. The <conference-time> child element SHOULD fall within
the timeframe of the conference. This element is explained in the
section 3.2.1 of this draft. Notice the <recurrence> element is not
defined in the <conference-time> child elements of the <sidebars-by-
val> element.
Notice as well that the <sidebars-by-val> and the <entry> child
element do not include the attribute 'state' defined in [5].
The <users> child element contains a set of <user> elements each
containing a sidebar conference URI. The <sidebars-by-val> element
is described in Section 5.9.2 of [5].
4. XML Schema
In accordance with the XCON framework document [1], the Conference
Object is a logical representation of a conference instance. It is
separated into two XML schemas, the common conference information
schema and the conference template schema. The common conference
information schema, called common-conference-schema.xsd contains core
information that is utilized in any conference. The conference
template schema contains the variable information part of the
Conference Object. The document [11] supplies a set of core media
templates that SHOULD be used in conjunction with this data model.
In this draft we have only defined the common-conference-schema.xsd.
[Editors Note: Authors are working on this and will release a new
revision of this draft with the full schema in the near future]
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
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.
A versioning procedure for this schema is provided. The <version>
element MUST be included in the root <conference-info> element. The
complete conference information, elements and attributes, are
associated with this version number. If new elements or attributes
are associated to the data model, the data model will have a higher
version number according with the new elements defined.
Novo, et al. Expires March 29, 2006 [Page 16]
Internet-Draft Common Conference Schema September 2005
Elements or attributes from unknown namespaces MUST be ignored.
The common conference information schema as is defined in [1] MUST
include an extension point to allow new templates to hook into the
schema and SHOULD be done using the <any namespace="##other">
construct.
6. XML example
The following is an example of a common conference information
document. 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"
entity="sips:conference@example.com">
<!--
VERSION
-->
<version>23.5.50</version>
<!--
CONFERENCE DESCRIPTION
-->
<conference-description xml:lang="en-us">
<display-text>Discussion of the best moments in Formula-1 \\
racing</display-text>
<subject> Sports:Formula-1</subject>
<free-text>This is a conference example</free-text>
<keywords>Formula-1, cars</keywords>
<web-page>http://www.example.com/users/alice/formula-1\\
</web-page>
<security-level>low</security-level>
<allow-sidebars>true</allow-sidebars>
<!--
CONFERENCE TIME
-->
<conference-time>
<entry>
<recurrence>7days</recurrence>
<mixing-start-time required-participant="moderator">
2006-10-17T09:30:00-05:00</mixing-start-time>
Novo, et al. Expires March 29, 2006 [Page 17]
Internet-Draft Common Conference Schema September 2005
<mixing-stop-time required-participant="participant">
2006-10-17T11:30:00-05:00</mixing-stop-time>
<must-join-before>2006-10-17T12:00:00-05:00</must-join-before>
</entry>
</conference-time>
<!--
CONFERENCE URIS
-->
<conf-uris>
<entry>
<uri>tel:+3585671234</uri>
<display-text>Conference Bridge</display-text>
<purpose>participation</purpose>
</entry>
<entry>
<uri>http://www.example.com/54634/live.ram</uri>
<purpose>streaming</purpose>
</entry>
</conf-uris>
<!--
SERVICE URIS
-->
<service-uris>
<entry>
<uri>http://www.example.com/formula1/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
<!--
MAXIMUM USER COUNT
-->
<maximum-user-count>
<entry role = "administrator">2</entry>
<entry role = "moderator">5</entry>
<entry role = "participant">150</entry>
</maximum-user-count>
<!--
AVAILABLE MEDIA
-->
<available-media>
<entry label="10234">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
<codecs>
<codec name="PCMU" policy="allowed"/>
</codecs>
</entry>
Novo, et al. Expires March 29, 2006 [Page 18]
Internet-Draft Common Conference Schema September 2005
<entry label="10235">
<display-text>main video</display-text>
<type>video</type>
<status>sendrecv</status>
<codecs>
<codec name="H.320" policy="allowed"/>
</codecs>
</entry>
</available-media>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Formula1</display-text>
<web-page>http://www.example.com/users/formula-1/\\
</web-page>
<uris>
<entry>
<uri>sip:alice@example.com</uri>
</entry>
<entry>
<uri>sip:carol@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<allow-conference-state>true</allow-conference-state>
<user-count>3</user-count>
<active>true</active>
<locked>false</locked>
</conference-state>
<!--
SECURITY MECHANISM
-->
<security-mechanism>
<entry-protocol name="SIP">
<methods default-policy="allowed">
<method name="MESSAGE" policy="disallowed"/>
</methods>
<option-tags default-policy="disallowed">
<option-tag name="100rel" policy="mandatory"/>
<option-tag name="preconditions" policy="allowed"/>
</option-tags>
<feature-tags default-policy="disallowed">
Novo, et al. Expires March 29, 2006 [Page 19]
Internet-Draft Common Conference Schema September 2005
<feature-tag name="video" policy="allowed"/>
</feature-tags>
<bodies default-policy="allowed" \\
default-encryption="allowed">
<body-disposition name="session" policy="allowed" \\
encryption="disallowed" default-policy="disallowed">
<body-format name="application/sdp" policy="allowed"/>
</body-disposition>
</bodies>
</entry-protocol>
</security-mechanism>
<!--
FLOOR INFORMATION
-->
<floor-information>
<allow-floor-events>true</allow-floor-events>
<floor-request-handling>true</floor-request-handling>
<conference-floor-policy>
<floor moderator-controlled="true" label="10234">
<media-types>audio</media-types>
<algorithm>Moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<moderator-uri>sip:alice@example.com</moderator-uri>
</floor>
<floor moderator-controlled="true" label="10235">
<media-types>video</media-types>
<algorithm>Moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<moderator-uri>sip:carol@example.com</moderator-uri>
</floor>
</conference-floor-policy>
</floor-information>
<!--
USERS
-->
<users>
<join-handling>true</join-handling>
<!--
DIAL OUT LIST
-->
<dial-out-list>
<target uri="sip:bob@example.com"/>
<target uri="sip:alice@example.com"/>
<target uri="sip:carol@example.com"/>
</dial-out-list>
<!--
REFER LIST
-->
Novo, et al. Expires March 29, 2006 [Page 20]
Internet-Draft Common Conference Schema September 2005
<refer-list>
<target uri="sip:john@example.com"/>
</refer-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"/>
<dial-out-list read-only= "administrator"/>
<refer-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>
<identity>
<domain>example.com</domain>
</identity>
<validity>
<from>2005-09-17T10:30:00-05:00</from>
<to>2005-10-20T12:30:00-05:00</to>
</validity>
</conditions>
<actions>
<allow-conference-state>true</allow-conference-state>
</actions>
</entry>
<entry id="2">
<conditions>
<identity>
Novo, et al. Expires March 29, 2006 [Page 21]
Internet-Draft Common Conference Schema September 2005
<uri>bob@example.com</uri>
</identity>
</conditions>
<actions>
<join-handling>block</join-handling>
</actions>
</entry>
</conference-rules>
</privileges-control-list>
<!--
USER
-->
<user entity="sip:bob@example.com">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>participant</entry>
</roles>
<languages>en</languages>
<authorization-mechanism> password="1a2b3c4d">Digest\\
</authorization-mechanism>
<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>
<entry id="1">
<show-floor-holder>false</show-floor-holder>
<show-floor-requests>false</show-floor-requests>
</entry>
</floors>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@example.com">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2006-10-17T10:00:00-05:00</when>
<reason>expert required</reason>
<by>sip:alice@example.com</by>
Novo, et al. Expires March 29, 2006 [Page 22]
Internet-Draft Common Conference Schema September 2005
</referred>
<status>connected</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2006-10-17T10:00:00-05:00</when>
<reason>invitation</reason>
<by>sip:alice@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
</user>
<!--
USER
-->
<user entity="sip:alice@example.com">
<display-text>Alice Kay</display-text>
<associated-aors>
<entry>
<uri>mailto:alice@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>moderator</entry>
</roles>
<languages>en</languages>
<authorization-mechanism> password="4r2q3ed5">Digest\\
</authorization-mechanism>
<sphere value="work"/>
<allow-refer-users-dynamically>true\\
</allow-refer-users-dynamically>
Novo, et al. Expires March 29, 2006 [Page 23]
Internet-Draft Common Conference Schema September 2005
<allow-invite-users-dynamically>true\\
</allow-invite-users-dynamically>
<allow-remove-users-dynamically>true\\
</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:alice@example.com">
<display-text>Alice's Desktop</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2006-10-17T09:35:08-05:00</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>truy45469123478</call-id>
<from-tag>asd456cbgt</from-tag>
<to-tag>3456jgjg1234</to-tag>
</sip>
</call-info>
</endpoint>
</user>
<!--
USER
-->
<user entity="sip:carol@example.com">
<display-text>Carol More</display-text>
<associated-aors>
Novo, et al. Expires March 29, 2006 [Page 24]
Internet-Draft Common Conference Schema September 2005
<entry>
<uri>mailto:carol@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
</entry>administrator</entry>
</roles>
<languages>en</languages>
<authorization-mechanism> password="2asd63et">Digest\\
</authorization-mechanism>
<sphere value="work"/>
<allow-refer-users-dynamically>true\\
</allow-refer-users-dynamically>
<allow-invite-users-dynamically>true\\
</allow-invite-users-dynamically>
<allow-remove-users-dynamically>true\\
</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:carol@example.com">
<display-text>Carol's Computer</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2006-10-17T09:30:05-05:00</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
Novo, et al. Expires March 29, 2006 [Page 25]
Internet-Draft Common Conference Schema September 2005
<display-text>full info</display-text>
<call-id>wevb12562321894</call-id>
<from-tag>asw456wedf</from-tag>
<to-tag>2365dfrt3497</to-tag>
</sip>
</call-info>
</endpoint>
</user>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref>
<entry>
<uri>sips:conference@example.com;grid=40</uri>
<display-text>private with Bob</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val>
<entry entity="sips:conference@example.com;grid=40">
<users>
<user entity="sip:bob@example.com"/>
<user entity="sip:carol@example.com"/>
</users>
</entry>
</sidebars-by-val>
</conference-info>
Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters. Two backslash
character marks where this 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.
Novo, et al. Expires March 29, 2006 [Page 26]
Internet-Draft Common Conference Schema September 2005
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.
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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-05 (work in progress),
May 2005.
[4] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
FirstEdition REC-xml-20001006, October 2000.
10.2. Informative References
[5] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in progress),
July 2005.
[6] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-camarillo-xcon-bfcp-00 (work in progress), May 2004.
[7] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[8] Camarillo, G., "A Session Initiation Protocol (SIP) Event
Package for Media Policy",
draft-camarillo-sipping-policy-package-00 (work in progress),
October 2003.
Novo, et al. Expires March 29, 2006 [Page 27]
Internet-Draft Common Conference Schema September 2005
[9] Koskelainen, P. and H. Khartabil, "An Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Usage for
Conference Policy Manipulation",
draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress),
February 2004.
[10] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-05 (work in
progress), July 2005.
[11] Boulton, C. and U. Chandra, "Media Policy Templates for XCON",
draft-boulton-xcon-media-template-01 (work in progress),
April 2005.
[12] Even, R., "Conferencing media policy requirements",
draft-even-sipping-media-policy-requirements-00 (work in
progress), February 2003.
[13] Mahy, R. and N. Ismail, "Media Policy Manipulation in the
Conference Policy Control Protocol",
draft-mahy-sipping-media-policy-control-00 (work in progress),
February 2003.
[14] Levin, O., "Conference Policy Control Protocol for Centralized
Conferencing", draft-levin-xcon-cpcp-00 (work in progress),
June 2003.
[15] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-mmusic-sdp-bfcp-02 (work in progress), July 2005.
[16] Khartabil, H. and A. Niemi, "Privileges for Manipulating a
Conference Policy",
draft-ietf-xcon-conference-policy-privileges-01 (work in
progress), October 2004.
Novo, et al. Expires March 29, 2006 [Page 28]
Internet-Draft Common Conference Schema September 2005
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
Novo, et al. Expires March 29, 2006 [Page 29]
Internet-Draft Common Conference Schema September 2005
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 (2005). 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 March 29, 2006 [Page 30]