XCON O. Novo Internet-Draft G. Camarillo Intended status: Informational Ericsson Expires: April 13, 2007 D. Morgan Fidelity Investments R. Even Polycom October 10, 2006 A Common Conference Information Data Model for Centralized Conferencing (XCON) draft-ietf-xcon-common-data-model-03.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 April 13, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document collects, organizes, and describes the conference variables that have been introduced in various protocol drafts of the XCON and SIPPING working groups. The goal of this document is to Novo, et al. Expires April 13, 2007 [Page 1]
Internet-Draft Common Conference Schema October 2006 allow the conference control protocols to use a unified common conference information data model for XCON. This document formally defines an Extensible Markup Language (XML) Schema that represents the common conference information in a conferencing server. The information is modeled as a series of elements, each of which contains a set of children and attributes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Common Conference Data . . . . . . . . . . . . . . . . . . . . 4 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Common Conference Policies . . . . . . . . . . . . . . . . 9 3.3. <conference-description> . . . . . . . . . . . . . . . . . 10 3.3.1. <conference-time> . . . . . . . . . . . . . . . . . . 11 3.3.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 13 3.3.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 13 3.3.5. <maximum-streams> . . . . . . . . . . . . . . . . . . 13 3.3.6. <available-media> . . . . . . . . . . . . . . . . . . 13 3.3.7. <controls> . . . . . . . . . . . . . . . . . . . . . . 14 3.3.7.1. mute . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.7.2. pause-video . . . . . . . . . . . . . . . . . . . 14 3.3.7.3. gain . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. <conference-state> . . . . . . . . . . . . . . . . . . . . 15 3.6. <floor-information> . . . . . . . . . . . . . . . . . . . 15 3.7. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.7.1. <allowed-users-list> . . . . . . . . . . . . . . . . . 17 3.7.2. <privileges-control-list> . . . . . . . . . . . . . . 18 3.7.2.1. <conference-rules> . . . . . . . . . . . . . . . . 18 3.7.2.1.1. <condition> . . . . . . . . . . . . . . . . . 18 3.7.2.1.2. <pseudonymous> . . . . . . . . . . . . . . . . 19 3.7.2.1.3. <has-been-referred> . . . . . . . . . . . . . 19 3.7.2.1.4. <has-been-invited> . . . . . . . . . . . . . . 19 3.7.2.1.5. <has-been-in-conference> . . . . . . . . . . . 19 3.7.2.1.6. <is-in-conference> . . . . . . . . . . . . . . 19 3.7.2.1.7. <administrator> . . . . . . . . . . . . . . . 19 3.7.2.1.8. <is-on-allowed-users-list-dial-out> . . . . . 20 3.7.2.1.9. <is-on-allowed-users-list-refer> . . . . . . . 20 3.7.2.1.10. <participant-passcode> . . . . . . . . . . . . 20 3.7.2.1.11. <administrators-passcode> . . . . . . . . . . 20 3.7.2.2. <actions> . . . . . . . . . . . . . . . . . . . . 21 3.8. <user> . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.8.1. from-mixer, to-mixer . . . . . . . . . . . . . . . . . 23 3.8.1.1. <floor> . . . . . . . . . . . . . . . . . . . . . 23 Novo, et al. Expires April 13, 2007 [Page 2]
Internet-Draft Common Conference Schema October 2006 3.9. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 24 3.10. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 24 4. RELAX NG schema . . . . . . . . . . . . . . . . . . . . . . . 24 5. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 48 6. XML example . . . . . . . . . . . . . . . . . . . . . . . . . 49 7. Security Considerations . . . . . . . . . . . . . . . . . . . 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 10.1. Normative References . . . . . . . . . . . . . . . . . . . 58 10.2. Informative References . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . . . . 61 Novo, et al. Expires April 13, 2007 [Page 3]
Internet-Draft Common Conference Schema October 2006 1. Introduction This document defines an Extensible Markup Language (XML) Schema that represents the conference object in a conferencing server. The information is modeled as a series of elements, each of which contains children and attributes. The Conference Object contains the XML schema, which is used to represent the core information that is utilized in any conference (capabilities, membership, roles, call control signalling, media, etc...) and specifies the set of rights, permissions and limitations pertaining to operations being performed on a certain Conference Object. This document gives an overview of the conference variables that have been introduced in various protocol drafts of the XCON working group to date and proposes to create a unified common conference information data model for XCON. This document has been constructed in compliance with the XCON Framework [1] and the Session Initiation Protocol (SIP) Event Package for Conference State [2]. It also incorporates data elements proposed in several XCON WG and SIPPING WG drafts. 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 [3]. This document uses the terminology defined in the XCON Conferencing Framework [1] and the SIPPING Conferencing Framework [4]. In addition, it uses definitions from The Binary Floor Control Protocol [7]. 3. Common Conference Data 3.1. General The conference object data model document is an XML [5] 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 Common Conference information document begins with the root element tag <conference-info> of conference-type. The <conference-info> has Novo, et al. Expires April 13, 2007 [Page 4]
Internet-Draft Common Conference Schema October 2006 the attribute 'entity' that contains the conference unique identifier that identifies the conference being described in the document. The <conference-info> element is comprised of <conference- description>, <host-info>, <conference-state>, <floor-information>, <users>, <sidebars-by-ref>, <sidebars-by-val>, child elements. A common conference document must at least include the <conference- description>, <host-info>, <conference-state>, and <users> child elements. Some of this information can be represented using the conference-info-type schema as defined in [2]. Changes in the state of the conference should be communicated to the subscribers using a conference package subscribers (ex. A Session Initiation Protocol (SIP) Event Package for Conference State). Critical changes should be communicated to specific subscribers, perhaps those with unique roles. The conference policy control protocol msy be used to retrieve the conference state at any time. The following non-normative diagram gives an example of the overall hierarchy used in this format. The operator "!" preceding an element indicates that this element is MANDATORY in the data model. The operator "*" preceding an element indicates that this element is introduced/proposed in this draft. !<conference-info> | |--!<conference-description> | |--<display-text> | |--<subject> | |--<free-text> | |--<keywords> | |--<web-page> | |--<security-level> | |--<allow-sidebars> | |--<conference-stage> | |--<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> | | |--<SIP> Novo, et al. Expires April 13, 2007 [Page 5]
Internet-Draft Common Conference Schema October 2006 | | | |--<uri> | | | |--<display-text> | | | |--<purpose> | | |--<H323> | | | |--<H.323-alias> | | | |--<H.323-URI> | | |--<PSTN/ISDN> | | | |--<phone number> | | | |--<PIN-code> | | | |--<purpose> | | | |--<rate> | | ... | |--<service-uris> | | |--<SIP> | | | |--<uri> | | | |--<display-text> | | | |--<purpose> | | |--<H323> | | | |--<H.323-alias> | | | |--<H.323-URI> | | |--<PSTN/ISDN> | | | |--<phone number> | | |--<BFCP> | | | |--<conference-ID> | | ... | |--<maximum-user-count> | | |--<entry> | | |--<entry> | | ... | |--<maximum-streams> | | |--<entry> | | |--<entry> | | ... | |--!<available-media> | | |--!<entry> | | | |--<type> | | | |--<display-text> | | | |--<status> | | | |--<mixing-mode> | | | |--<mix-level> | | | |--<codecs> | | | | |--<entry> | | | | |--<entry> | | | | ... | | | |--<controls> | | | | |--<mute> | | | | |--<gain> | | | | ... Novo, et al. Expires April 13, 2007 [Page 6]
Internet-Draft Common Conference Schema October 2006 | | |--<entry> | | | |--<type> | | | |--<display-text> | | | |--<status> | | | |--<mixing-mode> | | | |--<mix-level> | | | |--<codecs> | | | | |--<entry> | | | | |--<entry> | | | | ... | | | |--<controls> | | | | |--<pause-video> | | | | ... | | ... | |--!<host-info> | |--<display-text> | |--<web-page> | |--!<uris> | | |--!<SIP> | | | |--!<uri> | | | |--<display-text> | | | |--<purpose> | | |--<H323> | | | |--<H.323-alias> | | | |--<H.323-URI> | | |--<PSTN/ISDN> | | | |--<phone number> | ... |--!<conference-state> | |--<allow-conference-state> | |--<user-count> | |--!<active> | |--<locked> | |--<floor-information> | |--<allow-floor-events> | |--<floor-request-handling> | |--<conference-floor-policy> | | |--<floor> | | | |--<media-types> | | | |--<algorithm> | | | |--<max-floor-users> | | | |--<moderator-uri> | | | |--<moderator-uri> | | | ... | | ... | Novo, et al. Expires April 13, 2007 [Page 7]
Internet-Draft Common Conference Schema October 2006 |--!<users> | |--<join-handling> | |--<user-admission-policy> | |--<allowed-users-list> | | |--<target> | | |-- ... | | | |--<privileges-control-list> | | |--<conference-rules> | | | |--<entry> | | | | |--<condition> | | | | | |--<identity> | | | | | | | | | | | | | ... | | | | | | | | | | | |--<validity> | | | | | | |--<from> | | | | | | |--<until> | | | | | | | | | |--<actions> | | | | | | | | | | | ... | | | ... | | | |--!<user> | | |--<display-text> | | |--<associated-aors> | | |--<provide-anonymity> | | |--<roles> | | | | | | | ... | | |--<languages> | | |--<cascaded-focus> | | |--<sphere> | | |--<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> Novo, et al. Expires April 13, 2007 [Page 8]
Internet-Draft Common Conference Schema October 2006 | | | | |--<label> | | | | |--<src-id> | | | | |--<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> | | | | ... ... Following sections describe these elements in detail. The full XML schema is provided in Section 4. 3.2. Common Conference Policies Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object data model. Novo, et al. Expires April 13, 2007 [Page 9]
Internet-Draft Common Conference Schema October 2006 The set of rights describes the read/write access privileges for the conference object data model as a whole. Every element of the data model SHOULD has defined two attributes: the attribute 'read-only', and the attribute 'read-write'. These attributes describes the read/ write access privileges for accessing the Conference Object as a whole. It is partially described in [1]. When the conferencing server receives a request for access privacy-sensitive data it needs to match it against the 'read-only' and the 'read-write' attributes. Each attribute of each individual element is evaluated and as a result it is determined if the user can access that element. The attributes specify the minimum subscriber's role that can access or modify the element of the conference. Subscribers with a lower role cannot access or modify the element. If an attribute is not defined in some element, the 'read-only' attribute MUST be interpreted as a "participant" and the 'read-write' attribute MUST be interpreted as an "administrator" by default. It is possible to defined only one of the attributes of the element, the other attribute SHOULD be interpreted by default. This draft does not define the set of possible conferencing roles. However, it can also be the case that conflicts can occur given a hierarchy of elements. In that case, the lower-level element privileges predominate over the upper-level privileges element. This document defines a more specific right mechanism in Section 3.7.2, beyond the 'read-only' and 'read-write' attributes. The permissions and limits are specified as an integral part of the data model, with elements containing the allowed ranges for other elements (e.g., maximum number of participants) and lists of clients allowed to perform certain operations on a conference object. 3.3. <conference-description> The <conference-description> element describes the conference in its entirely. It SHOULD have an extra attribute 'xml:lang' to specify the language used in the contents of this element as defined Section 2.12 of [5]. It is comprised of <display-text>, <subject>, <free- text>, <keywords>, <web-page>, <security-level>, <allow-sidebars>, <conference-stage>, <conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>, <maximum-streams>, and <available-media>. The child elements <display-text>, <subject>, <free-text> and <keywords> are used to describe the conference content. These elements are defined in [2]. The child element <web-page> is an optional element that points to a URI with additional information about the conference. The child Novo, et al. Expires April 13, 2007 [Page 10]
Internet-Draft Common Conference Schema October 2006 elements <security-level> and <allow-sidebars> describe the capabilities of the conference. The <conference-stage> is a mandatory element that give the stage of the conference. This element can have 4 values: reserved, started, running, and ended. At the reserved stage the conference exists only in the conference control server. There is no running focus and there are no subscribers or notifications. The information is accessible only via the conference control protocol. At the started stage, there are no users yet in the conference, still it is possible to subscribe to the conference state. The running stage starts when the first user joins the conference. In the ended stage, there are no users connected to the conference, the conference information is only in the conference server for recurring conference or for CDR. At this stage a user can get information only from the conference control protocol. For instance, The Session Initiation Protocol (SIP) Event Package for Conference State [2] is only applicable in the start and running stage. The <conference-time> child element has information related to conference time and duration of the conference. Other elements from different namespaces MAY be present for the purposes of extensibility. 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 <maximum-streams> child element indicates the number of streams that can be for every media type. The <available-media> child element is used to describe the media characteristics of the conference. The following sections describe the remaining elements in more detail. Other child elements can be used to extend <conference- description> in the future. 3.3.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 of 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 Novo, et al. Expires April 13, 2007 [Page 11]
Internet-Draft Common Conference Schema October 2006 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 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 [6]. 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 near. 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 near. 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. Novo, et al. Expires April 13, 2007 [Page 12]
Internet-Draft Common Conference Schema October 2006 3.3.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: <SIP>, <H.323>, and <PSTN/ISDN>. The <SIP> element contains the <uri>, <display-text>, and <purpose>. <uri>, <display-text>, and <purpose> are described in [2]. 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. <PSTN/ISDN> element may include 1 or more <phone number> child elements and the call rate as well. 3.3.3. <service-uris> The <service-uris> describes auxiliary services available for the conference. It contains a sequence of child elements: <SIP>, <H.323>, <PSTN/ISDN>, and <BFCP>. <SIP> child element contains <uri>, <display-text>, and <purpose>. The purpose will be used to describe the service. These elements are described in [2]. <H.323>, and <PSTN/ISDN> child elements are described in <conf-uris> section. The <BFCP> has a sub-element <conference-ID> that are used by a floor control server to provide a client with a conference ID. 3.3.4. <maximum-user-count> The <maximum-user-count> contains the overall number of users allowed to join the conference. It contains a sequence of <entry> child elements. An <entry> element MAY contain the number of users with a specific role allowed to join the conference. 3.3.5. <maximum-streams> The <maximum-streams> contains the maximum number of streams that are permitted to be involved in a conference. It contains a sequence of <entry> child elements. An <entry> element MAY contain the number of streams of every specific type of stream, for instance, audio or video. The minimum value permitted is "1" and the maximum value permitted is "128". This element is optional. 3.3.6. <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 Novo, et al. Expires April 13, 2007 [Page 13]
Internet-Draft Common Conference Schema October 2006 elements. The attribute 'label' and the <type>, <display-text>, and <status> elements are described in [2]. 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 approvement of the moderator of the conference (automatic, moderator-controlled). The <codecs> element contains a <entry> elements. A <entry> element can have the attribute 'name' and 'policy'. The 'name' attribute identifies a codec, and the 'decision' attribute and the policy attribute contains the policy for that codec (allowed, or disallowed). The child elements <mixing-mode>, <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 that the policy describe for 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 stremas means 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. Next section explains the <controls> child element. 3.3.7. <controls> The <controls> element contains the basic audio and video global controls for a conferencing. It is expected that for most of the basic conferencing, these controls are sufficient. If the conference server wants to support more advanced control, then it is recommended extension of the data model to be used. In the <controls> element the schema is extensible, hence new control types can be added in a future. Similarly, controls that apply to a especific users would appear under the <users>/<user>/<endpoint> element. So, moderator controls that affect all media output would go under the <available- media> element. 3.3.7.1. mute The 'mute' control is used in conjunction with a audio stream to cease transmission of associated media. It has a 'Boolean' value. If this control is not specify, the access to the control is not available to the client and media SHOULD not be transported for the associated media stream. 3.3.7.2. pause-video The 'pause-video' control is used in conjunction with a video stream to cease transmission of associated media. It has a 'Boolena' value. Novo, et al. Expires April 13, 2007 [Page 14]
Internet-Draft Common Conference Schema October 2006 If this control is not specify, the access to the control is not available to the client and media SHOULD not be transported for the associated media stream. 3.3.7.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 from -127 to 127. If this control is not specify, the access to the control is not available to the client. 3.4. <host-info> The <host-info> element contains information about the entity hosting the conference. It contains the <display-text>, <web-page> child elements. These child elements are explained in [2]. <host-info> contains the <uris> child element as well. <uris> contains a sequence of child elements: <SIP>, <H.323>, and <PSTN/ISDN>. The child elements of <uris> are described in <conf-uris> section. 3.5. <conference-state> The <conference-state> element and the <user-count>, <active>, and <locked> child element are explained in section 5.5 of [2]. The <allow-conference-state> 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 [2]. If set to FALSE, the subscription to conference state events would be rejected. If this element is undefined it has a value of TRUE, causing the subscription to conference state events to be accepted. 3.6. <floor-information> The <floor-information> element has the <allow-floor-events>, <floor- request-handling>, and the <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. 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 value of FALSE, causing the subscription to floor control events to be rejected. Novo, et al. Expires April 13, 2007 [Page 15]
Internet-Draft Common Conference Schema October 2006 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 of 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 of the <Moderator- controlled>, <FCFS>, and <Random> elements indicating the algorithm. The <Max-floor-users> element in the <Floor> element is optional and, if present, dictates the maximum number of users who can have the floor at one time. The optional <Moderator-URI> indicates the URI of the moderator. It MUST be set if the attribute moderator-controlled is set to "true". 3.7. <users> The <users> element contains the <join-handling>, <user-admission- policy>, <allowed-users-list>, <privileges-control-list> and <user> child elements. Novo, et al. Expires April 13, 2007 [Page 16]
Internet-Draft Common Conference Schema October 2006 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 define 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> element is a list of three elements: 'closedAuthenticated', 'openAuthenticated', and 'anonymous'. If the <user-admission-policy> element is set to 'closedAuthenticated', users must be specified (and authenticate). If the attribute is set to 'openAuthenticated', users can be add after conference activation. The following sections describe the remaining elements in more detail. Other child elements can be used to extend <conference- description> in the future. 3.7.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 invite 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 element. 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. Value "refer" is used by the Novo, et al. Expires April 13, 2007 [Page 17]
Internet-Draft Common Conference Schema October 2006 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 towards 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. 3.7.2. <privileges-control-list> The <privileges-control-list> refers to a virtual set of rights pertaining to operations. This element contains the <conference- rules> element. 3.7.2.1. <conference-rules> The <conference-rules> element is a set of <entry> child elements with specific authorization rules that indicate who is allowed to subscribe to conference-information notifications, see floors, request/grant floors, and so on. Every <entry> element is represent by the 'id' attribute, each of which identifies a rule inside the conference. It contains the <condition> and <actions> sub elements. 3.7.2.1.1. <condition> The <condition> element determines whether a particular privilege applies to a user, a role, or domain. The <condition> element has the <identity> and the <validity> child element. These elements MUST NOT appear more than once in the condition part of a single rule. The <identity> element restricts matching of a rule either to a single entity or a group of entities. The <identity> element has the <one> and <many> child elements defined in Section 7.1 of [8]. The absence of the <identity> element in a <condition> element indicates that the privilege applies to all unauthenticated identities. Novo, et al. Expires April 13, 2007 [Page 18]
Internet-Draft Common Conference Schema October 2006 The <identity> element has other child elements. These child elements are <pseudonymous>, <has-been-referred>, <has-been-invited>, <has-been-in-conference>, <is-in-conference>, <administrator>, <is- on-allowed-users-list-dial-out>, <is-on-allowed-users-list-refer>, <participant-passcode>, and <administrator-passcode>. The <validity> element expresses the validity period of the rule with a starting and an ending time. The <validity> element and its child elements ,<from> and <until>, are defined in section 7.3 of [8]. 3.7.2.1.2. <pseudonymous> The <pseudonymous> element is used to match participants that have provided an authenticated identity to the conference focus, but have requested pseudonymity in the conference itself. A user requests pseudonymity by authenticating himself to the conference focus and providing a pseudonym in the signalling protocol (for example, using the From-header of a SIP request). The <pseudonymous> element can be combined with the <identity> element to provide the focus with a rule on what to do when a specific identity is authenticated and that identity is requesting pseudonymity through the signalling protocol. 3.7.2.1.3. <has-been-referred> The <has-been-referred> element can be used to match those participants that the focus has referred to the conference. 3.7.2.1.4. <has-been-invited> The <has-been-invited> element can be used to match those participants that the focus has invited into the conference. 3.7.2.1.5. <has-been-in-conference> The <has-been-in-conference> element can be used to match those participants that have joined the conference in the past. 3.7.2.1.6. <is-in-conference> The <is-in-conference> element can be used to match those participants that are currently participating in the conference. 3.7.2.1.7. <administrator> The <administrator> element can be used to match those participants that are administrators of a conference. Novo, et al. Expires April 13, 2007 [Page 19]
Internet-Draft Common Conference Schema October 2006 3.7.2.1.8. <is-on-allowed-users-list-dial-out> The <is-on-allowed-users-list-dial-out> element can be used to match those participants that are on the allowed-users-list with the method dial-out. 3.7.2.1.9. <is-on-allowed-users-list-refer> The <is-on-allowed-users-list-refer> element can be used to match those participants that are on the allowed-users-list with the method refer. 3.7.2.1.10. <participant-passcode> The <participant-passcode> element can be used to match those participants that have knowledge of a passcode for the conference (PIN code). A focus need not care if a user using a passcode to join is calling from a PSTN or an IP phone. For example: Using a SIP phone, a SIP INVITE request arrives directly at the focus. The focus examines the identity and discovers that there are no rules allowing this identity to join. The focus also determines that there are no rules explicitly prohibiting this identity from joining. The focus in this case decides to challenge the identity for a passcode, if there is a rule that allows users with a passcode knowledge to join. If no such rule exists, the focus would not challenge for a passcode. For PSTN users, the system can be set up for an IVR system to prompt the user for a passcode before forwarding the request to the focus. The focus does not need to care if there is an IVR system or not. It can apply the same procedure as above. It checks if there are any the rules allowing or denying the identity access. In this case, the identity is the GW. If no rules exist for that identity but a general passcode rule does, then the focus would challenge the GW/IVR for the passcode. A focus can challenge for the passcode using, for example, a HTTP Digest challenge. The username, passcode and realm need to be assigned and distributed is a manner that is outside the scope of this document. Mutliple passcodes can be assigned to multiple users. 3.7.2.1.11. <administrators-passcode> In some cases, administrators of the conference are assigned a different passcode than normal participants. The <administrator- passcode> element can be used to match those key participants that have knowledge on a key participant passcode for the conference. Novo, et al. Expires April 13, 2007 [Page 20]
Internet-Draft Common Conference Schema October 2006 Again, a focus need not care if a user using a passcode to join is calling from a PSTN or an IP phone. It is important that the focus has a unique identity for each user joining from a PSTN phone via a gateway. It is not enough that one identity to be assigned to all users joining from the same gateway since administrators have more control over conference duration. It might be required that a gateway maps the telephone number of the PSTN phone into the IP signalling protocol header that usually carries the asserted identity or a user. 3.7.2.2. <actions> The <actions> element in the applied rule is a positive grant of permission to the conference data model or the conferencing system. The <actions> element has the following operations: o The <allow-refer-users-dynamically> element represents a boolean action. If set to TRUE, the identity is allowed to instruct the focus to refer a user to the conference without modifying the allowed-users-list (in SIP terms, the identity is allowed to send a REFER request to the focus which results in the focus sending a REFER request to the user the referrer wishes to join the conference). If set to FALSE, the refer request is rejected. If this element is undefined it has a value of FALSE, causing the refer to be rejected. o The <allow-invite-users-dynamically> element represents a boolean action. If set to TRUE, the identity is allowed to instruct the focus to invite a user to the conference without modifying the allowed-users-list list (in SIP terms, the identity is allowed to send a REFER request to the focus which results in the focus sending an INVITE request to the user the referrer wishes to join the conference). If set to FALSE, the refer request is rejected. If this element is undefined it has a value of FALSE, causing the refer to be rejected. o The <allow-remove-users-dynamically> element represents a boolean action. If set to TRUE, the identity is allowed to instruct the focus to remove a user from the conference without modifying the ruleset (in SIP terms, the identity is allowed to send a REFER request to the focus which results in the focus sending an BYE request to the user the referrer wishes to leave the conference). If set to FALSE, the refer request is rejected. If this element is undefined it has a value of FALSE, causing the refer to be rejected. o The <show-floor-holder> 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 has defined values of: Novo, et al. Expires April 13, 2007 [Page 21]
Internet-Draft Common Conference Schema October 2006 * 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. * confirm: This action instructs the focus to allow the request. The focus then uses the defined floor algorithm to further allow of deny the floor. The algorithms used are outside the scope of this document. o 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 resolve to true for this participant that carried an action whose value was higher than block would automatically grant confirm/allow permission to that participant. o The <show-floor-requests> element is of type boolean transformation. If set to TRUE, the conference participant is able to see the floor requests. If set to FALSE, the conference participant is not able to see floor requests. If this element is undefined, it has a value of FALSE, causing the floor requests to not being seen by the conference participant. o A rule can be set that provides anonymity to a specific identity. In this case, the focus provides to the rest of the participants an anonymous identity for that user, for example anonymous1. 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. o The <read-write> element represents a boolean action. If set to TRUE, the identity is allowed to modify the element described inside the 'element' attribute in the conference policy. If set to FALSE, any modifications to the element are rejected. o The <read-only> element represents a boolean action. If set to TRUE, the identity is allowed to read the element described inside the 'element' attribute in the conference policy. If set to FALSE, any attempts to read the element are rejected. 3.8. <user> The element <user> describes a single participant in the conference. The following elements as well as the attributes of <user> are defined in [2], section 5.6: <display-text>, <associated-aors>, <roles>, <languages>, <cascaded-focus>, and <endpoint>. The <provide-anonymity> provides anonymity to the user. When a user is defined then the role must be defined or set to "participant" by default. This specification does not define the set of possible conferencing roles nor the semantics associated with each. Novo, et al. Expires April 13, 2007 [Page 22]
Internet-Draft Common Conference Schema October 2006 The <sphere> element can be used to indicate the state (e.g., 'work', 'home', 'meeting', 'travel') the user is currently in. It is defined in section 7.2 of [8]. The <allow-refer-users-dynamically>, <allow-invite-users-dynamically> and <allow-remove-users-dynamically> elements are defined in the previous section. The <endpoint> element is under a <user> parent. This element can provide the desired level of detail about the user's devices and signaling sessions taking part in the conference and has the following child elements defined in [2]: <display-text>, <referred>, <status>, <joining-method>, <joining-info>, <disconnection-method>, <disconnection-info>, <media>, and <call-info>. The <endpoint> element has as well two other child elements: <to-mixer>, and <from- mixer> child element described in the following section. 3.8.1. from-mixer, to-mixer Similarly that the controls defined in the <available-media> element, controls that apply to a particular user appear at this place in the document. The <to-mixer> element details properties associated with the incoming streams to the mixer. <from-mixer> element details properties associated with the outgoing streams from the mixer. Both of these elements have the attribute 'name'. '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. Every of these elements have the <floor> and <controls> child elements. 3.8.1.1. <floor> The <floors> 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 a floor from the moderator of the conference. The <floor> element has a 'Boolen' value. A value of 'false' indicates that this user does not hold the floor in this moment. If this control is not specify, this user SHOULD not specify the floor option. Novo, et al. Expires April 13, 2007 [Page 23]
Internet-Draft Common Conference Schema October 2006 3.9. <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 conference unique identifier and a <display-text> child element. The <sidebars-by-ref> element is described in Section 5.9.1 of [2]. Notice that the <sidebars-by-ref> child element does not include the attribute 'state' defined in [2]. 3.10. <sidebars-by-val> The <sidebars-by-val> element contains a set of <entry> child elements each containing information about a single sidebar. Notice as well that the <sidebars-by-val> and the <entry> child element do not include the attribute 'state' defined in [2]. 4. RELAX NG schema In accordance with the XCON framework document [1], the Conference Object is a logical representation of a conference instance. The common 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. <?xml version="1.0" encoding="UTF-8"?> <grammar xmlns="http://relaxng.org/ns/structure/1.0" xmlns:xs="http://relaxng.org/ns/compatibility/annotations/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <start> <ref name="conference-type"/> </start> <!-- CONFERENCE TYPE --> <define name="conference-type"> <element name="conference-info"> <ref name="role-type"/> <zeroOrMore> Novo, et al. Expires April 13, 2007 [Page 24]
Internet-Draft Common Conference Schema October 2006 <ref name="conference-description-type"/> <element name="host-info"> <ref name="host-type"/> </element> <element name="conference-state"> <ref name="conference-state-type"/> </element> <element name="floor-information"> <ref name="floor-information-type"/> </element> <element name="users"> <ref name="user-type"/> </element> <element name="sidebars-by-ref"> <ref name="sidebars-by-ref-type"/> </element> <element name="sidebars-by-val"> <ref name="sidebars-by-val-type"/> </element> </zeroOrMore> </element> </define> <!-- CONFERENCE DESCRIPTION TYPE --> <define name="conference-description-type"> <element name="conference-description"> <ref name="role-type"/> <optional> <element name="display-text"> <text/> </element> <element name="subject"> <text/> </element> <element name="free-text"> <text/> </element> <element name="keywords"> <list> <data type="string"/> </list> </element> <element name="webpage"> <data type="anyURI"/> </element> <element name="security-level"> Novo, et al. Expires April 13, 2007 [Page 25]
Internet-Draft Common Conference Schema October 2006 <ref name="SecurityLevel"/> </element> <element name="allow-sidebars"> <data type="boolean"/> </element> <element name="conference-stage"> <ref name="conference-stage-type"/> </element> <element name="conference-time"> <ref name="conferencetime-type"/> </element> <element name="conf-uris"> <ref name="uris-type"/> </element> <element name="service-uris"> <ref name="uris-type"/> </element> <element name="maximum-user-count"> <ref name="maximum-user-count-type"/> </element> <element name="maximum-streams"> <ref name="maximum-streams-type"/> </element> <element name="available-media"> <ref name="conference-media-type"/> </element> </optional> <xs:any/> </element> </define> <!-- SECURITY LEVEL --> <define name="SecurityLevel"> <choice> <value type="string">none</value> <value type="string">low</value> <value type="string">medium</value> <value type="string">high</value> </choice> </define> <!-- CONFERENCE STAGE --> <define name="conference-stage-type"> <choice> Novo, et al. Expires April 13, 2007 [Page 26]
Internet-Draft Common Conference Schema October 2006 <value type="string">reserved</value> <value type="string">started</value> <value type="string">running</value> <value type="string">ended</value> </choice> </define> <!-- CONFERENCE TIME --> <define name="conferencetime-type"> <ref name="role-type"/> <zeroOrMore> <element name="entry"> <optional> <element name="base"> <text/> </element> <element name="mixing-start-offset"> <data type="int"/> </element> <element name="mixing-stop-offset"> <data type="int"/> </element> <element name="can-join-after-offset"> <data type="int"/> </element> <element name="must-join-before-offset"> <data type="int"/> </element> <element name="request-users"> <data type="int"/> </element> <element name="notify-end-of-conference"> <data type="int"/> </element> <element name="allowed-extend-mixing-end-offset"> <data type="boolean"/> </element> </optional> </element> </zeroOrMore> </define> <!-- URIS TYPE --> <define name="uris-type"> Novo, et al. Expires April 13, 2007 [Page 27]
Internet-Draft Common Conference Schema October 2006 <ref name="role-type"/> <oneOrMore> <element name="SIP"> <ref name="uri-type"/> </element> <element name="H323"> <ref name="H323-type"/> </element> <element name="PSTN-ISDN"> <ref name="PSTN-type"/> </element> <element name="BFCP"> <ref name="BFCP-type"/> </element> </oneOrMore> </define> <!-- SIP TYPE --> <define name="uri-type"> <ref name="role-type"/> <oneOrMore> <element name="uri"> <data type="anyURI"/> </element> <zeroOrMore> <element name="display-text"> <text/> </element> <element name="purpose"> <text/> </element> <element name="PIN-code"> <data type="int"/> </element> </zeroOrMore> </oneOrMore> </define> <!-- H323 TYPE --> <define name="H323-type"> <ref name="role-type"/> <zeroOrMore> <element name="H.323-alias"> <text/> Novo, et al. Expires April 13, 2007 [Page 28]
Internet-Draft Common Conference Schema October 2006 </element> <element name="H.323-URI"> <data type="anyURI"/> </element> </zeroOrMore> </define> <!-- PSTN TYPE --> <define name="PSTN-type"> <ref name="role-type"/> <attribute name="PIN-code"> <text/> </attribute> <attribute name="purpose"> <text/> </attribute> <zeroOrMore> <element name="phone-number"> <data type="unsignedInt"/> </element> <element name="rate"> <data type="unsignedInt"/> </element> </zeroOrMore> </define> <!-- BFCP TYPE --> <define name="BFCP-type"> <ref name="role-type"/> <zeroOrMore> <element name="conference-id"> <data type="unsignedInt"/> </element> </zeroOrMore> </define> <!-- MAXIMUM USER TYPE --> <define name="maximum-user-count-type"> <ref name="role-type"/> <xs:attribute name="role"> <ref name="single-role-type"/> </xs:attribute> <zeroOrMore> Novo, et al. Expires April 13, 2007 [Page 29]
Internet-Draft Common Conference Schema October 2006 <element name="entry"> <data type="unsignedInt"/> </element> </zeroOrMore> </define> <!-- MAXIMUM STREAM TYPE --> <define name="maximum-streams-type"> <ref name="role-type"/> <zeroOrMore> <element name="entry"> <ref name="role-type"/> <attribute name="type"> <ref name="media-stream-type"/> </attribute> <attribute name="min"> <data type="positiveInteger"/> </attribute> <attribute name="max"> <data type="positiveInteger"/> </attribute> </element> </zeroOrMore> </define> <!-- MEDIA TYPES --> <define name="media-stream-type"> <choice> <value type="string">audio</value> <value type="string">video</value> </choice> </define> <!-- CONFERENCE MEDIA TYPE --> <define name="conference-media-type"> <ref name="role-type"/> <attribute name="label"> <text/> </attribute> <zeroOrMore> <element name="entry"> <ref name="conference-medium-type"/> Novo, et al. Expires April 13, 2007 [Page 30]
Internet-Draft Common Conference Schema October 2006 </element> </zeroOrMore> </define> <!-- CONFERENCE MEDIUM TYPE --> <define name="conference-medium-type"> <ref name="role-type"/> <attribute name="label"> <text/> </attribute> <zeroOrMore> <element name="type"> <text/> </element> <element name="display-text"> <text/> </element> <element name="status"> <ref name="media-status-type"/> </element> <element name="mixing-mode"> <ref name="mix-mode-type"/> </element> <element name="mix-level"> <data type="unsignedInt"/> </element> <element name="codecs"> <ref name="codecs-type"/> </element> <element name="controls"> <ref name="control-type"/> </element> </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> Novo, et al. Expires April 13, 2007 [Page 31]
Internet-Draft Common Conference Schema October 2006 <!-- CODECS TYPE --> <define name="codecs-type"> <ref name="role-type"/> <attribute name="decision"> <ref name="decision-type"/> </attribute> <zeroOrMore> <element name="entry"> <ref name="codec-type"/> </element> </zeroOrMore> </define> <!-- CODEC TYPE --> <define name="codec-type"> <ref name="role-type"/> <attribute name="name"> <text/> </attribute> <attribute name="policy"> <ref name="policy-type"/> </attribute> </define> <!-- 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> Novo, et al. Expires April 13, 2007 [Page 32]
Internet-Draft Common Conference Schema October 2006 <!-- CONTROL TYPE --> <define name="control-type"> <choice> <value type="string">integer</value> <value type="string">real</value> <value type="string">boolean</value> </choice> </define> <!-- HOST TYPE --> <define name="host-type"> <ref name="role-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> </define> <!-- CONFERENCE STATE TYPE --> <define name="conference-state-type"> <ref name="role-type"/> <zeroOrMore> <element name="allow-conference-state"> <data type="boolean"/> </element> <element name="user-count"> <data type="unsignedInt"/> </element> <element name="active"> <data type="boolean"/> </element> <element name="locked"> <data type="boolean"/> </element> </zeroOrMore> Novo, et al. Expires April 13, 2007 [Page 33]
Internet-Draft Common Conference Schema October 2006 </define> <!-- FLOOR INFORMATION TYPE --> <define name="floor-information-type"> <ref name="role-type"/> <zeroOrMore> <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> </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"> <ref name="role-type"/> <attribute name="moderator-controlled"> <data type="boolean"/> </attribute> <attribute name="label"> <text/> </attribute> <oneOrMore> <element name="Floor"> <zeroOrMore> <element name="Media-types"> Novo, et al. Expires April 13, 2007 [Page 34]
Internet-Draft Common Conference Schema October 2006 <ref name="role-type"/> <zeroOrMore> <element name="Video"> <empty/> </element> <element name="Audio"> <empty/> </element> <element name="Application"> <empty/> </element> <element name="Data"> <empty/> </element> <element name="Control"> <empty/> </element> <element name="Message"> <empty/> </element> <element name="Text"> <empty/> </element> </zeroOrMore> </element> <element name="Algorithm"> <ref name="role-type"/> <zeroOrMore> <element name="Moderator-controlled"> <empty/> </element> <element name="FCFS"> <empty/> </element> <element name="Random"> <empty/> </element> </zeroOrMore> </element> <element name="Max-floor-users"> <data type="nonNegativeInteger"/> </element> <element name="Moderator-URI"> <data type="anyURI"/> </element> </zeroOrMore> </element> </oneOrMore> Novo, et al. Expires April 13, 2007 [Page 35]
Internet-Draft Common Conference Schema October 2006 </define> <!-- USERS TYPE --> <define name="users-type"> <ref name="role-type"/> <zeroOrMore> <element name="join-handling"> <ref name="join-handling-type"/> </element> <element name="user-admission-policy"> <ref name="user-admission-policy-type"/> </element> <element name="user-must-be-specified"> <data type="boolean"/> </element> <element name="allowed-users-list"> <ref name="UserList"/> </element> <element name="privileges-control-list"> <ref name="privileges-control-list-type"/> </element> <element name="user"> <ref name="user-type"/> </element> </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> Novo, et al. Expires April 13, 2007 [Page 36]
Internet-Draft Common Conference Schema October 2006 </choice> </define> <!-- USERLIST --> <define name="UserList"> <ref name="role-type"/> <zeroOrMore> <element name="target"> <ref name="Target"/> </element> </zeroOrMore> </define> <!-- TARGET --> <define name="Target"> <ref name="role-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> <!-- PRIVILEGES CONTROL LIST TYPE --> <define name="privileges-control-list-type"> <ref name="role-type"/> <oneOrMore> <element name="conference-rules"> <ref name="conference-rules-type"/> </element> </oneOrMore> </define> Novo, et al. Expires April 13, 2007 [Page 37]
Internet-Draft Common Conference Schema October 2006 <!-- CONFERENCE RULES TYPE --> <define name="conference-rules-type"> <ref name="role-type"/> <attribute name="id"> <text/> </attribute> <zeroOrMore> <element name="entry"> <ref name="conference-rule-type"/> </element> </zeroOrMore> </define> <!-- CONFERENCE RULE TYPE --> <define name="conference-rule-type"> <ref name="role-type"/> <zeroOrMore> <element name="condition"> <ref name="condition-type"/> </element> <element name="action"> <ref name="action-type"/> </element> </zeroOrMore> </define> <!-- CONDITION TYPE --> <define name="condition-type"> <ref name="role-type"/> <element name="identity"> <ref name="identity-type"/> </element> <element name="validity"> <ref name="validityType"/> </element> </define> <!-- IDENTITY TYPE --> <define name="identity-type"> <ref name="role-type"/> <element name="identity"> <ref name="identityType"/> </element> Novo, et al. Expires April 13, 2007 [Page 38]
Internet-Draft Common Conference Schema October 2006 <element name="validity"> <ref name="validityType"/> </element> </define> <!-- ROLES IDENTITY TYPE --> <define name="identityType"> <choice> <element name="one"> <ref name="oneType"/> </element> <element name="many"> <ref name="manyType"/> </element> <element name="pseudonymous"> <text/> </element> <element name="has-been-referred"> <text/> </element> <element name="has-been-invited"> <text/> </element> <element name="has-been-in-conference"> <text/> </element> <element name="is-in-conference"> <text/> </element> <element name="administrator"> <text/> </element> <element name="is-on-allowed-users-list-dial-out"> <text/> </element> <element name="is-on-allowed-users-list-refer"> <text/> </element> <element name="participant-passcode"> <text/> </element> <element name="administrator-passcode"> <text/> </element> </choice> </define> Novo, et al. Expires April 13, 2007 [Page 39]
Internet-Draft Common Conference Schema October 2006 <!-- ACTION TYPE --> <define name="action-type"> <choice> <element name="allow-refer-users-dynamically"> <data type="boolean"/> </element> <element name="allow-invite-users-dynamically"> <data type="boolean"/> </element> <element name="allow-remove-users-dynamically"> <data type="boolean"/> </element> <element name="show-floor-holder"> <ref name="floor-request-type"/> </element> <element name="show-floor-request"> <data type="boolean"/> </element> <element name="provide-anonymity"> <data type="boolean"/> </element> <element name="read-only"> <ref name="single-role-type"/> </element> <element name="read-write"> <ref name="single-role-type"/> </element> </choice> </define> <!-- USER TYPE --> <define name="user-type"> <ref name="role-type"/> <attribute name="state"> <ref name="state-type"/> </attribute> <zeroOrMore> <element name="user"> <ref name="one-user-type"/> </element> </zeroOrMore> </define> <!-- ONE USER TYPE Novo, et al. Expires April 13, 2007 [Page 40]
Internet-Draft Common Conference Schema October 2006 --> <define name="one-user-type"> <ref name="role-type"/> <attribute name="entity"> <data type="anyURI"/> </attribute> <attribute name="state"> <ref name="state-type"/> </attribute> <zeroOrMore> <element name="display-text"> <text/> </element> <element name="associated-aors"> <ref name="uris-type"/> </element> <element name="provide-anonymity"> <data type="boolean"/> </element> <element name="roles"> <ref name="single-role-type"/> </element> <element name="languages"> <list> <data type="language"/> </list> </element> <element name="cascaded-focus"> <data type="anyURI"/> </element> <element name="sphere"> <ref name="sphereType"/> </element> <element name="allow-refer-users-dynamically"> <data type="boolean"/> </element> <element name="allow-invite-users-dynamically"> <data type="boolean"/> </element> <element name="allow-remove-users-dynamically"> <data type="boolean"/> </element> <element name="endpoint"> <ref name="endpoint-type"/> </element> </zeroOrMore> </define> Novo, et al. Expires April 13, 2007 [Page 41]
Internet-Draft Common Conference Schema October 2006 <!-- ENDPOINT TYPE --> <define name="endpoint-type"> <ref name="role-type"/> <attribute name="entity"> <text/> </attribute> <zeroOrMore> <element name="display-text"> <text/> </element> <element name="referred"> <ref name="execution-type"/> </element> <element name="status"> <ref name="endpoint-status-type"/> </element> <element name="joining-method"> <ref name="joining-type"/> </element> <element name="joining-info"> <ref name="execution-type"/> </element> <element name="disconnection-method"> <ref name="disconnection-type"/> </element> <element name="disconnection-info"> <ref name="execution-type"/> </element> <element name="media"> <ref name="media-type"/> </element> <element name="call-info"> <ref name="call-type"/> </element> </zeroOrMore> </define> <!-- MEDIA TYPE --> <define name="media-type"> <attribute name="id"> <text/> </attribute> <zeroOrMore> <element name="display-text"> Novo, et al. Expires April 13, 2007 [Page 42]
Internet-Draft Common Conference Schema October 2006 <text/> </element> <element name="type"> <text/> </element> <element name="label"> <text/> </element> <element name="src-id"> <text/> </element> <element name="status"> <ref name="media-status-type"/> </element> <element name="to-mixer"> <ref name="mixer-type"/> </element> <element name="from-mixer"> <ref name="mixer-type"/> </element> </zeroOrMore> </define> <!-- MIXER TYPE --> <define name="mixer-type"> <ref name="role-type"/> <optional> <element name="floor"> <data type="boolean"/> </element> <element name="controls"> <ref name="control-type"/> </element> </optional> </define> <!-- SIDEBARS-BY-REF TYPE --> <define name="sidebars-by-ref-type"> <ref name="role-type"/> <zeroOrMore> <element name="entry"> <ref name="uri-type"/> </element> </zeroOrMore> </define> Novo, et al. Expires April 13, 2007 [Page 43]
Internet-Draft Common Conference Schema October 2006 <!-- SIDEBARS-BY-VAL TYPE --> <define name="sidebars-by-val-type"> <ref name="role-type"/> <zeroOrMore> <element name="entry"> <ref name="conference-type"/> </element> </zeroOrMore> </define> <!-- ******************************************************************************** TYPES DEFINED IN THE EVENT PACKAGES FOR CONFERENCE STATE ******************************************************************************** --> <!-- MEDIA STATUS TYPE --> <define name="media-status-type"> <choice> <value type="string">recvonly</value> <value type="string">sendonly</value> <value type="string">sendrecv</value> <value type="string">inactive</value> </choice> </define> <!-- EXECUTION TYPE --> <define name="execution-type"> <zeroOrMore> <element name="when"> <data type="int"/> </element> <element name="reason"> <data type="string"/> </element> <element name="by"> <data type="anyURI"/> </element> </zeroOrMore> </define> Novo, et al. Expires April 13, 2007 [Page 44]
Internet-Draft Common Conference Schema October 2006 <!-- CALL TYPE --> <define name="call-type"> <zeroOrMore> <element name="sip"> <ref name="sip-dialog-id-type"/> </element> </zeroOrMore> </define> <!-- SIP DIALOG ID TYPE --> <define name="sip-dialog-id-type"> <zeroOrMore> <element name="display-text"> <text/> </element> <element name="call-id"> <text/> </element> <element name="from-tag"> <text/> </element> <element name="to-tag"> <text/> </element> </zeroOrMore> </define> <!-- DISCONNECTION TYPE --> <define name="disconnection-type"> <choice> <value type="string">departed</value> <value type="string">booted</value> <value type="string">failed</value> <value type="string">busy</value> </choice> </define> <!-- JOINING TYPE Novo, et al. Expires April 13, 2007 [Page 45]
Internet-Draft Common Conference Schema October 2006 --> <define name="joining-type"> <choice> <value type="string">dialed-in</value> <value type="string">dialed-out</value> <value type="string">focus-owner</value> </choice> </define> <!-- ENDPOINT STATUS TYPE --> <define name="endpoint-status-type"> <choice> <value type="string">pending</value> <value type="string">dialing-out</value> <value type="string">dialing-in</value> <value type="string">alerting</value> <value type="string">on-hold</value> <value type="string">connected</value> <value type="string">muted-via-focus</value> <value type="string">disconnecting</value> <value type="string">disconnected</value> </choice> </define> <!-- STATE TYPE --> <define name="state-type"> <choice> <value type="string">full</value> <value type="string">partial</value> <value type="string">deleted</value> </choice> </define> <!-- *********************************************** TYPE DEFINED IN THE ROLE DOCUMENT *********************************************** --> <!-- ROLE TYPE --> Novo, et al. Expires April 13, 2007 [Page 46]
Internet-Draft Common Conference Schema October 2006 <define name="role-type"> <attribute name="read-only"> <ref name="single-role-type"/> </attribute> <attribute name="write-only"> <ref name="single-role-type"/> </attribute> </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> <!-- ************************************************************ TYPE DEFINED IN THE COMMON POLICY DOCUMENT ************************************************************ --> <!-- VALIDITY TYPE --> <define name="validityType"> <choice> <element name="from"> <data type="int"/> </element> <element name="until"> <data type="int"/> </element> </choice> </define> <!-- ONE TYPE Novo, et al. Expires April 13, 2007 [Page 47]
Internet-Draft Common Conference Schema October 2006 --> <define name="oneType"> <attribute name="id"> <data type="anyURI"/> </attribute> </define> <!-- MANY TYPE --> <define name="manyType"> <choice> <element name="except"> <ref name="exceptType"/> </element> </choice> <attribute name="domain"> <text/> </attribute> </define> <define name="exceptType"> <attribute name="domain"> <text/> </attribute> <attribute name="id"> <data type="anyURI"/> </attribute> </define> <!-- SPHERE TYPE --> <define name="sphereType"> <attribute name="value"> <text/> </attribute> </define> </grammar> 5. XML Schema Extensibility The Common Conference Information Data Model defined in this document is meant to be extensible toward specific application domains. Such Novo, et al. Expires April 13, 2007 [Page 48]
Internet-Draft Common Conference Schema October 2006 an extension is accomplished by defining elements, child elements and attributes that are specific to the desired application domain. Each extension MUST define its own namespace. Points of extension MUST be defined in the schema, and SHOULD be done using the <anyName>/ <except> construct. Elements or attributes from unknown namespaces MUST be ignored. 6. XML example The following is an example of a common conference information document. The conference starts on October 17, 2006, 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:common-conference-schema" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:sesspol="urn:ietf:params:xml:ns:sessionpolicy" xmlns:compol="urn:ietf:params:xml:ns:common-policy" entity="sips:conference@example.com"> <!-- CONFERENCE DESCRIPTION --> <info:conference-description xml:lang="en-us"> <info:display-text>Discussion of Formula-1 racing< /info:display-text> <info:subject> Sports:Formula-1</info:subject> <info:free-text>This is a conference example</info:free-text> <info:keywords>Formula-1, cars</info:keywords> <web-page>http://www.example.com/users/alice/formula-1< /web-page> <security-level>low</security-level> <allow-sidebars>true</allow-sidebars> <conference-stage>running</conference-stage> <!-- CONFERENCE TIME --> <conference-time> <entry> <base>BEGIN:VCALENDAR Novo, et al. Expires April 13, 2007 [Page 49]
Internet-Draft Common Conference Schema October 2006 PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:20051103T140728Z UID:carol at example.com ORGANIZER:MAILTO:carol at example.com DTSTART:20061017T143000Z RRULE:FREQ=WEEKLY DTEND:20061017T163000Z</base> <mixing-start-offset required-participant="moderator"> 20061017T142900Z</mixing-start-offset> <mixing-end-offset required-participant="participant"> 20061017T163100Z</mixing-end-offset> <must-join-before-offset> 20061017T15300Z</must-join-before-offset> </entry> </conference-time> <!-- CONFERENCE UNIQUE IDENTIFIERS --> <info:conf-uris> <info:SIP> <info:uri>tel:+3585671234</info:uri> <info:display-text>Conference Bridge</info:display-text> <info:purpose>participation</info:purpose> </info:SIP> <info:SIP> <info:uri>http://www.example.com/54634/live.ram</info:uri> <info:purpose>streaming</info:purpose> </info:SIP> </info:conf-uris> <!-- SERVICE URIS --> <info:service-uris> <info:SIP> <info:uri>http://www.example.com/formula1/</info:uri> <info:purpose>web-page</info:purpose> </info:SIP> </info:service-uris> <!-- MAXIMUM USER COUNT --> <maximum-user-count> <entry role = "administrator">2</entry> <entry role = "moderator">5</entry> <entry role = "participant">150</entry> Novo, et al. Expires April 13, 2007 [Page 50]
Internet-Draft Common Conference Schema October 2006 </maximum-user-count> <!-- AVAILABLE MEDIA --> <info:available-media> <info:entry label="10234"> <info:display-text>main audio</info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status> <mixing-mode>automatic</mixing-mode> <mix-level>3</mix-level> <codecs decision="automatic"> <codec name="PCMU" policy="allowed"/> </codecs> </info:entry> <info:entry label="10235"> <info:display-text>main video</info:display-text> <info:type>video</info:type> <mixing-mode>automatic</mixing-mode> <mix-level>4</mix-level> <info:status>sendrecv</info:status> <sesspol:codecs decision="automatic"> <sesspol:codec name="H.263" policy="allowed"/> </sesspol:codecs> </info:entry> </info:available-media> </info:conference-description> <!-- HOST INFO --> <info:host-info> <info:display-text>Formula1</info:display-text> <info:web-page>http://www.example.com/formula-1/< /info:web-page> <info:uris> <info:SIP> <info:uri>sip:alice@example.com</info:uri> </info:SIP> <info:SIP> <info:uri>sip:carol@example.com</info:uri> </info:SIP> </info:uris> </info:host-info> <!-- CONFERENCE STATE --> <info:conference-state> <allow-conference-state>true< Novo, et al. Expires April 13, 2007 [Page 51]
Internet-Draft Common Conference Schema October 2006 /allow-conference-state> <info:user-count>3</info:user-count> <info:active>true</info:active> <info:locked>false</info:locked> </info:conference-state> <!-- FLOOR INFORMATION --> <floor-information> <allow-floor-events>true</allow-floor-events> <floor-request-handling>1 </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> <moderator-uri>sip:alice@example.com< /moderator-uri> </floor> <floor moderator-controlled="true" label="10235"> <media-types>video</media-types> <algorithm>Moderator-controlled</algorithm> <max-floor-users>1</max-floor-users> <moderator-uri>sip:carol@example.com< /moderator-uri> </floor> </conference-floor-policy> </floor-information> <!-- USERS --> <users> <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> <!-- PRIVILEGES CONTROL LIST --> <privileges-control-list> <conference-rules> <entry id="1"> Novo, et al. Expires April 13, 2007 [Page 52]
Internet-Draft Common Conference Schema October 2006 <conditions> <compol:identity> <compol:domain>example.com</compol:domain> </compol:identity> <compol:validity> <compol:from>20061017T143000Z</compol:from> <compol:to>20061017T163000Z</compol:to> </compol:validity> </conditions> <compol:actions> <compol:allow-conference-state>true< /compol:allow-conference-state> </compol:actions> </entry> <entry id="2"> <conditions> <compol:identity> <compol:uri>bob@example.com</compol:uri> </compol:identity> </conditions> <compol:actions> <join-handling>block</join-handling> </compol:actions> </entry> </conference-rules> </privileges-control-list> <!-- USER --> <info:user entity="sip:bob@example.com"> <info:display-text>Bob Hoskins</display-text> <info:associated-aors> <info:entry> <info:uri>mailto:bob@example.com</info:uri> <info:display-text>email</info:display-text> </info:entry> </info:associated-aors> <provide-anonymity>false</provide-anonymity> <info:roles> <info:entry>participant</info:entry> </info:roles> <info:languages>en</info: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< Novo, et al. Expires April 13, 2007 [Page 53]
Internet-Draft Common Conference Schema October 2006 /allow-remove-users-dynamically> <!-- ENDPOINTS --> <info:endpoint entity="sip:bob@example.com"> <info:display-text>Bob's Laptop</info:display-text> <info:referred> <info:when>20061017T140000Z</info:when> <info:reason>expert required</info:reason> <info:by>sip:alice@example.com</info:by> </info:referred> <info:status>connected</info:status> <info:joining-method>dialed-out</info:joining-method> <info:joining-info> <info:when>20061017T140000Z</info:when> <info:reason>invitation</info:reason> <info:by>sip:alice@example.com</info:by> </info:joining-info> <!-- MEDIA --> <info:media id="1"> <info:label>10235</info:label> <info:src-id>432424</info:src-id> </info:media> <!-- CALL INFO --> <info:call-info> <info:sip> <info:display-text>full info</info:display-text> <info:call-id>hsjh8980vhsb78</info:call-id> <info:from-tag>vav738dvbs</info:from-tag> <info:to-tag>8954jgjg8432</info:to-tag> </info:sip> </info:call-info> </info:endpoint> </info:user> <!-- USER --> <info:user entity="sip:alice@example.com"> <info:display-text>Alice Kay</info:display-text> <info:associated-aors> <info:entry> <info:uri>mailto:alice@example.com</info:uri> <info:display-text>email</info:display-text> </info:entry> Novo, et al. Expires April 13, 2007 [Page 54]
Internet-Draft Common Conference Schema October 2006 </info:associated-aors> <provide-anonymity>false</provide-anonymity> <info:roles> <info:entry>moderator</info:entry> </info:roles> <info:languages>en</info: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 --> <info:endpoint entity="sip:alice@example.com"> <info:display-text>Alice's Desktop</info:display-text> <info:status>connected</info:status> <info:joining-method>dialed-in</info:joining-method> <info:joining-info> <info:when>20061017T133508Z</info:when> <info:reason>invitation</info:reason> <info:by>sip:conference@example.com</info:by> </info:joining-info> <!-- MEDIA --> <info:media id="1"> <info:label>10235</info:label> <info:src-id>432424</info:src-id> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>10234</info:label> <info:src-id>532535</info:src-id> <info:status>sendrecv</info:status> </info:media> <!-- CALL INFO --> <info:call-info> <info:sip> <info:display-text>full info</info:display-text> <info:call-id>truy45469123478</info:call-id> <info:from-tag>asd456cbgt</info:from-tag> <info:to-tag>3456jgjg1234</info:to-tag> </info:sip> Novo, et al. Expires April 13, 2007 [Page 55]
Internet-Draft Common Conference Schema October 2006 </info:call-info> </info:endpoint> </info:user> <!-- USER --> <info:user entity="sip:carol@example.com"> <info:display-text>Carol More</info:display-text> <info:associated-aors> <info:entry> <info:uri>mailto:carol@example.com</info:uri> <info:display-text>email</info:display-text> </info:entry> </info:associated-aors> <provide-anonymity>false</provide-anonymity> <info:roles> </info:entry>administrator</info:entry> </info:roles> <info:languages>en</info: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 --> <info:endpoint entity="sip:carol@example.com"> <info:display-text>Carol's Computer</info:display-text> <info:status>connected</info:status> <info:joining-method>dialed-in</info:joining-method> <info:joining-info> <info:when>20061017T133005Z</info:when> <info:reason>invitation</info:reason> <info:by>sip:conference@example.com</info:by> </info:joining-info> <!-- MEDIA --> <info:media id="1"> <info:label>10235</info:label> <info:src-id>432424</info:src-id> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>10234</info:label> Novo, et al. Expires April 13, 2007 [Page 56]
Internet-Draft Common Conference Schema October 2006 <info:src-id>532535</info:src-id> <info:status>sendrecv</info:status> </info:media> <!-- CALL INFO --> <info:call-info> <info:sip> <info:display-text>full info</info:display-text> <info:call-id>wevb12562321894</info:call-id> <info:from-tag>asw456wedf</info:from-tag> <info:to-tag>2365dfrt3497</info:to-tag> </info:sip> </info:call-info> </info:endpoint> </info:user> </users> <!-- SIDEBARS BY REFERENCE --> <info:sidebars-by-ref> <info:entry> <info:uri>sips:conference@example.com;grid=40</info:uri> <info:display-text>private with Bob</info:display-text> </info:entry> </info:sidebars-by-ref> <!-- SIDEBARS BY VALUE --> <info:sidebars-by-val> <info:entry entity="sips:conference@example.com;grid=40"> <info:users> <info:user entity="sip:bob@example.com"/> <info:user entity="sip:carol@example.com"/> </info:users> </info:entry> </info:sidebars-by-val> </info:conference-info> Note that due to RFC formatting conventions, this documents splits lines whose content would exceed 72 characters. Two backslash characters mark where the lines folding has taken place. These backslash would not appear in the actual XML data model. Novo, et al. Expires April 13, 2007 [Page 57]
Internet-Draft Common Conference Schema October 2006 7. 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. 8. IANA Considerations 9. 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. I would like to thanks Orit Levin, Adam Roach, Mary Barnes, Chris Boulton, Umesh Chandra, Orit Levin, Jari Urpilainen, and Srivatsa Srinivasan for their comments. Also, I would like to thanks Hisham Khartabil, Petri Koskelainen, and Aki Niemi to let us use the policy information of their cpcp drafts in this document. 10. References 10.1. Normative References [1] Barnes, M., "A Framework and Data Model for Centralized Conferencing", draft-ietf-xcon-framework-05 (work in progress), September 2006. [2] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [5] Paoli, J., Maler, E., Sperberg-McQueen, C., and T. Bray, "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>. Novo, et al. Expires April 13, 2007 [Page 58]
Internet-Draft Common Conference Schema October 2006 [6] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. 10.2. Informative References [7] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", draft-ietf-xcon-bfcp-06 (work in progress), December 2005. [8] Schulzrinne, H., "Common Policy: A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-11 (work in progress), August 2006. [9] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-mmusic-sdp-bfcp-03 (work in progress), December 2005. 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 V8C Boston, MA 02109-3614 USA Email: Dave.Morgan@fmr.com Novo, et al. Expires April 13, 2007 [Page 59]
Internet-Draft Common Conference Schema October 2006 Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel Email: roni.even@polycom.co.il Novo, et al. Expires April 13, 2007 [Page 60]
Internet-Draft Common Conference Schema October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 April 13, 2007 [Page 61]