Internet Engineering Task Force (IETF) O. Novo Request for Comments: 6501 G. Camarillo Category: Standards Track Ericsson ISSN: 2070-1721 D. Morgan Fidelity Investments J. Urpalainen Nokia March 2012 Conference Information Data Model for Centralized Conferencing (XCON) Abstract RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the 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. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 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. Novo, et al. Standards Track [Page 1] RFC 6501 Data Model Schema March 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction ....................................................4 2. Terminology .....................................................4 3. Overview ........................................................4 3.1. Data Model Format ..........................................5 3.2. Data Model Namespace .......................................5 3.3. The Conference Object Identifier ...........................5 3.3.1. Conference Object URI Definition ....................7 3.3.2. Normalization and Conference Object URI Comparison ..7 3.4. Data Model Structure .......................................7 4. Data Model Definition ...........................................8 4.1. .........................................12 4.2. ..................................12 4.2.1. .........................................13 4.2.2. ...................................13 4.2.3. ...................................13 4.2.4. ...................................13 4.2.5. ..................................13 4.2.6. ........................................15 4.2.7. ..................................15 Novo, et al. Standards Track [Page 2] RFC 6501 Data Model Schema March 2012 4.3. ...............................................18 4.4. ........................................18 4.4.1. ..............18 4.5. .......................................18 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. ..................................23 4.6.5. and Its Sub-Elements .................24 4.6.5.1. .......................25 4.6.5.2. ...................................26 4.6.5.3. ...........26 4.6.5.4. ..........26 4.6.5.5. ..........26 4.6.5.6. ................................27 4.7. .........................................28 4.8. .........................................28 5. RELAX NG Schema ................................................28 6. XML Schema Extensibility .......................................39 7. XML Example ....................................................39 8. Security Considerations ........................................49 9. IANA Considerations ............................................51 9.1. RELAX NG Schema Registration ..............................51 9.2. XML Namespace Registration ................................52 9.3. Conference Object Identifier Registration .................52 9.4. Conference User Identifier Registration ...................53 10. Acknowledgements ..............................................53 11. References ....................................................53 11.1. Normative References .....................................53 11.2. Informative References ...................................54 Appendix A. Non-Normative RELAX NG Schema in XML Syntax ..........56 Appendix B. Non-Normative W3C XML Schema .........................84 Novo, et al. Standards Track [Page 3] RFC 6501 Data Model Schema March 2012 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 XML-based format. 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 [RFC5239]. The conference object represents a particular instantiation of a conference information data model. Consequently, conference objects use the XML format defined in this document. The Session Initiation Protocol (SIP) event package for conference state, specified in [RFC4575], 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 [RFC5239] (e.g., floor control). The data model defined in this document constitutes a superset of the data format defined in [RFC4575]. The result is a data format that supports more call signaling protocols (CSPs) besides SIP and that covers all the functionality defined in the centralized conferencing framework [RFC5239]. 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 [RFC2119]. This document uses the terminology defined in the centralized conferencing framework [RFC5239], the SIPPING conferencing framework [RFC4353], and the BFCP (Binary Floor Control Protocol) specification [RFC4582]. 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] with new elements. Examples of such extensions include scheduling elements, media control elements, floor control elements, non-SIP URIs, and the addition of localization extensions to text elements. This data model can be used by conference servers providing different types of basic Novo, et al. Standards Track [Page 4] RFC 6501 Data Model Schema March 2012 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 [W3C.REC-xml-20081126] document. Conference object documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. The normative description of the syntax of the conference object document, for use by implementers of parsers and generators, is found in the RELAX NG schema provided in Section 5. Compliant messages MUST meet the requirements of that schema. 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: 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., email). 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 protocol, 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 1 illustrates the relationship between the identifiers used for the protocols and the general conference object identifier (XCON-URI). Novo, et al. Standards Track [Page 5] RFC 6501 Data Model Schema March 2012 +--------------------------+ | Conference | | Object | | Identifier | +--------------------------+ | xcon:Ji092i@example.com | +------+-------------------+ | | | +-----------------+---------------+ | | +-----------+-----------+ +----------+---------+ | CSP Conference IDs | |BFCP 'Conference ID'| +-----------------------+ +--------------------+ | h323:i092@example.com | | i092 | | tel:+44(0)2920930033 | +----------+---------+ | sip:i092@example.com | | +-----------------------+ +-------+--------+ | BFCP 'Floor ID'| +----------------+ | 543 | | 236 | +----------------+ Figure 1: Conference Object Mapping In Figure 1, 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 a URI. The BFCP, as defined in [RFC4582], 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/interfaces 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. Novo, et al. Standards Track [Page 6] RFC 6501 Data Model Schema March 2012 Further elements can be added to the tree representation in Figure 1 to enable a complete representation of a conference instance within a conferencing system. 3.3.1. Conference Object URI Definition The syntax is defined by the following ABNF [RFC5234] rules. XCON-URI = "xcon" ":" [conf-object-id "@"] host 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 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 to connect. 3.3.2. Normalization and Conference Object URI Comparison In order to facilitate the comparison of the XCON-URI identifiers, all the components of the identifiers MUST be converted to lowercase. After normalizing the URI strings, the URI comparison MUST be applied on a character-by-character basis as prescribed by [RFC3986], Section 6.2.1. The host construction, as defined in RFC 3986, can take the form of an IP address, which is not conventionally compared on a character- 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- by-character comparison still applies. 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). Novo, et al. Standards Track [Page 7] RFC 6501 Data Model Schema March 2012 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. Note that some of the elements described above such as , , , or are not defined in the data model in this specification but are defined in the data format of [RFC4575]. 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 symbol "!" preceding an element indicates that the element is REQUIRED in the data model. The symbol "*" following an element indicates that the element is introduced and defined in this document. That is, elements without a "*" have already been defined in [RFC4575]. ! | |-- | |--* | |-- | |-- | |-- | |-- | |--* | |--* | |--* | |--* | | |--* | | | |--* | | | |--* | | | |--* | | | |--* | | | |--* Novo, et al. Standards Track [Page 8] RFC 6501 Data Model Schema March 2012 | | | |--* | | | |--* | | | |--* | | ... | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |--* | | ... | |-- | | |-- | | | |-- | | | |-- | | | |-- | | ... | |-- | | ... | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |--* | | | |--* | | | | |--* | | | | | |--* | | | | |--* | | | | | |--* | | | | ... | | | |--* | | | | |--* | | | | |--* | | | | ... | | |-- | | | |-- | | | |-- | | | |-- | | | |--* | | | |--* | | | | |--* | | | | | |--* | | | | |--* | | | | | |--* | | | | ... | | | |--* | | | | |--* Novo, et al. Standards Track [Page 9] RFC 6501 Data Model Schema March 2012 | | | | |--* | | | | ... | | ... | |-- | |-- | |-- | |-- | | |-- | | | |-- | | | |-- | ... |-- | |--* | |-- | |-- | |-- | |--* | |--* | |--* | |--* | |--* | | |--* | | | |--!* | | | |--* | | | |--* | | | |--* | | | ... | | ... | |-- | |--* | |--* | |--* | | |--* | | | | | |--* | | | |--* | | | | |-- * | | | |--* | | | |-- | | |-- | | |-- | | |--* | | |-- Novo, et al. Standards Track [Page 10] RFC 6501 Data Model Schema March 2012 | | | | | | | ... | | |-- | | |-- | | |--* | | |--* | | |--* | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | | |-- | | | | |-- | | | | |--