XCON O. Novo Internet-Draft G. Camarillo Expires: September 7, 2006 Ericsson D. Morgan Fidelity Investments March 06, 2006 A Common Conference Information Data Model for Centralized Conferencing (XCON) draft-novo-xcon-common-data-model-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2006. 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 allow the conference control protocols to use a unified common conference information data model for XCON. This document formally Novo, et al. Expires September 7, 2006 [Page 1] Internet-Draft Common Conference Schema March 2006 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Common Conference Data . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. . . . . . . . . . . . . . . . . . 9 3.2.1. . . . . . . . . . . . . . . . . . . 10 3.2.2. . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. . . . . . . . . . . . . . . . . . . . . 11 3.2.4. . . . . . . . . . . . . . . . . . 12 3.2.5. . . . . . . . . . . . . . . . . . . 12 3.3. . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. . . . . . . . . . . . . . . . . . . . . 12 3.5. . . . . . . . . . . . . . . . . . . . 13 3.6. . . . . . . . . . . . . . . . . . . . 13 3.7. . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7.1. . . . . . . . . . . . . . . . . . . . . 14 3.7.2. . . . . . . . . . . . . . . . . . . . 14 3.7.3. . . . . . . . . . . . . . . . . . . . . . 14 3.7.4. . . . . . . . . . . . . . . 14 3.7.4.1. . . . . . . . . . . . . . . . 15 3.7.4.2. . . . . . . . . . . . . . . . . 15 3.7.4.2.1. . . . . . . . . . . . . . . . . . 15 3.7.4.2.2. . . . . . . . . . . . . . . . . . . 16 3.7.5. . . . . . . . . . . . . . . . . . . . . . . . . 17 3.8. . . . . . . . . . . . . . . . . . . . . 17 3.9. . . . . . . . . . . . . . . . . . . . . 18 3.10. Template . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.10.1. . . . . . . . . . . . . . . . . . . 18 3.10.2. . . . . . . . . . . . . . . . . . . 18 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 35 6. XML example . . . . . . . . . . . . . . . . . . . . . . . . . 35 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . . . . 49 Novo, et al. Expires September 7, 2006 [Page 2] Internet-Draft Common Conference Schema March 2006 1. Introduction This document 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 children and attributes. The common conference information is a part of the Conference Object. The Conference Object contains two components: the "Common Conference Information" component and the "Conference Template" component. The common conference information component contains the XML schema, which is used to represent the core information that is utilized in any conference (capabilities,membership, roles, call control signalling, media, etc...) and specifies the set of rights, permissions and limitations pertaining to operations being performed on a certain Conference Object. This document gives an overview of the conference variables that have been introduced in various protocol drafts of the XCON working group to date and proposes to create a unified common conference information data model for XCON. This document has been constructed in compliance with the XCON Framework [1] and the Session Initiation Protocol (SIP) Event Package for Conference State [2]. It also incorporates data elements proposed in several XCON WG and SIPPING WG drafts. [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 Novo, et al. Expires September 7, 2006 [Page 3] Internet-Draft Common Conference Schema March 2006 MUST be well formed and SHOULD be valid. Conference object data model documents MUST be based on XML 1.0 and SHOULD be encoded using UTF-8. A Common Conference information document begins with the root element tag of conference-type. The has the attribute 'entity' that contains the conference URI that identifies the conference being described in the document. The element is comprised of , , , , , , , , , and child elements. A common conference document must at least include the , , , , and 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 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. [Editors Note: The non-normative diagram will be remove in the following versions of the draft. Its uses is only to make easier the reader to see the hierarchical position of the elements.] ! | |--! | |-- | |-- | |-- | |-- | |-- | |-- | |-- | |-- | |-- | | |-- | | | |-- Novo, et al. Expires September 7, 2006 [Page 4] Internet-Draft Common Conference Schema March 2006 | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | ... | |-- | | |-- | | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | ... | |-- | | |-- | | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | ... | |-- | | |-- | | |-- | | ... | |--! | | |--! | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | | |-- | | | | |-- | | | | ... | | |-- | | | |-- | | | |-- Novo, et al. Expires September 7, 2006 [Page 5] Internet-Draft Common Conference Schema March 2006 | | | |-- | | | |-- | | | |-- | | | |-- | | | | |-- | | | | |-- | | | | ... | | ... | |--! | |-- | |-- | |--! | | |--! | | | |--! | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | | |-- | | | |-- | ... |--! | |-- | |-- | |--! | |-- | |-- | |-- | | |-- | | | |-- | | | ... | | |-- | | | |-- | | | ... | | |-- | | | |-- | | | ... | | |-- | | | |-- | | | | |-- | | | ... | ... | |-- | |-- Novo, et al. Expires September 7, 2006 [Page 6] Internet-Draft Common Conference Schema March 2006 | |-- | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | ... | | ... | |--! | |-- | |-- | |-- | | |-- | | |-- ... | | | |-- | | |-- | | |-- ... | | |-- | | |-- ... | | | |-- | | |-- | | |-- ... | | |-- | | |-- ... | | | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | ... | | | | | |-- | | | |-- | | | | |-- | | | | | |-- | | | | | | | | | | | | | ... | | | | | | | | | | | |-- | | | | | | |-- | | | | | | |-- Novo, et al. Expires September 7, 2006 [Page 7] Internet-Draft Common Conference Schema March 2006 | | | | | | | | | |-- | | | | | | | | | | | ... | | | ... | | | |--! | | |-- | | |-- | | |-- | | |-- | | | | | | | ... | | |-- | | |-- | | |-- | | |-- | | |-- | | |-- | | |-- | | |-- | | | |-- | | | | |-- | | | | |-- | | | ... | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | | |-- | | | | |-- | | | | |-- | | | | |-- | | | | |-- | | | | ... | | | |-- | | | | |-- | | | | | |-- | | | | | |-- | | | | | |-- | | | | | |-- | ... ... |-- Novo, et al. Expires September 7, 2006 [Page 8] Internet-Draft Common Conference Schema March 2006 | |-- | | |-- | | |-- | |-- | | |-- | | |-- | ... |-- | |-- | | | | | ... | |-- | | | | ... ... |-- |-- | |- | |- ... The following sections describe these elements in detail. The full XML schema is provided in Section 4. 3.2. The element describes the conference in its entirely. It SHOULD have an extra attribute 'xml:lang' to specify the language used in the contents of this element as defined Section 2.12 of [5]. It is comprised of , , , , , , , , , , , and . The child elements , , and are used to describe the conference content. These elements are defined in [2]. The child element is an optional element that points to a URI with additional information about the conference. These elements are described in [8]. The child elements and describe the capabilities of the conference. These elements are described in [8]. The is a compulsory element that give the stage of the conference. This element can have 4 values: reserved, started, running, and ended. At the reserved stage the conference exists only in the conference control server. There is no running focus and Novo, et al. Expires September 7, 2006 [Page 9] Internet-Draft Common Conference Schema March 2006 there are no subscribers or notifications. The information is accessible only via the conference control protocol. At he started stage, there are no users yet in the conference, still it is possible to subscribe to the conference state. The running stage starts when the first user joins the conference. In the ended stage, there are not any user connect to the conference, the conference information is only in the conference server if recurrence was defined. A user can get information only from the conference control protocol. For instance, the Session Initiation Protocol (SIP) Event Package for Conference State [2] is only applicable in the start and running stage. The child element has information related to conference time and duration of the conference. Other elements from different namespaces MAY be present for the purposes of extensibility. The and are used to describe the conference-related URIs. The child element indicates the number of users that can be invited to the conference. The child element is used to describe the media characteristics of the conference. The following sections describe the remaining elements in more detail. Other child elements can be used to extend in the future. 3.2.1. The element contains the information related to conference time and duration of a conference. The element contains one or more elements each defining the time information of a single conference occurrence. Every element contains a child element that specifies when conference media mixing starts before the conference starts, child element that specifies the time a conference media mixing stops after the conference stops. If the element is not present, it indicates that the conference media mixing starts immediately. If the element is not present, it indicates that the conference occurrence is not bounded. and elements both have the mandatory 'require-participant' attribute. This attribute has one of 4 values: 'none', 'administrator', 'moderator', and 'participant'. For mixing start offset, this attribute allows a privileged user to define when media mixing starts based on the latter of the mixing start time, and the time the first participant, administrator, or moderator arrives. If the value is set to 'none', mixing starts according to the mixing start time. For mixing end offset, this attribute allows a Novo, et al. Expires September 7, 2006 [Page 10] Internet-Draft Common Conference Schema March 2006 privileged user to define when media mixing ends based on the earlier of the mixing end offset, and the time the last participant, or moderator leaves. If the value is set to 'none', mixing stops according to the mixing end offset. If the conference policy was modified so that last privileged user is now a normal conference participant, and the conference requires a privileged user to continue; that conference MUST terminate [8]. An administrator can indicate the time when users can join a conference by populating the element. Similarly, an administrator can define the time after which new users are not allowed to join the conference anymore. This is done by populating the element. The child element specifies the iCalendar object of the conference. The iCalendar object components are defined in [6]. The element also contains the child element. This elements is explained in section 4.3.3 of [8]. The element defines in minutes when the system has to send a notification when the end of the conference is near. If the element is not present, it indicates that the system does not notify the users when the end of the conference is near. The refers to the possibility to extend the conference. It has two values: allowed, denied. 3.2.2. The contains the URI to be used in order to access the conference by different signaling means. It contains a sequence of child elements: , , and . The element contains the , , and . These elements are described in [2]. The element will include either a or a child elements. The has an attribute 'PIN code' with the PIN code of the conference if used. element will include 1 to 6 child elements (for H.320) as well. 3.2.3. The describes auxiliary services available for the conference. It contains a sequence of child elements: , , and . child element contains , , and . These elements are described in [2]. , and child elements are described in section. Novo, et al. Expires September 7, 2006 [Page 11] Internet-Draft Common Conference Schema March 2006 3.2.4. The contains the overall number of users allowed to join the conference. It contains a sequence of child elements. An element MAY contain the number of users with a specific role allowed to join the conference [9]. 3.2.5. The has the 'label' attribute that is the media stream identifier assigned by the conferencing server. This element contains a sequence of child elements of conference-medium- type. Each element contains the , , , , and child elements. The attribute 'label' and the , , and elements are described in [2]. The element specifies the allowed codecs in the conference [10]. It has an attribute 'decision' that specifies if the focus decides the common codec automatically or needs the approvement of the moderator of the conference (automatic, moderator-controlled). The element contains a elements. A element can have the attribute 'name' and 'policy'. The 'name' attribute identifies a codec, and the 'decision' attribute and the policy attribute contains the policy for that codec (allowed, or disallowed) [10]. The child elements , describe a default policy by which the mixer will build the outgoing stream from the incoming streams. Notice that this policy is different that the policy describe for the floors for each media. The child element describes the number of participants in audio media streams or the number of sub-windows in video media streams (for instance, a value of 4 in the element for video stremas means 2x2 layout). The child element MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Automatic" values indicating the default algorithm to be use with every media stream. 3.3. The element contains information about the entity hosting the conference. It contains the , child elements. These child elements are explained in [2]. contains the child element as well. contains a sequence of child elements: , , and . The child elements of are described in section. 3.4. The element and the , , and Novo, et al. Expires September 7, 2006 [Page 12] Internet-Draft Common Conference Schema March 2006 child element are explained in section 5.5 of [2]. The is described in section 4.3.7.2 of [8]. 3.5. The element has a single mandatory attribute, 'name'. The 'name' attribute identifies a protocol the policy of each protocol element is referring to. It contains a series of sub-elements. Each sub-element contains the policy related to the usage of a particular protocol. [Editors Note: The element only has defined the feature for the SIP protocol. Discussion about other protocols (PSTN, HTML, Jabber, H.323, etc...) are in the XCON WG mailing list.] The element has a series of child elements: methods, option-tags, feature-tags, and bodies. These elements are described in sections 6.1, 6.2,6.3, and 6.4 of [10]. 3.6. The element has the , , and the child elements. Other elements from different namespaces MAY be present for the purposes of extensibility. The element has one or more . The number of child elements indicates how many floors the conference can have. A element has the mandatory element, the mandatory element that MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Random" values indicating the algorithm, the optional element, and the optional set of element indicating the URIs of the moderators. The element, its attributes, and the child element are described in Section 18.8 of [11]. The , and are described in section 4.3.7.2 of [8]. This draft extends the element with a new attribute 'label'. The 'label' attribute identifies the media that the floor is controlling. 3.7. The element contains the , , , , , and child elements. The element besides to have the "block", "confirm", and "allow" values described in section 4.3.7.2.3 of [8], it has the Novo, et al. Expires September 7, 2006 [Page 13] Internet-Draft Common Conference Schema March 2006 following extra values: "IVR", "directed-operator", "moderator- controlled". If the element has the "IVR" value, the user has to define the PIN code, in the case of "directed-operator" the user is directed to an operator, in the case of the "moderator- controlled" value the user has to wait for the approve of the chair of the conference. The element is a boolean value specifying whether only defined users can join the conference. If the element is set to true, the conference initiator will need to specify the users. The following sections describe the remaining elements in more detail. Other child elements can be used to extend in the future. 3.7.1. The child element contains a list of user URIs, PSTN phone number, role, or domain (*@example.com) that the focus uses to determine who can join the conference. The element includes zero or more child element and zero or more child element. Those two child elements includes the mandatory 'uri' attribute. If users are specify in this list, the system does not need any IVR to ask the user for conference ID since the system knows according, for instance, to the "contact" in SIP or calling number in PSTN, to which conference to connect the user. 3.7.2. The child element contains a list of user URIs, PSTN phone number, role, or domain (*@example.com) that the focus uses to determine who to invite to join a conference. The element includes zero or more child element and zero or more child element. Those two child elements includes the mandatory 'uri' attribute. The use of the and elements are described in section 4.3.4 of [8]. 3.7.3. The child element contains a list of resources that the focus needs to refer to the conference. The is identical to the element and is described in section 4.3.5 of [8]. 3.7.4. The refers to a virtual set of rights, Novo, et al. Expires September 7, 2006 [Page 14] Internet-Draft Common Conference Schema March 2006 permissions and limitations pertaining to operations. This element contains the and the . 3.7.4.1. The element describes the read/write access privileges for accessing the Conference Object as a whole. It is partially described in [1]. The contains a list of 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 receives a request for access to privacy-sensitive data it needs to match it against the 'read-only' and the 'read-write' attributes. Each attribute of each individual element is evaluated and as a result it is determined if the user can access that element. The attributes specify the minimum subscriber's role that can access or modify the element of the conference. Subscribers with a lower role cannot access or modify the element. If an element is not defined in the then the 'read-only' attribute MUST be interpreted as a "participant" and the 'read-write' attribute MUST be interpreted as an "administrator" by default. It is possible to defined only one of the attributes of the element, the other attribute SHOULD be interpreted by default. This draft does not define the set of possible conferencing roles. However, it can also be the case that conflicts can occur given a hierarchy of elements. In that case, the lower-level element privileges predominate over the upper-level privileges element. 3.7.4.2. The element is a set of 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. It is partially described in [8] Every

Novo, et al. Expires September 7, 2006 [Page 39] Internet-Draft Common Conference Schema March 2006

example.com 20061017T143000Z 20061017T163000Z

true\\

bob@example.com

block

Bob Hoskins

Novo, et al. Expires September 7, 2006 [Page 40] Internet-Draft Common Conference Schema March 2006 mailto:bob@example.com

false

participant en

password="1a2b3c4d">Digest\\

false\\

false

false \\

Bob's Laptop

20061017T140000Z expert required sip:alice@example.com connected

dialed-out

20061017T140000Z invitation sip:alice@example.com

Novo, et al. Expires September 7, 2006 [Page 41] Internet-Draft Common Conference Schema March 2006 10235

432424

full info

hsjh8980vhsb78

vav738dvbs

8954jgjg8432

Alice Kay

mailto:alice@example.com

false

moderator en

password="4r2q3ed5">Digest\\

true\\

Alice's Desktop

connected dialed-in Novo, et al. Expires September 7, 2006 [Page 42] Internet-Draft Common Conference Schema March 2006 20061017T133508Z invitation sip:conference@example.com 10235

432424

sendrecv 10234

532535

sendrecv

full info

truy45469123478

asd456cbgt

3456jgjg1234

Carol More

mailto:carol@example.com

false

administrator en

password="2asd63et">Digest\\ Novo, et al. Expires September 7, 2006 [Page 43] Internet-Draft Common Conference Schema March 2006

true\\

Carol's Computer

connected

dialed-in

20061017T133005Z invitation sip:conference@example.com

10235

432424

sendrecv 10234

532535

sendrecv

full info

wevb12562321894

asw456wedf

2365dfrt3497

sips:conference@example.com;grid=40

private with Bob

Note that due to RFC formatting conventions, this documents splits lines whose content would exceed 72 characters. Two backslash characters mark where the lines folding has taken place. These backslash would not appear in the actual XML data model. 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. Roni Even, and Orit Levin contributed with many good concepts that are Novo, et al. Expires September 7, 2006 [Page 45] Internet-Draft Common Conference Schema March 2006 described here. Also I would like to thanks Adam Roach, Mary Barnes, Chris Boulton, Umesh Chandra, Orit Levin, and Jari Urpilainen for their comments. 10. References 10.1. Normative References [1] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencing", draft-barnes-xcon-framework-02 (work in progress), February 2005. [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-12 (work in progress), July 2005. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-05 (work in progress), May 2005. [5] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [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] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01 (work in progress), October 2004. [9] Levin, O., "Centralized Conference Control Protocol", draft-levin-xcon-cccp-04 (work in progress), January 2006. [10] Camarillo, G., "A Session Initiation Protocol (SIP) Event Package for Media Policy", draft-camarillo-sipping-policy-package-00 (work in progress), Novo, et al. Expires September 7, 2006 [Page 46] Internet-Draft Common Conference Schema March 2006 October 2003. [11] Koskelainen, P. and H. Khartabil, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy Manipulation", draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress), February 2004. [12] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-07 (work in progress), February 2006. [13] Boulton, C. and U. Chandra, "Media Policy Templates for XCON", draft-boulton-xcon-media-template-02 (work in progress), October 2005. [14] Even, R., "Conferencing media policy requirements", draft-even-sipping-media-policy-requirements-00 (work in progress), February 2003. [15] Mahy, R. and N. Ismail, "Media Policy Manipulation in the Conference Policy Control Protocol", draft-mahy-sipping-media-policy-control-00 (work in progress), February 2003. [16] Levin, O., "Conference Policy Control Protocol for Centralized Conferencing", draft-levin-xcon-cpcp-00 (work in progress), June 2003. [17] 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. [18] Khartabil, H. and A. Niemi, "Privileges for Manipulating a Conference Policy", draft-ietf-xcon-conference-policy-privileges-01 (work in progress), October 2004. Novo, et al. Expires September 7, 2006 [Page 47] Internet-Draft Common Conference Schema March 2006 Authors' Addresses Oscar Novo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Oscar.Novo@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com David P. Morgan Fidelity Investments 82 Devonshire St, MZ V8C Boston, MA 02109-3614 USA Email: Dave.Morgan@fmr.com Novo, et al. Expires September 7, 2006 [Page 48] Internet-Draft Common Conference Schema March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 is currently provided by the Internet Society. Novo, et al. Expires September 7, 2006 [Page 49]