From: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-06.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-06.txt' Date: October 31, 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 Announced: http://article.gmane.org/gmane.ietf.announce/21579/match=ietf+announce+xml ============================================================================== XCON O. Novo Internet-Draft G. Camarillo Intended status: Standards Track Ericsson Expires: May 3, 2008 D. Morgan Fidelity Investments R. Even Polycom October 31, 2007 Conference Information Data Model for Centralized Conferencing (XCON) draft-ietf-xcon-common-data-model-06.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 May 3, 2008. 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 information data model is designed to convey information about the conference and about participation in the Novo, et al. Expires May 3, 2008 [Page 1] Internet-Draft Data Model Schema October 2007 conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 6 3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 6 3.3. The Conference Object Identifier . . . . . . . . . . . . . 7 3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 8 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 9 4.1. . . . . . . . . . . . . . . . . . . . . 12 4.2. . . . . . . . . . . . . . . . . . 13 4.2.1. . . . . . . . . . . . . . . . . . . . . 13 4.2.2. . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. . . . . . . . . . . . . . . . . . . . . . 13 4.2.4. . . . . . . . . . . . . . . . . . . . . . . 13 4.2.5. . . . . . . . . . . . . . . . . . . . 13 4.2.6. . . . . . . . . . . . . . . . . . . 14 4.2.7. . . . . . . . . . . . . . . . . . . . . . 15 4.2.8. . . . . . . . . . . . . . . . . . . . . 15 4.2.9. . . . . . . . . . . . . . . . . . 15 4.2.10. . . . . . . . . . . . . . . . . . . 15 4.3. . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. . . . . . . . . . . . . . . . . . . . . 18 4.4.1. . . . . . . . . 18 4.4.2. . . . . . . . . . . . . . . . . . . . . . 18 4.4.3. . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.4. . . . . . . . . . . . . . . . . . . . . . . . 19 4.5. . . . . . . . . . . . . . . . . . . . 19 4.5.1. . . . . . . . . . . . . . . . . . . . 19 4.5.2. . . . . . . . . . . . . . . . . . 19 4.5.3. . . . . . . . . . . . . . . . 19 4.5.4. . . . . . . . . . . . . . . 20 4.6. . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6.1. . . . . . . . . . . . . . . . . . . . 21 4.6.2. . . . . . . . . . . . . . . . 21 4.6.3. . . . . . . . . . . . . . . . . . 22 4.6.4. and Its Sub-elements . . . . . . . . . . 22 4.6.4.1. . . . . . . . . . . . . . . . . . . 23 4.6.4.2. . . . . . . . . . . . . . . . . 23 4.6.4.3. . . . . . . . . . . . . . . . 24 4.6.4.4. . . . . . . . . . . . . . . . . . . . . . 24 4.6.4.5. . . . . . . . . . . . . . . . . . . . 24 Novo, et al. Expires May 3, 2008 [Page 2] Internet-Draft Data Model Schema October 2007 4.6.4.6. . . . . . . . . . . . . . . . . . 24 4.6.4.7. . . . . . . . . . 24 4.6.4.8. . . . . . . . . . 24 4.6.4.9. . . . . . . . . . 25 4.6.4.10. . . . . . . . . . . . . . . . . . . . . 25 4.7. . . . . . . . . . . . . . . . . . . . . 26 4.8. . . . . . . . . . . . . . . . . . . . . 26 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 26 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 33 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 41 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 42 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 9.1. Conference Relax NG Schema Registration . . . . . . . . . 42 9.2. Conference Namespace Registration . . . . . . . . . . . . 42 9.3. Conference Object Identifier Registration . . . . . . . . 42 9.4. Conference User Identifier Registration . . . . . . . . . 43 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . . 43 Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 Intellectual Property and Copyright Statements . . . . . . . . . . 65 Novo, et al. Expires May 3, 2008 [Page 3] Internet-Draft Data Model Schema October 2007 1. Introduction There is a core data set of conference information that is utilized in any conference, independent of the specific conference media. This core data set called the 'conference information data model' is defined in this document using an Extensible Markup Language (XML)- based. The conference information data model defined in this document is logically represented by the conference object. Conference objects are a fundamental concept in Centralized Conferencing, as described in the Centralized Conferencing Framework [4]. A conference object contains data that represents a conference during each of its various stages (e.g., created/creation, reserved/ reservation, active/activation, completed/completion). A conference object can be manipulated using a conference control protocol at a conference server. The conference object represents a particular instantiation of a conference information data model. 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, call control signaling, media, etc.) and specifies who, and in which way that information can be manipulated. Figure 1 shows the logical functional elements of a conference server as defined by the Centralized 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 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, Q.931, ISUP, 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 May 3, 2008 [Page 4] Internet-Draft Data Model Schema October 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, 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 May 3, 2008 [Page 5] Internet-Draft Data Model Schema October 2007 The Session Initiation Protocol (SIP) Event Package for Conference State, specified in RFC4575 [1], already defines a data format for conferences. However, that model is SIP specific and lacks elements related to some of the functionality defined by the Centralized Conferencing Framework [4] (e.g., floor control). The data model defined in this document constitutes a superset of the data format defined in RFC4575 [1]. The result is a data format that supports more call signaling protocols besides SIP and that covers all the functionality defined in the Centralized 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 Centralized Conferencing Framework [4], the SIPPING conferencing framework [7] and the BFCP (Binary Floor Control Protocol) specification [5]. Readers of this document should be familiar with the terminology used in those documents. 3. Overview The data model specified in this document is the result of extending the data format defined in RFC4575 [1] with new elements. Examples of such extensions include scheduling elements, media control elements, floor control elements, non-SIP URIs, and addition of localization extensions to text elements. 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 additional advanced features. 3.1. Data Model Format A conference object document is an XML [8] document that MUST be well formed and SHOULD be valid. Conference object documents MUST be based on XML 1.0 and SHOULD be encoded using UTF-8. 3.2. Data Model Namespace This specification defines a new namespace specification for identifying the elements defined in the data model. This namespace is as follows: Novo, et al. Expires May 3, 2008 [Page 6] Internet-Draft Data Model Schema October 2007 urn:ietf:params:xml:ns:xcon-conference-info 3.3. The Conference Object Identifier The conference object identifier (XCON-URI) can be viewed as a key to accessing a specific conference object. It can be used, for instance, by the conference control protocol to access, manipulate and delete a conference object. A conference object identifier is provided to the conferencing client by the conference notification service or through out-of-band mechanisms (e.g. E-Mail). A conferencing system may maintain a relationship between the conference object identifiers and the identifiers associated with each of the complementary centralized conferencing protocols (e.g., call signaling protocols, BFCP, etc.). To facilitate the maintenance of these relationships, the conference object identifier acts as a top level identifier within the conferencing system for the purpose of identifying the interfaces for these other protocols. This implicit binding provides a structured mapping of the various protocols with the associated conference object Identifier. Figure 2 illustrates the relationship between the identifiers used for the protocols and the general conference object identifier (XCON-URI). +--------------------------+ | Conference | | Object | | Identifier | +--------------------------+ | xcon:Ji092i@example.com | +------+-------------------+ | | | +-----------------+---------------+ | | +-----------+-----------+ +----------+---------+ | CSP Conference IDs | |BFCP 'Conference ID'| +-----------------------+ +--------------------+ |h323:Ji092i@example.com| | Ji092i | |tel:+44(0)2920930033 | +----------+---------+ |sip:Ji092i@example.com | | +-----------------------+ +-------|--------+ | BFCP 'Floor ID'| +----------------+ | 543 | | 09cnJk | +----------------+ Novo, et al. Expires May 3, 2008 [Page 7] Internet-Draft Data Model Schema October 2007 Figure 2: Conference Object Mapping In Figure 2, the conference object identifier acts as the top level key in the identification process. The call signaling protocols have an associated conference user identifier, often represented in the form of URIs. The binary floor control protocol, as defined in [5], defines the 'conference ID' identifier which represents a conference instance within floor control. When created within the conferencing system, the 'conference ID' has a 1:1 mapping to the unique conference object Identifier(XCON-URI). Operations associated with the conference control protocols are directly associated with the conference object, thus the primary identifier associated with these protocols is the conference object identifier(XCON-URI). The mappings between additional protocols/interface is not strictly 1:1 and does allow for multiple occurrences. For example, multiple call signaling protocols will each have a representation that is implicitly linked to the top level conference object identifier e.g. H323 and SIP URIs that represent a conference instance. It should be noted that a conferencing system is free to structure such relationships as required and this information is just included as a guideline that can be used. 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. 3.4. 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). 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. Novo, et al. Expires May 3, 2008 [Page 8] Internet-Draft Data Model Schema October 2007 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. Note that some of the elements described above such , , , or are not defined in the data model but are defined in the data format of RFC 4575 [1]. We describe them here because they are part of the basic structure of the data model. 4. Data Model Definition 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 "*" 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 May 3, 2008 [Page 9] Internet-Draft Data Model Schema October 2007 | | | |-- | | | |-- | | | |-- | | ... | |-- | | ... | |-- | | |--! | | | |-- | | | |-- | | | |-- | | | |--* | | | |--* | | | | |--* | | | | |--* | | | | ... | | | |--* | | | | |--* | | | | |--* | | | | ... | | |-- | | | |-- | | | |-- | | | |-- | | | |--* | | | |--* | | | | |--* | | | | |--* | | | | ... | | | |--* | | | | |--* | | | | |--* | | | | ... | | ... | |-- | |-- | |-- | |-- | | |-- | | | |-- | | | |-- | ... |-- | |--* | |-- | |-- | |-- Novo, et al. Expires May 3, 2008 [Page 10] Internet-Draft Data Model Schema October 2007 | |--* | |--* | |--* | |--* | |--* | | |--* | | | |--!* | | | |--!* | | | |--* | | | |--* | | | ... | | ... | |--! | |--* | |--* | |--* | | |--* | | |-- ... | | | | | |-- | | |-- | | |-- | | |--* | | |-- | | | | | | | ... | | |-- | | |-- | | |--* | | |--* | | |--* | | |--! | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | | |-- | | | | |-- | | | | |--