view Side-By-Side changes
XCON O. Novo Internet-Draft G. Camarillo Intended status: Informational Ericsson Expires:January 11,April 13, 2007EricssonD. Morgan Fidelity Investments R. Even PolycomJulyOctober 10, 2006 A Common Conference Information Data Model for Centralized Conferencing (XCON)draft-ietf-xcon-common-data-model-02.txtdraft-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 onJanuary 11,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. ExpiresJanuary 11,April 13, 2007 [Page 1] Internet-Draft Common Conference SchemaJulyOctober 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.<conference-description> . . . . . . . . . . . . . . . . . 11 3.2.1. <conference-time> . . . .Common Conference Policies . . . . . . . . . . . . . .12 3.2.2. <conf-uris>. . 9 3.3. <conference-description> . . . . . . . . . . . . . . . . . 10 3.3.1. <conference-time> . .13 3.2.3. <service-uris>. . . . . . . . . . . . . . . . 11 3.3.2. <conf-uris> . . . .13 3.2.4. <maximum-user-count>. . . . . . . . . . . . . . . . . 133.2.5. <maximum-streams> . . . . . . . . . . . . . . . . . . 14 3.2.6. <available-media> . . . . . . . . . . . . . . . . . . 14 3.2.7. <controls> . . . . . . . .3.3.3. <service-uris> . . . . . . . . . . . . . .14 3.2.7.1. mute. . . . . . 13 3.3.4. <maximum-user-count> . . . . . . . . . . . . . . . . .15 3.2.7.2. pause-video13 3.3.5. <maximum-streams> . . . . . . . . . . . . . . . . . . 13 3.3.6. <available-media> .15 3.3. <host-info>. . . . . . . . . . . . . . . . . 13 3.3.7. <controls> . . . . . .16 3.4. <conference-state>. . . . . . . . . . . . . . . . 14 3.3.7.1. mute . . . .16 3.5. <security-mechanism>. . . . . . . . . . . . . . . . . . .16 3.5.1. <methods>14 3.3.7.2. pause-video . . . . . . . . . . . . . . . . . . . 14 3.3.7.3. gain . . .17 3.5.2. <option-tags>. . . . . . . . . . . . . . . . . . . .17 3.5.3. <feature-tags>15 3.4. <host-info> . . . . . . . . . . . . . . . . . . . .17 3.5.4. <bodies>. . . 15 3.5. <conference-state> . . . . . . . . . . . . . . . . . . . .1715 3.6. <floor-information> . . . . . . . . . . . . . . . . . . .1815 3.7. <users> . . . . . . . . . . . . . . . . . . . . . . . . .1916 3.7.1. <allowed-users-list> . . . . . . . . . . . . . . . . .2017 3.7.2. <privileges-control-list> . . . . . . . . . . . . . .2018 3.7.2.1.<data-access-rights> . . . . . . . . . . . . . . . 20 3.7.2.2.<conference-rules> . . . . . . . . . . . . . . . .21 3.7.2.2.1.18 3.7.2.1.1. <condition> . . . . . . . . . . . . . . . . .21 3.7.2.2.1.1. <external-list> . . . . .18 3.7.2.1.2. <pseudonymous> . . . . . . . .22 3.7.2.2.1.2. <pseudonymous>. . . . . . . . 19 3.7.2.1.3. <has-been-referred> . . . . . .22 3.7.2.2.1.3. <has-been-referred>. . . . . . . 19 3.7.2.1.4. <has-been-invited> . . . .22 3.7.2.2.1.4. <has-been-invited>. . . . . . . . . . 19 3.7.2.1.5. <has-been-in-conference> . .22 3.7.2.2.1.5. <has-been-in-conference>. . . . . . . . .22 3.7.2.2.1.6.19 3.7.2.1.6. <is-in-conference> . . . . . . . . . . . .22 3.7.2.2.1.7. <administrator>. . 19 3.7.2.1.7. <administrator> . . . . . . . . . . .23 3.7.2.2.1.8. <is-on-allowed-users-list-dial-out>. . .23 3.7.2.2.1.9. <is-on-allowed-users-list-refer>. 19 3.7.2.1.8. <is-on-allowed-users-list-dial-out> . . . .23 3.7.2.2.1.10. <participant-passcode>. 20 3.7.2.1.9. <is-on-allowed-users-list-refer> . . . . . . . 20 3.7.2.1.10. <participant-passcode> . .23 Novo, et al. Expires January 11, 2007 [Page 2] Internet-Draft Common Conference Schema July 2006 3.7.2.2.1.11. <administrators-passcode>. . . . . . . .24 3.7.2.2.2. <actions>. . 20 3.7.2.1.11. <administrators-passcode> . . . . . . . . . . 20 3.7.2.2. <actions> . . . . . .24 3.7.3. <user>. . . . . . . . . . . . . . 21 3.8. <user> . . . . . . . . . .25 3.7.3.1. from_mixer, to_mixer. . . . . . . . . . . . . . .26 3.7.3.1.1. <floor>. 22 3.8.1. from-mixer, to-mixer . . . . . . . . . . . . . . . . . 23 3.8.1.1. <floor> .27 3.7.3.1.2. <gain>. . . . . . . . . . . . . . . . . . . .27 3.8.23 Novo, et al. Expires April 13, 2007 [Page 2] Internet-Draft Common Conference Schema October 2006 3.9. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . .28 3.9.24 3.10. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . .2824 4.XML Schema . . .RELAX NG schema . . . . . . . . . . . . . . . . . . . . . . .2824 5. XML Schema Extensibility . . . . . . . . . . . . . . . . . . .4248 6. XML example . . . . . . . . . . . . . . . . . . . . . . . . .4349 7. Security Considerations . . . . . . . . . . . . . . . . . . .5358 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .5358 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .5358 10. References . . . . . . . . . . . . . . . . . . . . . . . . . .5358 10.1. Normative References . . . . . . . . . . . . . . . . . . .5358 10.2. Informative References . . . . . . . . . . . . . . . . . .5459 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .5559 Intellectual Property and Copyright Statements . . . . . . . . . .5661 Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page 3] Internet-Draft Common Conference SchemaJulyOctober 2006 1. Introduction This document defines an Extensible Markup Language (XML) Schema that represents thecommonconferenceinformationobject in a conferencing server. The information is modeled as a series of elements, each of which contains children and attributes. Thecommon conference information is a part of the Conference Object. TheConference Object contains the XML schema, which is used to represent the core information that is utilized in any conference(capabilities,membership,(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.[Editors Note: This document is still in early stages of development and is intended to trigger discussions.]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 usingNovo, et al. Expires January 11, 2007 [Page 4] Internet-Draft Common Conference Schema July 2006UTF-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>,<security-mechanism>, <Floor Information>,<floor-information>, <users>, <sidebars-by-ref>, <sidebars-by-val>, child elements. A common conference document must at least include the<conference-description>,<conference- description>, <host-info>, <conference-state>,<available-media>,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-stage> | |--<conference-time> | | |--<entry> | | | |--<base> | | | |--<mixing-start-offset> | | | |--<mixing-end-offset> | | | |--<can-join-after-offset> | | | |--<must-join-before-offset> | | | |--<request-user>Novo, et al. Expires January 11, 2007 [Page 5] Internet-Draft Common Conference Schema July 2006| | | |--<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>*|--<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>|--<mix-level> | | | |--<codecs> | | | | |--<entry> | | | | |--<entry> | | | | ... | | | |--<controls> | | | ||--<control>|--<mute> | | | | |--<gain> ||--<display-text>| | | ... Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page 6] Internet-Draft Common Conference SchemaJulyOctober 2006 | | |--<entry> | | ||--<value> | | | | |--<control> | ||--<type> | | | |--<display-text> | | | |--<status> | ||--<value>| |--<mixing-mode> | | |...|--<mix-level> | | | |--<codecs> | | | | |--<entry> | | | | |--<entry> | | | | ... | ||--<entry>| |--<controls> | ||--<type>| | |--<pause-video> ||--<display-text>| | ||--<status>... | | ... ||--<mixing-mode>|--!<host-info> | |--<display-text> | |--<web-page> ||--<mix level>|--!<uris> | | |--!<SIP> ||--<controls>| | |--!<uri> | ||--<control>| |--<display-text> | | | |--<purpose> ||--<display-text>| |--<H323> | | | |--<H.323-alias> | ||--<value>| |--<H.323-URI> | | |--<PSTN/ISDN> ||--<control>| | |--<phone number> | ... |--!<conference-state> | |--<allow-conference-state> ||--<display-text>|--<user-count> | |--!<active> | |--<locked> | |--<floor-information> | |--<allow-floor-events> ||--<value>|--<floor-request-handling> | |--<conference-floor-policy> | | |--<floor> |...| | |--<media-types> ||--<codecs>| | |--<algorithm> | ||--<entry>| |--<max-floor-users> | | ||--<entry>|--<moderator-uri> | | | |--<moderator-uri> |...| | ... ||--!<host-info>||--<display-text>... ||--<web-page>Novo, et al. Expires April 13, 2007 [Page 7] Internet-Draft Common Conference Schema October 2006 |--!<users> ||--!<uris>|--<join-handling> | |--<user-admission-policy> ||--!<SIP>|--<allowed-users-list> | | |--<target> ||--!<uri>| |-- ... | ||--<display-text>| |--<privileges-control-list> | ||--<purpose>|--<conference-rules> | ||--<H323>| |--<entry> | ||--<H.323-alias>| | |--<condition> ||--<H.323-URI>| ||--<PSTN/ISDN>| | |--<identity> ||--<phone number>|... |--!<conference-state>||--<allow-conference-state>||--<user-count>||--!<active>||--<locked> Novo, et al. Expires January 11, 2007 [Page 7] Internet-Draft Common Conference Schema July 2006||--<security-mechanism>||--<entry-protocol=SIP>| ||--<methods>| | ||--<method>... | | |...| ||--<option-tags>| | ||--<option-tag>| | |...|--<validity> | ||--<feature-tags>| | ||--<feature-tag>| |--<from> | |...| ||--<bodies>| | |--<until> ||--<body-disposition>| | | ||--<body-format>| | |...||--<entry-protocol=H.323>*|--<actions> | ||--<version>*||--<entry-protocol=H.320>*| ||--<supported>*|...||--<floor-information>||--<allow-floor-events>||--<floor-request-handling>||--<conference-floor-policy>| ... ||--<floor>| | ... ||--<media-types>| | |--!<user> ||--<algorithm>| |--<display-text> | ||--<max-floor-users>|--<associated-aors> | | |--<provide-anonymity> ||--<moderator-uri>| |--<roles> | ||--<moderator-uri>| | |...| | ... ||--!<users>||--<join-handling>|--<languages> ||--<user-admission-policy>||--<allowed-users-list>|--<cascaded-focus> | ||--<target>|--<sphere> | ||-- ...|--<allow-refer-users-dynamically> | | |--<allow-invite-users-dynamically> ||--<privileges-control-list>| |--<allow-remove-users-dynamically> ||--<data-access-rights>| |--!<endpoint> | ||--<entry name=sidebars-by-ref>| |--<display-text> | ||--<entry name=sidebars-by-val>| |--<referred> | ||--<entry name=conference-time>|| | |--<entry name=mixing-start-offset> Novo, et al. Expires January 11, 2007 [Page 8] Internet-Draft Common Conference Schema July 2006 | | | ... | | | | | |--<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> | | |--<floors> | | | |--<entry> | | | | |--<show-floor-holder> | | | | |--<show-floor-requests> | | | ... | | |--<endpoint> | | | |--<display-text> | | | |--<referred> | | | |--<status>|--<status> | | | |--<joining-method> | | | |--<joining-info> | | | |--<disconnection-method> | | | |--<disconnection-info> | | ||--<media>|--!<media> | | | | |--<type> | | | | |--<display-text>| | | | |--<label>Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page9]8] Internet-Draft Common Conference SchemaJulyOctober 2006 | | | ||--<src-id> | | | | |--<status> | | | | |--<to_mixer> | | | | | |--<floor> | | | | | |--<controls> | | | | | | |--<control>|--<label> | | | | |--<src-id> | | ||--<display-text>| |--<status> | | | | |--<to-mixer> | ||--<value>| | | |--<floor> | | ||--<control>| | |--<controls> | | | | ||--<display-text>| |--<mute> | | | | | ||--<value>|--<gain> | | | | | | ... | | | ||--<from_mixer>|--<from-mixer> | | | | | |--<floor> | | | | | |--<controls> | | | | | ||--<control> | ||--<pause-video> | | | | ||--<display-text>| ... | | | | ... | ||--<value>| |--<call-info> | | | | |--<sip> ||--<control>| | | | |--<display-text> | | ||--<display-text>| | |--<call-id> | | | | ||--<value>|--<from-tag> | | | | | |--<to-tag> | ... ... |--<sidebars-by-ref> | |--<entry> | | |-- <user> |...| |-- <display-text> | |--<entry> ||--<call-info>| |-- <user> | | |-- <display-text> ||--<sip>... |--<sidebars-by-val> | |--<entry> | | | ||--<display-text>| ... || | | |--<call-id> | | | | | |--<from-tag> | | | | | |--<to-tag> | ... ... |--<sidebars-by-ref> | |--<entry> | | |-- <user> | | |-- <display-text> | |--<entry> | | |-- <user> | | |-- <display-text> | ... |--<sidebars-by-val> | |--<entry> | | | | | ... | |--<entry>|--<entry> | | | | ... ...The followingFollowing 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. ExpiresJanuary 11,April 13, 2007 [Page10]9] Internet-Draft Common Conference SchemaJulyOctober 2006XML schema is provided in Section 4. 3.2. <conference-description>The<conference-description> elementset of rights describes the read/write access privileges for the conferencein its entirely. Itobject data model as a whole. Every element of the data model SHOULDhave an extrahas defined two attributes: the attribute'xml:lang' to specify'read-only', and thelanguage used inattribute 'read-write'. These attributes describes thecontents of this elementread/ write access privileges for accessing the Conference Object asdefined Section 2.12 of [5].a whole. It iscomprised 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 definedpartially described in[2]. The child element <web-page> is an optional element that points to[1]. When the conferencing server receives aURI with additional information aboutrequest for access privacy-sensitive data it needs to match it against theconference. The child elements <security-level>'read-only' and<allow-sidebars> describethecapabilities'read-write' attributes. Each attribute ofthe conference. The <conference-stage>each individual element is evaluated and as amandatory elementresult it is determined if the user can access thatgiveelement. The attributes specify thestage ofminimum subscriber's role that can access or modify theconference. Thiselementcan have 4 values: reserved, started, running, and ended. Atof thereserved stageconference. Subscribers with a lower role cannot access or modify theconference exists onlyelement. If an attribute is not defined in some element, theconference control server. There is no running focus'read-only' attribute MUST be interpreted as a "participant" andthere are no subscribers or notifications. The information is accessible only via the conference control protocol. At the started stage, there are no users yet intheconference, still it'read-write' attribute MUST be interpreted as an "administrator" by default. It is possible tosubscribe todefined only one of theconference state. The running stage starts whenattributes of thefirst user joinselement, theconference. Inother attribute SHOULD be interpreted by default. This draft does not define theended stage, there are no users connected toset of possible conferencing roles. However, it can also be theconference,case that conflicts can occur given a hierarchy of elements. In that case, theconference information is only inlower-level element privileges predominate over theconference server for recurring conference or for CDR. At this stageupper-level privileges element. This document defines auser can get information only from the conference control protocol. For instance, The Session Initiation Protocol (SIP) Event Package for Conference State [2] is only applicablemore specific right mechanism in Section 3.7.2, beyond thestart'read-only' andrunning stage.'read-write' attributes. The<conference-time> child element has information related to conference timepermissions anddurationlimits are specified as an integral part of theconference. Otherdata model, with elementsfrom different namespaces MAY be present forcontaining thepurposesallowed ranges for other elements (e.g., maximum number ofextensibility. The <conf-uris>participants) and<service-uris> are usedlists of clients allowed todescribe the conference-related identifiers.perform certain operations on a conference object. 3.3. <conference-description> The<maximum-user- count> child<conference-description> elementindicatesdescribes thenumber of users that can be invitedconference in its entirely. It SHOULD have an extra attribute 'xml:lang' to specify theconference. The <maximum-streams> child element indicateslanguage used in thenumbercontents ofstreams that can be for every media type. The <available-media> childthis 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 themedia characteristics ofconference 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. ExpiresJanuary 11,April 13, 2007 [Page11]10] Internet-Draft Common Conference SchemaJulyOctober 2006The following sectionselements <security-level> and <allow-sidebars> describe theremaining elements in more detail. Other child elements can be used to extend <conference- description> incapabilities of thefuture. 3.2.1. <conference-time>conference. The<conference-time><conference-stage> is a mandatory elementcontainsthat give theinformation related to conference time and durationstage ofathe conference.The <conference-time>This elementcontains one or more <entry> elements each definingcan have 4 values: reserved, started, running, and ended. At the reserved stage thetime information of a singleconferenceoccurrence. Every <entry> element contains a <mixing-start-offset> child element that specifies whenexists only in the conferencemedia mixing starts beforecontrol server. There is no running focus and there are no subscribers or notifications. The information is accessible only via the conferencestarts, <mixing-end-offset> child element that specifiescontrol protocol. At thetime a conference media mixing stops afterstarted stage, there are no users yet in theconference stops. The <mixing-end-offset> child element expressesconference, still it is possible to subscribe to theoffset as signed integers representing seconds before/after DTEND field.conference state. The<mixing- start-offset> child element expressesrunning stage starts when theoffset as signed integers representing seconds before/after DTSTART field. Iffirst user joins the<mixing- start-offset> element is not present, it indicates thatconference. In theconference media mixing starts immediately. Ifended stage, there are no users connected to the<mixing-end- offset> element is not present, it indicates thatconference, the conferenceoccurrenceinformation isnot bounded. <mixing-start-offset> and <mixing-end- offset> elements both haveonly in themandatory 'require-participant' attribute. This attribute has one of 4 values: 'none', 'administrator', 'moderator', and 'participant'. For mixing start offset,conference server for recurring conference or for CDR. At thisattribute allowsstage aprivilegeduserto define when media mixing starts based oncan get information only from thelatter ofconference control protocol. For instance, The Session Initiation Protocol (SIP) Event Package for Conference State [2] is only applicable in themixingstarttime,andtherunning stage. The <conference-time> child element has information related to conference time and duration of thefirst participant, administrator, or moderator arrives. If the value is set to 'none', mixing starts according toconference. Other elements from different namespaces MAY be present for themixing start time. For mixing end offset, this attribute allows a privileged user to define when media mixing ends based on the earlierpurposes ofthe mixing end offset,extensibility. The <conf-uris> and <service-uris> are used to describe thetimeconference-related identifiers. The <maximum-user- count> child element indicates thelast participant, or moderator leaves. Ifnumber of users that can be invited to thevalueconference. The <maximum-streams> child element indicates the number of streams that can be for every media type. The <available-media> child element issetused to'none', mixing stops accordingdescribe 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 themixing end offset. Iffuture. 3.3.1. <conference-time> The <conference-time> element contains the information related to conferencepolicy was modified so that last privileged user is now a normal conference participant,time and duration of a conference. The <conference-time> element contains one or more <entry> elements each defining the time information of a single conferencerequiresoccurrence. Every <entry> element contains aprivileged user to continue;<mixing-start-offset> child element thatconference MUST terminate. An administrator can indicate the timespecifies whenusers can join aconferenceby populatingmedia mixing starts before the<can-join-after-offset> element. Similarly, an administrator can defineconference starts, <mixing-end-offset> child element that specifies the time a conference media mixing stops afterwhich new users are not allowed to jointhe conferenceanymore. This is done by populating the <must-join-before-offset>stops. The <mixing-end-offset> child elementexpressingexpresses the offset as signed integers representing seconds before/afterDTSTARTDTEND field. The<base><mixing- start-offset> child elementspecifies the iCalendar object ofexpresses the offset as signed integers Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page12]11] Internet-Draft Common Conference SchemaJulyOctober 2006conference. 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 integersrepresenting seconds before/after DTSTART field.The <notify-end-of-conference> element defines in seconds when the system has to send a notification whenIf theend of<mixing- start-offset> element is not present, it indicates that the conferenceis near.media mixing starts immediately. If the<notify-end-of-conference><mixing-end- offset> element is not present, it indicates that thesystem doesconference occurrence is notnotifybounded. <mixing-start-offset> and <mixing-end- offset> elements both have theusersmandatory '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 theendlatter of theconference 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 tomixing start time, and thepossibility to extendtime theconference. It has two values: allowed, denied. 3.2.2. <conf-uris> The <conf-uris> containsfirst participant, administrator, or moderator arrives. If theidentifiersvalue is set tobe used in order'none', mixing starts according toaccesstheconference by different signaling means. It containsmixing start time. For mixing end offset, this attribute allows asequenceprivileged user to define when media mixing ends based on the earlier ofchild elements: <SIP>, <H.323>, and <PSTN/ISDN>. The <SIP> element containsthe<uri>, <display-text>, and <purpose>. <uri>, <display-text>,mixing end offset, 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' withthePIN code oftime theconference if used and a 'purpose' attribute that describes tolast participant, or moderator leaves. If theuser which phone numbervalue is set to 'none', mixing stops according touse. <PSTN/ISDN> element may include 1 or more <phone number> child elements andthecall rate as well. 3.2.3. <service-uris> The <service-uris> describes auxiliary services available formixing end offset. If theconference. It containsconference policy was modified so that last privileged user is now asequence of child elements: <SIP>, <H.323>, <PSTN/ISDN>, and <BFCP>. <SIP> child element contains <uri>, <display-text>,normal conference participant, and<purpose>. The purpose will be used to describetheservice. 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 byconference requires afloor control serverprivileged user toprovide a client with acontinue; that conferenceID. 3.2.4. <maximum-user-count> The <maximum-user-count> containsMUST terminate. An administrator can indicate theoverall number oftime when usersallowed tocan jointhe conference. It containsasequence of <entry> child elements. An <entry> element MAY containconference by populating thenumber of<can-join-after-offset> element. Similarly, an administrator can define the time after which new userswith a Novo, et al. Expires January 11, 2007 [Page 13] Internet-Draft Common Conference Schema July 2006 specific roleare not allowed to join the conference[8]. 3.2.5. <maximum-streams>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<maximum-streams> contains<base> child element specifies themaximum numberiCalendar object ofstreams thatthe conference. The iCalendar object components arepermitted to be involveddefined ina conference. It contains a sequence of <entry> child elements. An[6]. The <entry> elementMAY containalso contains thenumber of streams of every specific type of stream, for instance, audio or video. The minimum value permitted<request-user> child element. It is"1" andpossible to define themaximum value permittedtime when users or resources on the allowed-users-list is"128".requested to join the conference by using the <request-users> element. This elementis optional. 3.2.6. <available-media>expresses the offset as signed integers representing seconds before/after DTSTART field. The<available-media><notify-end-of-conference> element defines in seconds when the system has to send a notification when the'label' attribute thatend of the conference is near. If themedia stream identifier assigned by<notify-end-of-conference> element is not present, it indicates that theconferencing server. Thissystem 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<entry>childelements of conference-medium- type. Each <entry>elements: <SIP>, <H.323>, and <PSTN/ISDN>. The <SIP> element contains the<type>,<uri>, <display-text>,<status>, <mixing-mode>, <mix level>, <controls, and <codecs> child elements. The attribute 'label'andthe <type>,<purpose>. <uri>, <display-text>, and<status> elements<purpose> are described in [2]. The<codecs><H.323> elementspecifies the allowed codecs in the conference. It has an attribute 'decision' that specifies if the focus decides the common codec automaticallyincludes either a <H.323-alias> orneeds the approvement ofa <H.323-URI> child elements. The <PSTN/ISDN> has an attribute 'PIN code' with themoderatorPIN code of the conference(automatic, moderator-controlled). The <codecs> element containsif used and a<entry> elements. A <entry> element can have the'purpose' attribute'name'that describes to the user which phone number to use. <PSTN/ISDN> element may include 1 or more <phone number> child elements and'policy'.the call rate as well. 3.3.3. <service-uris> The'name' attribute identifies a codec, and<service-uris> describes auxiliary services available for the'decision' attributeconference. It contains a sequence of child elements: <SIP>, <H.323>, <PSTN/ISDN>, andthe policy attribute<BFCP>. <SIP> child element containsthe policy for that codec (allowed, or disallowed).<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<mixing-mode>, <mix level> describeare described in <conf-uris> section. The <BFCP> has adefault policy by which the mixer will build the outgoing stream from the incoming streams. Notice that this policy is differentsub-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 thepolicy describe foroverall number of users allowed to join thefloors for each media. The <mix level>conference. It contains a sequence of <entry> child elements. An <entry> elementdescribesMAY contain the number ofparticipants in audio media streams orusers with a specific role allowed to join the conference. 3.3.5. <maximum-streams> The <maximum-streams> contains the maximum number ofsub-windows in video mediastreams(for instance,that are permitted to be involved in avalue of 4 in the <mix level> element for video stremas means 2x2 layout). The <mixing-mode>conference. It contains a sequence of <entry> child elements. An <entry> elementMUSTMAY containone and only one ofthe"Moderator-controlled", "FCFS",number of streams of every specific type of stream, for instance, audio or video. The minimum value permitted is "1" and"Automatic" values indicatingthedefault algorithm to be use with everymaximum value permitted is "128". This element is optional. 3.3.6. <available-media> The <available-media> has the 'label' attribute that is the mediastream. Next section explainsstream identifier assigned by the<controls> child element. 3.2.7. <controls> The <controls>conferencing server. This element containsthe basic audio and video global controls foraconferencing. It is expected that for mostsequence ofthe basic conferencing, these controls are sufficient. If the conference server wants to support more advanced control, then it is recommended extension<entry> child elements of conference-medium- type. Each <entry> element contains thedata model to be used. In the<type>, <display-text>, <status>, <mixing-mode>, <mix-level>, <controls>elementand <codecs> child Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page14]13] Internet-Draft Common Conference SchemaJulyOctober 2006 elements. The attribute 'label' and theschema is extensible, hence new control types can be added in a future. Controls that apply at a different level than endpoint/ stream would appear at an appropriate place<type>, <display-text>, and <status> elements are described inthe document. So, moderator controls that affect all media output would go under the <available-media> element. 3.2.7.1. mute[2]. The'mute' control is used<codecs> element specifies the allowed codecs inconjunction with a media stream to cease transmission of associated media.the conference. It hasa 'Boolean' value. When muting,an attribute 'decision' that specifies if thecontrol consists offocus decides thefollowing attributes: 'type', 'name', 'enable'. Andcommon codec automatically or needs thefollowing additional elements: 'label', and 'value'. The descriptionapprovement ofthese elements arethefollowing: type: The 'mute' control has a typemoderator of'Boolean'. name:the conference (automatic, moderator-controlled). Thecontrol is named 'mute'. enable:<codecs> element contains a <entry> elements. A <entry> element can have the attribute 'name' and 'policy'. Theenable'name' attributespecifies if access to the control is available toidentifies a codec, and theclient. The value is of type 'boolean''decision' attribute andis set to 'true' as default. The Control also consists ofthefollowing additional elements: display-text: Provides a Control label that can be rendered topolicy attribute contains theclient. value: Providespolicy for that codec (allowed, or disallowed). The child elements <mixing-mode>, <mix-level> describe a defaultvalue forpolicy by which theControl. Formixer will build theBlue-Print exampleoutgoing stream from thevalueincoming streams. Notice that this policy is'True'. 3.2.7.2. pause-videodifferent that the policy describe for the floors for each media. The'pause-video' control is used<mix-level> child element describes the number of participants inconjunction with aaudio mediastream to cease transmissionstreams or the number ofassociated media. It hassub-windows in video media streams (for instance, a'Boolean' value. The 'pause-video' control consistsvalue of 4 in thefollowing attributes: type:<mix-level> element for video stremas means 2x2 layout). The'pause-video' control has a type<mixing-mode> child element MUST contain one and only one of'Boolean'. name: The control is named 'pause-video'. default: Indicatesthedefault value for"Moderator-controlled", "FCFS", and "Automatic" values indicating the'pause-video' control when not set. The attribute type is 'Boolean' with adefaultvalue of 'false. Setting the 'default' attributealgorithm to'false' specifies that media shouldbetransported for the associateduse with every media stream.When set to the value of 'true', media should not be transported forNext section explains theassociated media stream. Novo,<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. ExpiresJanuary 11,April 13, 2007 [Page15]14] Internet-Draft Common Conference SchemaJulyOctober 2006enable: The enable attribute specifies ifIf this control is not specify, the access to the control is not available to theclient. The value is of type 'boolean'client andis set to 'true' as default. The Control also consists ofmedia SHOULD not be transported for thefollowing additional elements: display-text: Providesassociated media stream. 3.3.7.3. gain The 'gain' control is used in conjunction with aControl label that can be renderedmedia output stream to indicate theclient. value: Providesamount of amplification of an audio stream. It has adefault'Int' number valuefor the Control. Forfrom -127 to 127. If this control is not specify, theBlue-Print exampleaccess to thevaluecontrol is'True'. 3.3.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.4.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.5. <security-mechanism> The <security-mechanism> contains a series of <entry-protocol> sub- elements.3.6. <floor-information> The<entry-protocol><floor-information> element hasa single mandatory attribute, 'name'. The 'name' attribute identifies a protocolthepolicy of each protocol element is referring to. Each <entry- protocol> sub-element contains<allow-floor-events>, <floor- request-handling>, and thepolicy related to<conference-floor-policy> child elements. Other elements from different namespaces MAY be present for theusagepurposes ofa particular protocol. The <entry-protocol>extensibility. This element hasa seriesits own XML namespace. The absence ofchild elements: methods, option-tags, feature-tags,this namespace andbodies are defined for the SIP protocol. Theseits elementsare described infrom an XML document indicates that thefollowing sections. H.323 protocol hasconference does not have asubfloor. The <allow-floor-events> element<version> that says which version of H.323 is supported. H.320 protocol hasrepresents asubboolean 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<supported> that says if H.320issupported or not.undefined, it has a value of FALSE, causing the subscription to floor control events to be rejected. Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page16]15] Internet-Draft Common Conference SchemaJulyOctober 20063.5.1. <methods> The <methods> element contains a default-policy attribute and <method> elements.Thedefault-policy attribute contains the policy for methods that are not listed as <method> elements. A <method><floor-request-handling> elementhas two attributes: name and policy. The name attribute identifies a method, anddefines thepolicy attribute containsactions used by thepolicy for that method (allowed or disallowed). 3.5.2. <option-tags> The <option-tags>conference focus to control floor requests. This elementcontains a default-policy attribute and <option-tag> elements. The default-policy attribute containsdefines thepolicy for option-tagsaction thatare not listed as <option-tag> elements. An <option-tag> element has two attributes: name and policy. The name attribute identifies a method, and the policy attribute containsthepolicy for that method (mandatory, allowed, or disallowed). 3.5.3. <feature-tags> The <feature-tags> element containsfocus is to take when processing adefault-policy attribute and <feature-tag> elements. The default-policy attribute contains the policy for feature-tags that are not listed as <feature-tag> elements. A <feature-tag> element has two attributes: name and policy. The name attribute identifiesparticular request to amethod, andfloor within a conference. This element defines values of: o block: This action instructs thepolicy attribute containsfocus to deny thepolicy for that method (allowed, or disallowed). 3.5.4. <bodies> The <bodies> element contains a default-policy attribute, a default- encryption attribute and <body-disposition> elements.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. Thedefault- policy attribute containsfocus then uses thepolicy for body dispositions that are not listed as <body-disposition> elements.defined floor algorithm to further allow of deny the floor. Thedefault-encryption attribute containsalgorithms used are outside theencryption policy for body dispositionsscope of this document. Note thatare not listed as <body-disposition> elements. A <body-disposition> element can haveplacing anumbervalue ofattributes: name, policy, default-policy, and encryption. The name attribute identifiesblock for this element does not guarantee that abody-disposition, and the policy attribute containsparticipant is blocked from joining thepolicyconference. Any other rule that might evaluate to true for this participant thatbody-disposition (allowed, or disallowed).carried an action whose value was higher than block would automatically grant confirm/allow permission to that participant. Thedefault-policy attribute<conference-floor-policy> element is mandatory and contains thepolicy for body formats that are not listed as <body-format> elements. The encryptionrequired boolean attribute that indicateswhether or not encryptionif the floor isallowed for a particular body disposition. A <body-disposition> element contains <body-format> elements. A body-format elementmoderator controlled or not. One or more <Floor> elements canhave a two attributes: name and policy. The Novo, et al. Expires January 11, 2007 [Page 17] Internet-Draft Common Conference Schema July 2006 name attribute identifies a <body-format>, andappear in thepolicy<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 attributecontainsMUST be equal to thepolicy'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 forthat body-format (allowedone ordisallowed). 3.6. <floor-information> The <floor-information>more media types; the mandatory <Media-types> elementhascan contain zero or more of the<allow-floor-events>, <floor- request-handling>,<Video>, <Audio>, <Application>, <Data> ,<Control>, <Message>, and <text> elements indicating the<conference-floor-policy> child elements.media of the floor. One type of media can only appear once. Otherelements from different namespaces MAYmedia types can bepresent fordefined by extensions. A floor can be controlled using many algorithms; thepurposes of extensibility. Thismandatory <Algorithm> elementhas its own XML namespace. The absenceMUST contain one and only ofthis namespacethe <Moderator- controlled>, <FCFS>, andits<Random> elementsfrom an XML document indicates thatindicating theconference does not have a floor.algorithm. The<allow-floor-events><Max-floor-users> elementrepresents a boolean action. If set to TRUE,in thefocus<Floor> element isinstructed to acceptoptional and, if present, dictates the maximum number of users who can have thesubscription tofloorcontrol events. Ifat one time. The optional <Moderator-URI> indicates the URI of the moderator. It MUST be setto FALSE,if thefocusattribute moderator-controlled isinstructedset toreject the subscription. If this"true". 3.7. <users> The <users> elementis undefined, it has a value of FALSE, causingcontains thesubscription to floor control events to be rejected.<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<floor-request-handling><join-handling> element defines the actions used by the conference focus to controlfloor requests.conference participation. This element defines the action that the focus is to take when processing a particular request toa floor withinjoin a conference. This element defines values of: o block: This action instructs the focus to deny access to thefloor request.conference. This action is the default action taken in the absence of any other actions. o confirm: This action instructs the focus toallowplace 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 therequest. Thefocusthen usesto accept thedefined floor algorithmconference join request and grant access tofurther allow of denythefloor. The algorithms used are outsideconference within thescopeinstructions specified in the transformations of thisdocument.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<conference-floor-policy><user-admission-policy> element ismandatorya list of three elements: 'closedAuthenticated', 'openAuthenticated', andcontains'anonymous'. If therequired boolean attribute that indicates if<user-admission-policy> element is set to 'closedAuthenticated', users must be specified (and authenticate). If thefloorattribute ismoderator controlled or not. One orset to 'openAuthenticated', users can be add after conference activation. The following sections describe the remaining elements in more<Floor>detail. Other child elements canappearbe used to extend <conference- description> in the<conference-floor-policy> element. Every floor is defined using the 'label' attribute.future. 3.7.1. <allowed-users-list> Thenumber<allowed-users-list> child element contains a list ofthose elements indicates how many floorsuser URIs, PSTN phone numbers, roles, or domains (*@example.com) that theconference can have. A floorfocus uses to determine who canbe used for onejoin the conference, who can invite to join a conference, ormore media types;who themandatory <Media-types>focus needs to "refer to" the conference. The <allowed-users-list> elementcan containincludes zero or moreof<target> child element. This child element includes the<Video>, <Audio>, <Application>, <Data> ,<Control>, <Message>,mandatory 'uri' attribute and<text> elements indicatingthemedia of the floor. One type of mediamandatory 'method' attribute. The same 'uri' attribute with different method values canonlyappear in the list more than once.Other media typesThe '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 canbe definedjoin the conference. Value "refer" is used byextensions.the Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page18]17] Internet-Draft Common Conference SchemaJulyOctober 2006A 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 setfocus 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. The <join-handling> element definesdetermine theactions used byresources that theconferencefocus needs tocontrol conference participation. This element defines"refer to" theaction thatconference. In SIP, this is achieved by the focusis to take when processingsending aparticularREFER request tojointhose potential participants. In aconference. This element defines values of: o block: This action instructsdifferent paradigm, this could also mean that the focusto deny accesssends an SMS or an email to theconference.referred user. Thisaction islist can be updated during thedefault action takenconference lifetime so it can be used for mid-conference refers as well. The "refer" value differs from the "dial-out" in that theabsencedial-out contains a list ofany other actions. o confirm: This action instructsresources that the focusto place the participant onwill initiate apending list (e.g., by parking the callsession with. The resources ona music-on-hold server), awaiting moderator input for further actions. o allow: This action instructsthefocus to accept"refer" value, on theconference join request and grant accessother hand, are expected to initiate theconference within the instructions specified in the transformations of this rule. o IVR: This action instructssession establishment towards the focus themselves. It is also envisioned thatthe user has to define the PIN code. o directed-operator: This action instructs the focusdifference users will have different access rights todirectthose lists and therefore a separation between theusertwo is needed. 3.7.2. <privileges-control-list> The <privileges-control-list> refers toan operator. Note that placingavaluevirtual set ofblock for thisrights pertaining to operations. This elementdoes not guarantee that a participant is blocked from joiningcontains theconference. 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.<conference- rules> element. 3.7.2.1. <conference-rules> The<user-admission-policy><conference-rules> element is alistset ofthree elements: 'closedAuthenticated', 'openAuthenticated', and 'anonymous'. If the <user-admission-policy><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 issetrepresent 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'closedAuthenticated', users must be specified (and authenticate). Ifa user, a role, or domain. The <condition> element has theattribute is set<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'openAuthenticated', users can be add after conference activation.a single entity or a group of entities. Thefollowing sections describe<identity> element has theremaining<one> and <many> child elements defined inmoreSection 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. ExpiresJanuary 11,April 13, 2007 [Page19]18] Internet-Draft Common Conference SchemaJulyOctober 2006detail. OtherThe <identity> element has other child elements. These child elementscan be used to extend <conference- description> in the future. 3.7.1. <allowed-users-list>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<allowed-users-list> child<validity> elementcontains a list of user URIs, PSTN phone numbers, roles, or domains (*@example.com) thatexpresses thefocus uses to determine who can joinvalidity period of theconference, who can invite to joinrule with aconference, or who the focus needs to "refer to" the conference.starting and an ending time. The<allowed-users-list><validity> elementincludes zero or more <target> child element. This child element includes the mandatory 'uri' attributeandthe mandatory 'method' attribute. The 'method' attribute is a list with the following values: "dial-in", "dial-out,its child elements ,<from> and"refer".<until>, are defined in section 7.3 of [8]. 3.7.2.1.2. <pseudonymous> Thevalue "dial-in"<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 focusto determine whoand providing a pseudonym in the signalling protocol (for example, using the From-header of a SIP request). The <pseudonymous> element canjoinbe combined with theconference. Value "dial-out" is used by<identity> element to provide the focus with a rule on what todetermine who to invite to join the conference. Value "refer"do when a specific identity isused byauthenticated and that identity is requesting pseudonymity through thefocussignalling protocol. 3.7.2.1.3. <has-been-referred> The <has-been-referred> element can be used todetermine the resourcesmatch those participants that the focusneedshas referred to"refer to"the conference.In SIP, this is achieved by the focus sending a REFER request3.7.2.1.4. <has-been-invited> The <has-been-invited> element can be used to match thosepotential participants. In a different paradigm, this could also meanparticipants that the focussends an SMS or an email tohas invited into thereferred user. This listconference. 3.7.2.1.5. <has-been-in-conference> The <has-been-in-conference> element can beupdated duringused to match those participants that have joined the conferencelifetime so itin the past. 3.7.2.1.6. <is-in-conference> The <is-in-conference> element can be usedfor mid-conference refers as well. The "refer" value differs from the "dial-out" into match those participants that are currently participating in thedial-out contains a list of resources that the focus will initiate a session with.conference. 3.7.2.1.7. <administrator> Theresources 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<administrator> element can be used to match thoselists 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, permissions and limitations pertaining to operations. This element contains the <data-access-rights> and the <conference-rules>. 3.7.2.1. <data-access-rights> The <data-access-rights> element describes the read/write access privileges for accessing the Conference Object as a whole. It is partially described in [1]. The <data-access-rights> contains a listparticipants that are administrators of<entry> elements defined in the Conference Object. Every element has three attributes: the attribute 'name', 'read-only', and the attribute 'read-write'. When the conferencing server receivesarequest for access to privacy-sensitive data it needs to match it against the 'read-only' and the 'read-write' attributes. Eachconference. Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page20]19] Internet-Draft Common Conference SchemaJulyOctober 2006attribute of each individual3.7.2.1.8. <is-on-allowed-users-list-dial-out> The <is-on-allowed-users-list-dial-out> elementis evaluated and as a result it is determined if the usercanaccessbe used to match those participants thatelement. The attributes specifyare on theminimum subscriber's role that can access or modifyallowed-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> elementofcan be used to match those participants that are on theconference. Subscribersallowed-users-list witha lower role cannot access or modifytheelement. If anmethod refer. 3.7.2.1.10. <participant-passcode> The <participant-passcode> elementis not defined in the <data-access-rights> then the 'read-only' attribute MUSTcan beinterpreted as a "participant" and the 'read-write' attribute MUST be interpreted as an "administrator" by default. It is possibleused todefined only one of the attributesmatch those participants that have knowledge of a passcode for theelement, the other attribute SHOULD be interpreted by default. This draft doesconference (PIN code). A focus need notdefine the set of possible conferencing roles. However, it can also be the case that conflicts can occur givencare if ahierarchy of elements. In that case, the lower-level element privileges predominate over the upper-level privileges element. 3.7.2.2. <conference-rules> The <conference-rules> element isuser using aset of <entry> child elements with specific authorization rules that indicate who is allowed to subscribepasscode toconference-information notifications, see floors, request/grant floors, and so on. Every <entry> elementjoin isrepresent by the 'id' attribute, each of which identifiescalling from arule insidePSTN or an IP phone. For example: Using a SIP phone, a SIP INVITE request arrives directly at theconference. It containsfocus. The focus examines the<condition>identity and<actions> sub elements. 3.7.2.2.1. <condition>discovers that there are no rules allowing this identity to join. The<condition> elementfocus also determineswhether a particular privilege applies to a user, a role, or domain.that there are no rules explicitly prohibiting this identity from joining. The<condition> element has the <identity> and the <validity> child element. These elements MUST NOT appear more than oncefocus in this case decides to challenge thecondition part ofidentity for asingle rule. The <identity> element restricts matching ofpasscode, if there is a ruleeither to a single entity orthat allows users with agroup of entities. The <identity> element haspasscode knowledge to join. If no such rule exists, the<one> and <many> child elements defined in Section 7.1 of [9]. The absence offocus would not challenge for a passcode. For PSTN users, the<identity> element insystem can be set up for an IVR system to prompt the user for a<condition> element indicates thatpasscode before forwarding theprivilege appliesrequest toall unauthenticated identities.the focus. The<identity> element has other child elements. These child elementsfocus 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<external-list>, <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>. Novo, et al. Expires January 11, 2007 [Page 21] Internet-Draft Common Conference Schema July 2006 The <validity> element expressesany thevalidity period ofrules 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 rulewithdoes, then the focus would challenge the GW/IVR for the passcode. A focus can challenge for the passcode using, for example, astarting and an ending time.HTTP Digest challenge. The<validity> elementusername, passcode andits child elements ,<from>realm need to be assigned and<until>, are defined in section 7.3distributed 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[9]. 3.7.2.2.1.1. <external-list>the conference are assigned a different passcode than normal participants. The<external-list><administrator- passcode> element can be used to match those key participants thatare part ofhave knowledge on aresource list that is created externally. The <external-list> element containskey participant passcode for the conference. Novo, et al. Expires April 13, 2007 [Page 20] Internet-Draft Common Conference Schema October 2006 Again, alist of <except> elements and allowsfocus need not care if a user using a passcode toimplementjoin is calling from asimple blacklist mechanism. The <except> element containsPSTN or anidentity. 3.7.2.2.1.2. <pseudonymous> The <pseudonymous> elementIP phone. It isused to match participantsimportant thathave provided an authenticated identity to the conference focus, but have requested pseudonymity intheconference itself. Afocus has a unique identity for each userrequests pseudonymity by authenticating himselfjoining 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 conferencefocus and providingduration. It might be required that apseudonym ingateway maps the telephone number of the PSTN phone into the IP signalling protocol(for example, usingheader that usually carries theFrom-header ofasserted identity or aSIP request).user. 3.7.2.2. <actions> The<pseudonymous> element can be combined with the <identity><actions> elementto providein thefocus with aapplied ruleon what to do when a specific identity is authenticated and that identityisrequesting pseudonymity througha positive grant of permission to thesignalling protocol. 3.7.2.2.1.3. <has-been-referred>conference data model or the conferencing system. The<has-been-referred><actions> elementcan be used to match those participants that the focushasreferred totheconference. 3.7.2.2.1.4. <has-been-invited>following operations: o The<has-been-invited><allow-refer-users-dynamically> elementcan be usedrepresents a boolean action. If set tomatch those participants thatTRUE, the identity is allowed to instruct the focushas invited into the conference. 3.7.2.2.1.5. <has-been-in-conference> The <has-been-in-conference> element can be used to match those participants that have joinedto refer a user to the conferenceinwithout modifying thepast. 3.7.2.2.1.6. <is-in-conference> The <is-in-conference> element can be usedallowed-users-list (in SIP terms, the identity is allowed tomatch those participants that are currently participatingsend a REFER request to the focus which results in theconference. Novo, et al. Expires January 11, 2007 [Page 22] Internet-Draft Common Conference Schema July 2006 3.7.2.2.1.7. <administrator> The <administrator> element can be used to match those participants that are administrators offocus sending aconference. 3.7.2.2.1.8. <is-on-allowed-users-list-dial-out> The <is-on-allowed-users-list-dial-out> element can be usedREFER request tomatch those participants that are ontheallowed-users-list withuser themethod dial-out. 3.7.2.2.1.9. <is-on-allowed-users-list-refer> The <is-on-allowed-users-list-refer> element can be usedreferrer wishes tomatch those participants that are onjoin theallowed-users-list withconference). If set to FALSE, themethod refer. 3.7.2.2.1.10. <participant-passcode> The <participant-passcode>refer request is rejected. If this elementcan be used to match those participants that have knowledgeis undefined it has a value of FALSE, causing the refer to be rejected. o The <allow-invite-users-dynamically> element represents apasscode forboolean action. If set to TRUE, the identity is allowed to instruct theconference (PIN code). Afocusneed not care ifto invite a userusing a passcodetojointhe conference without modifying the allowed-users-list list (in SIP terms, the identity iscalling fromallowed to send aPSTN orREFER request to the focus which results in the focus sending anIP phone. For example: Using a SIP phone, a SIPINVITE requestarrives directly atto thefocus. The focus examinesuser theidentity and discovers that there are no rules allowing this identityreferrer wishes tojoin. The focus also determines that there are no rules explicitly prohibitingjoin the conference). If set to FALSE, the refer request is rejected. If thisidentity from joining.element is undefined it has a value of FALSE, causing the refer to be rejected. o Thefocus in this case decides<allow-remove-users-dynamically> element represents a boolean action. If set tochallengeTRUE, the identityfor a passcode, if thereisa rule that allows users with a passcode knowledgeallowed tojoin. If no such rule exists,instruct the focuswould not challenge forto remove apasscode. For PSTN users,user from thesystem can be set up for an IVR system to promptconference without modifying theuser for a passcode before forwardingruleset (in SIP terms, the identity is allowed to send a REFER request to thefocus. Thefocusdoes not need to care if there iswhich results in the focus sending anIVR system or not. It can applyBYE request to thesame procedure as above. It checks if there are anyuser therules allowing or denyingreferrer wishes to leave theidentity access. In this case,conference). If set to FALSE, theidentityrefer request isthe GW.rejected. Ifno rules exist for that identity butthis element is undefined it has ageneral passcode rule does, thenvalue of FALSE, causing thefocus would challengerefer to be rejected. o The <show-floor-holder> element defines theGW/IVR foractions used by thepasscode. Aconference focuscan challenge forto control floor requests. This element defines thepasscode using, for example, a HTTP Digest challenge. The username, passcode and realm needaction that the focus is tobe assigned and distributed istake when processing amanner that is outside the scope of this document. Mutliple passcodes can be assignedparticular request tomultiple users.a floor within a conference. This element has defined values of: Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page23]21] Internet-Draft Common Conference SchemaJulyOctober 20063.7.2.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* block: This action instructs theconference. Again, afocusneed not care if a user using a passcodetojoin is calling from a PSTN or an IP phone. It is important thatdeny thefocus has a unique identity for each user joining from a PSTN phone via a gateway. Itfloor request. This action isnot enough that one identity to be assigned to all users joining fromthesame gateway since administrators have more control over conference duration. It might be required that a gateway mapsdefault action taken in thetelephone numberabsence of any other actions. * confirm: This action instructs thePSTN phone into the IP signalling protocol header that usually carriesfocus to allow theasserted identity or a user. 3.7.2.2.2. <actions>request. The<actions> element infocus then uses theapplied rule is a positive grant of permissiondefined floor algorithm to further allow of deny theconference data model or the conferencing system.floor. The<actions> element hasalgorithms used are outside thefollowing operations:scope of this document. oThe <allow-refer-users-dynamically>Note that placing a value of block for this elementrepresentsdoes not guarantee that aboolean action. If set to TRUE, the identityparticipant isallowed to instructblocked from joining thefocusconference. Any other rule that might resolve torefer a usertrue for this participant that carried an action whose value was higher than block would automatically grant confirm/allow permission tothe conference without modifying the allowed-users-list (in SIP terms, the identitythat participant. o The <show-floor-requests> element isallowed to send a REFER request to the focus which results in the focus sending a REFER requestof type boolean transformation. If set to TRUE, theuser the referrer wishesconference participant is able tojoinsee theconference).floor requests. If set to FALSE, therefer requestconference participant isrejected.not able to see floor requests. If this element isundefinedundefined, it has a value of FALSE, causing thereferfloor requests tobe rejected.not being seen by the conference participant. oThe <allow-invite-users-dynamically> element represents a boolean action. IfA rule can be set that provides anonymity toTRUE, the identity is allowed to instructa specific identity. In this case, the focus provides toinvite a user to the conference without modifyingtheallowed-users-list list (in SIP terms,rest of the participants an anonymous identity for that user, for example anonymous1. This can be achieved by using the <provide-anonymity> element. It isallowed to sendaREFER requestboolean transformation. If set to TRUE, thefocus which results in the focus sendingconference participants will see anINVITE request toanonymous identity for the userthe referrer wishes to join the conference). If set to FALSE, the refer request is rejected. If this elementwhose identity isundefined it has a value of FALSE, causingpresent in therefer to be rejected.conditions. o The<allow-remove-users-dynamically><read-write> element represents a boolean action. If set to TRUE, the identity is allowed toinstructmodify thefocus to remove a user fromelement described inside the 'element' attribute in the conferencewithout modifyingpolicy. If set to FALSE, any modifications to theruleset (in SIP terms,element are rejected. o The <read-only> element represents a boolean action. If set to TRUE, the identity is allowed tosend a REFER request to the focus which results in the focus sending an BYE request toread theuserelement described inside thereferrer wishes to leave'element' attribute in theconference).conference policy. If set to FALSE, any attempts to read therefer request iselement are rejected.If this3.8. <user> The elementis undefined it has<user> describes avalue of FALSE, causingsingle participant in thereferconference. 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. ExpiresJanuary 11,April 13, 2007 [Page24]22] Internet-Draft Common Conference SchemaJulyOctober 2006rejected. oThe<show-floor-holder><sphere> elementdefines the actionscan be usedby the conference focustocontrol floor requests. This element definesindicate theaction thatstate (e.g., 'work', 'home', 'meeting', 'travel') thefocususer isto take when processing a particular request to a floor withincurrently 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 aconference.<user> parent. This elementhas defined values of: * block: This action instructscan provide thefocus to denydesired level of detail about thefloor request. This action is the default action takenuser's devices and signaling sessions taking part in theabsence of anyconference 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 otheractions. * confirm: This action instructschild elements: <to-mixer>, and <from- mixer> child element described in thefocusfollowing section. 3.8.1. from-mixer, to-mixer Similarly that the controls defined in the <available-media> element, controls that apply toallowa particular user appear at this place in therequest.document. Thefocus then uses<to-mixer> element details properties associated with thedefined floor algorithmincoming streams tofurther allowthe mixer. <from-mixer> element details properties associated with the outgoing streams from the mixer. Both ofdenythese elements have thefloor.attribute 'name'. 'Name' attribute has the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn". Thealgorithms used are outside"VideoOut" and "AudioOut" media streams detail properties associated with thescopeoutgoing 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 ofthis document. o Notethese elements have the <floor> and <controls> child elements. 3.8.1.1. <floor> The <floors> element describes a floor thatplacingjoins this participant in the conference. If avalue of blockparticipant, forthis element does not guarantee thatinstance, needs to talk in the conference, it first needs to get aparticipant is blockedfloor fromjoiningthe moderator of the conference.Any other ruleThe <floor> element has a 'Boolen' value. A value of 'false' indicates thatmight resolve to true forthisparticipant 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 seeuser does not hold the floorrequests.in this moment. Ifset to FALSE, the conference participantthis control is notable to see floor requests. Ifspecify, 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> elementis undefined, it hascontains avalueset ofFALSE, causing the floor requests to not being seen by the<entry> child elements. Each <entry> child element contains a <user> child element with a sidebar conferenceparticipant. o A rule can be set that provides anonymity tounique identifier and aspecific 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><display-text> child element.ItThe <sidebars-by-ref> element isa boolean transformation. If set to TRUE,described in Section 5.9.1 of [2]. Notice that theconference participants will see an anonymous identity for<sidebars-by-ref> child element does not include theuser whose identity is presentattribute 'state' defined inthe conditions. o[2]. 3.10. <sidebars-by-val> The<read-write><sidebars-by-val> elementrepresentscontains aboolean action. Ifsetto TRUE,of <entry> child elements each containing information about a single sidebar. Notice as well that theidentity is allowed to modify<sidebars-by-val> and the <entry> child elementdescribed insidedo not include the'element'attribute 'state' defined in [2]. 4. RELAX NG schema In accordance with theconference 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,XCON framework document [1], theidentityConference Object isallowed to read the element described inside the 'element' attribute in thea logical representation of a conferencepolicy. If set to FALSE, any attempts to read the element are rejected. 3.7.3. <user>instance. Theelement <user> describes a single participantcommon conference information schema contains core information that is utilized intheany conference.The following elements as well asIt also contains theattributesvariable information part of<user> are definedthe Conference Object. This specification defines some document fragments in[2], section 5.6: <display-text>, <associated-aors>, <roles>, <languages>, <cascaded-focus>, and <endpoint>.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. ExpiresJanuary 11,April 13, 2007 [Page 25] Internet-Draft Common Conference SchemaJulyOctober 2006The <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. 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 [9]. The <allow-refer-users-dynamically>, <allow-invite-users-dynamically> and <allow-remove-users-dynamically> elements are defined in the previous section. The <floors> element is a container of <entry> child elements, each describing a floor that joins this participant in the conference. The <entry> element has the <show-floor-holder> and the <show-floor- requests> child element. The <entry> child elements is represent by the 'id' attribute, each of which identifies a floor inside the conference. 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.7.3.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. The <controls> child elements defined the same elements described in section 3.2.7 and some new ones.<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. ExpiresJanuary 11,April 13, 2007 [Page 26] Internet-Draft Common Conference SchemaJulyOctober 20063.7.3.1.1. <floor> 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 control can be enabled or disabled by the moderator during the conference creation stage. When the floor control is not enabled then any participant can speak in the conference at any time. In this conference very basic controls like muting or pausing the output stream, changing the volume of the output stream are provided to end participants. The <floor> element consists of the following attributes: floor_id: Uniquely identifies the floor within the context of this template and has a value of '1'. instances: Value of '1' implies only one occurrence of this floor at any one time. enable: A value of 'false' indicates that this floor is not enabled by default. value: A value of false specifies that the instance represented by this template does not have control of the floor. 3.7.3.1.2. <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. The control consists of the following attributes: type: The 'gain' control has a type of 'Int'. name: The control is named 'gain'. enable: The enable attribute specifies if access to the control is available to the client. The Control also consists of the following additional elements: value: Indicates the default value for the 'gain' control when not set. display-text: Provides a Control label that can be rendered to the client.<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. ExpiresJanuary 11,April 13, 2007 [Page27]31] Internet-Draft Common Conference SchemaJulyOctober 20063.8. <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.9. <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. XML Schema In accordance with the XCON framework document [1], the<!-- 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 ConferenceObject 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 theSchema 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 ConferenceObject. This specification makes use of XML namespaces for identifying common conference information documents and document fragments. The namespace URI for elements defined by this specification is a URN: urn:ietf:params:xml:ns:common-conference-schema. <?xml version="1.0" encoding="UTF-8" ?> <xs:schema xmlns="urn:ietf:params:xml:ns:common-conference-schema" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:compol="urn:ietf:params:xml:ns:common-policy" xmlns:role="urn:ietf:params:xml:ns:role-schema" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:common-conference-schema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="urn:ietf:params:xml:ns:conference-info" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\conference-info.xsd" /> <xs:import namespace="urn:ietf:params:xml:ns:common-policy" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\common-policy.xsd" /> <xs:import namespace="urn:ietf:params:xml:ns:role-schema" schemaLocation="C:\DOCUME~1\eoscdia\Desktop\role-schema.xsd" /> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>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> <!-- CONFERENCEINFOFLOOR 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. ExpiresJanuary 11,April 13, 2007 [Page28]34] Internet-Draft Common Conference SchemaJulyOctober 2006--> <xs:element name="conference-info" type="conference-type"/> <!-- CONFERENCE TYPE --> <xs:complexType name="conference-type"> <xs:sequence> <xs:element name="conference-description" type="conference-description-type"/> <xs:element name="host-info" type="host-type"/> <xs:element name="conference-state" type="conference-state-type"/> <xs:element name="security-mechanism" type="security-mechanisms-type" minOccurs="0"/> <xs:element name="floor-information" type="floor-information-type" minOccurs="0"/> <xs:element name="users" type="users-type"/> <xs:element name="sidebars-by-ref" type="sidebars-by-ref-type" minOccurs="0"/> <xs:element name="sidebars-by-val" type="sidebars-by-val-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!-- CONFERENCE DESCRIPTION TYPE --> <xs:complexType name="conference-description-type"> <xs:sequence> <xs:element name="display-text" type="xs:string" minOccurs="0"/> <xs:element name="subject" type="xs:string" minOccurs="0"/> <xs:element name="free-text" type="xs:string" minOccurs="0"/> <xs:element name="keywords" type="info:keywords-type" minOccurs="0"/> <xs:element name="webpage" type="xs:anyURI" minOccurs="0"/> <xs:element name="security-level" type="SecurityLevel" minOccurs="0"/> <xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/> <xs:element name="conference-stage" type="conference-stage-type"/> <xs:element name="conference-time" type="conferencetime-type" minOccurs="0"/> <xs:element name="conf-uris" type="uris-type" minOccurs="0"/> <xs:element name="service-uris" type="uris-type" minOccurs="0"/> <xs:element name="maximum-user-count" type="maximum-user-count-type" minOccurs="0"/> <xs:element name="available-media" type="conference-media-type"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- SECURITY LEVEL --> <xs:simpleType name="SecurityLevel"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="low"/> <xs:enumeration value="medium"/><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. ExpiresJanuary 11,April 13, 2007 [Page29]35] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:enumeration value="high"/> </xs:restriction> </xs:simpleType></define> <!--CONFERENCE STAGEUSERS TYPE --><xs:simpleType name="conference-stage-type"> <xs:restriction base="xs:string"> <xs:enumeration value="reserved"/> <xs:enumeration value="started"/> <xs:enumeration value="running"/> <xs:enumeration value="ended"/> </xs:restriction> </xs:simpleType><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> <!--CONFERENCE TIMEUSERS ADMISSION POLICY --><xs:complexType name="conferencetime-type"> <xs:sequence> <xs:element name="entry" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="base" type="xs:string"/> <xs:element name="mixing-start-offset" type="xs:integer" minOccurs="0"/> <xs:element name="mixing-stop-offset" type="xs:integer" minOccurs="0"/> <xs:element name="can-join-after-offset" type="xs:integer" minOccurs="0"/> <xs:element name="must-join-before-offset" type="xs:integer" minOccurs="0"/> <xs:element name="request-users" type="xs:integer" minOccurs="0"/> <xs:element name="notify-end-of-conference" type="xs:integer" minOccurs="0"/> <xs:element name="allowed-extend-mixing-end-offset" type="xs:boolean" default="true" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType><define name="user-admission-policy-type"> <choice> <value type="string">closedAuthenticated</value> <value type="string">openAuthenticated</value> <value type="string">anonymous</value> </choice> </define> <!--URISJOIN HANDLING TYPE --><xs:complexType name="uris-type"> <xs:sequence> <xs:element name="SIP" type="uri-type" maxOccurs="unbounded"/> <xs:element name="H323" type="H323-type" maxOccurs="unbounded"/> <xs:element name="PSTN-ISDN" type="PSTN-type" maxOccurs="unbounded"/> <xs:element name="BFCP" type="BFCP-type" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!--<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. ExpiresJanuary 11,April 13, 2007 [Page30]36] Internet-Draft Common Conference SchemaJulyOctober 2006SIP TYPE --> <xs:complexType name="uri-type"> <xs:sequence> <xs:element name="uri" type="xs:anyURI"/> <xs:element name="display-text" type="xs:string" minOccurs="0"/> <xs:element name="purpose" type="xs:string" minOccurs="0"/> <xs:element name="PIN-code" type="xs:integer" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType></choice> </define> <!--H323 TYPEUSERLIST --><xs:complexType name="H323-type"> <xs:sequence> <xs:element name="H.323-alias" type="xs:string" minOccurs="0"/> <xs:element name="H.323-URI" type="xs:anyURI"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><define name="UserList"> <ref name="role-type"/> <zeroOrMore> <element name="target"> <ref name="Target"/> </element> </zeroOrMore> </define> <!--PSTN TYPETARGET --><xs:complexType name="PSTN-type"> <xs:sequence> <xs:element name="phone-number" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="rate" type="xs:unsignedInt" minOccurs="0"/> </xs:sequence> <xs:attribute name="PIN-code" type="xs:string" use="required"/> <xs:attribute name="purpose" type="xs:string"/> </xs:complexType><define name="Target"> <ref name="role-type"/> <attribute name="uri"> <data type="anyURI"/> </attribute> <attribute name="method"> <ref name="method-type"/> </attribute> </define> <!--BFCPMETHOD TYPE --><xs:complexType name="BFCP-type"> <xs:sequence> <xs:element name="conference-id" type="xs:unsignedInt" minOccurs="0"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><define name="method-type"> <choice> <value type="string">dial-in</value> <value type="string">dial-out</value> <value type="string">refer</value> </choice> </define> <!--MAXIMUM USERPRIVILEGES CONTROL LIST TYPE --><xs:complexType name="maximum-user-count-type"> <xs:sequence><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. ExpiresJanuary 11,April 13, 2007 [Page31]37] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:element name="entry" type="xs:unsignedInt" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="role" type="role:role-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><!-- CONFERENCEMEDIARULES TYPE --><xs:complexType name="conference-media-type"> <xs:sequence> <xs:element name="entry" type="conference-medium-type" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="label" type="xs:string" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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> <!-- CONFERENCEMEDIUMRULE TYPE --><xs:complexType name="conference-medium-type"> <xs:sequence> <xs:element name="type" type="xs:string"/> <xs:element name="display-text" type="xs:string" minOccurs="0"/> <xs:element name="status" type="info:media-status-type" minOccurs="0"/> <xs:element name="mixing-mode" type="mix-mode-type" minOccurs="0"/> <xs:element name="mix level" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="codecs" type="codecs-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="label" type="xs:string" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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> <!--MIX MODECONDITION TYPE --><xs:simpleType name="mix-mode-type"> <xs:restriction base="xs:string"> <xs:enumeration value="Moderator-controlled"/> <xs:enumeration value="FCFS"/> <xs:enumeration value="Automatic"/> </xs:restriction> </xs:simpleType><define name="condition-type"> <ref name="role-type"/> <element name="identity"> <ref name="identity-type"/> </element> <element name="validity"> <ref name="validityType"/> </element> </define> <!--CODECSIDENTITY TYPE --><xs:complexType name="codecs-type"> <xs:sequence> <xs:element name="entry" type="codec-type" maxOccurs="unbounded"/><define name="identity-type"> <ref name="role-type"/> <element name="identity"> <ref name="identityType"/> </element> Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page32]38] Internet-Draft Common Conference SchemaJulyOctober 2006</xs:sequence> <xs:attribute name="decision" type="decision-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- CODEC TYPE --> <xs:complexType name="codec-type"> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="policy" type="policy-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- DECISION TYPE --> <xs:simpleType name="decision-type"> <xs:restriction base="xs:string"> <xs:enumeration value="Automatic"/> <xs:enumeration value="Moderator-controlled"/> </xs:restriction> </xs:simpleType> <!-- POLICY TYPE --> <xs:simpleType name="policy-type"> <xs:restriction base="xs:string"> <xs:enumeration value="Allowed"/> <xs:enumeration value="Disallowed"/> </xs:restriction> </xs:simpleType> <!-- HOST TYPE --> <xs:complexType name="host-type"> <xs:sequence> <xs:element name="display-text" type="xs:string" minOccurs="0"/> <xs:element name="web-page" type="xs:anyURI" minOccurs="0"/> <xs:element name="uris" type="uris-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><element name="validity"> <ref name="validityType"/> </element> </define> <!--CONFERENCE STATEROLES IDENTITY TYPE --><xs:complexType name="conference-state-type"> <xs:sequence> <xs:element name="allow-conference-state" type="xs:boolean" minOccurs="0"/><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. ExpiresJanuary 11,April 13, 2007 [Page33]39] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:element name="user-count" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="active" type="xs:boolean" minOccurs="0"/> <xs:element name="locked" type="xs:boolean" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><!--SECURITY MECHANISMSACTION TYPE --><xs:complexType name="security-mechanisms-type"> <xs:sequence> <xs:element name="entry-protocol" type="security-mechanism-type" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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> <!--SECURITY MECHANISMUSER TYPE --><xs:complexType name="security-mechanism-type"> <xs:sequence> <xs:element name="methods" type="methods-type" minOccurs="0"/> <xs:element name="option-tags" type="option-tags-type" minOccurs="0"/> <xs:element name="feature-tags" type="feature-tags-type" minOccurs="0"/> <xs:element name="bodies" type="bodies-type" minOccurs="0"/> <xs:element name="version" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="supported" type="xs:boolean" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- METHODS TYPE --> <xs:complexType name="methods-type"> <xs:sequence> <xs:element name="method" type="codec-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="default-policy" type="policy-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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> <!--OPTION TAGSONE USER TYPE--> <xs:complexType name="option-tags-type"> <xs:sequence>Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page34]40] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:element name="option-tag" type="codec-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="default-policy" type="default-policy-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- DEFAULT POLICY TYPE--><xs:simpleType name="default-policy-type"> <xs:restriction base="xs:string"> <xs:enumeration value="Allowed"/> <xs:enumeration value="Disallowed"/> <xs:enumeration value="Mandatory"/> </xs:restriction> </xs:simpleType> <!-- FEATURE TAGS TYPE --> <xs:complexType name="feature-tags-type"> <xs:sequence> <xs:element name="feature-tag" type="codec-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="default-policy" type="policy-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- BODIES TYPE --> <xs:complexType name="bodies-type"> <xs:sequence> <xs:element name="body-disposition" type="body-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="default-policy" type="policy-type" use="required"/> <xs:attribute name="default-encryption" type="policy-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- BODY TYPE --> <xs:complexType name="body-type"> <xs:sequence> <xs:element name="body-format" type="codec-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/><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. ExpiresJanuary 11,April 13, 2007 [Page35]41] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:attribute name="policy" type="policy-type" use="required"/> <xs:attribute name="default-policy" type="policy-type" use="required"/> <xs:attribute name="encryption" type="policy-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><!--FLOOR INFORMATIONENDPOINT TYPE --><xs:complexType name="floor-information-type"> <xs:sequence> <xs:element name="allow-floor-events" type="xs:boolean" maxOccurs="unbounded"/> <xs:element name="floor-request-handling" type="floor-request-type" maxOccurs="unbounded"/> <xs:element name="conference-floor-policy" type="Conference-floor-policy" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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> <!--FLOOR REQUESTMEDIA TYPE --><xs:simpleType name="floor-request-type"> <xs:restriction base="xs:string"> <xs:enumeration value="block"/> <xs:enumeration value="confirm"/> </xs:restriction> </xs:simpleType> <!-- CONFERENCE FLOOR POLICY --> <xs:complexType name="Conference-floor-policy"> <xs:sequence> <xs:element name="Floor" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Media-types"> <xs:complexType> <xs:sequence> <xs:element name="Video" minOccurs="0"/> <xs:element name="Audio" minOccurs="0"/> <xs:element name="Application" minOccurs="0"/> <xs:element name="Data" minOccurs="0"/> <xs:element name="Control" minOccurs="0"/> <xs:element name="Message" minOccurs="0"/> <xs:element name="Text" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element><define name="media-type"> <attribute name="id"> <text/> </attribute> <zeroOrMore> <element name="display-text"> Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page36]42] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:element name="Algorithm"> <xs:complexType> <xs:sequence> <xs:element name="Moderator-controlled" minOccurs="0"/> <xs:element name="FCFS" minOccurs="0"/> <xs:element name="Random" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Max-floor-users" type="xs:nonNegativeInteger" minOccurs="0"/> <xs:element name="Moderator-URI" type="xs:anyURI" minOccurs="0"/> </xs:sequence> <xs:attribute name="moderator-controlled" type="xs:boolean" default="false"/> <xs:attribute name="label" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <!-- USERS TYPE --> <xs:complexType name="users-type"> <xs:sequence> <xs:element name="join-handling" type="join-handling-type" minOccurs="0"/> <xs:element name="user-admission-policy" type="user-admission-policy-type"/> <xs:element name="user-must-be-specified" type="xs:boolean" minOccurs="0"/> <xs:element name="allowed-users-list" type="UserList" minOccurs="0"/> <xs:element name="privileges-control-list" type="privileges-control-list-type" minOccurs="0"/> <xs:element name="user" type="user-type" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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> <!--USERS ADMISSION POLICY --> <xs:simpleType name="user-admission-policy-type"> <xs:restriction base="xs:string"> <xs:enumeration value="closedAuthenticated"/> <xs:enumeration value="openAuthenticated"/> <xs:enumeration value="anonymous"/> </xs:restriction> </xs:simpleType> <!-- JOIN HANDLINGSIDEBARS-BY-REF TYPE --><xs:simpleType name="join-handling-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. ExpiresJanuary 11,April 13, 2007 [Page37]43] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:restriction base="xs:string"> <xs:enumeration value="block"/> <xs:enumeration value="allow"/> <xs:enumeration value="confirm"/> <xs:enumeration value="IVR"/> <xs:enumeration value="directed-operator"/> </xs:restriction> </xs:simpleType> <!-- USERLIST --> <xs:complexType name="UserList"> <xs:sequence> <xs:element name="target" type="Target" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!-- TARGET --> <xs:complexType name="Target"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute name="method" type="xs:methodType" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType><!--METHODSIDEBARS-BY-VAL TYPE --><xs:complexType name="methodType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice minOccurs="0"> <xs:element name="dial-in" type="xs:string"/> <xs:element name="dial-out" type="xs:string"/> <xs:element name="refer" type="xs:string"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> </xs:restriction> </xs:complexContent> </xs:complexType><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 ******************************************************************************** --> <!--PRIVILEGES CONTROL LISTMEDIA 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. ExpiresJanuary 11,April 13, 2007 [Page38]44] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:complexType name="privileges-control-list-type"> <xs:sequence> <xs:element name="data-access-rights" type="data-access-rights-type" maxOccurs="unbounded"/> <xs:element name="conference-rules" type="conference-rules-type" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- DATA ACCESS RIGHTS TYPE --> <xs:complexType name="data-access-rights-type"> <xs:sequence> <xs:element name="entry" type="entry-rights-type" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- ENTRY RIGHTS TYPE --> <xs:complexType name="entry-rights-type"> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="read-only" type="role:role-type" use="required"/> <xs:attribute name="read-write" type="role:role-type" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><!--CONFERENCE RULESCALL TYPE --><xs:complexType name="conference-rules-type"> <xs:sequence> <xs:element name="entry" type="conference-rule-type" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><define name="call-type"> <zeroOrMore> <element name="sip"> <ref name="sip-dialog-id-type"/> </element> </zeroOrMore> </define> <!--CONFERENCE RULESIP DIALOG ID TYPE --><xs:complexType name="conference-rule-type"> <xs:sequence> <xs:element name="condition" type="condition-type" maxOccurs="unbounded"/> <xs:element name="action" type="action-type" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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> <!--CONDITIONJOINING TYPE-->Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page39]45] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:complexType name="condition-type"> <xs:sequence> <xs:element name="identity" type="identity-type"/> <xs:element name="validity" type="compol:validityType"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType>--> <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> <!--IDENTITYSTATE TYPE --><xs:complexType name="identity-type"> <xs:sequence> <xs:element name="identity" type="identityType" maxOccurs="unbounded"/> <xs:element name="validity" type="compol:validityType" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><define name="state-type"> <choice> <value type="string">full</value> <value type="string">partial</value> <value type="string">deleted</value> </choice> </define> <!--ROLES IDENTITY*********************************************** TYPE DEFINED IN THE ROLE DOCUMENT *********************************************** --><xs:complexType name="identityType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice minOccurs="0"> <xs:element name="one" type="compol:oneType"/> <xs:element name="many" type="compol:manyType"/> <xs:element name="external-list" type="xs:string"/> <xs:element name="pseudonymous" type="xs:string"/> <xs:element name="has-been-referred" type="xs:string"/> <xs:element name="has-been-invited" type="xs:string"/> <xs:element name="has-been-in-conference" type="xs:string"/> <xs:element name="is-in-conference" type="xs:string"/> <xs:element name="administrator" type="xs:string"/> <xs:element name="is-on-allowed-users-list-dial-out" type="xs:string"/> <xs:element name="is-on-allowed-users-list-refer" type="xs:string"/> <xs:element name="participant-passcode" type="xs:string"/> <xs:element name="administrator-passcode" type="xs:string"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> </xs:restriction> </xs:complexContent> </xs:complexType><!--ACTIONROLE TYPE --><xs:complexType name="action-type"> <xs:complexContent> <xs:restriction base="xs:anyType">Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page40]46] Internet-Draft Common Conference SchemaJulyOctober 2006<xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="allow-refer-users-dynamically" type="xs:boolean"/> <xs:element name="allow-invite-users-dynamically" type="xs:boolean"/> <xs:element name="allow-remove-users-dynamically" type="xs:boolean"/> <xs:element name="show-floor-holder" type="floor-request-type"/> <xs:element name="show-floor-request" type="xs:boolean"/> <xs:element name="provide-anonymity" type="xs:boolean"/> <xs:element name="read-only" type="role:role-type"/> <xs:element name="read-write" type="role:role-type"/> </xs:choice> </xs:restriction> </xs:complexContent> </xs:complexType><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> <!--USER************************************************************ TYPE DEFINED IN THE COMMON POLICY DOCUMENT ************************************************************ --><xs:complexType name="user-type"> <xs:sequence> <xs:element name="user" type="one-user-type" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="state" type="info:state-type" use="optional" default="full"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><!--ONE USERVALIDITY TYPE --><xs:complexType name="one-user-type"> <xs:sequence> <xs:element name="display-text" type="xs:string" minOccurs="0"/> <xs:element name="associated-aors" type="info:uris-type" minOccurs="0"/> <xs:element name="provide-anonymity" type="xs:boolean" minOccurs="0"/> <xs:element name="roles" type="role:role-type" minOccurs="0"/> <xs:element name="languages" type="info:user-languages-type" minOccurs="0"/> <xs:element name="cascaded-focus" type="xs:anyURI" minOccurs="0"/> <xs:element name="sphere" type="compol:sphereType" minOccurs="0"/> <xs:element name="allow-refer-users-dynamically" type="xs:boolean"/> <xs:element name="allow-invite-users-dynamically" type="xs:boolean"/> <xs:element name="allow-remove-users-dynamically" type="xs:boolean"/> <xs:element name="floors" type="show-floors-type"/> <xs:element name="endpoint" type="info:endpoint-type" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="entity" type="xs:anyURI"/> <xs:attribute name="state" type="info:state-type" use="optional" default="full"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType><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. ExpiresJanuary 11,April 13, 2007 [Page41]47] Internet-Draft Common Conference SchemaJulyOctober 2006SHOW FLOORS TYPE --> <xs:complexType name="show-floors-type"> <xs:sequence> <xs:element name="entry" type="show-floor-type" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- SHOW FLOOR TYPE --> <xs:complexType name="show-floor-type"> <xs:sequence> <xs:element name="show-floor-holder" type="xs:boolean" minOccurs="0"/> <xs:element name="show-floor-request" type="xs:boolean"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- SIDEBARS-BY-REF TYPE--><xs:complexType name="sidebars-by-ref-type"> <xs:sequence> <xs:element name="entry" type="info:uri-type" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- SIDEBARS-BY-VAL TYPE --> <xs:complexType name="sidebars-by-val-type"> <xs:sequence> <xs:element name="entry" type="conference-type" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:schema><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. EachNovo, et al. Expires January 11, 2007 [Page 42] Internet-Draft Common Conference Schema July 2006extension MUST define its own namespace. Points of extension MUST be defined in the schema, and SHOULD be done using the<any namespace="##other"><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 ofthe best moments in Formula-1\\ racing</info:display-text>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><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 PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN<base>BEGIN:VCALENDAR Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page43]49] Internet-Draft Common Conference SchemaJulyOctober 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=WEEKLYDTEND:20061017T163000Z </base>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></maximum-user-count>Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page44]50] Internet-Draft Common Conference SchemaJulyOctober 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><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><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/users/formula-1/\\ </info:web-page><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 \\ </allow-conference-state><allow-conference-state>true< Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page45]51] Internet-Draft Common Conference SchemaJulyOctober 2006 /allow-conference-state> <info:user-count>3</info:user-count> <info:active>true</info:active> <info:locked>false</info:locked> </info:conference-state> <!--SECURITY MECHANISM --> <security-mechanism> <entry-protocol name="SIP"> <sesspol:methods default-policy="allowed"> <sesspol:method name="MESSAGE" policy="disallowed"/> </sesspol:methods> <sesspol:option-tags default-policy="disallowed"> <sesspol:option-tag name="100rel" policy="mandatory"/> <sesspol:option-tag name="preconditions" policy="allowed"/> </sesspol:option-tags> <sesspol:feature-tags default-policy="disallowed"> <sesspol:feature-tag name="video" policy="allowed"/> </sesspol:feature-tags> <sesspol:bodies default-policy="allowed" \\ default-encryption="allowed"> <sesspol:body-disposition name="session" policy="allowed" \\ encryption="disallowed" default-policy="disallowed"> <sesspol:body-format name="application/sdp" \\ policy="allowed"/> </sesspol:body-disposition> </sesspol:bodies> </entry-protocol> </security-mechanism> <!--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><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 \\ Novo, et al. Expires January 11, 2007 [Page 46] Internet-Draft Common Conference Schema July 2006 </moderator-uri><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><data-access-rights> <conference-description read-only= "observer"/> <security-level read-only= "administrator"/> <allow-sidebars read-only= "creator" \\ read-write= "creator"/> <conference-time read-only= "administrator"/> <maximum-user-count read-write= "creator"/> <codecs read-only= "creator" read-write= "creator"/> <host-info read-write= "creator"/> <conference-state read-write= "creator"/> <security-mechanism read-only= "creator"/> <floor-information read-only= "administrator"/> <allowed-users-list read-only= "administrator"/> <privileges-control-list read-only= "creator"/> <conditions read-only= "creator"/> <validity read-only= "creator"/> <allow-conference-state read-only= "observer"/> <sidebars-by-ref read-only= "observer"\\ read-write= "creator"/> <sidebars-by-val read-only= "observer"\\ read-write= "creator"/> </data-access-rights><conference-rules> <entry id="1"><conditions> <compol:identity>Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page47]52] Internet-Draft Common Conference SchemaJulyOctober 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: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\\ </allow-remove-users-dynamically> <floors><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. ExpiresJanuary 11,April 13, 2007 [Page48]53] Internet-Draft Common Conference SchemaJulyOctober 2006<entry id="1"> <show-floor-holder>false</show-floor-holder> <show-floor-requests>false \\ </show-floor-requests> </entry> </floors>/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. ExpiresJanuary 11,April 13, 2007 [Page49]54] Internet-Draft Common Conference SchemaJulyOctober 2006<info:associated-aors> <info:entry> <info:uri>mailto:alice@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>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><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. ExpiresJanuary 11,April 13, 2007 [Page50]55] Internet-Draft Common Conference SchemaJulyOctober 2006<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></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><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. ExpiresJanuary 11,April 13, 2007 [Page51]56] Internet-Draft Common Conference SchemaJulyOctober 2006<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>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 backslashNovo, et al. Expires January 11, 2007 [Page 52] Internet-Draft Common Conference Schema July 2006characters 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,andJariUrpilainenUrpilainen, 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. and C. Boulton,M., "A Framework and Data Model for Centralized Conferencing",draft-barnes-xcon-framework-02draft-ietf-xcon-framework-05 (work in progress),February 2005.September 2006. [2] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State",draft-ietf-sipping-conference-package-12 (work in progress), July 2005.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 InitiationProtocol", draft-ietf-sipping-conferencing-framework-05 (work in progress), Novo, et al. Expires January 11, 2007 [Page 53] Internet-Draft Common Conference Schema July 2006 May 2005.Protocol (SIP)", RFC 4353, February 2006. [5]Sperberg-McQueen, C.,Paoli, J., Maler, E., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEditionhttp://www.w3.org/TR/2000/REC-xml-20001006,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 October2000.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] Levin, O., "Centralized Conference Control Protocol", draft-levin-xcon-cccp-04draft-ietf-xcon-bfcp-06 (work in progress),January 2006. [9]December 2005. [8] Schulzrinne, H., "Common Policy:An XMLA Document Format for Expressing Privacy Preferences",draft-ietf-geopriv-common-policy-10draft-ietf-geopriv-common-policy-11 (work in progress),MayAugust 2006.[10][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.Novo, et al. Expires January 11, 2007 [Page 54] Internet-Draft Common Conference Schema July 2006Authors' 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. ExpiresJanuary 11,April 13, 2007 [Page55]60] Internet-Draft Common Conference SchemaJulyOctober 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 PropertyStatementThe 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.Disclaimer of Validity 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. 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.Acknowledgment Funding for the RFC Editor function iscurrentlyprovided by theInternet Society.IETF Administrative Support Activity (IASA). Novo, et al. ExpiresJanuary 11,April 13, 2007 [Page56]61] ----