draft-ietf-xcon-common-data-model-32.txt   rfc6501.txt 
XCON O. Novo Internet Engineering Task Force (IETF) O. Novo
Internet-Draft G. Camarillo Request for Comments: 6501 G. Camarillo
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: March 23, 2012 D. Morgan ISSN: 2070-1721 D. Morgan
Fidelity Investments Fidelity Investments
J. Urpalainen J. Urpalainen
Nokia Nokia
Sep 20, 2011 March 2012
Conference Information Data Model for Centralized Conferencing (XCON) Conference Information Data Model
draft-ietf-xcon-common-data-model-32.txt for Centralized Conferencing (XCON)
Abstract Abstract
RFC5239 defines the idea of a centralized conferencing (XCON) as an RFC 5239 defines centralized conferencing (XCON) as an association of
association of participants with a central focus. The state of a participants with a central focus. The state of a conference is
conference is represented by a conference object. This document represented by a conference object. This document defines an XML-
defines an Extensible Markup Language (XML)-based conference based conference information data model to be used for conference
information data model to be used for conference objects. A objects. A conference information data model is designed to convey
conference information data model is designed to convey information information about the conference and about participation in the
about the conference and about participation in the conference. The conference. The conference information data model defined in this
conference information data model defined in this document document constitutes an extension of the data format specified in the
constitutes an extension of the data format specified in the Session Session Initiation Protocol (SIP) event package for conference State.
Initiation Protocol (SIP) Event Package for Conference State.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 23, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6501.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview ........................................................4
3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 6 3.1. Data Model Format ..........................................5
3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 6 3.2. Data Model Namespace .......................................5
3.3. The Conference Object Identifier . . . . . . . . . . . . . 6 3.3. The Conference Object Identifier ...........................5
3.3.1. Conference Object URI Definition . . . . . . . . . . . 8 3.3.1. Conference Object URI Definition ....................7
3.3.2. Normalization and Conference Object URI Comparison . . 8 3.3.2. Normalization and Conference Object URI Comparison ..7
3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 8 3.4. Data Model Structure .......................................7
4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 9 4. Data Model Definition ...........................................8
4.1. <conference-info> . . . . . . . . . . . . . . . . . . . . 13 4.1. <conference-info> .........................................12
4.2. <conference-description> . . . . . . . . . . . . . . . . . 13 4.2. <conference-description> ..................................12
4.2.1. <language> . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. <language> .........................................13
4.2.2. <allow-sidebars> . . . . . . . . . . . . . . . . . . . 14 4.2.2. <allow-sidebars> ...................................13
4.2.3. <cloning-parent> . . . . . . . . . . . . . . . . . . . 14 4.2.3. <cloning-parent> ...................................13
4.2.4. <sidebar-parent> . . . . . . . . . . . . . . . . . . . 14 4.2.4. <sidebar-parent> ...................................13
4.2.5. <conference-time> . . . . . . . . . . . . . . . . . . 14 4.2.5. <conference-time> ..................................13
4.2.6. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 16 4.2.6. <conf-uris> ........................................15
4.2.7. <available-media> . . . . . . . . . . . . . . . . . . 16 4.2.7. <available-media> ..................................15
4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 19 4.3. <host-info> ...............................................18
4.4.1. <allow-conference-event-subscription> . . . . . . . . 19 4.4. <conference-state> ........................................18
4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 19 4.4.1. <allow-conference-event-subscription> ..............18
4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 19 4.5. <floor-information> .......................................18
4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 20 4.5.1. <conference-ID> ....................................19
4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 20 4.5.2. <allow-floor-events> ...............................19
4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 20 4.5.3. <floor-request-handling> ...........................19
4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.4. <conference-floor-policy> ..........................20
4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 21 4.6. <users> ...................................................20
4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 22 4.6.1. <join-handling> ....................................21
4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 23 4.6.2. <user-admission-policy> ............................21
4.6.4. <deny-users-list> . . . . . . . . . . . . . . . . . . 24 4.6.3. <allowed-users-list> ...............................22
4.6.5. <user> and Its <user> Sub-elements . . . . . . . . . . 24 4.6.4. <deny-users-list> ..................................23
4.6.5.1. <provide-anonymity> . . . . . . . . . . . . . . . 26 4.6.5. <user> and Its <user> Sub-Elements .................24
4.6.5.2. <roles> . . . . . . . . . . . . . . . . . . . . . 26 4.6.5.1. <provide-anonymity> .......................25
4.6.5.3. <allow-refer-users-dynamically> . . . . . . . . . 26 4.6.5.2. <roles> ...................................26
4.6.5.4. <allow-invite-users-dynamically> . . . . . . . . . 26 4.6.5.3. <allow-refer-users-dynamically> ...........26
4.6.5.5. <allow-remove-users-dynamically> . . . . . . . . . 27 4.6.5.4. <allow-invite-users-dynamically> ..........26
4.6.5.6. <endpoint> . . . . . . . . . . . . . . . . . . . . 27 4.6.5.5. <allow-remove-users-dynamically> ..........26
4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 28 4.6.5.6. <endpoint> ................................27
4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 28 4.7. <sidebars-by-ref> .........................................28
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 29 4.8. <sidebars-by-val> .........................................28
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 39 5. RELAX NG Schema ................................................28
7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 40 6. XML Schema Extensibility .......................................39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 7. XML Example ....................................................39
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 8. Security Considerations ........................................49
9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 51 9. IANA Considerations ............................................51
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 51 9.1. RELAX NG Schema Registration ..............................51
9.3. Conference Object Identifier Registration . . . . . . . . 52 9.2. XML Namespace Registration ................................52
9.4. Conference User Identifier Registration . . . . . . . . . 53 9.3. Conference Object Identifier Registration .................52
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 9.4. Conference User Identifier Registration ...................53
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 10. Acknowledgements ..............................................53
11.1. Normative References . . . . . . . . . . . . . . . . . . . 54 11. References ....................................................53
11.2. Informative References . . . . . . . . . . . . . . . . . . 55 11.1. Normative References .....................................53
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 55 11.2. Informative References ...................................54
Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 83 Appendix A. Non-Normative RELAX NG Schema in XML Syntax ..........56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 Appendix B. Non-Normative W3C XML Schema .........................84
1. Introduction 1. Introduction
There is a core data set of conference information that is utilized There is a core data set of conference information that is utilized
in any conference, independent of the specific conference media. in any conference, independent of the specific conference media.
This core data set called the 'conference information data model' is This core data set, called the "conference information data model",
defined in this document using an Extensible Markup Language (XML)- is defined in this document using an XML-based format. The
based format. The conference information data model defined in this conference information data model defined in this document is
document is logically represented by the conference object. logically represented by the conference object.
Conference objects are a fundamental concept in Centralized Conference objects are a fundamental concept in centralized
Conferencing, as described in the Centralized Conferencing Framework conferencing, as described in the centralized conferencing framework
[RFC5239]. The conference object represents a particular [RFC5239]. The conference object represents a particular
instantiation of a conference information data model. Consequently, instantiation of a conference information data model. Consequently,
conference objects use the XML format defined in this document. conference objects use the XML format defined in this document.
The Session Initiation Protocol (SIP) Event Package for Conference The Session Initiation Protocol (SIP) event package for conference
State, specified in [RFC4575], already defines a data format for state, specified in [RFC4575], already defines a data format for
conferences. However, that model is SIP specific and lacks elements conferences. However, that model is SIP specific and lacks elements
related to some of the functionality defined by the Centralized related to some of the functionality defined by the centralized
Conferencing Framework [RFC5239] (e.g., floor control). The data conferencing framework [RFC5239] (e.g., floor control). The data
model defined in this document constitutes a superset of the data model defined in this document constitutes a superset of the data
format defined in [RFC4575]. The result is a data format that format defined in [RFC4575]. The result is a data format that
supports more call signaling protocols besides SIP and that covers supports more call signaling protocols (CSPs) besides SIP and that
all the functionality defined in the Centralized Conferencing covers all the functionality defined in the centralized conferencing
Framework [RFC5239]. framework [RFC5239].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the terminology defined in the Centralized This document uses the terminology defined in the centralized
Conferencing Framework [RFC5239], the SIPPING conferencing framework conferencing framework [RFC5239], the SIPPING conferencing framework
[RFC4353] and the BFCP (Binary Floor Control Protocol) specification [RFC4353], and the BFCP (Binary Floor Control Protocol) specification
[RFC4582]. Readers of this document should be familiar with the [RFC4582]. Readers of this document should be familiar with the
terminology used in those documents. terminology used in those documents.
3. Overview 3. Overview
The data model specified in this document is the result of extending The data model specified in this document is the result of extending
the data format defined in [RFC4575] with new elements. Examples of the data format defined in [RFC4575] with new elements. Examples of
such extensions include scheduling elements, media control elements, such extensions include scheduling elements, media control elements,
floor control elements, non-SIP URIs, and addition of localization floor control elements, non-SIP URIs, and the addition of
extensions to text elements. This data model can be used by localization extensions to text elements. This data model can be
conference servers providing different types of basic conferences. used by conference servers providing different types of basic
conferences. It is expected that this data model can be further
It is expected that this data model can be further extended with new extended with new elements in the future in order to implement
elements in the future in order to implement additional advanced additional advanced features.
features.
3.1. Data Model Format 3.1. Data Model Format
A conference object document is an XML [W3C.REC-xml-20081126] A conference object document is an XML [W3C.REC-xml-20081126]
document. Conference object documents MUST be based on Extensible document. Conference object documents MUST be based on XML 1.0 and
Markup Language (XML) 1.0 and MUST be encoded using UTF-8. MUST be encoded using UTF-8.
The normative description of the syntax of the conference object The normative description of the syntax of the conference object
document, for use by implementors of parsers and generators, is found document, for use by implementers of parsers and generators, is found
in the RelaxNG schema provided in Section 5. Compliant messages MUST in the RELAX NG schema provided in Section 5. Compliant messages
meet the requirements of that schema. MUST meet the requirements of that schema.
3.2. Data Model Namespace 3.2. Data Model Namespace
This specification defines a new namespace specification for This specification defines a new namespace specification for
identifying the elements defined in the data model. This namespace identifying the elements defined in the data model. This namespace
is as follows: is as follows:
urn:ietf:params:xml:ns:xcon-conference-info urn:ietf:params:xml:ns:xcon-conference-info
3.3. The Conference Object Identifier 3.3. The Conference Object Identifier
The conference object identifier (XCON-URI) can be viewed as a key to The conference object identifier (XCON-URI) can be viewed as a key to
accessing a specific conference object. It can be used, for accessing a specific conference object. It can be used, for
instance, by the conference control protocol to access, manipulate instance, by the conference control protocol to access, manipulate
and delete a conference object. A conference object identifier is and delete a conference object. A conference object identifier is
provided to the conferencing client by the conference notification provided to the conferencing client by the conference notification
service or through out-of-band mechanisms (e.g. E-Mail). service or through out-of-band mechanisms (e.g., email).
A conferencing system may maintain a relationship between the A conferencing system may maintain a relationship between the
conference object identifiers and the identifiers associated with conference object identifiers and the identifiers associated with
each of the complementary centralized conferencing protocols (e.g., each of the complementary centralized conferencing protocols (e.g.,
call signaling protocols, BFCP, etc.). To facilitate the maintenance call signaling protocol, BFCP, etc.). To facilitate the maintenance
of these relationships, the conference object identifier acts as a of these relationships, the conference object identifier acts as a
top level identifier within the conferencing system for the purpose top-level identifier within the conferencing system for the purpose
of identifying the interfaces for these other protocols. This of identifying the interfaces for these other protocols. This
implicit binding provides a structured mapping of the various implicit binding provides a structured mapping of the various
protocols with the associated conference object Identifier. Figure 1 protocols with the associated conference object identifier. Figure 1
illustrates the relationship between the identifiers used for the illustrates the relationship between the identifiers used for the
protocols and the general conference object identifier (XCON-URI). protocols and the general conference object identifier (XCON-URI).
+--------------------------+ +--------------------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+--------------------------+ +--------------------------+
| xcon:Ji092i@example.com | | xcon:Ji092i@example.com |
+------+-------------------+ +------+-------------------+
skipping to change at page 7, line 32 skipping to change at page 6, line 32
| sip:i092@example.com | | | sip:i092@example.com | |
+-----------------------+ +-------+--------+ +-----------------------+ +-------+--------+
| BFCP 'Floor ID'| | BFCP 'Floor ID'|
+----------------+ +----------------+
| 543 | | 543 |
| 236 | | 236 |
+----------------+ +----------------+
Figure 1: Conference Object Mapping Figure 1: Conference Object Mapping
In Figure 1, the conference object identifier acts as the top level In Figure 1, the conference object identifier acts as the top-level
key in the identification process. The call signaling protocols have key in the identification process. The call signaling protocols have
an associated conference user identifier, often represented in the an associated conference user identifier, often represented in the
form of URIs. The binary floor control protocol, as defined in form of a URI. The BFCP, as defined in [RFC4582], defines the
[RFC4582], defines the 'conference ID' identifier which represents a 'conference ID' identifier which represents a conference instance
conference instance within floor control. When created within the within floor control. When created within the conferencing system,
conferencing system, the 'conference ID' has a 1:1 mapping to the the 'conference ID' has a 1:1 mapping to the unique conference object
unique conference object Identifier(XCON-URI). Operations associated identifier(XCON-URI). Operations associated with the conference
with the conference control protocols are directly associated with control protocols are directly associated with the conference object;
the conference object, thus the primary identifier associated with thus, the primary identifier associated with these protocols is the
these protocols is the conference object identifier(XCON-URI). The conference object identifier(XCON-URI). The mappings between
mappings between additional protocols/interface is not strictly 1:1 additional protocols/interfaces is not strictly 1:1 and does allow
and does allow for multiple occurrences. For example, multiple call for multiple occurrences. For example, multiple call signaling
signaling protocols will each have a representation that is protocols will each have a representation that is implicitly linked
implicitly linked to the top level conference object identifier e.g. to the top-level conference object identifier, e.g., H323 and SIP
H323 and SIP URIs that represent a conference instance. It should be URIs that represent a conference instance. It should be noted that a
noted that a conferencing system is free to structure such conferencing system is free to structure such relationships as
relationships as required and this information is just included as a required, and this information is just included as a guideline that
guideline that can be used. can be used.
Further elements can be added to the tree representation in Figure 1 Further elements can be added to the tree representation in Figure 1
to enable a complete representation of a conference instance within a to enable a complete representation of a conference instance within a
conferencing system. conferencing system.
3.3.1. Conference Object URI Definition 3.3.1. Conference Object URI Definition
XCON-URI = "xcon" ":" [conf-object-id "@"] host The syntax is defined by the following ABNF [RFC5234] rules.
conf-object-id = 1*( unreserved / "+" / "=" / "/" ) XCON-URI = "xcon" ":" [conf-object-id "@"] host
host and unreserved are defined in RFC3986[RFC3986] conf-object-id = 1*( unreserved / "+" / "=" / "/" )
Note: host and unreserved are defined in RFC 3986 [RFC3986].
An XCON-URI is not designed to be resolved, and an application MUST An XCON-URI is not designed to be resolved, and an application MUST
NOT attempt to perform a standard DNS lookup on the host portion of NOT attempt to perform a standard DNS lookup on the host portion of
such a URI in an attempt to discover an IP address or port at which such a URI in an attempt to discover an IP address or port at which
to connect. to connect.
3.3.2. Normalization and Conference Object URI Comparison 3.3.2. Normalization and Conference Object URI Comparison
In order to facilitate the comparison of the XCON-URI identifiers, In order to facilitate the comparison of the XCON-URI identifiers,
all the components of the identifiers MUST be converted to lowercase. all the components of the identifiers MUST be converted to lowercase.
After normalizing the URI strings, the URIs comparison MUST applied a After normalizing the URI strings, the URI comparison MUST be applied
character-by-character basis as prescribed by RFC3986, Section 6.2.1. on a character-by-character basis as prescribed by [RFC3986], Section
6.2.1.
The host construction, as defined in RFC3986 can take the form of an The host construction, as defined in RFC 3986, can take the form of
IP address, which is not conventionally compared on a character-by- an IP address, which is not conventionally compared on a character-
character basis. The host part of an XCON-URI serves only as an by-character basis. The host part of an XCON-URI serves only as an
identifier; that is, it is never used as an address. The character- identifier; that is, it is never used as an address. The character-
by-character comparison still applies. by-character comparison still applies.
3.4. Data Model Structure 3.4. Data Model Structure
The information in this data model is structured in the following The information in this data model is structured in the following
manner. All the information related to a conference is contained in manner. All the information related to a conference is contained in
a <conference-info> element. The <conference-info> element contains a <conference-info> element. The <conference-info> element contains
the following child elements: the following child elements:
skipping to change at page 9, line 20 skipping to change at page 8, line 20
o The <users> element describes the membership information as a o The <users> element describes the membership information as a
whole. The <users> element contains a set of <user> child whole. The <users> element contains a set of <user> child
elements, each describing a single participant in the conference. elements, each describing a single participant in the conference.
o If a participant in the main conference joins a sidebar, a new o If a participant in the main conference joins a sidebar, a new
element is created in the conference referenced from the element is created in the conference referenced from the
<sidebars-by-ref> element or under one of the <sidebars-by-val> <sidebars-by-ref> element or under one of the <sidebars-by-val>
elements. elements.
Note that some of the elements described above such <conference- Note that some of the elements described above such as <conference-
info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by- info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
val> are not defined in the data model in this specification but are val> are not defined in the data model in this specification but are
defined in the data format of [RFC4575]. We describe them here defined in the data format of [RFC4575]. We describe them here
because they are part of the basic structure of the data model. because they are part of the basic structure of the data model.
4. Data Model Definition 4. Data Model Definition
The following non-normative diagram shows the structure of conference The following non-normative diagram shows the structure of conference
object documents. The symbol "!" preceding an element indicates that object documents. The symbol "!" preceding an element indicates that
the element is REQUIRED in the data model. The symbol "*" following the element is REQUIRED in the data model. The symbol "*" following
skipping to change at page 13, line 5 skipping to change at page 12, line 4
| | | | | |--<to-tag> | | | | | |--<to-tag>
| ... ... | ... ...
|--<sidebars-by-ref> |--<sidebars-by-ref>
| |--<entry> | |--<entry>
| | |-- <user> | | |-- <user>
| | |-- <display-text> | | |-- <display-text>
| |--<entry> | |--<entry>
| | |-- <user> | | |-- <user>
| | |-- <display-text> | | |-- <display-text>
| ... | ...
|--<sidebars-by-val> |--<sidebars-by-val>
| |--<entry> | |--<entry>
| | | | | |
| | ... | | ...
| |--<entry> | |--<entry>
| | | | | |
| ... ... | ... ...
The following sections describe these elements in detail. The full The following sections describe these elements in detail. The full
Relax NG schema is provided in Section 5. RELAX NG schema is provided in Section 5.
4.1. <conference-info> 4.1. <conference-info>
A conference object document begins with the root element A conference object document begins with the root element
<conference-info>, which is defined in [RFC4575]. The 'state' and <conference-info>, which is defined in [RFC4575]. The 'state' and
'version' attributes of the <conference-info> element are defined in 'version' attributes of the <conference-info> element are defined in
[RFC4575] and are not used in the context of the XCON Conference [RFC4575] and are not used in the context of the XCON Conference
Information Model since they apply only to notification mechanisms. Information Model since they apply only to notification mechanisms.
In addition, [RFC4575] defines an 'entity' attribute that contains In addition, [RFC4575] defines an 'entity' attribute that contains
the SIP URI identifier. This especification extends the meaning of the SIP URI identifier. This specification extends the meaning of
the 'entity' attribute to the conference object identifier (XCON-URI) the 'entity' attribute to the conference object identifier (XCON-URI)
explained in Section 3.3. explained in Section 3.3.
This specification adds to the <conference-info> element the <floor- This specification adds to the <conference-info> element the child
information> child elements. elements of the <floor-information> element.
4.2. <conference-description> 4.2. <conference-description>
The <conference-description> element, which is defined in [RFC4575], The <conference-description> element, which is defined in [RFC4575],
describes the conference as a whole. It SHOULD have an attribute describes the conference as a whole. It SHOULD have an attribute
'lang' to specify the language used in the contents of this element. 'lang' to specify the language used in the contents of this element.
It is comprised of <language>, <display-text>, <subject>, <free- It is comprised of <language>, <display-text>, <subject>, <free-
text>, <keywords>, <allow-sidebars>, <cloning-parent>, <sidebar- text>, <keywords>, <allow-sidebars>, <cloning-parent>, <sidebar-
parent>, <conference-time>, <conf-uris>, <service-uris>, <maximum- parent>, <conference-time>, <conf-uris>, <service-uris>, <maximum-
user-count>, and <available-media>. The <display-text>, <subject>, user-count>, and <available-media>. The <display-text>, <subject>,
<free-text>, <keywords>, <service-uris>,and <maximum-user-count> <free-text>, <keywords>, <service-uris>, and <maximum-user-count>
elements are described in section 5.3 of [RFC4575]. elements are described in Section 5.3 of [RFC4575].
The following sections describe these elements in more detail. Other The following sections describe these elements in more detail. Other
child elements MAY be defined in the future to extend the child elements MAY be defined in the future to extend the
<conference-description> element. <conference-description> element.
4.2.1. <language> 4.2.1. <language>
The <language> element indicates the predominant language that is The <language> element indicates the predominant language that is
expected to be employed within a conference. This element contains expected to be employed within a conference. This element contains
only one language. The possible values of this element are the only one language. The possible values of this element are the
values of the 'Subtag' column of the [RFC5646] defined in [IANA-Lan]. values of the 'Subtag' column of the "Language Subtag Registry" at
This element does not enforce the language of the conference, but [IANA-Lan] originally defined in [RFC5646]. This element does not
only informs the participants about the desirable language that they enforce the language of the conference: it only informs the
should use in the conference. Participants are free to switch to participants about the desirable language that they should use in the
other languages if they like. conference. Participants are free to switch to other languages if
they like.
4.2.2. <allow-sidebars> 4.2.2. <allow-sidebars>
The <allow-sidebars> element represents a boolean value. If set to The <allow-sidebars> element represents a boolean value. If set to
"true" or "1", the conference is allowed to create sidebar true or "1", the conference is allowed to create sidebar conferences.
conferences. If absent, or set to "false" or "0", the conference can If absent, or set to "false" or "0", the conference cannot create
not create sidebar conferences. sidebar conferences.
4.2.3. <cloning-parent> 4.2.3. <cloning-parent>
When the <cloning-parent> is present, it indicates that the When the <cloning-parent> is present, it indicates that the
conference object is a child of a parent conference. The <cloning- conference object is a child of a parent conference. The <cloning-
parent> element contains the conference object Identifier (XCON-URI) parent> element contains the conference object identifier (XCON-URI)
(different from the main XCON-URI) of the parent. (different from the main XCON-URI) of the parent.
4.2.4. <sidebar-parent> 4.2.4. <sidebar-parent>
When the <sidebar-parent> is present, it indicates that the When the <sidebar-parent> is present, it indicates that the
conference object represents a sidebar of another conference. The conference object represents a sidebar of another conference. The
<sidebar-parent> element contains the conference object Identifier <sidebar-parent> element contains the conference object identifier
(XCON-URI) (different from the main XCON-URI) of the parent. (XCON-URI) (different from the main XCON-URI) of the parent.
4.2.5. <conference-time> 4.2.5. <conference-time>
The <conference-time> element contains the information related to The <conference-time> element contains the information related to
conference time, policy, and duration of a conference. The time, policy, and duration of a conference. The <conference-time>
<conference-time> element contains one or more <entry> elements each element contains one or more <entry> elements, each defining the time
defining the time and policy information specifying a single and policy information specifying a single conference occurrence.
conference occurrence. The <conference-time> element differs from The <conference-time> element differs from the iCalendar objects
the iCalendar objects [RFC5545] in the possibility to define [RFC5545] in that it has the ability to define different policies
different policies (<can-join-after-offset>, <must-join-before- (<can-join-after-offset>, <must-join-before-offset>) for the same
offset>) for the same conference at different times. conference at different times.
Every <entry> element contains the following child elements: Every <entry> element contains the following child elements:
o <base>: The <base> child element specifies the iCalendar object of o <base>: The <base> child element specifies the iCalendar object of
the conference. The iCalendar object components are defined in the conference. The iCalendar object components are defined in
[RFC5545]. [RFC5545].
o <mixing-start-offset>: The <mixing-start-offset> child element o <mixing-start-offset>: The <mixing-start-offset> child element
specifies when the conference media mixing starts before the specifies when the conference media mixing starts before the
conference starts. The <mixing-start-offset> element specifies an conference starts. The <mixing-start-offset> element specifies an
absolute value rather than an offset value. If the <mixing-start- absolute value rather than an offset value. If the <mixing-start-
offset> element is not present, it indicates that the conference offset> element is not present, it indicates that the conference
media mixing starts immediately. The <mixing-start-offset> MUST media mixing starts immediately. The <mixing-start-offset> MUST
include the 'required-participant' attribute. This attribute include the 'required-participant' attribute. This attribute
contains one of the following values: "none", "administrator", contains one of the following values: "none", "administrator",
"moderator", "user", "observer", and "participant". The roles' "moderator", "user", "observer", and "participant". The roles'
semantic definitions are out of the scope of this document and is semantic definitions are out of the scope of this document and are
subject to future policy documents. More values can be specified subject to future policy documents. More values can be specified
in the future. The 'required-participant' attribute allows a in the future. The 'required-participant' attribute allows a
privileged user to define when media mixing starts based on the privileged user to define when media mixing starts based on the
latter of the mixing start time, and the time the first latter of the mixing start time and the time the first participant
participant arrives. If the value is set to "none'", mixing arrives. If the value is set to "none", mixing starts according
starts according to the mixing start time. to the mixing start time.
o <mixing-end-offset>: The <mixing-end-offset> child element o <mixing-end-offset>: The <mixing-end-offset> child element
specifies the time conference media mixing stops after the specifies the time conference media mixing stops after the
conference stops. If the <mixing-end-offset> element is not conference stops. If the <mixing-end-offset> element is not
present, it indicates that the conference occurrence is not present, it indicates that the conference occurrence is not
bounded. The <mixing-end-offset> element MUST include the bounded. The <mixing-end-offset> element MUST include the
'required-participant' attribute. This attribute contains one of 'required-participant' attribute. This attribute contains one of
the following values: "none", "administrator", "moderator", the following values: "none", "administrator", "moderator",
"observer", "user", and "participant". More values can be "user", "observer", and "participant". More values can be
specified in the future. The 'required-participant' attribute specified in the future. The 'required-participant' attribute
allows a privileged user to define when media mixing ends based on allows a privileged user to define when media mixing ends based on
the earlier of the <mixing-end-offset>, and the time the last the earlier of the <mixing-end-offset> and the time the last
participant leaves. If the value is set to "none", mixing stops participant leaves. If the value is set to "none", mixing stops
according to the <mixing-end-offset>. If the conference policy according to the <mixing-end-offset>. If the conference policy
was modified so that last privileged user is now a normal was modified so that the last privileged user is now a normal
conference participant, and the conference requires a privileged conference participant, and the conference requires a privileged
user to continue; that conference MUST terminate. user to continue, that conference MUST terminate.
o <can-join-after-offset>: An administrator can indicate the time o <can-join-after-offset>: An administrator can indicate the time
when users can join a conference by populating the <can-join- when users can join a conference by populating the <can-join-
after-offset> element. after-offset> element.
o <must-join-before-offset>: An administrator can define the time o <must-join-before-offset>: An administrator can define the time
after which new users are not allowed to join the conference after which new users are not allowed to join the conference
anymore. anymore.
o <request-user>: It defines the time when users or resources on the o <request-user>: This element defines the time when users or
<allowed-users-list> are requested to join the conference by using resources on the <allowed-users-list> are requested to join the
the <request-users> element. conference by using the <request-users> element.
o <notify-end-of-conference>: The <notify-end-of-conference> element o <notify-end-of-conference>: The <notify-end-of-conference> element
defines in seconds when the system MUST send a notification when defines in seconds when the system MUST send a notification that
the end of the conference is approaching. If the <notify-end-of- the end of the conference is approaching. If the <notify-end-of-
conference> element is not present, it indicates that the system conference> element is not present, this indicates that the system
does not notify the users when the end of the conference is does not notify the users when the end of the conference is
approaching. approaching.
o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing- o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
end-offset> element indicates if the conference is allowed to be end-offset> element indicates if the conference is allowed to be
extended. It has a boolean value. extended. It has a boolean value.
4.2.6. <conf-uris> 4.2.6. <conf-uris>
The <conf-uris> contains a set of <entry> child elements - each The <conf-uris> contains a set of <entry> child elements -- each
containing a new element, <conference-password>. This element containing a new element: <conference-password>. This element
contains the password(s) of the conference, for instance, PSTN contains the password(s) of the conference, for instance, Public
conference will store the 'PIN code' in this element. All the other Switched Telephone Network (PSTN) conference will store the 'PIN
<conf-uris> child element are described in section 5.3.1 of code' in this element. All the other <conf-uris> child elements are
[RFC4575]. described in Section 5.3.1 of [RFC4575].
The schema in Section 5 allows <conference-password> to appear The RELAX NG schema in Section 5 allows <conference-password> to
anywhere uris-type is expanded. This document only provides meaning appear anywhere uris-type is expanded. This document only provides
for <conference-password> appearing as a descendent of the <conf- meaning for <conference-password> appearing as a descendant of the
uris> element. Future standardization may give meaning to <conf-uris> element. Future standardization may give meaning to
<conference-password> appearing in other elements of type uris-type. <conference-password> appearing in other elements of type "uris-
In the absence of such standardization, <conference-password> MUST type". In the absence of such standardization, <conference-password>
NOT appear in elements of type uris-type other than <conf-uris>. MUST NOT appear in elements of type "uris-type" other than <conf-
uris>.
4.2.7. <available-media> 4.2.7. <available-media>
The <available-media> element consists of a sequence of <entry> child The <available-media> element consists of a sequence of <entry> child
elements. Each <entry> element MAY contain the following child elements. Each <entry> element MAY contain the following child
elements: elements:
o The <type>, <display-text>, and <status> elements are described in o The <display-text>, <type>, and <status> elements are described in
section 5.3.4 of [RFC4575]. Section 5.3.4 of [RFC4575].
o The child element <mixing-mode> describes a default scheduling o The child element <mixing-mode> describes a default scheduling
policy by which the mixer will build the outgoing stream from the policy by which the mixer will build the outgoing stream from the
incoming streams. Note that this policy is different than the incoming streams. Note that this policy is different than the
policy describing the floors for each media. The <mixing-mode> policy describing the floors for each media. The <mixing-mode>
child element MUST contain one and only one of the "Moderator- child element MUST contain one and only one of the "moderator-
controlled", "FCFS", and "Automatic" values, indicating the controlled", "FCFS", and "automatic" values, indicating the
default algorithm to use with every media stream. The "Moderator- default algorithm to use with every media stream. The "moderator-
controlled" value indicates that the moderator of the conference, controlled" value indicates that the moderator of the conference
controls the media stream policy. The "FCFS" value indicates a controls the media stream policy. The "FCFS" value indicates a
'first-come-first-served' policy. The "Automatic" value means the 'first-come-first-served' policy. The "automatic" value means the
mixer choose the best scheduling policy for the conference. mixer must choose the best scheduling policy for the conference.
o The <codecs> element specifies the allowed codecs in the o The <codecs> element specifies the allowed codecs in the
conference. It has an attribute 'decision' that specifies if the conference. It has an attribute 'decision' that specifies if the
focus decides the common codec automatically or needs the approval focus decides the common codec automatically or needs the approval
of the moderator of the conference ("automatic", "moderator- of the moderator of the conference ("automatic", "moderator-
controlled"). The <codecs> element contains <codec> elements. A controlled"). The <codecs> element contains <codec> elements. A
<codec> element can have the attribute 'name' and 'policy'. The <codec> element can have the attribute 'name' and 'policy'. The
'name' attribute is a codec identifier assigned by the 'name' attribute is a codec identifier assigned by the
conferencing server. The 'policy' attribute contains the policy conferencing server. The 'policy' attribute contains the policy
for that codec (allowed, or disallowed). The <codec> element has for that codec (allowed or disallowed). The <codec> element has
the child element <subtype> which stores the codec's name. The the child element <subtype>, which stores the codec's name. The
possible values of this element are the values of the 'subtype' possible values of this element are the values of the 'subtype'
column of the RTP Payload Format media types per [RFC4855] defined column of the "RTP Payload Format media types" registry at [IANA]
in IANA [IANA]. It is expected that future conferencing originally defined in [RFC4855]. It is expected that future
specifications will define corresponding schema extensions, as conferencing specifications will define corresponding schema
appropriate. extensions, as appropriate.
o The <controls> element contains the basic audio and video global o The <controls> element contains the basic audio and video global
control elements for a conference. These controls are sufficient control elements for a conference. These controls are sufficient
for the majority of basic conferences. If the conference server for the majority of basic conferences. If the conference server
wants to support more advanced controls, then it is RECOMMENDED wants to support more-advanced controls, then it is RECOMMENDED
that an extension to the data model be used. In the <controls> that an extension to the data model be used. In the <controls>
element the schema is extensible, hence new control types can be element, the schema is extensible; hence, new control types can be
added in the future. So moderator controls that affect all media added in the future. So, moderator controls that affect all media
output would go under the <available-media> element. The output would go under the <available-media> element. The
following controls elements are defined for <controls>: following child elements are defined for <controls>:
* The <mute> element is used in conjunction with an audio stream * The <mute> element is used in conjunction with an audio stream
to cease transmission of any audio from the associated stream. to cease transmission of any audio from the associated stream.
That means that for the entire duration where mute is That means that for the entire duration where mute is
applicable, all current and future participants of the applicable, all current and future participants of the
conference are muted and will not send any audio. It has a conference are muted and will not send any audio. It has a
"boolean" value. If this control is not specified, access to boolean value. If this control is not specified, access to the
the control is not available to the client. control is not available to the client.
* The <pause-video> element is used in conjunction with a video * The <pause-video> element is used in conjunction with a video
stream to cease transmission of associated media. It has a stream to cease transmission of associated media. It has a
"boolean" value. If this control is not specified, the access boolean value. If this control is not specified, the access to
to the control is not available to the client. the control is not available to the client.
* The <gain> element is used in conjunction with a media output * The <gain> element is used in conjunction with a media output
stream to indicate the amount of amplification of an audio stream to indicate the amount of amplification of an audio
stream. The value is an integer number that ranges from -127 stream. The value is an integer number that ranges from -127
to 127. If this control is not specified, access to the to 127. If this control is not specified, access to the
control is not available to the client. control is not available to the client.
* The <video-layout> element is used in conjunction with a video * The <video-layout> element is used in conjunction with a video
stream to specify how the video streams (of participants) are stream to specify how the video streams (of participants) are
viewed by each participant. Only one layout type can be viewed by each participant. Only one layout type can be
skipping to change at page 18, line 15 skipping to change at page 17, line 25
participants than panels in the specified layout, then blanking participants than panels in the specified layout, then blanking
(black screen) MAY be mixed into the stream on the behalf of (black screen) MAY be mixed into the stream on the behalf of
the missing input streams. If unspecified, the <video-layout> the missing input streams. If unspecified, the <video-layout>
default type SHOULD be "single-view". The <video-layout> types default type SHOULD be "single-view". The <video-layout> types
are as follows, although any number of custom layouts may be are as follows, although any number of custom layouts may be
specified in future extensions: specified in future extensions:
+ single-view: Only one stream is presented by the focus to + single-view: Only one stream is presented by the focus to
all participants in one panel. all participants in one panel.
+ dual-view: This dual view option will present the video + dual-view: This dual-view option will present the video
side-by-side in 2 panels and not alter the aspect ratio of side-by-side in two panels and not alter the aspect ratio of
the streams. This will require the focus to introduce the streams. This will require the focus to introduce
blanking on parts of the overall image as viewed by the blanking on parts of the overall image as viewed by the
participants. participants.
+ dual-view-crop: This side-by-side layout option instructs + dual-view-crop: This side-by-side layout option instructs
the focus to alter the aspect ratio of the streams (alter- the focus to alter the aspect ratio of the streams (alter-
aspect-ratio=TRUE) so that blanking is not necessary. The aspect-ratio=true) so that blanking is not necessary. The
focus handles the cropping of the streams. focus handles the cropping of the streams.
+ dual-view-2x1: This layout option instructs the focus to + dual-view-2x1: This layout option instructs the focus to
place one stream above the other, in essence with two rows place one stream above the other, in essence, with two rows
and one column. In this option the aspect ratio is not and one column. In this option, the aspect ratio is not
altered and blanking is introduced. altered and blanking is introduced.
+ dual-view-2x1-crop: This layout option also instructs the + dual-view-2x1-crop: This layout option also instructs the
focus to place one stream above the other, in essence with focus to place one stream above the other, in essence, with
two rows and one column. In this option the aspect ratio is two rows and one column. In this option, the aspect ratio
altered and the video streams are cropped. is altered and the video streams are cropped.
+ quad-view: Four equal-sized panels in a 2x2 layout is + quad-view: Four equal-sized panels in a 2x2 layout are
presented by the focus to all participants. Typically the presented by the focus to all participants. Typically, the
aspect ratio of the streams are maintained (alter-aspect- aspect ratio of the streams are maintained (alter-aspect-
ratio= FALSE). ratio= FALSE).
+ multiple-3x3: Nine equal-sized panels in a 3x3 layout is + multiple-3x3: Nine equal-sized panels in a 3x3 layout are
presented by the focus to all participants. Typically the presented by the focus to all participants. Typically, the
aspect ratio of the streams are preserved. aspect ratio of the streams are preserved.
+ multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is + multiple-4x4: 16 equal-sized panels in a 4x4 layout are
presented by the focus to all participants. Typically the presented by the focus to all participants. Typically, the
aspect ratio of the streams are preserved. aspect ratio of the streams are preserved.
+ multiple-5x1: This option refers to a 5x1 layout where one + multiple-5x1: This option refers to a 5x1 layout where one
panel will occupy 4/9 of the mixed video stream while the panel will occupy 4/9 of the mixed video stream while the
others will each occupy 1/9 of the stream. Typically the others will each occupy 1/9 of the stream. Typically, the
aspect ratio of the streams is preserved. aspect ratio of the streams is preserved.
+ automatic: This option allows the focus to add panels as + automatic: This option allows the focus to add panels as
streams are added. streams are added.
4.3. <host-info> 4.3. <host-info>
The <host-info> element and its child elements are described in The <host-info> element and its child elements are described in
[RFC4575], section 5.4. [RFC4575], Section 5.4.
4.4. <conference-state> 4.4. <conference-state>
The <conference-state> is introduced in [RFC4575]. The <conference- The <conference-state> is introduced in [RFC4575]. The <conference-
state> element contains the <allow-conference-event-subscription>, state> element contains the <allow-conference-event-subscription>,
<user-count>, <active>, and <locked> child elements. The <user- <user-count>, <active>, and <locked> child elements. The <user-
count>, <active>, and <locked> child elements are defined in count>, <active>, and <locked> child elements are defined in
[RFC4575], section 5.5. [RFC4575], Section 5.5.
4.4.1. <allow-conference-event-subscription> 4.4.1. <allow-conference-event-subscription>
The <allow-conference-event-subscription> element represents a The <allow-conference-event-subscription> element represents a
boolean action. If set to TRUE, the focus is instructed to allow the boolean action. If set to true, the focus is instructed to allow the
subscription to conference state events, such as 'SIP Event Package subscription to conference state events, such as 'SIP event package
for Conference State' [RFC4575]. If set to FALSE, the subscription for conference state' [RFC4575]. If set to FALSE, the subscription
to conference state events MUST be rejected. If this element is to conference state events MUST be rejected. If this element is
undefined it has a default value of TRUE, causing the subscription to undefined, it has a default value of true, causing the subscription
conference state events to be accepted. to conference state events to be accepted.
4.5. <floor-information> 4.5. <floor-information>
The <floor-information> element contains the <conference-ID>, <allow- The <floor-information> element contains the <conference-ID>, <allow-
floor-events>, <floor-request-handling>, and <conference-floor- floor-events>, <floor-request-handling>, and <conference-floor-
policy> child elements. The absence of this element from an XML policy> child elements. The absence of this element from an XML
document indicates that the conference does not have a floor. document indicates that the conference does not have a floor.
4.5.1. <conference-ID> 4.5.1. <conference-ID>
The <conference-ID> represents a conference instance within floor The <conference-ID> represents a conference instance within floor
control. When BFCP serves as the floor control protocol, the control. When BFCP serves as the floor control protocol, the
<conference-ID> is a 32-bit BFCP conference identifier defined in <conference-ID> is a 32-bit BFCP conference identifier defined in
[RFC4582] section 5.1. Note that when created within the [RFC4582], Section 5.1. Note that when created within the
conferencing system, there is a 1:1 mapping between this conferencing system, there is a 1:1 mapping between this
<conference-ID> and the unique conference object Identifier (XCON- <conference-ID> and the unique conference object identifier (XCON-
URI). URI).
4.5.2. <allow-floor-events> 4.5.2. <allow-floor-events>
The <allow-floor-events> element represents a boolean action. If set The <allow-floor-events> element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor to true, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject control events. If set to FALSE, the focus is instructed to reject
the subscription. If this element is undefined, it has a default the subscription. If this element is undefined, it has a default
value of FALSE, causing the subscription to floor control events to value of FALSE, causing the subscription to floor control events to
be rejected. be rejected.
A conference participant can subscribe himself to a floor control A conference participant can subscribe himself to a floor control
event in two different ways: one method is using an offer/answer event in two different ways: one method is using an offer/answer
exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters
in the SDP ([RFC4583]), the other method is a general authorization in the SDP [RFC4583], the other method is a general authorization
mechanism described in section 9 of [RFC4582] and in [RFC5018]. mechanism described in Section 9 of [RFC4582] and in [RFC5018].
Future documentation may define additional connection mechanisms. Future documentation may define additional connection mechanisms.
4.5.3. <floor-request-handling> 4.5.3. <floor-request-handling>
The <floor-request-handling> element defines the actions used by the The <floor-request-handling> element defines the actions used by the
conference focus to control floor requests. This element defines the conference focus to control floor requests. This element defines the
action that the focus is to take when processing a particular request action that the focus is to take when processing a particular request
to a floor within a conference. This element defines values of: to a floor within a conference. This element defines values of the
following:
o "block": This action instructs the focus to deny the floor o "block": This action instructs the focus to deny the floor
request. This action is the default action taken in the absence request. This action is the default action taken in the absence
of any other actions. of any other actions.
o "confirm": This action instructs the focus to allow the request. o "confirm": This action instructs the focus to allow the request.
The focus then uses the defined floor algorithm to further allow The focus then uses the defined floor algorithm to further allow
or deny the floor. The algorithms used are outside the scope of or deny the floor. The algorithms used are outside the scope of
this document. this document.
Note that this section discusses floor control information, Note that this section discusses floor control information;
therefore, the value "block" in a <floor-request-handling> element is therefore, the value "block" in a <floor-request-handling> element is
not related with the "block" value in the <join-handling> element not related with the "block" value in the <join-handling> element
(see Section 4.6). (see Section 4.6.1).
4.5.4. <conference-floor-policy> 4.5.4. <conference-floor-policy>
The <conference-floor-policy> element has one or more <floor> child The <conference-floor-policy> element has one or more <floor> child
elements. Every <floor> child elements has an attribute 'id' which elements. Every <floor> child elements has an attribute 'id', which
uniquely identifies a floor within a conference. In the case of BFCP uniquely identifies a floor within a conference. In the case of BFCP
[RFC4582], the 'id' attribute corresponds to the floor-id identifier [RFC4582], the 'id' attribute corresponds to the floor-id identifier
defined in [RFC4582] section 5.2.2. defined in [RFC4582], Section 5.2.2.
o <media-label>: Every floor is identified for one or more mandatory o <media-label>: Every floor is identified for one or more mandatory
<media-label> element. If the <available-media> information is <media-label> elements. If the <available-media> information is
included in the conference document, the value of this element included in the conference document, the value of this element
MUST be equal to the 'label' value of the corresponding media MUST be equal to the "label" value of the corresponding media
stream <entry> in the <available-media> container. The number of stream <entry> in the <available-media> container. The number of
those elements indicates how many floors the conference can have. those elements indicates how many floors the conference can have.
A floor can be used for one or more media types; A floor can be used for one or more media types;
o <algorithm>: A floor can be controlled using many algorithms; the o <algorithm>: A floor can be controlled using many algorithms; the
mandatory <algorithm> element MUST be set to any of the mandatory <algorithm> element MUST be set to any of the
"moderator-controlled", "FCFS" or "random" values indicating the "moderator-controlled", "FCFS", or "random" values indicating the
algorithm. The "Moderator-controlled" value indicates that the algorithm. The "moderator-controlled" value indicates that the
moderator of the conference controls the floor. The "FCFS" value moderator of the conference controls the floor. The "FCFS" value
states for 'first-come-first-served' floor control. indicates a 'first-come-first-served' policy.
o <max-floor-users>: The <max-floor-users> child element in the o <max-floor-users>: The <max-floor-users> child element in the
<floor> element is OPTIONAL and, if present, dictates the maximum <floor> element is OPTIONAL and, if present, dictates the maximum
number of users who can have the floor at one time. number of users who can have the floor at one time.
o <moderator-id>: The OPTIONAL <moderator-id> indicates the 'User o <moderator-id>: The OPTIONAL <moderator-id> indicates the "User
ID' of the moderator(s). It MUST be set if the element ID" of the moderator(s). It MUST be set if the element
<algorithm> is set to "Moderator-controlled" value. When the <algorithm> is set to the "moderator-controlled" value. When the
floor is created within the conferencing system, the XCON-User floor is created within the conferencing system, the XCON-USERID
identifier MAY be used as the moderator-id. In the case of BFCP MAY be used as the <moderator-id>. In the case where the BFCP is
as the floor control protocol, the <moderator-id> is defined in the floor control protocol, the <moderator-id> is defined in
[RFC4582] section 3. Note that [RFC4582] refers to the moderator [RFC4582], Section 3. Note that [RFC4582] refers to the moderator
role as a 'floor chair'. role as a "floor chair".
4.6. <users> 4.6. <users>
The <users> element is described in [RFC4575] and contains the <join- The <users> element is described in [RFC4575] and contains the <join-
handling>, <user-admission-policy>, <allowed-users-list> and <deny- handling>, <user-admission-policy>, <allowed-users-list>, and <deny-
users-list> defined in this document and <user> child elements users-list> defined in this document and <user> child elements
defined in [RFC4575]. When the <users> element is used in the defined in [RFC4575]. When the <users> element is used in the
context of the XCON Conference Information Model, the 'state' and context of the XCON Conference Information Model, the 'state' and
'version' attributes defined in [RFC4575] are not used, since they 'version' attributes defined in [RFC4575] are not used, since they
apply only to notification mechanisms. The following sections apply only to notification mechanisms. The following sections
describe these elements in more detail. Other child elements and describe these elements in more detail. Other child elements and
attributes can be used to extend <users> in the future. attributes can be used to extend <users> in the future.
4.6.1. <join-handling> 4.6.1. <join-handling>
skipping to change at page 22, line 27 skipping to change at page 21, line 39
o "directed-operator": This action instructs the focus to direct the o "directed-operator": This action instructs the focus to direct the
user to an operator. user to an operator.
4.6.2. <user-admission-policy> 4.6.2. <user-admission-policy>
The <user-admission-policy> is an element that lets an organizer (or The <user-admission-policy> is an element that lets an organizer (or
a participant with appropriate rights) choose a policy for the a participant with appropriate rights) choose a policy for the
conference that controls how users are authenticated into the conference that controls how users are authenticated into the
conference, using a mechanism of the conference's choosing. Since a conference, using a mechanism of the conference's choosing. Since a
variety of signaling protocols are possible, a variety of variety of signaling protocols are possible, a variety of
authentication mechanism - determined by every individual conference authentication mechanisms -- determined by every individual
servers - may need to be mapped from the different protocols. The conference server -- may need to be mapped from the different
specific types of authentication mechanism are beyond the scope of protocols. The specific types of authentication mechanisms are
this document. The list of possible values are: beyond the scope of this document. The list of possible values are
as follows:
o "closedAuthenticated": A 'closedAuthenticated' policy MUST have o "closedAuthenticated": A 'closedAuthenticated' policy MUST have
each conference participant in the allowed users list (listed each conference participant in the allowed users list (listed
under the <allowed-users-list> element) with each participant under the <allowed-users-list> element) with each participant
being sufficiently (up to local policy) authenticated. Conference being sufficiently (up to local policy) authenticated. Conference
join requests for users not in the allowed users list or join requests for users not in the allowed users list or
participants not authenticated should be rejected unless a <join- participants not authenticated should be rejected unless a <join-
handling> action of 'confirm' is selected in which case the user handling> action of 'confirm' is selected; in which case, the user
is placed on a pending list as indicated earlier. A is placed on a pending list as indicated earlier. A
'closedAuthenticated' policy MUST NOT include a <deny-users-list>. 'closedAuthenticated' policy MUST NOT include a <deny-users-list>.
If <deny-users-list> appears in the data model, it MUST be If <deny-users-list> appears in the data model, it MUST be
ignored. ignored.
o "openAuthenticated": An 'openAuthenticated' policy requires each o "openAuthenticated": An 'openAuthenticated' policy requires each
conferencing participant to be sufficiently authenticated. conferencing participant to be sufficiently authenticated.
Typically this implies that anyone capable of authenticating with Typically, this implies that anyone capable of authenticating with
the conferencing system may join the conference. The the conferencing system may join the conference. The
'openAuthenticated' policy permits the specification of "banned" 'openAuthenticated' policy permits the specification of "banned"
conferencing participants. Such banned users are prevented from conferencing participants. Such banned users are prevented from
re-joining the conference until they have been un-banned. An re-joining the conference until they have been un-banned. An
'openAuthenticated' policy SHOULD have a deny users list (listed 'openAuthenticated' policy SHOULD have a deny users list (listed
under the <deny-users-list> XML element) to support banning of under the <deny-users-list> XML element) to support the banning of
conferencing participants from a conference. An conferencing participants from a conference. An
'openAuthenticated' policy MUST NOT include an <allowed-users- 'openAuthenticated' policy MUST NOT include an <allowed-users-
list>. If <allowed-users-list> appears in the data model, it MUST list>. If <allowed-users-list> appears in the data model, it MUST
be ignored. be ignored.
o "anonymous": An 'anonymous' policy allows any join requests in and o "anonymous": An 'anonymous' policy grants any join requests and is
is the least restrictive policy. An 'anonymous' policy MUST NOT the least restrictive policy. An 'anonymous' policy MUST NOT
include either an <allowed-users-list> or a <deny-users-list>. If include either an <allowed-users-list> or a <deny-users-list>. If
any of these lists appear in the data model, they MUST be ignored. any of these lists appear in the data model, they MUST be ignored.
In all other cases, the appearance of an <allowed-users-list> and In all other cases, the appearance of an <allowed-users-list> and
<deny-users-list> MUST be ignored, except as otherwise described in a <deny-users-list> MUST be ignored, except as otherwise described in a
future specification. Future specifications describing the use of future specification. Future specifications describing the use of
these lists must provide clear guidance on how to process the lists these lists must provide clear guidance on how to process the lists
when they occur concurrently, especially when both lists contain the when they occur concurrently, especially when both lists contain the
same user. For example, such specification could disallow both list same user. For example, such a specification could disallow both
from appearing at the same time similar to user-admission-policy lists from appearing at the same time similar to <user-admission-
values defined in this document. policy> values defined in this document.
4.6.3. <allowed-users-list> 4.6.3. <allowed-users-list>
The <allowed-users-list> child element contains a list of user URIs The <allowed-users-list> child element contains a list of user URIs
(e.g. xcon-userid defined in Section 4.6.5), roles (defined in (e.g., XCON-USERID, as defined in Section 4.6.5), roles (defined in
Section 4.6.5.2), or domains (e.g.: *@example.com) that the focus Section 4.6.5.2), or domains (e.g., *@example.com) that the focus
uses to determine who can join the conference, who can be invited to uses to determine who can join the conference, who can be invited to
join a conference, or who the focus needs to "refer to" the join a conference, or who the focus needs to "refer to" the
conference. The <allowed-users-list> element includes zero or more conference. The <allowed-users-list> element includes zero or more
<target> child elements. This child element includes the mandatory <target> child elements. This child element includes the mandatory
'uri' attribute and the mandatory 'method' attribute. The same 'uri' 'uri' attribute and the mandatory 'method' attribute. The same 'uri'
attribute with different method values can appear in the list more attribute with different method values can appear in the list more
than once. than once.
The 'method' attribute is a list with the following values: The 'method' attribute is a list with the following values:
o "dial-in": The value "dial-in" is used by the focus to determine o "dial-in": The value "dial-in" is used by the focus to determine
who can join the conference. who can join the conference.
o "dial-out": The value "dial-out" contains a list of resources that o "dial-out": The value "dial-out" contains a list of resources with
the focus will initiate a session with. which the focus will initiate a session.
o "refer": The value "refer" is used by the focus to determine the o "refer": The value "refer" is used by the focus to determine the
resources that the focus needs to "refer to" the conference. In resources that the focus needs to "refer to" the conference. In
SIP, this is achieved by the focus sending a REFER request to SIP, this is achieved by the focus sending a REFER request to
those potential participants. In a different paradigm, this could those potential participants. In a different paradigm, this could
also mean that the focus sends an SMS or an email to the referred 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 user. This list can be updated during the conference lifetime so
it can be used for mid-conference refers as well. it can be used for mid-conference refers as well.
The "refer" value differs from the "dial-out" in that the resources The "refer" value differs from "dial-out" in that the resources on
on the "refer" value are expected to initiate the session the "refer" value are expected to initiate the session establishment
establishment toward the focus themselves. It is also envisioned toward the focus themselves. It is also envisioned that different
that different users will have different access rights to those lists users will have different access rights to those lists and therefore
and therefore a separation between the two is needed. a separation between the two is needed.
The <allowed-users-list> element has a <persistent-list> child The <allowed-users-list> element has a <persistent-list> child
element as well. Some chatroom systems allow -- and some require -- element as well. Some chat room systems allow -- and some require --
registration of detailed information about a user before they are registration of detailed information about a user before they are
allowed to join a chatroom. The <persistent-list> child element allowed to join a chat room. The <persistent-list> child element
stores persistent information about users who are not actively part stores persistent information about users who are not actively part
of an ongoing chatroom session. The <persistent-list> element stores of an ongoing chat room session. The <persistent-list> element
the following information: stores the following information:
o user: The <user> element stores the name, nickname, the conference o user: The <user> element stores the name, nickname, conference
user identifier (XCON-USERID) and email address of a user. It has user identifier (XCON-USERID), and email address of a user. It
three attributes: 'name', 'nickname' and 'id' and an <email> has three attributes: 'name', 'nickname', and 'id' and an <email>
element. Future extensions to this schema may define new elements element. Future extensions to this schema may define new elements
for the <user> element. for the <user> element.
Future extensions to this schema may define new elements for the Future extensions to this schema may define new elements for the
<target> element. <target> element.
4.6.4. <deny-users-list> 4.6.4. <deny-users-list>
The <deny-users-list> child element contains a list of user URIs The <deny-users-list> child element contains a list of user URIs
(e.g. SIP URI, xcon-userid defined in Section 4.6.5), roles (defined (e.g., SIP URI, XCON-USERID defined in Section 4.6.5), roles (defined
in Section 4.6.5.2), or domains (e.g.: *@example.com) that the focus in Section 4.6.5.2), or domains (e.g.: *@example.com) that the focus
uses to determine who has been 'banned' from the conference. Such uses to determine who has been 'banned' from the conference. Such
banned users are prevented from re-joining the chatroom until they banned users are prevented from re-joining the chat room until the
have been un-banned. ban has been lifted.
4.6.5. <user> and Its <user> Sub-elements 4.6.5. <user> and Its <user> Sub-Elements
The element <user> is described in [RFC4575] and describes a single The element <user> is described in [RFC4575] and describes a single
participant in the conference. The <user> element has an attribute participant in the conference. The <user> element has an attribute
'entity'. However, when the <user> element is used in the context of 'entity'. However, when the <user> element is used in the context of
the XCON Conference Information Model, the 'state' and 'version' the XCON Conference Information Model, the 'state' and 'version'
attributes defined in [RFC4575] are not used, since they apply only attributes defined in [RFC4575] are not used, since they only apply
to notification mechanisms. to notification mechanisms.
The attribute 'entity' contains a unique conference user identifier The attribute 'entity' contains a unique conference user identifier
(XCON-USERID) within the scope of the conference. The URI format of (XCON-USERID) within the scope of the conference. The URI format of
this identifier is as follow: this identifier is as follows (using ABNF [RFC5234]):
XCON-USERID = "xcon-userid" ":" conf-user-id XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*unreserved conf-user-id = 1*unreserved
[unreserved is defined in RFC3986] Note: unreserved is defined in RFC 3986.
In order to facilitate the comparison of the XCON-USERID identifiers, In order to facilitate the comparison of the XCON-USERID identifiers,
all the components of the identifiers MUST be converted to lowercase. all the components of the identifiers MUST be converted to lowercase.
After normalizing the URI strings, the URIs comparison MUST applied a
codepoint-by-codepoint after conversion to a common character After normalizing the URI strings, the URIs comparison MUST be
encoding as prescribed by [RFC3986], Section 6.2.1. applied codepoint-by-codepoint after conversion to a common character
encoding, as prescribed by [RFC3986], Section 6.2.1.
Other user identifiers can be associated with this conference user Other user identifiers can be associated with this conference user
identifier and enable the conferencing system to correlate and map identifier and enable the conferencing system to correlate and map
these multiple authenticated user identities to a single global user these multiple authenticated user identities to a single global user
identifier. Figure 2 illustrates an example using the conference identifier. Figure 2 illustrates an example using the conference
user identifier in association with the user identity defined for user identifier in association with the user identity defined for
BFCP, SIP, and H323 user identity. It should be noted that a BFCP, SIP, and H323 user identity. It should be noted that a
conferencing system is free to structure such relationships as conferencing system is free to structure such relationships as
required and this information is just included as a guideline. required, and this information is just included as a guideline.
+----------------+ +----------------+
| Conference | | Conference |
| User | | User |
| Identifier | | Identifier |
+----------------+ +----------------+
|xcon-userid:John| |XCON-USERID:John|
+-------+--------+ +-------+--------+
| |
| |
| |
+----------------------+-------------------------+ +----------------------+-------------------------+
| | | | | |
+-------+--------+ +-----------+-----------+ +-----------+-----------+ +-------+--------+ +-----------+-----------+ +-----------+-----------+
| BFCP User ID | | SIP User URI | | H323 User URI | | BFCP User ID | | SIP User URI | | H323 User URI |
+----------------+ +-----------------------+ +-----------------------+ +----------------+ +-----------------------+ +-----------------------+
| 543 | |sip:851221@example.com | |h323:taeduk@example.com| | 543 | |sip:851221@example.com | |h323:taeduk@example.com|
+----------------+ +-----------------------+ +-----------------------+ +----------------+ +-----------------------+ +-----------------------+
Figure 2: Conference User Mapping Figure 2: Conference User Mapping
The element <user> element contains the <display-text>, <associated- The element <user> element contains the <display-text>, <associated-
aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>, aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>,
<allow-refer-users-dynamically>, <allow-invite-users-dynamically>, <allow-refer-users-dynamically>, <allow-invite-users-dynamically>,
<allow-remove-users-dynamically>, and <endpoint>. The following <allow-remove-users-dynamically>, and <endpoint>. The following
sections describe these elements in more detail. The <display-text>, sections describe these elements in more detail. The <display-text>,
<associated-aors>, <languages>, and <cascaded-focus> are defined in <associated-aors>, <languages>, and <cascaded-focus> are defined in
in [RFC4575], section 5.6. [RFC4575], Section 5.6.
4.6.5.1. <provide-anonymity> 4.6.5.1. <provide-anonymity>
The <provide-anonymity> element specifies what level of anonymity the The <provide-anonymity> element specifies what level of anonymity the
server should provide to the user. In this case, the focus provides server should provide to the user. In this case, the focus provides
to the rest of the participants an anonymous identity for that user, the rest of the participants with an anonymous identity for that
for example anonymousX, or it does not provide any information for user, for example, anonymousX, or it does not provide any information
that user such that other users can not see he is a participant in for that user such that other users cannot see he is a participant in
the conference. This element only affects the way the user the conference. This element only affects the way the user
information is provided to the other participants. The real user information is provided to the other participants. The real user
information is stored in the data model but SHOULD NOT be provided to information is stored in the data model but SHOULD NOT be provided to
the other participants of the conference. This can be achieved by the other participants of the conference. This can be achieved by
using the <provide-anonymity> element. This element has three using the <provide-anonymity> element. This element has three
values: 'private', 'semi-private' and 'hidden'. The 'private' value values: "private", "semi-private", and "hidden". The "private" value
specifies that this user is completely anonymous in the conference. specifies that this user is completely anonymous in the conference.
'semi-private' value specifies that this user is anonymous to all The "semi-private" value specifies that this user is anonymous to all
users who have not been granted permission to see him. 'hidden' value users who have not been granted permission to see him. The "hidden"
specifies that other users can not see this participant in the value specifies that other users cannot see this participant in the
conference. conference.
4.6.5.2. <roles> 4.6.5.2. <roles>
A role provides the context for the set of conference operations that A <role> provides the context for the set of conference operations
a participant can perform. This element can contain one or more of that a participant can perform. This element can contain one or more
the following values: "administrator", "moderator", "user", of the following values: "administrator", "moderator", "user",
"participant", "observer", and "none". A role of "none" indicates "participant", "observer", and "none". A role of "none" indicates
that any role is assigned; The roles semantic definition is out of that any role is assigned. The <roles> semantic definition is out of
the scope of this document and is subject to future policy documents. the scope of this document and is subject to future policy documents.
This element can be extended with new roles in future documents. This element can be extended with new roles in future documents.
4.6.5.3. <allow-refer-users-dynamically> 4.6.5.3. <allow-refer-users-dynamically>
The <allow-refer-users-dynamically> element represents a boolean The <allow-refer-users-dynamically> element represents a boolean
value. If set to TRUE, a participant is allowed to instruct the value. If set to true, a participant is allowed to instruct the
focus to refer a user to the conference without modifying the focus to refer a user to the conference without modifying the
<allowed-users-list> (in SIP terms, a participant is allowed to send <allowed-users-list> (in SIP terms, a participant is allowed to send
a REFER request [RFC3515] to the focus which results in the focus a REFER request [RFC3515] to the focus, which results in the focus
sending a REFER request to the user the referrer wishes to join the sending a REFER request to the user the referrer wishes to join the
conference). If set to FALSE, the refer request is rejected. If conference). If set to FALSE, the REFER request is rejected. If
this element is undefined it has a value of FALSE, causing the refer this element is undefined, it has a value of FALSE, causing the REFER
to be rejected. request to be rejected.
4.6.5.4. <allow-invite-users-dynamically> 4.6.5.4. <allow-invite-users-dynamically>
The <allow-invite-users-dynamically> element represents a boolean The <allow-invite-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the action. If set to true, a participant is allowed to instruct the
focus to invite a user to the conference without modifying the focus to invite a user to the conference without modifying the
<allowed-users-list> list (in SIP terms, a participant is allowed to <allowed-users-list> list (in SIP terms, a participant is allowed to
send a REFER request [RFC3515] to the focus which results in the send a REFER request [RFC3515] to the focus, which results in the
focus sending an INVITE request to the user the referrer wishes to focus sending an INVITE request to the user the referrer wishes to
join the conference). If set to FALSE, the refer request is join the conference). If set to FALSE, the REFER request is
rejected. If this element is undefined it has a value of FALSE, rejected. If this element is undefined, it has a value of FALSE,
causing the refer to be rejected. causing the REFER request to be rejected.
4.6.5.5. <allow-remove-users-dynamically> 4.6.5.5. <allow-remove-users-dynamically>
The <allow-remove-users-dynamically> element represents a boolean The <allow-remove-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the action. If set to true, a participant is allowed to instruct the
focus to remove a user from the conference without modifying the focus to remove a user from the conference without modifying the
ruleset (in SIP terms, a participant is allowed to send a REFER ruleset (in SIP terms, a participant is allowed to send a REFER
request [RFC3515] to the focus which results in the focus sending an request [RFC3515] to the focus, which results in the focus sending a
BYE request to the user the referrer wishes to leave the conference). 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 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. undefined, it has a value of FALSE, causing the REFER request to be
rejected.
4.6.5.6. <endpoint> 4.6.5.6. <endpoint>
The <endpoint> child element is identical to the element with the The <endpoint> child element is identical to the element with the
same name in [RFC4575] except that the 'state' attribute is not same name in [RFC4575] except that the 'state' attribute is not
included. When the <endpoint> element is used in the context of the included. When the <endpoint> element is used in the context of the
XCON Conference Information Model, the 'state' and 'version' XCON Conference Information Model, the 'state' and 'version'
attributes defined in [RFC4575] are not used, since they apply only attributes defined in [RFC4575] are not used, since they apply only
to notification mechanisms. The <endpoint> element can provide the to notification mechanisms. The <endpoint> element can provide the
desired level of detail about the user's devices and their signaling desired level of detail about the user's devices and their signaling
sessions taking part in the conference. sessions taking part in the conference.
The <endpoint> element has the following child elements: <display- The <endpoint> element has the following child elements: <display-
text>, <referred>, <status>, <joining-method>, <joining-info>, text>, <referred>, <status>, <joining-method>, <joining-info>,
<disconnection-method>, <disconnection-info>, <media>,and <call- <disconnection-method>, <disconnection-info>, <media>, and <call-
info>. All the <endpoint> child elements are defined in [RFC4575] info>. All the <endpoint> child elements are defined in [RFC4575]
with the exception of the <to-mixer> element, and the <from-mixer> with the exception of the <to-mixer> element and the <from-mixer>
element. element.
The <endpoint>/<media> element has two other child elements defined The <endpoint>/<media> element has two other child elements defined
in this document, the <to-mixer>, and the <from-mixer>: in this document: the <to-mixer> and the <from-mixer>:
o <from-mixer>, <to-mixer>: These are controls that apply to a o <from-mixer>, <to-mixer>: These are controls that apply to a
user's media stream being sent from the mixer to the participants user's media stream being sent from the mixer to the participant's
endpoint or to the mixer from the participants endpoint. The <to- endpoint or to the mixer from the participant's endpoint. The
mixer> element details properties associated with the incoming <to-mixer> element details properties associated with the incoming
streams to the mixer (streams sent to the mixer from the streams to the mixer (streams sent to the mixer from the
participant). The <from-mixer> element details properties participant). The <from-mixer> element details properties
associated with the outgoing streams from the mixer (sent from the associated with the outgoing streams from the mixer (sent from the
mixer to the participant). Both of these elements have the mixer to the participant). Both of these elements have the
attribute 'name'. The 'name' attribute has the values "VideoIn", attribute 'name'. The 'name' attribute has the values "VideoIn",
"VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and "VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and
"AudioOut" media streams detail properties associated with the "AudioOut" media streams detail properties associated with the
outgoing video and audio from the mixer. The "VideoIn" and outgoing video and audio from the mixer. The "VideoIn" and
"AudioIn" media stream details properties associated with the "AudioIn" media stream details properties associated with the
incoming video and audio to the mixer. Both of these elements can incoming video and audio to the mixer. Both of these elements can
have the <floor> child element defined: have the <floor> child element defined:
* The <floor> element refers to the floor assigned to a certain * The <floor> element refers to the floor assigned to a certain
participant in the conference. If a participant, for instance, participant in the conference. If a participant, for instance,
needs to talk in the conference, it first needs to get the needs to talk in the conference, it first needs to get the
floor from the chair of the conference. The <floor> element floor from the chair of the conference. The <floor> element
has an attribute 'id' which uniquely identifies a floor within has an attribute 'id', which uniquely identifies a floor within
a conference. The 'id' attribute corresponds to the floor-id a conference. The 'id' attribute corresponds to the floor-id
identifier defined in [RFC4582] section 5.2.2. The <floor> identifier defined in [RFC4582], Section 5.2.2. The <floor>
element has a "Boolean" value. A value of FALSE indicates that element has a boolean value. A value of FALSE indicates that
this user does not hold the floor in this moment. If this this user does not hold the floor in this moment. If this
control is not specified, this user SHOULD NOT specify the control is not specified, this user SHOULD NOT specify the
floor option. floor option.
The <to-mixer> and <from-mixer> elements can have the <controls> The <to-mixer> and <from-mixer> elements can have the <controls>
child element: child element:
* Controls that apply to a specific user would appear under the * Controls that apply to a specific user would appear under the
<controls> element. <controls> element.
o More values can be defined in the future. o More values can be defined in the future.
4.7. <sidebars-by-ref> 4.7. <sidebars-by-ref>
The <sidebars-by-ref> element contains a set of <entry> child The <sidebars-by-ref> element contains a set of <entry> child
elements. This element is described in [RFC4575], 5.9.1. When the elements. This element is described in [RFC4575], Section 5.9.1.
<sidebars-by-ref> element is used in the context of the XCON When the <sidebars-by-ref> element is used in the context of the XCON
Conference Information Model, the 'state' and 'version' attributes conference information model, the 'state' and 'version' attributes
defined in [RFC4575] are not used, since they apply only to defined in [RFC4575] are not used, since they apply only to
notification mechanisms. notification mechanisms.
4.8. <sidebars-by-val> 4.8. <sidebars-by-val>
The <sidebars-by-val> element contains a set of <entry> child The <sidebars-by-val> element contains a set of <entry> child
elements each containing information about a single sidebar. This elements each containing information about a single sidebar. This
element is described in [RFC4575], 5.9.2. When the <sidebars-by-val> element is described in [RFC4575], Section 5.9.2. When the
element is used in the context of the XCON Conference Information <sidebars-by-val> element is used in the context of the XCON
Model, the 'state' and 'version' attributes defined in [RFC4575] are conference information model, the 'state' and 'version' attributes
not used, since they apply only to notification mechanisms. defined in [RFC4575] are not used, since they apply only to
notification mechanisms.
5. RELAX NG Schema 5. RELAX NG Schema
In accordance with the Centralized Conferencing Framework document In accordance with the centralized conferencing framework document
[RFC5239], the Conference Object is a logical representation of a [RFC5239], the conference object is a logical representation of a
conference instance. The conference information schema contains core conference instance. The conference information schema contains core
information that is utilized in any conference. It also contains the information that is utilized in any conference. It also contains the
variable information part of the Conference Object. variable information part of the conference object.
The normative schema is backwards compatible with [RFC5239], in other The normative schema is backwards compatible with [RFC5239], in other
words, valid [RFC5239] instance documents are also valid according to words, valid [RFC5239] instance documents are also valid according to
this RELAX NG schema [RELAX]. In addition to approximately similar this RELAX NG schema [RELAX]. In addition to approximately similar
RELAX NG [RELAX] definitions of [RFC5239], this schema contains RELAX NG [RELAX] definitions of [RFC5239], this schema contains
extension elements in the extension elements in the
"urn:ietf:params:xml:ns:xcon-conference-info" namespace. "urn:ietf:params:xml:ns:xcon-conference-info" namespace.
default namespace = "urn:ietf:params:xml:ns:conference-info" default namespace = "urn:ietf:params:xml:ns:conference-info"
namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info" namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info"
skipping to change at page 39, line 43 skipping to change at page 39, line 34
| decision | decision
| name | name
| policy | policy
| uri | uri
| method | method
| id | id
| nickname) { text }* | nickname) { text }*
6. XML Schema Extensibility 6. XML Schema Extensibility
The Conference Information Data Model defined in this document is The conference information data model defined in this document is
meant to be extensible. Extensions are accomplished by defining meant to be extensible. Extensions are accomplished by defining
elements or attributes qualified by namespaces other than elements or attributes qualified by namespaces other than
"urn:ietf:params:xml:ns:conference-info" and "urn:ietf:params:xml:ns:conference-info" and
"urn:ietf:params:xml:ns:xcon-conference-info" for use wherever the "urn:ietf:params:xml:ns:xcon-conference-info" for use wherever the
schema allows such extensions (i.e., where the RelaxNG definition schema allows such extensions (i.e., where the RELAX NG definition
specifies "anyAttribute" or "anyElement"). specifies "anyAttribute" or "anyElement").
Elements or attributes from unknown namespaces MUST be ignored. Elements or attributes from unknown namespaces MUST be ignored.
7. XML Example 7. XML Example
The following is an example of a conference information document. The following is an example of a conference information document.
The conference starts on October 17, 2007, at 10:30 AM in New York The conference starts on October 17, 2007, at 10:30 a.m. in New York
City and finishes the same day at 12:30 PM every week. In this City and finishes the same day at 12:30 p.m. every week and repeats
example, there are currently 3 participants in a conference, one every week. In this example, there are currently three participants
administrator, one moderator, and one participant. Sidebars are in the conference: one administrator, one moderator, and one
allowed in this conference and ,consequently, there is one sidebar in participant. Sidebars are allowed in this conference and,
the conference. In addition, Alice and Carol are using a floor in consequently, there is one sidebar in the conference. In addition,
the main conference to manage the audio and video resources. At the Alice and Carol are using a floor in the main conference to manage
moment, Alice is assigned to use the floor. the audio and video resources. At the moment, Alice is assigned to
use the floor.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<conference-info <conference-info
xmlns="urn:ietf:params:xml:ns:conference-info" xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
entity="conference123@example.com"> entity="conference123@example.com">
<!-- <!--
CONFERENCE DESCRIPTION CONFERENCE DESCRIPTION
--> -->
<conference-description xml:lang="en-us"> <conference-description xml:lang="en-us">
skipping to change at page 49, line 40 skipping to change at page 49, line 29
</xcon:conference-floor-policy> </xcon:conference-floor-policy>
</xcon:floor-information> </xcon:floor-information>
</conference-info> </conference-info>
Note that due to RFC formatting conventions, this documents splits Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters. lines whose content would exceed 72 characters.
8. Security Considerations 8. Security Considerations
There are numerous security considerations for this document. This There are numerous security considerations for this document.
section discusses them. Overall, the security considerations for Overall, the security considerations for authentication and the
authentication (Section 11) and the Security and Privacy of Identity Security and Privacy of Identity described in Sections 11 and 11.2,
(Section 11.2) described in the centralized conferencing framework respectively, of the centralized conferencing framework document
[RFC5239] applies to this document. [RFC5239] apply to this document.
This specification defines a data model for conference objects. This specification defines a data model for conference objects.
Different conferencing systems may use different protocols to provide Different conferencing systems may use different protocols to provide
access to these conference objects. This section contains general access to these conference objects. This section contains general
security considerations for the conference objects and for the security considerations for the conference objects and for the
protocols. The specification of each particular protocol needs to protocols. The specification of each particular protocol needs to
discuss how the specific protocol meets the security requirements discuss how the specific protocol meets the security requirements
provided in this section. provided in this section.
A given conferencing system usually supports different protocols in A given conferencing system usually supports different protocols in
order to implement different functions (e.g., SIP for session control order to implement different functions (e.g., SIP for session control
and BFCP for floor control). Each of these protocols may use their and BFCP for floor control). Each of these protocols may use its own
own authentication mechanism. In cases where a user is authenticated authentication mechanism. In cases where a user is authenticated
using multiple authentication mechanisms, it is up to the using multiple authentication mechanisms, it is up to the
conferencing system to map all the different authentications to the conferencing system to map all the different authentications to the
same user. Discussing the specifics of different authentication same user. Discussing the specifics of different authentication
mechanism is beyond the scope of this document. mechanism is beyond the scope of this document.
Furthermore, users may use different identifiers to access to a Furthermore, users may use different identifiers to access a
conference as explained in Section 4.6.5. These different namespaces conference, as explained in Section 4.6.5. These different
can be associated with a unique conference user identifier (XCON- namespaces can be associated with a unique conference user identifier
USERID). A mapping database is used to map all these authenticated (XCON-USERID). A mapping database is used to map all these
user namespaces to the XCON-USERID. There are several threats authenticated user namespaces to the XCON-USERID. There are several
against this database. In order to minimize these threats, the threats against this database. In order to minimize these threats,
administrator of the conferencing system MUST ensure that only the administrator of the conferencing system MUST ensure that only
authorized users can connect to this database (e.g., by using access authorized users can connect to this database (e.g., by using access
control rules). In particular, the integrity of the database MUST be control rules). In particular, the integrity of the database MUST be
protected against unauthorized modifications. In addition to that, protected against unauthorized modifications. In addition, the XCON-
the XCON-USERID or XCON-URI SHOULD be hard to guess. It is critical USERID or XCON-URI SHOULD be hard to guess. It is critical that the
that the URI remain difficult to "guess" via brute force methods. URI remain difficult to "guess" via brute force methods. Generic
Generic security considerations for usage of URIs are discussed in security considerations for usage of URIs are discussed in [RFC3986].
[RFC3986].
It is RECOMMENDED the database uses encryption mechanisms if the It is RECOMMENDED that the database uses encryption mechanisms if the
information is stored in long term storage (e.g., disk). If the information is stored in long-term storage (e.g., disk). If the
database contains sensitive elements (e.g., passwords) the database contains sensitive elements (e.g., passwords), the
confidentiality of the database MUST be protected from unauthorized confidentiality of the database MUST be protected from unauthorized
users. If no sensitive elements is present then confidentiality is users. If no sensitive elements are present, then confidentiality is
not needed. In addition to implementing access control, as discussed not needed. In addition to implementing access control, as discussed
above, it is RECOMMENDED that administrators of conferencing systems above, it is RECOMMENDED that administrators of conferencing systems
only provide access to the database over encrypted channels (e.g., only provide access to the database over encrypted channels (e.g.,
using TLS encryption) in order to avoid eavesdroppers. using TLS encryption) in order to avoid eavesdroppers.
Administrators of conferencing systems SHOULD also avoid disclosing Administrators of conferencing systems SHOULD also avoid disclosing
information to unauthorized parties when a conference is being cloned information to unauthorized parties when a conference is being cloned
or when a sidebar is being created. For example, an external sidebar or when a sidebar is being created. For example, an external sidebar
as defined in [RFC5239], section 9.4.2, may include participants who as defined in [RFC5239], Section 9.4.2, may include participants who
were not authorized for the parent conference. were not authorized for the parent conference.
The security considerations for authentication (Section 11.1) The security considerations for authentication described in Section
described in the centralized conferencing framework [RFC5239] also 11.1 of the centralized conferencing framework document [RFC5239]
apply to this document. Similarly, the security considerations for also apply to this document. Similarly, the security considerations
authorization (Section 5.2) described in the Session Initiation for authorization described in Section 5.2 of the Session Initiation
Protocol (SIP) REFER Method [RFC3515] apply to this document as well. Protocol (SIP) REFER Method [RFC3515] apply to this document as well.
Note that the specification of the privacy policy is outside the Note that the specification of the privacy policy is outside the
scope of this document. Saying that, a privacy policy will be needed scope of this document. Saying that, a privacy policy will be needed
in the real implementation of the data model and, therefore, is in the real implementation of the data model and, therefore, is
subject to future policy documents. subject to future policy documents.
9. IANA Considerations 9. IANA Considerations
9.1. Relax NG Schema Registration 9.1. RELAX NG Schema Registration
This specification registers a schema. The schema can be found This specification registers a schema. The schema can be found
as the sole content of Section 5. as the sole content of Section 5.
URI: urn:ietf:params:xml:schema:xcon-conference-info URI: urn:ietf:params:xml:schema:xcon-conference-info
Registrant Contact: IETF XCON working group, Registrant Contact: IETF XCON working group <xcon@ietf.org>,
<xcon@ietf.org>, Oscar Novo Oscar Novo <Oscar.Novo@ericsson.com>
<Oscar.Novo@ericsson.com>
Relax NG Schema: The Relax NG schema to be registered is contained RELAX NG Schema: The RELAX NG schema to be registered is contained
in Section 5. Its first line is in Section 5. Its first line is as follows:
default namespace = "urn:ietf:params:xml:ns:conference-info" default namespace = "urn:ietf:params:xml:ns:conference-info"
and its last line is and its last line is as follows:
anyAttribute = attribute * - (xml:lang | entity anyAttribute = attribute * - (xml:lang | entity
| required-participant | label | decision | name | required-participant | label | decision | name
| policy | uri | method | id | nickname) { text }* | policy | uri | method | id | nickname) { text }*
9.2. XML Namespace Registration 9.2. XML Namespace Registration
This section registers a new XML namespace. This section registers a new XML namespace.
URI: urn:ietf:params:xml:ns:xcon-conference-info URI: urn:ietf:params:xml:ns:xcon-conference-info
Registrant Contact: IETF XCON working group, Registrant Contact: IETF XCON working group <xcon@ietf.org>,
<xcon@ietf.org>, Oscar Novo Oscar Novo <Oscar.Novo@ericsson.com>
<Oscar.Novo@ericsson.com>
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title> Centralized Conferencing Namespace</title> <title> Centralized Conferencing Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Centralized Conferencing</h1> <h1>Namespace for Centralized Conferencing</h1>
<h2>urn:ietf:params:xml:ns:xcon-conference-info</h2> <h2>urn:ietf:params:xml:ns:xcon-conference-info</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc6501.txt">
[NOTE TO IANA/RFC-EDITOR: RFC 6501</a>.</p>
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body> </body>
</html> </html>
END END
9.3. Conference Object Identifier Registration 9.3. Conference Object Identifier Registration
The IANA is requested to register the following URI scheme
under the Permanent URI Schemes registry.
XCON-URI = "xcon" ":" [conf-object-id "@"] host
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
host and unreserved are defined in [RFC3986]
URI scheme name: xcon URI scheme name: xcon
Status: permanent Status: permanent
URI scheme syntax: see Section 3.3.1. URI scheme syntax: see Section 3.3.1.
URI schema semantics: see Section 3.3 URI schema semantics: see Section 3.3
Encoding considerations: see Section 8 Encoding considerations: see Section 8
Intended usage: see Section 3.3 Intended usage: see Section 3.3
Applications and/or protocols that use this URI scheme name: Applications and/or protocols that use this URI scheme name:
Centralized Conferencing systems Centralized Conferencing systems
Interoperability considerations: none Interoperability considerations: none
Security considerations: see Section 8 Security considerations: see Section 8
Relevant publications: Conference Information Data Model for Relevant publications: conference information data model for
Centralized Conferencing (XCON) Centralized Conferencing (XCON)
Contact: Oscar Novo<oscar novo_at_ericsson.com> Contact: Oscar Novo <oscar.novo@ericsson.com>
Author/Change controller: Oscar Novo<oscar novo_at_ericsson.com> Author/Change controller: Oscar Novo <oscar.novo@ericsson.com>
9.4. Conference User Identifier Registration 9.4. Conference User Identifier Registration
The IANA is requested to register the following URI scheme URI scheme name: XCON-USERID
under the Permanent URI Schemes registry.
XCON-USERID = "xcon-userid" ":" conf-user-id
conf-user-id = 1*unreserved
unreserved is defined in [RFC3986]
URI scheme name: xcon-userid
Status: permanent Status: permanent
URI scheme syntax: see Section 4.6.5 URI scheme syntax: see Section 4.6.5
URI schema semantics: see Section 4.6.5 URI schema semantics: see Section 4.6.5
Encoding considerations: see Section 8 Encoding considerations: see Section 8
Intended usage: see Section 4.6.3 and 4.6.5 Intended usage: see Section 4.6.3 and 4.6.5
Applications and/or protocols that use this URI scheme name: Applications and/or protocols that use this URI scheme name:
Centralized Conferencing systems. Centralized Conferencing systems.
Interoperability considerations: none Interoperability considerations: none
Security considerations: see Section 8 Security considerations: see Section 8
Relevant publications: Conference Information Data Model for Relevant publications: conference information data model for
Centralized Conferencing (XCON) Centralized Conferencing (XCON)
Contact: Oscar Novo<oscar novo_at_ericsson.com> Contact: Oscar Novo <oscar.novo@ericsson.com>
Author/Change controller: Oscar Novo<oscar novo_at_ericsson.com> Author/Change controller: Oscar Novo <oscar.novo@ericsson.com>
10. Acknowledgements 10. Acknowledgements
This document is really a distillation of many ideas discussed over a This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. We documents in the XCON working group and the SIPPING working group.
would like to thank Orit Levin, Roni Even, Adam Roach, Mary Barnes, We would like to thank Orit Levin, Roni Even, Adam Roach, Mary
Chris Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Barnes, Chris Boulton, Umesh Chandra, Hisham Khartabil, Petri
Aki Niemi, Rohan Mahy, Jonathan Lennox, Sean Duddy, Richard Barnes, Koskelainen, Aki Niemi, Rohan Mahy, Jonathan Lennox, Sean Duddy,
and Henning Schulzrinne for their comments. Also, we would like to Richard Barnes, and Henning Schulzrinne for their comments. Also, we
thank Mary Barnes, and Chris Boulton for letting us use the would like to thank Mary Barnes and Chris Boulton for letting us use
conference and user identifier information of their xcon drafts. the conference and user identifier information of their XCON
Last but not least, we would like to express our gratitude to all documents. Last but not least, we would like to express our
those reviewers for their invaluable contribution: Simon Pietro gratitude to all those reviewers for their invaluable contributions:
Romano, Lorenzo Miniero, Tobia Castaldi, Miguel Garcia, Mary Barnes, Simon Pietro Romano, Lorenzo Miniero, Tobia Castaldi, Miguel Garcia,
Srivatsa Srinivasan, Avshalom Houri, Pierre Tane, and Ben Campbell. Mary Barnes, Srivatsa Srinivasan, Avshalom Houri, Pierre Tane, and
Ben Campbell.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
skipping to change at page 54, line 43 skipping to change at page 54, line 16
Initiation Protocol (SIP) Event Package for Conference Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006. State", RFC 4575, August 2006.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams", for Binary Floor Control Protocol (BFCP) Streams",
RFC 4583, November 2006. RFC 4583, November 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545, Core Object Specification (iCalendar)", RFC 5545,
September 2009. September 2009.
11.2. Informative References 11.2. Informative References
[IANA] "IANA registry for RTP Payload Types" [IANA] IANA, "RTP Payload Types",
"http://www.iana.org/assignments/rtp-parameters". <http://www.iana.org/assignments/rtp-parameters>.
[IANA-Lan] [IANA-Lan] IANA, "Language Subtag Registry",
"IANA Language Subtag Registry" <http://www.iana.org/assignments/
"http://www.iana.org/assignments/ language-subtag-registry>.
language-subtag-registry".
[RELAX] "RELAX NG Home Page" "ISO/IEC 19757-2:2008". [RELAX] "RELAX NG Home Page", ISO/IEC 19757-2:2008.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, Session Initiation Protocol (SIP)", RFC 4353,
skipping to change at page 55, line 38 skipping to change at page 55, line 12
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC5018] Camarillo, G., "Connection Establishment in the Binary [RFC5018] Camarillo, G., "Connection Establishment in the Binary
Floor Control Protocol (BFCP)", RFC 5018, September 2007. Floor Control Protocol (BFCP)", RFC 5018, September 2007.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Sperberg-McQueen, C., Yergeau, F., Bray, T., Paoli, J., Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
Appendix A. Non-Normative RELAX NG Schema in XML Syntax Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<grammar <grammar
ns="urn:ietf:params:xml:ns:conference-info" ns="urn:ietf:params:xml:ns:conference-info"
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
skipping to change at page 83, line 28 skipping to change at page 84, line 12
</define> </define>
</grammar> </grammar>
Appendix B. Non-Normative W3C XML Schema Appendix B. Non-Normative W3C XML Schema
The non-normative W3C XML schema defines extension elements in the The non-normative W3C XML schema defines extension elements in the
"urn:ietf:params:xml:ns:xcon-conference-info" namespace. Note that "urn:ietf:params:xml:ns:xcon-conference-info" namespace. Note that
<xs:any> extensions in this schema are stricter than in the normative <xs:any> extensions in this schema are stricter than in the normative
RELAX NG schema [RELAX], and the normative RELAX NG schema [RELAX] RELAX NG schema [RELAX], and the normative RELAX NG schema [RELAX]
allows unordered child elements unlike this schema (and the [RFC4575] allows unordered child elements unlike this schema (and the [RFC4575]
schema). Also note that this schema allows also otherwise valid schema). Also, note that this schema allows otherwise valid
extension elements to appear in the non-allowed positions. Likewise extension elements to appear in the non-allowed positions. Likewise,
the cardinalities of these extension elements can not be constrained the cardinalities of these extension elements cannot be constrained
with this schema. with this schema.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
xmlns="urn:ietf:params:xml:ns:xcon-conference-info" xmlns="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified" elementFormDefault="qualified" attributeFormDefault="unqualified" elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info"> targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info">
skipping to change at page 93, line 13 skipping to change at page 94, line 13
</xs:schema> </xs:schema>
Authors' Addresses Authors' Addresses
Oscar Novo Oscar Novo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Oscar.Novo@ericsson.com EMail: Oscar.Novo@ericsson.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
David P. Morgan David P. Morgan
Fidelity Investments Fidelity Investments
82 Devonshire St, MZ V3C 82 Devonshire St, MZ V3C
Boston, MA 02109-3614 Boston, MA 02109-3614
USA USA
Email: Dave.Morgan@fmr.com EMail: Dave.Morgan@fmr.com
Jari Urpalainen Jari Urpalainen
Nokia Nokia
Itamerenkatu 11-13 Itamerenkatu 11-13
Helsinki 00180 Helsinki 00180
Finland Finland
Phone: +358 7180 37686 Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com EMail: jari.urpalainen@nokia.com
 End of changes. 178 change blocks. 
460 lines changed or deleted 449 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/