From: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-05.txt Title: Conference Information Data Model for Centralized Conferencing (XCON) Reference: IETF Centralized Conferencing (XCON) Working Group, Internet Draft 'draft-ietf-xcon-common-data-model-05.txt' Date: April 17, 2007 I-D Tracker: http://ietfreport.isoc.org/idref/draft-ietf-xcon-common-data-model/ IETF Centralized Conferencing (XCON) Working Group Charter http://www.ietf.org/html.charters/xcon-charter.html Centralized Conferencing Status Pages http://tools.ietf.org/wg/xcon XCON: Centralized Conferencing Working Group Supplemental Home Page http://www.softarmor.com/xcon/ IETF Real-time Applications and Infrastructure http://www.ietf.org/html.charters/wg-dir.html#Real-time%20Applications%20and%20Infrastructure%20Area ============================================================================== XCON O. Novo Internet-Draft G. Camarillo Intended status: Standards Track Ericsson Expires: October 19, 2007 D. Morgan Fidelity Investments R. Even Polycom April 17, 2007 Conference Information Data Model for Centralized Conferencing (XCON) draft-ietf-xcon-common-data-model-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference object, which can be manipulated using a conference control protocol, at a conference server represents a Novo, et al. Expires October 19, 2007 [Page 1] Internet-Draft Data Model Schema April 2007 particular instantiation of this data model. The conference information data model defined in this document is an extension of (and thus, compatible with) the model specified in the Session Initiation Protocol (SIP) Event Package for Conference State. Novo, et al. Expires October 19, 2007 [Page 2] Internet-Draft Data Model Schema April 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Data Model Structure . . . . . . . . . . . . . . . . . . . 6 3.2. Role Definitions . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Role in a Floor . . . . . . . . . . . . . . . . . . . 8 3.2.2. Changing Roles . . . . . . . . . . . . . . . . . . . . 8 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 8 4.1. . . . . . . . . . . . . . . . . . 13 4.1.1. . . . . . . . . . . . . . . . . . . 14 4.1.2. . . . . . . . . . . . . . . . . . . . . . 15 4.1.3. . . . . . . . . . . . . . . . . . . . . 16 4.1.4. . . . . . . . . . . . . . . . . . 16 4.1.5. . . . . . . . . . . . . . . . . . . 16 4.1.5.1. . . . . . . . . . . . . . . . . . . . . 17 4.1.5.1.1. mute . . . . . . . . . . . . . . . . . . . . . 17 4.1.5.1.2. pause-video . . . . . . . . . . . . . . . . . 17 4.1.5.1.3. gain . . . . . . . . . . . . . . . . . . . . . 18 4.1.5.1.4. video-layout . . . . . . . . . . . . . . . . . 18 4.2. . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. . . . . . . . . . . . . . . . . . . . . 19 4.4. . . . . . . . . . . . . . . . . . . . 19 4.5. . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.1. . . . . . . . . . . . . . . . . . 22 4.5.2. . . . . . . . . . . . . . . . . . . . . . . . . 22 4.5.2.1. , . . . . . . . . . . . . . 24 4.5.2.1.1. . . . . . . . . . . . . . . . . . . . 24 4.5.3. . . . . . . . . . . . . . . . . . . 24 4.5.4. . . . . . . . . . . . . . . . . . . 24 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 25 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 32 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 9.1. Conference Relax NG Schema Registration . . . . . . . . . 41 9.2. Conference Namespace Registration . . . . . . . . . . . . 41 9.3. Conference Object Identifier Registration . . . . . . . . 41 9.4. Conference User Identifier Registration . . . . . . . . . 42 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . . 42 11.2. Informative References . . . . . . . . . . . . . . . . . . 42 Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Intellectual Property and Copyright Statements . . . . . . . . . . 68 Novo, et al. Expires October 19, 2007 [Page 3] Internet-Draft Data Model Schema April 2007 1. Introduction Conference objects are a fundamental concept in Centralized conferencing, as described in the XCON Conferencing Framework [4]. A conference object contains data that represents a conference during each of its various stages (e.g., reserved, started, running, ended, etc.). Conference Objects are instantiations of the conference information data model defined in this document. Consequently, conference objects follow the XML format defined in this document. A conference object contains the core information of a conference (i.e., capabilities, membership, roles, call control signaling, media, etc.) and specifies who, and in which way, can manipulate that information. Figure 1 shows logical functional elements of a conference server as defined by the XCON Conferencing Framework [4]. They are a Conference Control Server, a Floor Control Server, a number of Foci, and a Notification Service. A conference control protocol provides the interface between a conference and media control client, and the conference control server. A floor control protocol (e.g., BFCP [5]) provides the interface between a floor control client and the floor control server. A call signaling protocol (e.g., SIP, H.323, PSTN, etc.) provides the interface between a call signaling client and a Focus. A notification protocol (e.g., SIP-based event notifications [6]) provides the interface between the conferencing client and the Notification Service. Within a conference, the conference control server, floor control server, and focus can modify the information in the conference object. Novo, et al. Expires October 19, 2007 [Page 4] Internet-Draft Data Model Schema April 2007 ............................................................... . Conferencing Server . . +---------------------------------------------------+ . . | C o n f e r e n c e o b j e c t | . . +-+--------------------------------------------------+| . . | C o n f e r e n c e o b j e c t || . . +-+---------------------------------------------------+|| . . | C o n f e r e n c e o b j e c t ||| . . | +--------------------------------------------------+||| . . | | Conference Information Data Model |||| . . | | +----------------------------------------------+ |||| . . | | | Conference description (times, duration) | |||| . . | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| . . | | | Host information | |||| . . | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| . . | | | Conference state | |||| . . | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| . . | | | Floor information | |||| . . | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| . . | | | Membership (users, roles, capacity) | |||| . . | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| . . | | | Sidebars, Etc. | |||| . . | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| . . | | | Etc. | |||| . . | | +----------------------------------------------+ |||+ . . | +--------------------------------------------------+|+ . . +----^------------------^-------------^--------|------+ . . | | | | . . +------v-------+ +--------v-----+ +-----v-+ +----v-------+ . . | Conference | | Floor | | | | | . . | Control | | Control | |Foci | |Notification| . . | Server | | Server | | | |Service | . . +-----^--------+ +---^----------+ +-^-----+ +------------+ . ........|..............|..............|..........|............. |Conference |Binary Floor |Call |Notification |Control |Control |Signaling |Protocol |Protocol |Protocol |Protocol | ........v..............v..............v..........v............. . C o n f e r e n c i n g C l i e n t . ............................................................... Figure 1: Conference Server Architecture Novo, et al. Expires October 19, 2007 [Page 5] Internet-Draft Data Model Schema April 2007 The Session Initiation Protocol (SIP) Event Package for Conference State, specified in RFC 4575 [1], already defines a data model for conferences. However, that model is SIP specific and lacks elements related to some of the functionality defined by the XCON conferencing framework [4] (e.g., floor control). The data model defined in this document extends the one defined in RFC 4575 [1]. The result is a data model that supports more call signaling protocols besides SIP and that covers all the functionality defined in the XCON conferencing framework [4]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. This document uses the terminology defined in the XCON Conferencing Framework [4], the SIP conferencing framework [7] and the BFCP (Binary Floor Control Protocol) specification [5]. Readers of this document are supposed to be familiar with the terminology used in those documents. 3. Overview The data model defined in this document is the result of extending the data model defined in RFC 4575 [1] with new elements, which carry information such as non-SIP URIs or floor-control-related parameters. This data model can be used by conference servers providing different types of basic conferences. It is expected that this data model can be further extended with new elements in the future in order to implement advanced features. 3.1. Data Model Structure The information in this data model is structured in the following manner. All the information related to a conference is contained in a element. The element contains the following child elements: o The element describes the conference as a whole. It has, for instance, information about the URI of the conference, maximum users allowed in the conference, media available in the conference, or the time the conference will start. o The element contains information about the entity hosting the conference (e.g., its URI). Novo, et al. Expires October 19, 2007 [Page 6] Internet-Draft Data Model Schema April 2007 o The element informs the subscribers about the changes in the overall conference information. o The element contains information about the status of the different floors in the conference. o The element describes the membership information as a whole. The element contains a set of child elements, each describing a single participant in the conference. o If a participant in the main conference joins a sidebar, a new element is created in the conference referenced from the element or under one of the elements. 3.2. Role Definitions This section defines five logical roles for a Conference System to represent participants within a Conference Object. In hierarchical order they are: "administrator", "creator", "moderator", "participant", and "observer". A set of semantics associated with each role is out of the scope of this document. A Conference System MAY choose not to support a particular role. As well, additional roles may be defined in the future, as necessary, with their corresponding schema extensions. These five roles have an intrinsic hierarchical order within a specific conference. By hierarchical order, it is implied that the "administrator" by default SHOULD have higher privileges than a "creator", which by default SHOULD have higher privileges than a "moderator" and so on. For example, the "administrator" SHOULD have the ability to make changes to all conference variables during instantiation and full lifecycle of the Conference Object. The "creator" is the 'owner' of the conference and has various privileges which SHOULD allow them to modify the conference variables up to the time the conference is instantiated. The "moderator" is a logical entity that will manage the conference. The "participant" is a logical entity with generic privileges that will be attending a conference. The "observer" is a logical entity which can only receive media streams from the conference. All Conference Systems MUST have a role defined as "participant". Each user participating in a conference instance is an entity that can assume one or more roles. Any entity can be allocated to an appropriate logical role. A role can also be assumed in conjunction with the users identity within the Conference System as a result of an identity assertion transaction on the Conference System. If no roles are defined for an entity, they SHOULD by default be a "participant" but local policy MAY define an alternative. Novo, et al. Expires October 19, 2007 [Page 7] Internet-Draft Data Model Schema April 2007 3.2.1. Role in a Floor Floor control in centralized conferencing is described in the Binary Floor Control Protocol (BFCP) [5]. Floors can be specified in the Conference System or created dynamically. Users can be added or deleted from a floor when the conference is active. A floor chair is a logical entity that manages a floor (grants, denies, or revokes a floor). The floor chair is usually in an "administrator", "moderator", or "creator" role. A floor participant is a logical entity that requests floors, and possibly information about them from a floor control server. They are usually in a "participant" or even a "moderator" role [5]. Users in a conference MAY assume different roles in different floors. They MAY also assume different roles in the same floor, as floor transactions are processed. 3.2.2. Changing Roles Users can change roles during a conference. This can be done in two ways: First, the user can join a new floor in a different role. Second, an "administrator" or "creator" can dynamically change that user's role. This can be accomplished before the conference is instantiated, or during the conference, using an appropriate conference control protocol. A logical entity whose role has been changed will typically have access to the media streams associated with that role. 4. Data Model Definition A conference object document is an XML [8] document that MUST be well formed and SHOULD be valid. Conference object data model documents MUST be based on XML 1.0 and SHOULD be encoded using UTF-8. A conference object document begins with the root element tag , which is defined in [1]. The element has an 'entity' attribute that contains a conference object identifier (XCON-URI) that identifies the conference being described in the document. A conferencing system may maintain a relationship between the conference object identifiers and the identifiers associated with each of the complimentary centralized conferencing protocols (e.g., call signaling protocols, BFCP, etc.). This implicit binding provides a structured mapping of the various Novo, et al. Expires October 19, 2007 [Page 8] Internet-Draft Data Model Schema April 2007 protocols with the associated conference object Identifier. Figure 2 illustrates the relationship between the identifiers used for the protocols within the framework [4] and the general XCON-URI. +--------------------------+ | Conference | | Object | | Identifier | +--------------------------+ | xcon:Ji092i@example.com | +------+-------------------+ | | | +-----------------+---------------+ | | +-----------+-----------+ +-------+-------+ | CSP Conference IDs | | BFCP 'confid' | +-----------------------+ +---------------+ |h323:Ji092i@example.com| | Ji092i | |tel:+44(0)2920930033 | +-------+-------+ |sip:Ji092i@example.com | | +-----------------------+ +-------|-------+ | BFCP 'floorid | +---------------+ | UEK78d | | 09cnJk | +---------------+ Figure 2: Conference Object Mapping Further elements can be added to the tree representation in Figure 2 to enable a complete representation of a conference instance within a conferencing system. The element contains the , , , , , , child elements. All these elements, except , are defined in [1]. A conference document MUST at least include the , , , and child elements. The following non-normative diagram shows the structure of conference object documents. The operator "!" preceding an element indicates that the element is mandatory in the data model. The operator "*" Novo, et al. Expires October 19, 2007 [Page 9] Internet-Draft Data Model Schema April 2007 following an element indicates that the element is introduced and defined in this document. That is, elements without a "*" have already been defined in RFC 4575 [1]. ! | |--! | |-- | |-- | |--* | |-- | |--* | |--* | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | ... | |-- | | |--* | | | |-- | | | |-- | | | |-- | | |--* | | | |--* | | | |--* | | |--* | | | |--* | | ... | |-- | | |--* | | | |-- | | | |-- | | | |-- | | |--* | | | |--* | | | |--* | | |--* | | | |--* | | ... | |-- | | ... | |--! Novo, et al. Expires October 19, 2007 [Page 10] Internet-Draft Data Model Schema April 2007 | | |--! | | | |-- | | | |-- | | | |-- | | | |--* | | | |--* | | | |--* | | | | |--* | | | | |--* | | | | ... | | | |--* | | | | |--* | | | | |--* | | | | ... | | |-- | | | |-- | | | |-- | | | |-- | | | |--* | | | |--* | | | |--* | | | | |--* | | | | |--* | | | | ... | | | |--* | | | | |--* | | | | |--* | | | | ... | | ... | |-- | |-- | |-- | |--! | | |--! | | | |--! | | | |-- | | |--* | | | |--* | | | |--* | | |--* | | | |--* | ... |-- | |--* | |-- | |--! | |-- Novo, et al. Expires October 19, 2007 [Page 11] Internet-Draft Data Model Schema April 2007 | |--* | |--* | |--* | |--* | |--* | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | | ... | | ... | |--! | |--* | |--* | |--* | | |--* | | |-- ... | | | | | |--! | | |-- | | |-- | | |--* | | |-- | | | | | | | ... | | |-- | | |-- | | |--* | | |--* | | |--* | | |--! | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |--! | | | | |-- | | | | |-- | | | | |--