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. <conference-description> . . . . . . . . . . . . . . . . . 13 4.1.1. <conference-time> . . . . . . . . . . . . . . . . . . 14 4.1.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 15 4.1.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 16 4.1.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 16 4.1.5. <available-media> . . . . . . . . . . . . . . . . . . 16 4.1.5.1. <controls> . . . . . . . . . . . . . . . . . . . . 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. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. <conference-state> . . . . . . . . . . . . . . . . . . . . 19 4.4. <floor-information> . . . . . . . . . . . . . . . . . . . 19 4.5. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.1. <allowed-users-list> . . . . . . . . . . . . . . . . . 22 4.5.2. <user> . . . . . . . . . . . . . . . . . . . . . . . . 22 4.5.2.1. <from-mixer>, <to-mixer> . . . . . . . . . . . . . 24 4.5.2.1.1. <floor> . . . . . . . . . . . . . . . . . . . 24 4.5.3. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . 24 4.5.4. <sidebars-by-val> . . . . . . . . . . . . . . . . . . 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 <conference-info> element. The <conference-info> element contains the following child elements: o The <conference-description> 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 <host-info> 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 <conference-state> element informs the subscribers about the changes in the overall conference information. o The <floor-information> element contains information about the status of the different floors in the conference. o The <users> element describes the membership information as a whole. The <users> element contains a set of <user> 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 <sidebars-by-ref> element or under one of the <sidebars-by-val> 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 <conference-info>, which is defined in [1]. The <conference-info> 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 <conference-info> element contains the <conference-description>, <host-info>, <conference-state>, <floor-information>, <users>, <sidebars-by-ref>, <sidebars-by-val> child elements. All these elements, except <floor-information>, are defined in [1]. A conference document MUST at least include the <conference- description>, <host-info>, <conference-state>, and <users> 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]. !<conference-info> | |--!<conference-description> | |--<display-text> | |--<subject> | |--<free-text>* | |--<keywords> | |--<allow-sidebars>* | |--<conference-time>* | | |--<entry>* | | | |--<base>* | | | |--<mixing-start-offset>* | | | |--<mixing-end-offset>* | | | |--<can-join-after-offset>* | | | |--<must-join-before-offset>* | | | |--<request-user>* | | | |--<notify-end-of-conference>* | | | |--<allowed-extend-mixing-end-offset>* | | ... | |--<conf-uris> | | |--<entry>* | | | |--<uri> | | | |--<display-text> | | | |--<purpose> | | |--<H323>* | | | |--<H.323-alias>* | | | |--<H.323-URI>* | | |--<PSTN-ISDN>* | | | |--<phone number>* | | ... | |--<service-uris> | | |--<entry>* | | | |--<uri> | | | |--<display-text> | | | |--<purpose> | | |--<H323>* | | | |--<H.323-alias>* | | | |--<H.323-URI>* | | |--<PSTN-ISDN>* | | | |--<phone number>* | | ... | |--<maximum-user-count> | | ... | |--!<available-media> Novo, et al. Expires October 19, 2007 [Page 10]
Internet-Draft Data Model Schema April 2007 | | |--!<entry> | | | |--<type> | | | |--<display-text> | | | |--<status> | | | |--<mixing-mode>* | | | |--<mix-level>* | | | |--<codecs>* | | | | |--<entry>* | | | | |--<entry>* | | | | ... | | | |--<controls>* | | | | |--<mute>* | | | | |--<gain>* | | | | ... | | |--<entry> | | | |--<type> | | | |--<display-text> | | | |--<status> | | | |--<mixing-mode>* | | | |--<mix-level>* | | | |--<codecs>* | | | | |--<entry>* | | | | |--<entry>* | | | | ... | | | |--<controls>* | | | | |--<pause-video>* | | | | |--<video-layout>* | | | | ... | | ... | |--<host-info> | |--<display-text> | |--<web-page> | |--!<uris> | | |--!<entry> | | | |--!<uri> | | | |--<display-text> | | |--<H323>* | | | |--<H.323-alias>* | | | |--<H.323-URI>* | | |--<PSTN-ISDN>* | | | |--<phone number>* | ... |--<conference-state> | |--<allow-conference-event-subscription>* | |--<user-count> | |--!<active> | |--<locked> Novo, et al. Expires October 19, 2007 [Page 11]
Internet-Draft Data Model Schema April 2007 | |--<floor-information>* | |--<conference-ID>* | |--<allow-floor-events>* | |--<floor-request-handling>* | |--<conference-floor-policy>* | | |--<floor>* | | | |--<media-types>* | | | |--<algorithm>* | | | |--<max-floor-users>* | | | |--<chair-id>* | | | |--<chair-id>* | | | ... | | ... | |--!<users> | |--<join-handling>* | |--<user-admission-policy>* | |--<allowed-users-list>* | | |--<target>* | | |-- ... | | | | | |--!<user> | | |--<display-text> | | |--<associated-aors> | | |--<provide-anonymity>* | | |--<roles> | | | | | | | ... | | |--<languages> | | |--<cascaded-focus> | | |--<allow-refer-users-dynamically>* | | |--<allow-invite-users-dynamically>* | | |--<allow-remove-users-dynamically>* | | |--!<endpoint> | | | |--<display-text> | | | |--<referred> | | | |--<status> | | | |--<joining-method> | | | |--<joining-info> | | | |--<disconnection-method> | | | |--<disconnection-info> | | | |--!<media> | | | | |--<type> | | | | |--<display-text> | | | | |--<label> | | | | |--<src-id> Novo, et al. Expires October 19, 2007 [Page 12]
Internet-Draft Data Model Schema April 2007 | | | | |--<status> | | | | |--<to-mixer>* | | | | | |--<floor>* | | | | | |--<controls>* | | | | | | |--<mute>* | | | | | | |--<gain>* | | | | | | ... | | | | |--<from-mixer>* | | | | | |--<floor>* | | | | | |--<controls>* | | | | | | |--<pause-video>* | | | | | | ... | | | | ... | | | |--<call-info> | | | | |--<sip> | | | | | |--<display-text> | | | | | |--<call-id> | | | | | |--<from-tag> | | | | | |--<to-tag> | ... ... |--<sidebars-by-ref> | |--<entry> | | |-- <user> | | |-- <display-text> | |--<entry> | | |-- <user> | | |-- <display-text> | ... |--<sidebars-by-val> | |--<entry> | | | | | ... | |--<entry> | | | | ... ... The following sections describe these elements in detail. The full Relax NG schema is provided Section 5. 4.1. <conference-description> The <conference-description> element, which is defined in [1], describes the conference as a whole. It SHOULD have an extra attribute 'xml:lang' to specify the language used in the contents of this element as defined in Section 2.12 of [8]. It is comprised of <display-text>, <subject>, <free-text>, <keywords>, <allow-sidebars>, <conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>, Novo, et al. Expires October 19, 2007 [Page 13]
Internet-Draft Data Model Schema April 2007 and <available-media>. The <display-text>, <subject>, <free-text> and <keywords> elements are defined in [1]. They are used to describe the conference's content. The child element <allow-sidebars> describes the capabilities of the conference. The <conference-time> child element contains information related to conference time and duration of the conference. The <conf-uris> and <service-uris> are used to describe the conference-related identifiers. The <maximum-user-count> child element indicates the number of users that can be invited to the conference. The <available-media> child element is used to describe the media characteristics of the conference. The following sections describe these elements in more detail. Other child elements MAY be defined in the future to extend the <conference-description> element. 4.1.1. <conference-time> The <conference-time> element contains the information related to conference time and duration of a conference. The <conference-time> element contains one or more <entry> elements each defining the time information specifying a single conference occurrence. Every <entry> element contains a <mixing-start-offset> child element that specifies when conference media mixing starts before the conference starts, <mixing-end-offset> child element that specifies the time a conference media mixing stops after the conference stops. The <mixing-end-offset> child element expresses the offset as signed integers representing seconds before/after DTEND field. The <mixing- start-offset> child element expresses the offset as signed integers representing seconds before/after DTSTART field. If the <mixing- start-offset> element is not present, it indicates that the conference media mixing starts immediately. If the <mixing-end- offset> element is not present, it indicates that the conference occurrence is not bounded. <mixing-start-offset> and <mixing-end- offset> elements both have the mandatory 'require-participant' attribute. This attribute has one of 4 values: "none", "administrator", "moderator", and "participant". For <mixing-start- offset>, this attribute allows a privileged user to define when media mixing starts based on the latter of the mixing start time, and the time the first participant, administrator, or moderator arrives. If the value is set to "none'", mixing starts according to the mixing start time. For <mixing-end-offset>, this attribute allows a Novo, et al. Expires October 19, 2007 [Page 14]
Internet-Draft Data Model Schema April 2007 privileged user to define when media mixing ends based on the earlier of the <mixing-end-offset>, and the time the last participant, or moderator leaves. If the value is set to "none", mixing stops according to the <mixing-end-offset>. If the conference policy was modified so that last privileged user is now a normal conference participant, and the conference requires a privileged user to continue; that conference MUST terminate. An administrator can indicate the time when users can join a conference by populating the <can-join-after-offset> element. Similarly, an administrator can define the time after which new users are not allowed to join the conference anymore. This is done by populating the <must-join-before-offset> element expressing the offset as signed integers representing seconds before/after DTSTART field. The <base> child element specifies the iCalendar object of the conference. The iCalendar object components are defined in [3]. The <entry> element also contains the <request-user> child element. It is possible to define the time when users or resources on the <allowed-users-list> is requested to join the conference by using the <request-users> element. This element expresses the offset as signed integers representing seconds before/after DTSTART field. The <notify-end-of-conference> element defines in seconds when the system has to send a notification when the end of the conference is approaching. If the <notify-end-of-conference> element is not present, it indicates that the system does not notify the users when the end of the conference is approaching. The <notify-end-of- conference> child element expresses the offset as signed integers representing seconds before/after DTSTART field. The <allowed- extend-mixing-end-offset> refers to the possibility to extend the conference. It has two values: "allowed", "denied". 4.1.2. <conf-uris> The <conf-uris> contains the identifiers to be used in order to access the conference by different signaling means. It contains a sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>. The <entry> element refers to the SIP protocol. It keeps the same name that is defined in [1] to maintain backwards compatibility with this RFC. The <entry> element contains the <uri>, <display-text>, and <purpose> which are described in [1]. The currently defined <purpose> values to be used with the <conf-uris> are: o participation: Accessing a URI with this <purpose> will bring the party into the conference Novo, et al. Expires October 19, 2007 [Page 15]
Internet-Draft Data Model Schema April 2007 o streaming: Accessing a URI with this <purpose> will commence streaming the conference, but not allow active participation The <H.323> element includes either a <H.323-alias> or a <H.323-URI> child elements. The <PSTN-ISDN> has an attribute 'PIN code' with the PIN code of the conference if used and a 'purpose' attribute that describes to the user which phone number to use. The <PSTN-ISDN> element may include one or more <phone number> child elements. 4.1.3. <service-uris> The <service-uris> describes auxiliary services available for the conference. It contains a sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>. The <entry> child element contains <uri>, <display-text>, and <purpose>. The purpose will be used to describe the service. The currently defined <purpose> values to be used with the <service-uris> are: o web-page: Indicates the web page containing the additional information about the conference o recording: Indicates the link at which the recorded conference context can be retrieved o event: Indicates the URI at which a subscription to the conference event package may be requested. This would typically be the conference URI of the main conference Future extensions to this schema may define new values and register them with IANA. These elements are described in [1]. <H.323>, and <PSTN-ISDN> child elements are described in the <conf-uris> section. 4.1.4. <maximum-user-count> The <maximum-user-count> contains the overall number of users allowed to join the conference. Note that this value is set by an administrator and can reflect any local policies such as network consumption, CPU processing power, and licensing rules. 4.1.5. <available-media> The <available-media> has the 'label' attribute that is the media stream identifier assigned by the conferencing server. This element contains a sequence of <entry> child elements of conference-medium- type. Each <entry> element contains the <type>, <display-text>, <status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child elements. The attribute 'label' and the <type>, <display-text>, and <status> elements are described in [1]. The <codecs> element specifies the allowed codecs in the conference. It has an attribute 'decision' that specifies if the focus decides the common codec automatically or needs the approval of the moderator of the conference ("automatic", "moderator-controlled"). The <codecs> element contains <entry> elements. A <entry> element can have the Novo, et al. Expires October 19, 2007 [Page 16]
Internet-Draft Data Model Schema April 2007 attribute 'name' and 'policy'. The 'name' attribute identifies a codec, and the 'decision' attribute contains the policy for that codec (allowed, or disallowed). The child elements <mixing-mode> and <mix-level> describe a default policy by which the mixer will build the outgoing stream from the incoming streams. Notice that this policy is different than the policy describing the floors for each media. The <mix-level> child element describes the number of participants in audio media streams or the number of sub-windows in video media streams (for instance, a value of "4" in the <mix-level> element for video streams implies a 2x2 layout). The <mixing-mode> child element MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Automatic" values indicating the default algorithm to be use with every media stream. The next section explains the <controls> child element. 4.1.5.1. <controls> The <controls> element contains the basic audio and video global controls for a conference. It is expected that for the majority of the basic conferences, these controls are sufficient. If the conference server wants to support more advanced controls, then it is recommended that an extension of the data model be used. In the <controls> element the schema is extensible, hence new control types can be added in the future. Similarly, controls that apply to a specific user would appear under the <users>/<user>/<endpoint> element. So moderator controls that affect all media output would go under the <available-media> element. 4.1.5.1.1. mute The 'mute' control is used in conjunction with an audio stream to cease transmission of associated media. It has a "boolean" value. If this control is not specified, access to the control is not available to the client and media SHOULD NOT be transported for the associated media stream. 4.1.5.1.2. pause-video The 'pause-video' control is used in conjunction with a video stream to cease transmission of associated media. It has a "boolean" value. If this control is not specified, access to the control is not available to the client and media SHOULD NOT be transported for the associated media stream. Novo, et al. Expires October 19, 2007 [Page 17]
Internet-Draft Data Model Schema April 2007 4.1.5.1.3. gain The 'gain' control is used in conjunction with a media output stream to indicate the amount of amplification of an audio stream. It has a "int" number value. If this control is not specified, access to the control is not available to the client. 4.1.5.1.4. video-layout The 'video-layout' control is used in conjunction with a video stream to specify how the video streams (participants) are viewed by each participant. Only one layout type can be specified for each output stream. If there are fewer participants than panels in the specified layout, then blanking (black screen) MAY be mixed into the stream on the behalf of the missing input streams. If unspecified, the <video- layout> default type SHOULD be "single-view". The <layout> types are as follows: single-view: Only one stream is presented by the focus to all participants in one panel. dual-view: This dual view option will present the video side-by-side in 2 panels and not alter the aspect ratio of the streams. This will require the focus to introduce blanking on parts of the overall image as viewed by the participants. dual-view-crop: This side-by-side layout option instructs the focus to alter the aspect ratio of the streams (alter-aspect-ratio=TRUE) so that blanking is not necessary. The focus handles the cropping of the streams. dual-view-2x1: This layout option instructs the focus to place one stream above the other, in essence with two rows and one column. In this option the aspect ratio is not altered and blanking is introduced. dual-view-2x1-crop: This layout option also instructs the focus to place one stream above the other, in essence with two rows and one column. In this option the aspect ratio is altered and the video streams are cropped. quad-view: Four equal-sized panels in a 2x2 layout is presented by the focus to all participants. Typically the aspect ratio of the streams are maintained (alter-aspect-ratio= FALSE). multiple-3x3: Nine equal-sized panels in a 3x3 layout is presented by the focus to all participants. Typically the aspect ratio of the Novo, et al. Expires October 19, 2007 [Page 18]
Internet-Draft Data Model Schema April 2007 streams are preserved. multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is presented by the focus to all participants. Typically the aspect ratio of the streams are preserved. multiple-5x1: This option refers to a 5x1 layout where one panel will occupy 4/9 of the mixed video stream while the others will each occupy 1/9 of the stream. Typically the aspect ratio of the streams is preserved. automatic: This option allows the focus to add panels as streams are added up to a limit of "panels". 4.2. <host-info> The <host-info> element contains information about the entity hosting the conference. This information is set before the conference activation, and is rarely changed during the conference lifetime. The <host-info> element contains the <display-text>, <web-page> and <uris> child elements. The <display-text> and <web-page> child elements are explained in [1]. The <uris> child element contains a sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>. The <entry> element refers to the SIP protocol. It keeps the same name that is defined in [1] to maintain backwards compatibility with this RFC. Future extensions to the <uris> element may define new values. 4.3. <conference-state> The <conference-state> element and the <user-count>, <active>, and <locked> child elements are explained in section 5.5 of [1]. The <allow-conference-event-subscription> element represents a boolean action. If set to TRUE, the focus is instructed to allow the subscription to conference state events, such as the SIP Event Package for Conference State [1]. If set to FALSE, the subscription to conference state events would be rejected. If this element is undefined it has a default value of TRUE, causing the subscription to conference state events to be accepted. 4.4. <floor-information> The <floor-information> element has the <conference-ID>, <allow- floor-events>, <floor-request-handling>, and <conference-floor- policy> child elements. Other elements from different namespaces MAY be present for the purposes of extensibility. This element has its own XML namespace. The absence of this namespace and its elements from an XML document indicates that the conference does not have a floor. Novo, et al. Expires October 19, 2007 [Page 19]
Internet-Draft Data Model Schema April 2007 The <conference-ID> is used by a floor control server to provide a client with a conference ID. The <allow-floor-events> element represents a boolean action. If set to TRUE, the focus is instructed to accept the subscription to floor control events. If set to FALSE, the focus is instructed to reject the subscription. If this element is undefined, it has a default value of FALSE, causing the subscription to floor control events to be rejected. The <floor-request-handling> element defines the actions used by the conference focus to control floor requests. This element defines the action that the focus is to take when processing a particular request to a floor within a conference. This element defines values of: o "block": This action instructs the focus to deny the floor request. This action is the default action taken in the absence of any other actions. o "confirm": This action instructs the focus to allow the request. The focus then uses the defined floor algorithm to further allow or deny the floor. The algorithms used are outside the scope of this document. Note that placing a value of "block" for this element does not guarantee that a participant is blocked from joining the conference. Any other rule that might evaluate to TRUE for this participant that carried an action whose value was higher than "block" would automatically grant confirm/allow permission to that participant. The <conference-floor-policy> element is mandatory and contains the required boolean attribute that indicates if the floor is moderator controlled or not. One or more <floor> elements can appear in the <conference-floor-policy> element. Every floor is defined using the 'label' attribute. If the <available-media> information is included in the conference document, the value of this attribute MUST be equal to the 'label' value of the corresponding media stream <entry> in the <available-media> container. The number of those elements indicates how many floors the conference can have. A floor can be used for one or more media types; the mandatory <media-types> element can contain zero or more of the <video>, <audio>, <application>, <data> ,<control>, <message>, and <text> elements indicating the media of the floor. One type of media can only appear once. Other media types can be defined by extensions. A floor can be controlled using many algorithms; the mandatory <algorithm> element MUST contain one and only one of the <moderator- controlled>, <FCFS>, and <random> elements indicating the algorithm. The <max-floor-users> child element in the <floor> element is Novo, et al. Expires October 19, 2007 [Page 20]
Internet-Draft Data Model Schema April 2007 optional and, if present, dictates the maximum number of users who can have the floor at one time. The optional <chair-id> indicates the BFCP UserID of the moderator. It MUST be set if the attribute moderator-controlled is set to TRUE. 4.5. <users> The <users> element contains the <join-handling>, <user-admission- policy>, <allowed-users-list>, and <user> child elements. The <join-handling> element defines the actions used by the conference focus to control conference participation. This element defines the action that the focus is to take when processing a particular request to join a conference. This element defines values of: o "block": This action instructs the focus to deny access to the conference. This action is the default action taken in the absence of any other actions. o "confirm": This action instructs the focus to place the participant on a pending list (e.g., by parking the call on a music-on-hold server), awaiting moderator input for further actions. o "allow": This action instructs the focus to accept the conference join request and grant access to the conference within the instructions specified in the transformations of this rule. o "IVR": This action instructs the focus that the user has to provide the PIN code. o "directed-operator": This action instructs the focus to direct the user to an operator. Note that placing a value of block for this element does not guarantee that a participant is blocked from joining the conference. Any other rule that might evaluate to TRUE for this participant that carried an action whose value was higher than "block" would automatically grant confirm/allow permission to that participant. The <user-admission-policy> is an element that lets an organizer (or a participant with appropriate rights) choose a policy for the conference that controls how users are allowed into the conference. A 'closedAuthenticated' policy requires each conference participant to be in the allowed users list (listed under the <allowed-users- list> XML element) with each participant being sufficiently (up to local policy) authenticated. Conference join requests for users not in the allowed users list or participants not authenticated should be rejected unless a <join-handling> action of 'confirm' is selected in which case the user is placed on a pending list as indicated earlier. An 'openAuthenticated' policy requires each conferencing participant to be sufficiently authenticated (as before) but does not restrict Novo, et al. Expires October 19, 2007 [Page 21]
Internet-Draft Data Model Schema April 2007 which participants can join the conference. Typically this implies that anyone capable of authenticating with the conferencing system may join the conference. An 'anonymous' policy allows any join requests in and is the least restrictive in policies. The following sections describe the remaining elements in more detail. Other child elements can be used to extend <conference- description> in the future. 4.5.1. <allowed-users-list> The <allowed-users-list> child element contains a list of user URIs, PSTN phone numbers, roles, or domains (*@example.com) that the focus 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 conference. The <allowed-users-list> element includes zero or more <target> child elements. This child element includes the mandatory 'uri' attribute and the mandatory 'method' attribute. The same 'uri' attribute with different method values can appear in the list more than once. The 'method' attribute is a list with the following values: "dial-in", "dial-out", and "refer". The value "dial-in" is used by the focus to determine who can join the conference. The value "refer" is used by the focus to determine the resources that the focus needs to "refer to" the conference. In SIP, this is achieved by the focus sending a REFER request to those potential participants. In a different paradigm, this could 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 it can be used for mid- conference refers as well. The "refer" value differs from the "dial-out" in that the "dial-out" contains a list of resources that the focus will initiate a session with. The resources on the "refer" value, on the other hand, are expected to initiate the session establishment toward the focus themselves. It is also envisioned that difference users will have different access rights to those lists and therefore a separation between the two is needed. 4.5.2. <user> The element <user> describes a single participant in the conference. The following elements of <user> are defined in [1], section 5.6: <display-text>, <associated-aors>, <roles>, <languages>, <cascaded- focus>, and <endpoint>. <user> has two attributes: 'entity' and 'state'. The attribute 'state' is defined in [1], section 5.6. The attribute 'entity' contains a unique conference user identifier. Other user identifiers can be associated with this conference user Novo, et al. Expires October 19, 2007 [Page 22]
Internet-Draft Data Model Schema April 2007 identifier and enable the conferencing system to correlate and map these multiple authenticated user identities to a single global user identifier. Figure 4 illustrates an example using the conference user identifier in association with the user identity defined for BFCP, SIP, and H323 user identity. 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. +--------------+ | Conference | | User | | Identifier | +--------------+ | John | +------+-------+ | | | +---------------------+---------------------+ | | | +-------+--------+ +-------+-------+ +--------+-------+ | BFCP User ID | | SIP User ID | | H323 User ID | +----------------+ +---------------+ +----------------+ | HK37ihdaj | | 123674 | | 928373 | +----------------+ +---------------+ +----------------+ Figure 4: Conference Object Mapping The <provide-anonymity> element provides anonymity to the user. In this case, the focus provides to the rest of the participants an anonymous identity for that user, for example anonymousX. This element only affects the way the user information is shown to the oher participants. The real information about the user is still stored in the data model. This can be achieved by using the <provide-anonymity> element. It is a boolean transformation. If set to TRUE, the conference participants will see an anonymous identity for the user whose identity is present in the conditions. The <endpoint> child element can provide the desired level of detail about the user's devices and their signaling sessions taking part in the conference and has the following child elements defined in RFC 4575 [1]: <display-text>, <referred>, <status>, <joining-method>, <joining-info>, <disconnection-method>, <disconnection-info>, <media>, and <call-info>. The <endpoint>/<media> element has two other child elements: <to-mixer>, and <from-mixer> described in the Novo, et al. Expires October 19, 2007 [Page 23]
Internet-Draft Data Model Schema April 2007 following section. 4.5.2.1. <from-mixer>, <to-mixer> Similar to the controls defined in the <available-media> element, controls that apply to a particular user appear at this place in the data structure. The <to-mixer> element details properties associated with the incoming streams to the mixer. The <from-mixer> element details properties associated with the outgoing streams from the mixer. Both of these elements have the attribute 'name'. The 'name' attribute has the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and "AudioOut" media streams detail properties associated with the outgoing video and audio from the mixer. The "VideoIn" and "AudioIn" media stream details properties associated with the incoming video and audio to the mixer. More values can be defined in the future. Each of these elements have the <floor> and <controls> child elements. 4.5.2.1.1. <floor> The <floor> element describes a floor that joins this participant in the conference. If a participant, for instance, needs to talk in the conference, it first needs to get the floor from the chair of the conference. The <floor> element has a "Boolean" value. A value of FALSE indicates that this user does not hold the floor in this moment. If this control is not specified, this user SHOULD NOT specify the floor option. 4.5.3. <sidebars-by-ref> The <sidebars-by-ref> element contains a set of <entry> child elements. Each <entry> child element contains a <user> child element with a sidebar unique conference user identifier and a <display-text> child element. 4.5.4. <sidebars-by-val> The <sidebars-by-val> element contains a set of <entry> child elements each containing information about a single sidebar. By using this element, the server can include a full or partial description of each sidebar (as a sub-conference) in the body of the main conference document. Novo, et al. Expires October 19, 2007 [Page 24]
Internet-Draft Data Model Schema April 2007 5. RELAX NG Schema In accordance with the XCON framework document [4], the Conference Object is a logical representation of a conference instance. The conference information schema contains core information that is utilized in any conference. It also contains the variable information part of the Conference Object. This specification defines some document fragments in RELAX NG format. namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace local = "" namespace ns1 = "urn:ietf:params:xml:ns:conference-info-urn" default namespace ns2 = "urn:ietf:params:xml:ns:conference-schema" start = element conference-info { conference-type } # CONFERENCE TYPE conference-type = attribute entity { text }, attribute version { xsd:unsignedInt }?, attribute state { state-type }?, conference-description-type, element host-info { host-type }?, element conference-state { conference-state-type }?, element floor-information { floor-information-type }?, element users { users-type }, element sidebars-by-ref { sidebars-by-ref-type }?, element sidebars-by-val { sidebars-by-val-type }?, anyElement* # CONFERENCE DESCRIPTION TYPE conference-description-type = element conference-description { attribute xml:lang { xsd:language }?, attribute state { state-type }?, element display-text { text }?, element subject { text }?, element free-text { text }?, element keywords { list { xsd:string* } }?, element allow-sidebars { xsd:boolean }?, element conference-time { conferencetime-type }?, element conf-uris { uris-type }?, element service-uris { uris-type }?, element maximum-user-count { xsd:int }?, element available-media { conference-media-type }?, anyElement* Novo, et al. Expires October 19, 2007 [Page 25]
Internet-Draft Data Model Schema April 2007 } # CONFERENCE TIME conferencetime-type = element entry { element base { text }?, element mixing-start-offset { xsd:dateTime { pattern = ".+T.+Z.*" }, attribute required-participant { single-role-type }, anyAttribute }?, element mixing-end-offset { xsd:dateTime { pattern = ".+T.+Z.*" }, attribute required-participant { single-role-type }, anyAttribute }?, element can-join-after-offset { xsd:dateTime { pattern = ".+T.+Z.*" } }?, element must-join-before-offset { xsd:dateTime { pattern = ".+T.+Z.*" } }?, element notify-end-of-conference { xsd:int }?, element allowed-extend-mixing-end-offset { allowed-extend-mixing-values }?, anyElement* }*, anyElement* # ALLOWED EXTEND MIXING VALUES allowed-extend-mixing-values = xsd:string "allowed" | xsd:string "denied" # URIS TYPE uris-type = attribute state { state-type }?, (element entry { uri-type }* & element H323 { H323-type }* & element PSTN-ISDN { PSTN-type }*), anyElement* # SIP TYPE uri-type = (element uri { xsd:anyURI }, element display-text { text }?, element purpose { text }?, anyElement*)* # H323 TYPE H323-type = element H.323-alias { text }?, element H.323-URI { xsd:anyURI }?, Novo, et al. Expires October 19, 2007 [Page 26]
Internet-Draft Data Model Schema April 2007 anyElement* # PSTN TYPE PSTN-type = attribute PIN-code { xsd:unsignedInt }, attribute purpose { xsd:unsignedInt }, (element phone-number { xsd:unsignedInt }, anyElement*)+ # CONFERENCE MEDIA TYPE conference-media-type = attribute state { state-type }?, element entry { conference-medium-type }*, anyElement* # CONFERENCE MEDIUM TYPE conference-medium-type = attribute label { text }, element display-text { text }?, element type { text }?, element status { media-status-type }?, element mixing-mode { mix-mode-type }?, element mix-level { xsd:unsignedInt }?, element codecs { codecs-type }?, element controls { controls-type }?, anyElement* # CONTROLS TYPE controls-type = attribute state { state-type }?, element control { control-type }*, anyElement* # MIX MODE TYPE mix-mode-type = xsd:string "moderator-controlled" | xsd:string "FCFS" | xsd:string "automatic" # CODECS TYPE codecs-type = attribute decision { decision-type }, element codec { codec-type }*, anyElement* # CODEC TYPE codec-type = attribute name { text }, attribute policy { policy-type } # DECISION TYPE decision-type = xsd:string "automatic" | xsd:string "moderator-controlled" # POLICY TYPE policy-type = xsd:string "allowed" | xsd:string "disallowed" # CONTROL TYPE Novo, et al. Expires October 19, 2007 [Page 27]
Internet-Draft Data Model Schema April 2007 control-type = element mute { xsd:boolean } | element pause-video { xsd:boolean } | element gain { xsd:int { minInclusive = "-127" maxInclusive = "127" } } | element video-layout { xsd:string "single-view" | xsd:string "dual-view" | xsd:string "dual-view-crop" | xsd:string "dual-view-2x1" | xsd:string "dual-view-2x1-crop" | xsd:string "quad-view" | xsd:string "multiple-3x3" | xsd:string "multiple-4x4" | xsd:string "multiple-5x1" | xsd:string "automatic" } | anyElement* # HOST TYPE host-type = (element display-text { text }, element web-page { xsd:anyURI }, element uris { uris-type }, anyElement*)* # CONFERENCE STATE TYPE conference-state-type = element allow-conference-event-subscription { xsd:boolean }?, element user-count { xsd:unsignedInt }?, element active { xsd:boolean }?, element locked { xsd:boolean }?, anyElement* # FLOOR INFORMATION TYPE floor-information-type = (element conference-ID { xsd:unsignedInt }, element allow-floor-events { xsd:boolean }, element floor-request-handling { floor-request-type }, element conference-floor-policy { Conference-floor-policy }, anyElement*)* # FLOOR REQUEST TYPE floor-request-type = xsd:string "block" | xsd:string "confirm" # CONFERENCE FLOOR POLICY Conference-floor-policy = element floor { attribute moderator-controlled { xsd:boolean }, attribute label { text }, anyAttribute, (element media-types { Novo, et al. Expires October 19, 2007 [Page 28]
Internet-Draft Data Model Schema April 2007 xsd:string "video" | xsd:string "audio" | xsd:string "application" | xsd:string "data" | xsd:string "control" | xsd:string "message" | xsd:string "text" }, element algorithm { xsd:string "moderator-controlled" | xsd:string "FCFS" | xsd:string "random" }, element max-floor-users { xsd:nonNegativeInteger }, element chair-id { xsd:anyURI }, anyElement*)* }+ # USERS TYPE users-type = attribute state { state-type }?, element join-handling { join-handling-type }?, element user-admission-policy { user-admission-policy-type }?, element user-must-be-specified { xsd:boolean }?, element allowed-users-list { UserList }?, element user { user-type }*, anyElement* # USERS ADMISSION POLICY user-admission-policy-type = xsd:string "closedAuthenticated" | xsd:string "openAuthenticated" | xsd:string "anonymous" # JOIN HANDLING TYPE join-handling-type = xsd:string "block" | xsd:string "allow" | xsd:string "confirm" | xsd:string "IVR" | xsd:string "directed-operator" # USERLIST UserList = element target { target-type }*, anyElement* # TARGET TYPE target-type = attribute uri { xsd:anyURI }, attribute method { method-type } # METHOD TYPE method-type = Novo, et al. Expires October 19, 2007 [Page 29]
Internet-Draft Data Model Schema April 2007 xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer" # USER TYPE user-type = attribute entity { xsd:anyURI }, attribute state { state-type }?, element display-text { text }?, element associated-aors { uris-type }?, element provide-anonymity { xsd:boolean }?, element roles { roles-type }?, element languages { list { xsd:language } }?, element cascaded-focus { xsd:anyURI }?, element allow-refer-users-dynamically { xsd:boolean }?, element allow-invite-users-dynamically { xsd:boolean }?, element allow-remove-users-dynamically { xsd:boolean }?, element endpoint { endpoint-type }*, anyElement* # ENDPOINT TYPE endpoint-type = attribute entity { text }, attribute state { state-type }?, element display-text { text }?, element referred { conference-info-urn* }?, element status { endpoint-status-type }?, element joining-method { joining-type }?, element joining-info { conference-info-urn* }?, element disconnection-method { disconnection-type }?, element disconnection-info { conference-info-urn* }?, element media { media-type }*, element call-info { conference-info-urn* }?, anyElement* # MEDIA TYPE media-type = attribute id { xsd:int }, attribute state { state-type }?, anyAttribute, element display-text { text }?, element type { text }?, element label { text }?, element src-id { text }?, element status { media-status-type }?, element to-mixer { mixer-type }?, element from-mixer { mixer-type }?, anyElement* # MIXER TYPE mixer-type = attribute state { state-type }?, Novo, et al. Expires October 19, 2007 [Page 30]
Internet-Draft Data Model Schema April 2007 (element floor { xsd:boolean }, element controls { controls-type })?, anyElement* # SIDEBARS-BY-REF TYPE sidebars-by-ref-type = attribute state { state-type }?, element entry { uri-type }*, anyElement* # SIDEBARS-BY-VAL TYPE sidebars-by-val-type = attribute state { state-type }?, element entry { conference-type }*, anyElement* # ROLES_TYPE roles-type = element entry { single-role-type }*, anyElement* # SINGLE ROLE TYPE single-role-type = xsd:string "administrator" | xsd:string "creator" | xsd:string "moderator" | xsd:string "participant" | xsd:string "observer" # ********************************* # EXTENSIBILITY OF THE SCHEMA # ********************************* # EXTENSIBILITY ELEMENTS anyElement = element * { (attribute * { text } | text | anyElement)* } # EXTENSIBILITY ATTRIBUTES anyAttribute = attribute * - (entity | version | state | xml:lang | required-participant | PIN-code | purpose | role | type | min | max Novo, et al. Expires October 19, 2007 [Page 31]
Internet-Draft Data Model Schema April 2007 | label | decision | name | policy | moderator-controlled | uri | method | id | domain | local:* | ns2:*) { text }* # ************************************************************* # TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE # ************************************************************* # WILDCARD FOR EVENT-PACKAGE NAMESPACE conference-info-urn = element ns1:* { (attribute * { text } | conference-info-urn)* } # DEFINITION OF STATE TYPE state-type = "full" | "partial" | "deleted" # DEFINITION OF ENDPOINT STATUS TYPE media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive" # ENDPOINT STATUS TYPE endpoint-status-type = "pending" | "dialing-out" | "dialing-in" | "alerting" | "on-hold" | "connected" | "muted-via-focus" | "disconnecting" | "disconnected" # JOINING TYPE joining-type = "dialed-in" | "dialed-out" | "focus-owner" # DISCONNECTION TYPE disconnection-type = "departed" | "booted" | "failed" | "busy" 6. XML Schema Extensibility The Conference Information Data Model defined in this document is meant to be extensible toward specific application domains. Such extensions are accomplished by defining elements, child elements and Novo, et al. Expires October 19, 2007 [Page 32]
Internet-Draft Data Model Schema April 2007 attributes that are specific to the desired application domain. The IETF MAY extend the data model schema with extension elements from the same namespace, but other instances are free to extend it from other than urn:ietf:params:xml:ns:conference-schema. Elements or attributes from unknown namespaces MUST be ignored. 7. XML Example The following is an example of a conference information document. The conference starts on October 17, 2007, at 10:30 AM in New York City and finishes the same day at 12:30 PM every week. In this example, there are currently 3 participants in a conference, one administrator, one moderator, and one participant. Note that sidebars are allowed in this conference and there is one sidebar in the conference. Also note that there is one floor moderator for the audio and a different floor moderator for the video. <?xml version="1.0" encoding="UTF-8"?> <conference-info xmlns="urn:ietf:params:xml:ns:conference-schema" entity="conference123@example.com" state="full"> <!-- CONFERENCE DESCRIPTION --> <conference-description xml:lang="en-us"> <display-text>Discussion of Formula-1 racing</display-text> <subject> Sports:Formula-1</subject> <free-text>This is a conference example</free-text> <keywords>Formula-1, cars</keywords> <webpage>http://www.example.com/users/formula-1</webpage> <security-level>low</security-level> <allow-sidebars>true</allow-sidebars> <conference-stage>running</conference-stage> <!-- CONFERENCE TIME --> <conference-time> <entry> <base>BEGIN:VCALENDAR PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:20061103T140728Z UID:20061103T140728Z-345FDA-carol@example.com ORGANIZER:MAILTO:carol@example.com DTSTART:20071017T143000Z Novo, et al. Expires October 19, 2007 [Page 33]
Internet-Draft Data Model Schema April 2007 RRULE:FREQ=WEEKLY DTEND:20071217T163000Z END:VEVENT END:VCALENDAR</base> <mixing-start-offset required-participant="moderator" > 2007-10-17T14:29:00Z</mixing-start-offset> <mixing-end-offset required-participant="participant" > 2007-10-17T16:31:00Z</mixing-end-offset> <must-join-before-offset > 2007-10-17T15:30:00Z</must-join-before-offset> </entry> </conference-time> <!-- CONFERENCE UNIQUE IDENTIFIERS --> <conf-uris state="full"> <SIP> <uri>tel:+3585671234</uri> <display-text>Conference Bridge</display-text> <purpose>participation</purpose> </SIP> <SIP> <uri>http://www.example.comlive.ram</uri> <purpose>streaming</purpose> </SIP> </conf-uris> <!-- SERVICE URIS --> <service-uris state="full"> <SIP> <uri>http://www.example.com/formula1/</uri> <purpose>web-page</purpose> </SIP> </service-uris> <!-- MAXIMUM USER COUNT --> <maximum-user-count> <entry role="administrator">2</entry> <entry role="moderator">5</entry> <entry role="participant">150</entry> </maximum-user-count> <!-- AVAILABLE MEDIA --> <available-media> <entry label="10234"> Novo, et al. Expires October 19, 2007 [Page 34]
Internet-Draft Data Model Schema April 2007 <display-text>main audio</display-text> <type>audio</type> <status>sendrecv</status> <mixing-mode>automatic</mixing-mode> <mix-level>3</mix-level> <codecs decision="automatic"> <codec name="PCMU" policy="allowed"/> </codecs> </entry> <entry label="10235"> <display-text>main video</display-text> <type>video</type> <status>sendrecv</status> <mixing-mode>automatic</mixing-mode> <mix-level>4</mix-level> <codecs decision="automatic"> <codec name="H.263" policy="allowed"/> </codecs> </entry> </available-media> </conference-description> <!-- HOST INFO --> <host-info> <display-text>Formula1</display-text> <web-page>http://www.example.com/formula1/</web-page> <uris state="full"> <SIP> <uri>sip:alice@example.com</uri> </SIP> <SIP> <uri>sip:carol@example.com</uri> </SIP> </uris> </host-info> <!-- CONFERENCE STATE --> <conference-state> <allow-conference-state>true</allow-conference-state> <user-count>3</user-count> <active>true</active> <locked>false</locked> </conference-state> <!-- FLOOR INFORMATION --> Novo, et al. Expires October 19, 2007 [Page 35]
Internet-Draft Data Model Schema April 2007 <floor-information> <conference-ID>567</conference-ID> <allow-floor-events>true</allow-floor-events> <floor-request-handling>confirm</floor-request-handling> <conference-floor-policy> <floor moderator-controlled="true" label="10234"> <media-types>audio</media-types> <algorithm>moderator-controlled</algorithm> <max-floor-users>1</max-floor-users> <chair-id>sip:alice@example.com</chair-id> </floor> <floor moderator-controlled="true" label="10235"> <media-types>video</media-types> <algorithm>moderator-controlled</algorithm> <max-floor-users>1</max-floor-users> <chair-id>sip:carol@example.com</chair-id> </floor> </conference-floor-policy> </floor-information> <!-- USERS --> <users state="full"> <join-handling>allow</join-handling> <!-- ALLOWED USERS LIST --> <allowed-users-list> <target uri="sip:bob@example.com" method="dial-out"/> <target uri="sip:alice@example.com" method="dial-out"/> <target uri="sip:carol@example.com" method="dial-out"/> <target uri="sip:john@example.com" method="refer"/> </allowed-users-list> <!-- USER BOB --> <user entity="bob534" state="partial"> <display-text>Bob Hoskins</display-text> <associated-aors state="full"> <SIP> <uri>mailto:bob@example.com</uri> <display-text>email</display-text> </SIP> </associated-aors> <provide-anonymity>false</provide-anonymity> <roles> <entry>participant</entry> </roles> Novo, et al. Expires October 19, 2007 [Page 36]
Internet-Draft Data Model Schema April 2007 <languages>en</languages> <sphere value="work"/> <allow-refer-users-dynamically >false</allow-refer-users-dynamically> <allow-invite-users-dynamically >false</allow-invite-users-dynamically> <allow-remove-users-dynamically >false</allow-remove-users-dynamically> <!-- ENDPOINTS --> <endpoint entity="sip:bob@example.com" state="full"> <display-text>Bob's Laptop</display-text> <referred> <when>2006-10-17T14:00:00Z</when> <reason>expert required</reason> <by>sip:alice@example.com</by> </referred> <status>connected</status> <joining-method>dialed-out</joining-method> <joining-info> <when>2006-10-17T14:00:00Z</when> <reason>invitation</reason> <by>sip:alice@example.com</by> </joining-info> <!-- MEDIA --> <media id="1"> <label>10235</label> <src-id>432424</src-id> </media> <!-- CALL INFO --> <call-info> <sip> <display-text>full info</display-text> <call-id>hsjh8980vhsb78</call-id> <from-tag>vav738dvbs</from-tag> <to-tag>8954jgjg8432</to-tag> </sip> </call-info> </endpoint> </user> <!-- Novo, et al. Expires October 19, 2007 [Page 37]
Internet-Draft Data Model Schema April 2007 USER ALICE --> <user entity="alice334" state="full"> <display-text>Alice Kay</display-text> <associated-aors state="full"> <SIP> <uri>mailto:alice@example.com</uri> <display-text>email</display-text> </SIP> </associated-aors> <provide-anonymity>false</provide-anonymity> <roles> <entry>moderator</entry> </roles> <languages>en</languages> <sphere value="work"/> <allow-refer-users-dynamically >true</allow-refer-users-dynamically> <allow-invite-users-dynamically >true</allow-invite-users-dynamically> <allow-remove-users-dynamically >true</allow-remove-users-dynamically> <!-- ENDPOINTS --> <endpoint entity="sip:alice@example.com" state="full"> <display-text>Alice's Desktop</display-text> <status>connected</status> <joining-method>dialed-in</joining-method> <joining-info> <when>2006-10-17T13:35:08Z</when> <reason>invitation</reason> <by>sip:conference@example.com</by> </joining-info> <!-- MEDIA --> <media id="1"> <label>10235</label> <src-id>432424</src-id> <status>sendrecv</status> </media> <media id="2"> <label>10234</label> <src-id>532535</src-id> <status>sendrecv</status> </media> Novo, et al. Expires October 19, 2007 [Page 38]
Internet-Draft Data Model Schema April 2007 <!-- CALL INFO --> <call-info> <sip> <display-text>full info</display-text> <call-id>truy45469123478</call-id> <from-tag>asd456cbgt</from-tag> <to-tag>3456jgjg1234</to-tag> </sip> </call-info> </endpoint> </user> <!-- USER CAROL --> <user entity="carol233" state="full"> <display-text>Carol More</display-text> <associated-aors state="full"> <SIP> <uri>mailto:carol@example.com</uri> <display-text>email</display-text> </SIP> </associated-aors> <provide-anonymity>false</provide-anonymity> <roles> <entry>administrator</entry> </roles> <languages>en</languages> <sphere value="work"/> <allow-refer-users-dynamically >true</allow-refer-users-dynamically> <allow-invite-users-dynamically >true</allow-invite-users-dynamically> <allow-remove-users-dynamically >true</allow-remove-users-dynamically> <!-- ENDPOINTS --> <endpoint entity="sip:carol@example.com" state="full"> <display-text>Carol's Computer</display-text> <status>connected</status> <joining-method>dialed-in</joining-method> <joining-info> <when>2006-10-17T13:30:05Z</when> <reason>invitation</reason> <by>sip:conference@example.com</by> Novo, et al. Expires October 19, 2007 [Page 39]
Internet-Draft Data Model Schema April 2007 </joining-info> <!-- MEDIA --> <media id="1"> <label>10235</label> <src-id>432424</src-id> <status>sendrecv</status> </media> <media id="2"> <label>10234</label> <src-id>532535</src-id> <status>sendrecv</status> </media> <!-- CALL INFO --> <call-info> <sip> <display-text>full info</display-text> <call-id>wevb12562321894</call-id> <from-tag>asw456wedf</from-tag> <to-tag>2365dfrt3497</to-tag> </sip> </call-info> </endpoint> </user> </users> <!-- SIDEBARS BY REFERENCE --> <sidebars-by-ref state="full"> <entry> <uri>sips:conference123;grid=40</uri> <display-text>private with Bob</display-text> </entry> </sidebars-by-ref> <!-- SIDEBARS BY VALUE --> <sidebars-by-val> <entry entity="conference123;grid=40"> <users> <user entity="bob534"/> <user entity="carol233"/> </users> </entry> </sidebars-by-val> Novo, et al. Expires October 19, 2007 [Page 40]
Internet-Draft Data Model Schema April 2007 </conference-info> Note that due to RFC formatting conventions, this documents splits lines whose content would exceed 72 characters. Two backslash characters mark where line folding has taken place. These backslashes would not appear in the actual XML data model. 8. Security Considerations A malicious user can manipulate parts of the Conference Information Data Model privileges document giving themselves and others privileges to manipulate the data model. It is very important that only authorized clients are able to manipulate the Conference Information Data Model document. Any conference control protocol MUST provide authentication, confidentiality and integrity. 9. IANA Considerations 9.1. Conference Relax NG Schema Registration URI: urn:ietf:params:xml:ns:conference-schema Relax NG Schema: The Relax NG schema to be registered is contained in Section 4. Its first line is namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" and its last line is disconnection-type = "departed" | "booted" | "failed" | "busy" 9.2. Conference Namespace Registration URI: urn:ietf:params:xml:ns:conference-schema 9.3. Conference Object Identifier Registration XCON_URI = "xcon" ":" [conf-object-id "@"] hostport ; hostport as defined in RFC3261 conf-object-id = 1*( unreserved / "+" / "=" / "/" ) ; unreserved as defined in RFC3986 Novo, et al. Expires October 19, 2007 [Page 41]
Internet-Draft Data Model Schema April 2007 9.4. Conference User Identifier Registration XCON_USERID = "xcon_userid" ":" conf-object-id conf-object-id = 1*( unreserved / "+" / "=" / "/" ) ; unreserved as defined in RFC3986 10. Acknowledgements This document is really a distillation of many ideas discussed over a long period of time. These ideas were contributed by many different drafts in the XCON working group and the SIPPING working group. We would like to thank Orit Levin, Adam Roach, Mary Barnes, Chris Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Aki Niemi, and Jari Urpilainen for their comments. Also, We would like to thank Mary Barnes, and Chris Boulton for letting us use the conference and user identifier information of their xcon drafts. 11. References 11.1. Normative References [1] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. 11.2. Informative References [4] Barnes, M., "A Framework and Data Model for Centralized Conferencing", draft-ietf-xcon-framework-07 (work in progress), January 2007. [5] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Novo, et al. Expires October 19, 2007 [Page 42]
Internet-Draft Data Model Schema April 2007 Notification", RFC 3265, June 2002. [7] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [8] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>. Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax <?xml version="1.0" encoding="UTF-8"?> <grammar ns="urn:ietf:params:xml:ns:conference-schema" xmlns="http://relaxng.org/ns/structure/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <start> <element name="conference-info"> <ref name="conference-type"/> </element> </start> <!-- CONFERENCE TYPE --> <define name="conference-type"> <attribute name="entity"> <text/> </attribute> <optional> <attribute name="version"> <data type="unsignedInt"/> </attribute> </optional> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <ref name="conference-description-type"/> <optional> <element name="host-info"> <ref name="host-type"/> </element> </optional> <optional> <element name="conference-state"> Novo, et al. Expires October 19, 2007 [Page 43]
Internet-Draft Data Model Schema April 2007 <ref name="conference-state-type"/> </element> </optional> <optional> <element name="floor-information"> <ref name="floor-information-type"/> </element> </optional> <element name="users"> <ref name="users-type"/> </element> <optional> <element name="sidebars-by-ref"> <ref name="sidebars-by-ref-type"/> </element> </optional> <optional> <element name="sidebars-by-val"> <ref name="sidebars-by-val-type"/> </element> </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- CONFERENCE DESCRIPTION TYPE --> <define name="conference-description-type"> <element name="conference-description"> <optional> <attribute name="xml:lang"> <data type="language"/> </attribute> </optional> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <optional> <element name="display-text"> <text/> </element> </optional> <optional> <element name="subject"> <text/> Novo, et al. Expires October 19, 2007 [Page 44]
Internet-Draft Data Model Schema April 2007 </element> </optional> <optional> <element name="free-text"> <text/> </element> </optional> <optional> <element name="keywords"> <list> <zeroOrMore> <data type="string"/> </zeroOrMore> </list> </element> </optional> <optional> <element name="allow-sidebars"> <data type="boolean"/> </element> </optional> <optional> <element name="conference-time"> <ref name="conferencetime-type"/> </element> </optional> <optional> <element name="conf-uris"> <ref name="uris-type"/> </element> </optional> <optional> <element name="service-uris"> <ref name="uris-type"/> </element> </optional> <optional> <element name="maximum-user-count"> <data type="int"/> </element> </optional> <optional> <element name="available-media"> <ref name="conference-media-type"/> </element> </optional> <zeroOrMore> <ref name="anyElement"/> Novo, et al. Expires October 19, 2007 [Page 45]
Internet-Draft Data Model Schema April 2007 </zeroOrMore> </element> </define> <!-- CONFERENCE TIME --> <define name="conferencetime-type"> <zeroOrMore> <element name="entry"> <optional> <element name="base"> <text/> </element> </optional> <optional> <element name="mixing-start-offset"> <data type="dateTime"> <param name="pattern">.+T.+Z.*</param> </data> <attribute name="required-participant"> <ref name="single-role-type"/> </attribute> <ref name="anyAttribute"/> </element> </optional> <optional> <element name="mixing-end-offset"> <data type="dateTime"> <param name="pattern">.+T.+Z.*</param> </data> <attribute name="required-participant"> <ref name="single-role-type"/> </attribute> <ref name="anyAttribute"/> </element> </optional> <optional> <element name="can-join-after-offset"> <data type="dateTime"> <param name="pattern">.+T.+Z.*</param> </data> </element> </optional> <optional> <element name="must-join-before-offset"> <data type="dateTime"> <param name="pattern">.+T.+Z.*</param> </data> Novo, et al. Expires October 19, 2007 [Page 46]
Internet-Draft Data Model Schema April 2007 </element> </optional> <optional> <element name="notify-end-of-conference"> <data type="int"/> </element> </optional> <optional> <element name="allowed-extend-mixing-end-offset"> <ref name="allowed-extend-mixing-values"/> </element> </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- ALLOWED EXTEND MIXING VALUES --> <define name="allowed-extend-mixing-values"> <choice> <value type="string">allowed</value> <value type="string">denied</value> </choice> </define> <!-- URIS TYPE --> <define name="uris-type"> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <interleave> <zeroOrMore> <element name="entry"> <ref name="uri-type"/> </element> </zeroOrMore> <zeroOrMore> <element name="H323"> <ref name="H323-type"/> Novo, et al. Expires October 19, 2007 [Page 47]
Internet-Draft Data Model Schema April 2007 </element> </zeroOrMore> <zeroOrMore> <element name="PSTN-ISDN"> <ref name="PSTN-type"/> </element> </zeroOrMore> </interleave> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- SIP TYPE --> <define name="uri-type"> <zeroOrMore> <element name="uri"> <data type="anyURI"/> </element> <optional> <element name="display-text"> <text/> </element> </optional> <optional> <element name="purpose"> <text/> </element> </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </zeroOrMore> </define> <!-- H323 TYPE --> <define name="H323-type"> <optional> <element name="H.323-alias"> <text/> </element> </optional> <optional> <element name="H.323-URI"> <data type="anyURI"/> </element> Novo, et al. Expires October 19, 2007 [Page 48]
Internet-Draft Data Model Schema April 2007 </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- PSTN TYPE --> <define name="PSTN-type"> <attribute name="PIN-code"> <data type="unsignedInt"/> </attribute> <attribute name="purpose"> <data type="unsignedInt"/> </attribute> <oneOrMore> <element name="phone-number"> <data type="unsignedInt"/> </element> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </oneOrMore> </define> <!-- CONFERENCE MEDIA TYPE --> <define name="conference-media-type"> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <zeroOrMore> <element name="entry"> <ref name="conference-medium-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- CONFERENCE MEDIUM TYPE --> <define name="conference-medium-type"> <attribute name="label"> Novo, et al. Expires October 19, 2007 [Page 49]
Internet-Draft Data Model Schema April 2007 <text/> </attribute> <optional> <element name="display-text"> <text/> </element> </optional> <optional> <element name="type"> <text/> </element> </optional> <optional> <element name="status"> <ref name="media-status-type"/> </element> </optional> <optional> <element name="mixing-mode"> <ref name="mix-mode-type"/> </element> </optional> <optional> <element name="mix-level"> <data type="unsignedInt"/> </element> </optional> <optional> <element name="codecs"> <ref name="codecs-type"/> </element> </optional> <optional> <element name="controls"> <ref name="controls-type"/> </element> </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- CONTROLS TYPE --> <define name="controls-type"> <optional> <attribute name="state"> <ref name="state-type"/> Novo, et al. Expires October 19, 2007 [Page 50]
Internet-Draft Data Model Schema April 2007 </attribute> </optional> <zeroOrMore> <element name="control"> <ref name="control-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- MIX MODE TYPE --> <define name="mix-mode-type"> <choice> <value type="string">moderator-controlled</value> <value type="string">FCFS</value> <value type="string">automatic</value> </choice> </define> <!-- CODECS TYPE --> <define name="codecs-type"> <attribute name="decision"> <ref name="decision-type"/> </attribute> <zeroOrMore> <element name="codec"> <ref name="codec-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- CODEC TYPE --> <define name="codec-type"> <attribute name="name"> <text/> </attribute> <attribute name="policy"> <ref name="policy-type"/> </attribute> </define> Novo, et al. Expires October 19, 2007 [Page 51]
Internet-Draft Data Model Schema April 2007 <!-- DECISION TYPE --> <define name="decision-type"> <choice> <value type="string">automatic</value> <value type="string">moderator-controlled</value> </choice> </define> <!-- POLICY TYPE --> <define name="policy-type"> <choice> <value type="string">allowed</value> <value type="string">disallowed</value> </choice> </define> <!-- CONTROL TYPE --> <define name="control-type"> <choice> <element name="mute"> <data type="boolean"/> </element> <element name="pause-video"> <data type="boolean"/> </element> <element name="gain"> <data type="int"> <param name="minInclusive">-127</param> <param name="maxInclusive">127</param> </data> </element> <element name="video-layout"> <choice> <value type="string">single-view</value> <value type="string">dual-view</value> <value type="string">dual-view-crop</value> <value type="string">dual-view-2x1</value> <value type="string">dual-view-2x1-crop</value> <value type="string">quad-view</value> <value type="string">multiple-3x3</value> <value type="string">multiple-4x4</value> <value type="string">multiple-5x1</value> <value type="string">automatic</value> </choice> Novo, et al. Expires October 19, 2007 [Page 52]
Internet-Draft Data Model Schema April 2007 </element> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </choice> </define> <!-- HOST TYPE --> <define name="host-type"> <zeroOrMore> <element name="display-text"> <text/> </element> <element name="web-page"> <data type="anyURI"/> </element> <element name="uris"> <ref name="uris-type"/> </element> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </zeroOrMore> </define> <!-- CONFERENCE STATE TYPE --> <define name="conference-state-type"> <optional> <element name="allow-conference-event-subscription"> <data type="boolean"/> </element> </optional> <optional> <element name="user-count"> <data type="unsignedInt"/> </element> </optional> <optional> <element name="active"> <data type="boolean"/> </element> </optional> <optional> <element name="locked"> <data type="boolean"/> </element> Novo, et al. Expires October 19, 2007 [Page 53]
Internet-Draft Data Model Schema April 2007 </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- FLOOR INFORMATION TYPE --> <define name="floor-information-type"> <zeroOrMore> <element name="conference-ID"> <data type="unsignedInt"/> </element> <element name="allow-floor-events"> <data type="boolean"/> </element> <element name="floor-request-handling"> <ref name="floor-request-type"/> </element> <element name="conference-floor-policy"> <ref name="Conference-floor-policy"/> </element> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </zeroOrMore> </define> <!-- FLOOR REQUEST TYPE --> <define name="floor-request-type"> <choice> <value type="string">block</value> <value type="string">confirm</value> </choice> </define> <!-- CONFERENCE FLOOR POLICY --> <define name="Conference-floor-policy"> <oneOrMore> <element name="floor"> <attribute name="moderator-controlled"> <data type="boolean"/> </attribute> <attribute name="label"> <text/> </attribute> Novo, et al. Expires October 19, 2007 [Page 54]
Internet-Draft Data Model Schema April 2007 <ref name="anyAttribute"/> <zeroOrMore> <element name="media-types"> <choice> <value type="string">video</value> <value type="string">audio</value> <value type="string">application</value> <value type="string">data</value> <value type="string">control</value> <value type="string">message</value> <value type="string">text</value> </choice> </element> <element name="algorithm"> <choice> <value type="string">moderator-controlled</value> <value type="string">FCFS</value> <value type="string">random</value> </choice> </element> <element name="max-floor-users"> <data type="nonNegativeInteger"/> </element> <element name="chair-id"> <data type="anyURI"/> </element> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </zeroOrMore> </element> </oneOrMore> </define> <!-- USERS TYPE --> <define name="users-type"> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <optional> <element name="join-handling"> <ref name="join-handling-type"/> </element> </optional> <optional> Novo, et al. Expires October 19, 2007 [Page 55]
Internet-Draft Data Model Schema April 2007 <element name="user-admission-policy"> <ref name="user-admission-policy-type"/> </element> </optional> <optional> <element name="user-must-be-specified"> <data type="boolean"/> </element> </optional> <optional> <element name="allowed-users-list"> <ref name="UserList"/> </element> </optional> <zeroOrMore> <element name="user"> <ref name="user-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- USERS ADMISSION POLICY --> <define name="user-admission-policy-type"> <choice> <value type="string">closedAuthenticated</value> <value type="string">openAuthenticated</value> <value type="string">anonymous</value> </choice> </define> <!-- JOIN HANDLING TYPE --> <define name="join-handling-type"> <choice> <value type="string">block</value> <value type="string">allow</value> <value type="string">confirm</value> <value type="string">IVR</value> <value type="string">directed-operator</value> </choice> </define> <!-- USERLIST --> Novo, et al. Expires October 19, 2007 [Page 56]
Internet-Draft Data Model Schema April 2007 <define name="UserList"> <zeroOrMore> <element name="target"> <ref name="target-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- TARGET TYPE --> <define name="target-type"> <attribute name="uri"> <data type="anyURI"/> </attribute> <attribute name="method"> <ref name="method-type"/> </attribute> </define> <!-- METHOD TYPE --> <define name="method-type"> <choice> <value type="string">dial-in</value> <value type="string">dial-out</value> <value type="string">refer</value> </choice> </define> <!-- USER TYPE --> <define name="user-type"> <attribute name="entity"> <data type="anyURI"/> </attribute> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <optional> <element name="display-text"> <text/> </element> </optional> Novo, et al. Expires October 19, 2007 [Page 57]
Internet-Draft Data Model Schema April 2007 <optional> <element name="associated-aors"> <ref name="uris-type"/> </element> </optional> <optional> <element name="provide-anonymity"> <data type="boolean"/> </element> </optional> <optional> <element name="roles"> <ref name="roles-type"/> </element> </optional> <optional> <element name="languages"> <list> <data type="language"/> </list> </element> </optional> <optional> <element name="cascaded-focus"> <data type="anyURI"/> </element> </optional> <optional> <element name="allow-refer-users-dynamically"> <data type="boolean"/> </element> </optional> <optional> <element name="allow-invite-users-dynamically"> <data type="boolean"/> </element> </optional> <optional> <element name="allow-remove-users-dynamically"> <data type="boolean"/> </element> </optional> <zeroOrMore> <element name="endpoint"> <ref name="endpoint-type"/> </element> </zeroOrMore> <zeroOrMore> Novo, et al. Expires October 19, 2007 [Page 58]
Internet-Draft Data Model Schema April 2007 <ref name="anyElement"/> </zeroOrMore> </define> <!-- ENDPOINT TYPE --> <define name="endpoint-type"> <attribute name="entity"> <text/> </attribute> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <optional> <element name="display-text"> <text/> </element> </optional> <optional> <element name="referred"> <zeroOrMore> <ref name="conference-info-urn"/> </zeroOrMore> </element> </optional> <optional> <element name="status"> <ref name="endpoint-status-type"/> </element> </optional> <optional> <element name="joining-method"> <ref name="joining-type"/> </element> </optional> <optional> <element name="joining-info"> <zeroOrMore> <ref name="conference-info-urn"/> </zeroOrMore> </element> </optional> <optional> <element name="disconnection-method"> <ref name="disconnection-type"/> </element> Novo, et al. Expires October 19, 2007 [Page 59]
Internet-Draft Data Model Schema April 2007 </optional> <optional> <element name="disconnection-info"> <zeroOrMore> <ref name="conference-info-urn"/> </zeroOrMore> </element> </optional> <zeroOrMore> <element name="media"> <ref name="media-type"/> </element> </zeroOrMore> <optional> <element name="call-info"> <zeroOrMore> <ref name="conference-info-urn"/> </zeroOrMore> </element> </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- MEDIA TYPE --> <define name="media-type"> <attribute name="id"> <data type="int"/> </attribute> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <ref name="anyAttribute"/> <optional> <element name="display-text"> <text/> </element> </optional> <optional> <element name="type"> <text/> </element> </optional> <optional> Novo, et al. Expires October 19, 2007 [Page 60]
Internet-Draft Data Model Schema April 2007 <element name="label"> <text/> </element> </optional> <optional> <element name="src-id"> <text/> </element> </optional> <optional> <element name="status"> <ref name="media-status-type"/> </element> </optional> <optional> <element name="to-mixer"> <ref name="mixer-type"/> </element> </optional> <optional> <element name="from-mixer"> <ref name="mixer-type"/> </element> </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- MIXER TYPE --> <define name="mixer-type"> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <optional> <element name="floor"> <data type="boolean"/> </element> <element name="controls"> <ref name="controls-type"/> </element> </optional> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> Novo, et al. Expires October 19, 2007 [Page 61]
Internet-Draft Data Model Schema April 2007 </define> <!-- SIDEBARS-BY-REF TYPE --> <define name="sidebars-by-ref-type"> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <zeroOrMore> <element name="entry"> <ref name="uri-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- SIDEBARS-BY-VAL TYPE --> <define name="sidebars-by-val-type"> <optional> <attribute name="state"> <ref name="state-type"/> </attribute> </optional> <zeroOrMore> <element name="entry"> <ref name="conference-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </define> <!-- ROLES_TYPE --> <define name="roles-type"> <zeroOrMore> <element name="entry"> <ref name="single-role-type"/> </element> </zeroOrMore> <zeroOrMore> <ref name="anyElement"/> Novo, et al. Expires October 19, 2007 [Page 62]
Internet-Draft Data Model Schema April 2007 </zeroOrMore> </define> <!-- SINGLE ROLE TYPE --> <define name="single-role-type"> <choice> <value type="string">administrator</value> <value type="string">creator</value> <value type="string">moderator</value> <value type="string">participant</value> <value type="string">observer</value> </choice> </define> <!-- ********************************* EXTENSIBILITY OF THE SCHEMA ********************************* --> <!-- EXTENSIBILITY ELEMENTS --> <define name="anyElement"> <element> <anyName/> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <text/> <ref name="anyElement"/> </choice> </zeroOrMore> </element> </define> <!-- EXTENSIBILITY ATTRIBUTES --> <define name="anyAttribute"> <zeroOrMore> <attribute> <anyName> <except> <name ns="">entity</name> <name ns="">version</name> <name ns="">state</name> <name ns="">xml:lang</name> Novo, et al. Expires October 19, 2007 [Page 63]
Internet-Draft Data Model Schema April 2007 <name ns="">required-participant</name> <name ns="">PIN-code</name> <name ns="">purpose</name> <name ns="">role</name> <name ns="">type</name> <name ns="">min</name> <name ns="">max</name> <name ns="">label</name> <name ns="">decision</name> <name ns="">name</name> <name ns="">policy</name> <name ns="">moderator-controlled</name> <name ns="">uri</name> <name ns="">method</name> <name ns="">id</name> <name ns="">domain</name> <nsName ns=""/> <nsName ns="urn:ietf:params:xml:ns:conference-schema"/> </except> </anyName> <text/> </attribute> </zeroOrMore> </define> <!-- ************************************************************* TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE ************************************************************* --> <!-- WILDCARD FOR EVENT-PACKAGE NAMESPACE --> <define name="conference-info-urn"> <element> <nsName ns="urn:ietf:params:xml:ns:conference-info-urn"/> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <ref name="conference-info-urn"/> </choice> </zeroOrMore> </element> </define> <!-- DEFINITION OF STATE TYPE --> Novo, et al. Expires October 19, 2007 [Page 64]
Internet-Draft Data Model Schema April 2007 <define name="state-type"> <choice> <value>full</value> <value>partial</value> <value>deleted</value> </choice> </define> <!-- DEFINITION OF ENDPOINT STATUS TYPE --> <define name="media-status-type"> <choice> <value>recvonly</value> <value>sendonly</value> <value>sendrecv</value> <value>inactive</value> </choice> </define> <!-- ENDPOINT STATUS TYPE --> <define name="endpoint-status-type"> <choice> <value>pending</value> <value>dialing-out</value> <value>dialing-in</value> <value>alerting</value> <value>on-hold</value> <value>connected</value> <value>muted-via-focus</value> <value>disconnecting</value> <value>disconnected</value> </choice> </define> <!-- JOINING TYPE --> <define name="joining-type"> <choice> <value>dialed-in</value> <value>dialed-out</value> <value>focus-owner</value> </choice> </define> <!-- DISCONNECTION TYPE --> <define name="disconnection-type"> Novo, et al. Expires October 19, 2007 [Page 65]
Internet-Draft Data Model Schema April 2007 <choice> <value>departed</value> <value>booted</value> <value>failed</value> <value>busy</value> </choice> </define> </grammar> Authors' Addresses Oscar Novo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Oscar.Novo@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com David P. Morgan Fidelity Investments 82 Devonshire St, MZ V3C Boston, MA 02109-3614 USA Email: Dave.Morgan@fmr.com Novo, et al. Expires October 19, 2007 [Page 66]
Internet-Draft Data Model Schema April 2007 Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel Email: roni.even@polycom.co.il Novo, et al. Expires October 19, 2007 [Page 67]
Internet-Draft Data Model Schema April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Novo, et al. Expires October 19, 2007 [Page 68]