XCON Working Group M. Barnes Internet-Draft Nortel Networks Expires: June 24, 2005 C. Boulton Ubiquity Software Corporation O. Levin Microsoft Corporation December 24, 2004 A Framework and Data Model for Centralized Conferencing draft-barnes-xcon-framework-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 June 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document introduces a framework and data model for Centralized Conferencing (XCON) applicable to participants using different call signaling protocols and sending media over varying network topologies. The XCON framework outlines the conferencing protocols, Barnes, et al. Expires June 24, 2005 [Page 1] Internet-Draft XCON Framework December 2004 which are complementary to the call signaling protocols, for building advanced conferencing applications. It also introduces the concept of an XCON conferencing data model which binds all the defined components together. The XCON framework is compatible with the functional model presented in the SIP Conferencing framework. This work is being discussed on the xcon@ietf.org mailing list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. XCON Data Model . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Conference Info . . . . . . . . . . . . . . . . . . . . . 8 4.2.1 Mixing Pattern . . . . . . . . . . . . . . . . . . . . 8 4.3 Conference Rules . . . . . . . . . . . . . . . . . . . . . 9 5. Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Template . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3 Conference Policy . . . . . . . . . . . . . . . . . . . . 10 5.4 Reservation . . . . . . . . . . . . . . . . . . . . . . . 10 5.5 Conference State . . . . . . . . . . . . . . . . . . . . . 10 5.6 Policy and State Dependencies . . . . . . . . . . . . . . 11 6. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 12 6.1 Call Control Signaling . . . . . . . . . . . . . . . . . . 12 6.2 Notifications . . . . . . . . . . . . . . . . . . . . . . 12 6.3 CPCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4 CCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5 Floor Control . . . . . . . . . . . . . . . . . . . . . . 13 7. Conferencing Operations . . . . . . . . . . . . . . . . . . . 14 7.1 Conference Creation and Deletion . . . . . . . . . . . . . 15 7.2 Participant Manipulations . . . . . . . . . . . . . . . . 15 7.3 Media Manipulations . . . . . . . . . . . . . . . . . . . 15 7.4 Sidebar Manipulations . . . . . . . . . . . . . . . . . . 15 7.5 Whispering or Private Messages . . . . . . . . . . . . . . 15 7.6 Conference Announcements and Recordings . . . . . . . . . 15 8. Relationships between SIPPING and XCON Frameworks . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Barnes, et al. Expires June 24, 2005 [Page 2] Internet-Draft XCON Framework December 2004 Intellectual Property and Copyright Statements . . . . . . . . 19 Barnes, et al. Expires June 24, 2005 [Page 3] Internet-Draft XCON Framework December 2004 1. Introduction This document introduces a framework and data model for Centralized Conferencing (XCON) applicable to participants using different signaling protocols and sending media over varying network topologies. The framework is protocol agnostic and is equally applicable to SIP, H.323, Jabber, HTML, PSTN, etc. and mixed conferencing systems. The XCON framework provides an expanded functional model by outlining the complementary (to call signaling interface) conferencing protocols between primary components for building rich conferencing applications and by introducing the data model which binds all the defined components together. 2. Conventions and Terminology The XCON framework document uses when appropriate and expands on the terminology introduced in the SIP conferencing framework [3]. The following additional terms are defined for use within the XCON conference framework. Conference Information: The XML definition of all conference components pertaining to the conference membership, media mixing, etc. including capabilities and limitations of each. Media Pattern: An abstract definition of mixer behavior registered with IANA and used by an XCON system for representing its supported media mixing modes (as a part of the conference information definition). The IANA registration MUST include the text description of the mixer behavior and optionally the XML definition to allow configuration, state presentation, and the mapping of input/outputs, media controls, sliders, radio boxes, etc. - if applicable. Conference Rules: The XML definition of rules pertaining to a conference creation and to the conference (information) manipulation at different stages of the conference lifetime. Conference Policy: A dynamically created data object which contains a set of rules defined at the onset of a conference and that can be modified during the conference lifetime. Conference Policy Control Protocol (CPCP): A protocol used by clients to manipulate the conference policy, most frequently outside the scope of an active conference. Conference Template: One of the static data objects created by and kept in an XCON system that reflects the capabilities of the system and is used to specify a tailored conference instance. A template provides the conference creator the default conference information required for successful conference creation with desired values (falling within boundary ranges) and default values Barnes, et al. Expires June 24, 2005 [Page 4] Internet-Draft XCON Framework December 2004 if not explicitly specified. Conference Reservation: A dynamically created (using Conference Template) data object which represents the status and the capabilities of an allocated conference instance and can have re-occurring properties. Conference State: A dynamic data object which represents the status of an active conference instance, is created on the conference focus onset, and is maintained by the focus in conjunction with information provided by other XCON components. Centralized Conference Control Protocol (CCCP): A protocol used by clients to manipulate the conference state during an active conference instance. Floor: A term used to apply to a set of data or resources associated with a conference instance, for which a conference participant (or group of participants) is granted temporary input access. Floor Chair: A Floor control protocol compliant client (human participant or automated entity) who is authorized to manage access to one floor (grants, denies, or revokes a floor). The floor chair does not have to be a participant in the conference instance. Multimedia stream: In the context of this framework document, this term is used to refer to the media composition of a conference instance, which is established via the signaling protocol between a focus and a participant. The multimedia stream is the union of a set of media such as voice, video, session-mode instant messaging, and interactive text that contribute to the conference instance mix. [Editor's Note: may need to revisit this definition based on Keith's L.'s mailing list comments on the previous version of the doc.] Sidebar: TBD. Signaling Interface (I/F): The session signaling protocol used between a participant and a focus instance. State: See "Conference State". Template: See "Conference Template". Whisper: TBD. 3. Overview The fundamental requirements for conferencing are outlined in [1]. These requirements are applicable for conferencing systems using various signaling protocols, including SIP. The centralized conferencing model proposed in this document is based on the following fundamental data types: o Conference Information o Conference Rules Barnes, et al. Expires June 24, 2005 [Page 5] Internet-Draft XCON Framework December 2004 The realization of a conference in the XCON system can be represented using the following data objects (being composed of the data types above): o Conference Template o Conference Policy o Conference Reservation o Conference State Figure 1 illustrates the composition of a conference instance life-cycle from creation to full state using the data objects presented. +---+-----------------------+ | | | | R | | | U | | | L | T E M P L A T E | | E | | | S | | | | | +---+-----------------------+ | | V +---+-----------------------+ | | | | R | | | U | | | L | R E S E R V A T I O N| | E | | | S | | | | | +---+-----------------------+ | | V +---------------------------+ +-+-------------------------+ | +-+-+-----------------------+ | | | | | | | | R | | | | | U | | | | | L | I N S T A N C E | | | | E | | | | | S | | |-+ | | |-+ Barnes, et al. Expires June 24, 2005 [Page 6] Internet-Draft XCON Framework December 2004 +---+-----------------------+ Figure 1: Conference Definition, Creation, and Lifetime [Editors note: Add text around figure 1. Figure 2 illustrates the decomposition of Conference info. +----------------------------------------------------+ | C O N F E R E N C E I N F O R M A T I O N | | T Y P E | | +----------------------------------------------+ | | | Conference Description | | | +----------------------------------------------+ | | +----------------------------------------------+ | | | Membership (Roles, Capacity, Names) | | | +----------------------------------------------+ | | +----------------------------------------------+ | | | Signaling (Protocol, Direction, Status) | | | +----------------------------------------------+ | | +----------------------------------------------+ | | | Sidebars, Etc. | | | +----------------------------------------------+ | | +------------+ +-----------+ +-------------+ | | | User Input | | Audio Mix | | Video Tiles | | | | Pattern | | Pattern | | Pattern | | | +------------+ +-----------+ +-------------+ ... | +----------------------------------------------------+ Figure 2: Conference Info Decomposition [Editors note: Add text around figure 2. Section 4 of this document describes the fundamental XCON data types. Section 5 of this document describes XCON data objects based upon these data types. Section 7 then describes the manipulation of these data objects in support of the conferencing operations, using XCON defined protocols. Section 6 describes the fundamental conferencing mechanisms and provides a high level overview of the XCON protocols. Section 8 of this document provides a summary of the relationship between the XCON framework and the SIPPING Conferencing framework, in the context of the XCON data model, highlighting the XCON and other signaling interfaces. 4. XCON Data Model Barnes, et al. Expires June 24, 2005 [Page 7] Internet-Draft XCON Framework December 2004 4.1 General The information related to any conference can be segmented into two main data types: the conference information and the conference rules. o Conference information: The definition of all conference components pertaining to the conference membership, media mixing, etc. including capabilities and limitations of each. o Conference rules: The set of permissions pertaining to a conference creation and to the conference (information) manipulation at different stages of the conference lifetime. The XCON data model defined in this framework has no strict separation between conference membership, conference media information and the related policies. This meets the requirement in many conference control operations to enable synchronized access to the conference policy as a whole, to the conference state as a whole, and for receiving notifications about changes to either. 4.2 Conference Info The basic conference-info type definition has been introduced in [4] and is being extended by XCON [TBD]. This definition contains all relevant data components required for representing a conference instance, including its membership, roles, capabilities and limitations at different stages in its life-cycle. The conference information is used for describing an XCON conferencing systems capabilities through the concept of a template (see Section 5.2), for conference reservations (see Section 5.4), for describing the conference state (see Section 5.5), and for providing snapshots of the conference information at any of the stages of the conference life-cycle. The Conference-info also includes the definition of the conference mixing patterns. 4.2.1 Mixing Pattern The concept of a "Mixing Pattern" is introduced in order to abstract the complexity and the details of the mixers' implementation by each conferencing server. Each Mixing Pattern type needs to be registered with IANA. The IANA registration MUST include the text description of the mixer behavior and optionally the XML definition to allow configuration, state presentation, and the mapping of input/outputs, media controls, sliders, radio boxes, etc. - if applicable. Barnes, et al. Expires June 24, 2005 [Page 8] Internet-Draft XCON Framework December 2004 4.3 Conference Rules Conference rules are defined in terms of TBD The XCON CPCP [9] contains an example of a conference policy schema. 5. Data Objects 5.1 General Any XCON system and any XCON conference instance can be represented using the objects described below. o Conference Template is a static data object created by and kept in an XCON system that reflects the capabilities of the system. A template provides the conference creator the default conference information required for successful conference creation with desired values (falling within boundary ranges). An XCON client has the ability to query an XCON compliant server to obtain a list of supported templates. o Conference Policy is a dynamically created data object which contains a set of rules defined at the onset of a conference and that can be modified during the lifetime of a conference instance. o Conference Reservation is a dynamically created data object which represents the status and the capabilities of an allocated conference instance and can have re-occurring properties. A conference reservation is created using the rule-set defined by a conference template. o Conference State is a dynamic data object which represents the status of an active conference instance, is created on the conference focus onset, and is maintained by the focus. Conference state can is crated from a migration from a Conference Reservation (creation of focus). This can either be the result of a client specified Conference reservation or due to the dynamic creation of a conference reservation (Ad-Hoc Conference) containing a set of pre-defined default values. 5.2 Template A conference template is a static semantic XML representation of an XCON conference. It provides relevant information that enables an authorized creating entity the ability to define the required granularity of conference configuration detail. An XCON conference server SHOULD/MUST support a minimum set of templates as defined in [ref to template draft]. If proprietary modifications are required to a template, the guidelines for creating/modifying templates, as defined in [ref], MUST be obeyed to maintain semantic continuity. This provides conference clients that receive unknown template features the ability to render information (e.g. an additional radio Barnes, et al. Expires June 24, 2005 [Page 9] Internet-Draft XCON Framework December 2004 button can be rendered to the user and it's value conveyed and selected by the client, even though it is not part of a standard template. [Editors Note: To be developed and aligned with XCON working group consensus.] 5.3 Conference Policy Conference policy is a set of rules that are defined at the onset of a conference and MAY be modified during the conference lifetime. At the conference onset, the Conference policy would typically be applied to the template (see Section 5.2) resulting in creation of the conference reservation (see Section 5.4) and/or state (see Section 5.5) object(s). During the conference reservation and/or state lifetime, any requested conference manipulation is checked against the conference policy object. The XCON CPCP [9] contains an example of a conference policy schema. 5.4 Reservation The concept of a "reservation" is introduced [ref]. A reservation can be described as being an instantiated conference template (as defined in Section 5.2) that is 'pre-state'. 'Pre-State' means that the creating client has uploaded the customized template to the conference server. The server has verified that no semantics of the template and no Conference Policy has been violated. The desired conference is then considered instantiated and recognized as a conference waiting to commence (TODO - clear definition of reservation --> conference instance state change required). This means that a semantically valid XCON conference template has been utilized for creating a conference reservation. The proposed reservation is then uploaded to the conference server using the specified interface mechanism (TODO: expansion required when appropriate detail available). All variable values specified for the instantiated conference definition fall in the ranges supplied by the constraints of the templates XML definition and default values are used if not specified. An attempt to instantiate a conference value within a template that does not comply will be rejected. [Editors Note: To be developed and aligned with XCON working group consensus.] 5.5 Conference State Conference state is the set of dynamic information describing a Barnes, et al. Expires June 24, 2005 [Page 10] Internet-Draft XCON Framework December 2004 conference instance in progress. This information can include the focus information, participants' information, associated media sessions in progress, the current loudest speaker, the current chair, etc. The basic XML schema is defined the SIPPING Conference Package [4]. There are different ways to affect the conference state. A participant can join and leave the conference using the signaling interface only. A participant can change its own media streams using the signaling interface only. This kind of operations is called "1st party signaling" and does not affect the state of other participants in the conference instance. Limited operations for controlling other conference participants (a so called "3rd party control") through the focus are possible using some signaling interfaces. In SIP for example, REFER can be used for this purpose as described in [5]. In order to perform richer conference control a user agent client needs to implement a CCCP client interface. Using CCCP, a client can directly affect its own conference state, conference state of other participants, and the state of the Focus/MCUs/"mixers", etc. which may also indirectly affect the state of other participants. Conference control using CCCP is logically performed on the conference state. Using CCCP requests, a client can directly manipulate the conference state data object. The CCCP server receives the state change requests and interacts with the focus to ensure that the required operations (e.g. signaling) are carried out. Changes in the conference state are reported to conference participants and authorized parties using well-defined event mechanisms subject to each interested parties privileges. For example, for SIP entities it is the Event Notification mechanism defined in RFC 3265 [16]. 5.6 Policy and State Dependencies Changes in the conference policy can automatically cause changes in the conference state, while changes in the conference state never change conference policy. There are many examples of how a change in conference policy can change the state - changing the end time of a conference causes the conference to end early, reducing the maximum number of participants could cause some to be removed. Barnes, et al. Expires June 24, 2005 [Page 11] Internet-Draft XCON Framework December 2004 A change in conference state never changes the conference policy because by definition the conference policy must authorize any change in state. If a request fails due to a policy, this will be indicated in the response reason. The user may then attempt to change the policy, and then retry the state change request. For example, a user may request a participant to be added to a conference. The focus must check the policy to see if the user's role and/or URI allow the user to participate in the conference. For example, the policy might say that only members of example.com may join the conference. 6. Conferencing Mechanisms 6.1 Call Control Signaling The focus is the central component of the conference. Participants interface with the focus using an appropriate Call Control Signaling protocol. Participants request to establish or join a conference using the Call control signaling interface. A focus then either accepts (after checking the policy), sends a progress indication (e.g. for a parked call while awaiting moderator approval to join) or rejects that request using the call control signaling interface. In the case of an active conference, CCCP would be used to affect the conference state. For example, CCCP requests to add and delete participants will be communicated to the focus and checked against the conference policy rules. If approved, the participants will be added or deleted using the call signaling to/from the conference instance by the focus. 6.2 Notifications The focus is responsible for implementing a Conference Notification Service. The role of the Conference Notification Service is to provide updates on the Conference State to authorized parties (e.g. participants) as defined in [4]. 6.3 CPCP A Conference Policy Control Protocol (CPCP) is proposed as a standardized means of storing and manipulating the Conference Policy. The conference policy is comprised of the rules associated with a specific conference instance. These rules can be modified during the life-cycle of a conference instance. Requirements for the CPCP are defined in the CPCP Requirements document [8]. The Conference Policy Control Protocol document [9] defines the XML Schema for the conference policy data elements. Barnes, et al. Expires June 24, 2005 [Page 12] Internet-Draft XCON Framework December 2004 The privileges as to which users are allowed to read and/or manipulate a specific Conference Policy instance are defined in a separate Extensible Markup Language (XML) Schema[11]. This schema is based on the common policy model being used for geographic privacy information and for presence information. A separate document [10] proposes XCAP as one protocol mechanism for storing and manipulating this conferencing policy data. XCAP is a HTTP 1.1 based protocol that allows clients to read, write, modify and delete application data stored in XML format on a server. One of the main advantages of XCAP is that it maps XML document elements and attributes to HTTP URIs that can be directly accessed by HTTP. 6.4 CCCP A Centralized Conferencing Control Protocol [12] is defined to allow participants or otherwise authorized entities to directly manipulate an active conference. CCCP is defined as a set of transactions issued over a reliable transport protocol. A transaction consists of a Request carrying the required information in an XML body and a corresponding Response carrying an appropriate XML body. CCCP requests are submitted to the focus and can be prioritized and queued, or even interleaved based on the requestor's role and the corresponding affected XML element(s). CCCP requires no single lock per document, and the CCCP server functionality supported by the focus, can locally define an optimization strategy independent of CCCP client behavior. 6.5 Floor Control A mechanism for floor control within an XCON conferencing system is defined in the 'Binary Floor Control Protocol' specification [7]. Floor control is not a mandatory mechanism for an XCON server implementation but provides advanced media input control features for participants. An XCON compliant client supporting floor control needs to obtain information for connecting to a floor control server to enable it to issue floor requests. This connection information can be retrieved using information provided by mechanisms such as negotiation using the SDP[18] offer/answer[21] exchange on the signaling interface with the focus. As well as the Client --> Floor Server connection information, a client wishing to interact with a Floor Control server requires access to additional information. This information associates Floor Control interactions with the appropriate Floor instance. Once a Barnes, et al. Expires June 24, 2005 [Page 13] Internet-Draft XCON Framework December 2004 connection has been established and authenticated (see [7] for authentication details), a specific floor control message requires detailed information to uniquely identify a user, a floor and a conference instance. This information, defined in the next set of bullet points, can be obtained using methods such as negotiation using the SDP[18] offer/answer[21] exchange on the signaling interface with the focus: o Conference ID - Each XCON conference instance has a unique conference identifier. This is obtained from the Conference server and MUST be included in all Floor messages. When using SDP[18] offer/answer[21] exchange to negotiate a Floor control connection with the focus using the signaling interface, the unique conference identifier is contained in the 'confid' SDP attribute, as defined in [20] e.g. a=confid:2874. o User ID - Each user within an XCON conference (as represented by Conference ID) has a unique identifier within that instance. This is obtained from the Conference server and MUST be included in all Floor messages. When using SDP offer/answer exchange to negotiate a Floor control connection with the focus using the signaling interface, the unique conference identifier is contained in the 'userid' SDP attribute, as defined in [20] e.g. a=userid:8937. o Floor ID - A media session with an XCON conferencing server can have any number of 'Floors' (0 or more) that are represented by a unique identifier within the conference instance (as represented by Conference ID). When using SDP offer/answer exchange to negotiate a Floor control connection with the focus using the signaling interface, the unique conference identifier is contained in the 'floorid' SDP attribute, as defined in [20] e.g.a=floorid:1 m-stream:10 . Each 'floorid' attribute, representing a unique floor, has an 'm-stream' tag containing one or more identifiers. The identifiers represent individual SDP media sessions instance (as defined using 'm=' from SDP[18]) using the SDP 'Label' attribute as defined in [19]. 7. Conferencing Operations This section addresses how the scenarios identified in [2] can be realized with the functionality provided by the XCON protocols. The SIP specific mechanisms for some of these operations are described in [3]. [Editor's note: This whole section needs additional work based upon the new agreed model, new terminology and needs to reflect the rework done in the other WG documents. In the end, some XML snippets would also likely be useful.] Barnes, et al. Expires June 24, 2005 [Page 14] Internet-Draft XCON Framework December 2004 7.1 Conference Creation and Deletion When a conference is first initiated via the Call Signaling Interface from a client, the focus uses a template to create the initial conference instance, applying the rules associated with the particular conference. There are several ways in which a conference can be created: ad-hoc using the Call Control Signaling (with default template implicitly) or by CCCP with pointing to a specific template and applying rules to it. TBD more. 7.2 Participant Manipulations Participants manipulate an active conference using Call Control Signaling and/or a CCCP protocol. The Call Control signaling impacts the conference indirectly based on the actions taken by the Focus based upon the signaling (e.g. add a party to the conference). CCCP allows a participant to directly impact the conference state, however the focus still ensures that any manipulations comply with the rules. 7.3 Media Manipulations CCCP can be used to manipulate the media during an active conference. As a result, focus will use signaling interface towards the participants forcing the requested conference state. 7.4 Sidebar Manipulations 7.5 Whispering or Private Messages 7.6 Conference Announcements and Recordings [Editor's note: this needs a lot of revamping based on new model, also taking into consideration Cullen's comments on the previous version of doc ]. 8. Relationships between SIPPING and XCON Frameworks The following diagram is intended to show at a high level the relationship between the fundamental model introduced in [3] and the basic data elements required for supporting the XCON data model. Further detail of the XCON data model is provided in Section 4 of this document. [Editor's note: Insert here a diagram similar to the one in the Barnes, et al. Expires June 24, 2005 [Page 15] Internet-Draft XCON Framework December 2004 powerpoint charts (an updated/modified version of what was presented at IETF-61)] 9. Security Considerations The framework put forth in this draft introduces signaling interfaces which have a variety of potential threats. Each of the specific protocols defined in support of this framework must adequately address those threats. 10. IANA Considerations This is an informational draft, with no IANA considerations required. 11. Acknowledgements This document is the result of XCON working group architectural discussions among Hisham Khartabil, Roni Even, Adam Roach, Alan Johnston, Brian Rosen, Paul Kyzivat, Cullen Jennings, Keith Lantz, Henning Schulzrinne, and the authors. 12. References 12.1 Normative References 12.2 Informative References [1] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", draft-ietf-sipping-conferencing-requirements-01 (work in progress), October 2004. [2] Even, R., "Conferencing Scenarios", draft-ietf-xcon-conference-scenarios-02 (work in progress), July 2004. [3] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-03 (work in progress), October 2004. [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-08 (work in progress), December 2004. [5] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Barnes, et al. Expires June 24, 2005 [Page 16] Internet-Draft XCON Framework December 2004 draft-ietf-sipping-cc-conferencing-06 (work in progress), November 2004. [6] Schulzrinne, H., "Requirements for Floor Control Protocol", draft-ietf-xcon-floor-control-req-02 (work in progress), October 2004. [7] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", draft-ietf-xcon-bfcp-01 (work in progress), October 2004. [8] Koskelainen, P. and H. Khartabil, "Requirements for Conference Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in progress), August 2004. [9] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01 (work in progress), October 2004. [10] Khartabil, H., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usages for Conference Policy Manipulation and Conference Policy Privelges Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress), October 2004. [11] Khartabil, H. and A. Niemi, "Privileges for Manipulating a Conference Policy", draft-ietf-xcon-conference-policy-privileges-01 (work in progress), October 2004. [12] Levin, O. and G. Kimchi, "Centralized Conference Control Protocol (CCCP)", draft-levin-xcon-cccp-00 (work in progress), October 2004. [13] Jennings, C., "Media Mixer Control for XCON", draft-jennings-xcon-media-control-01 (work in progress), July 2004. [14] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", draft-rosen-xcon-conf-sidebars-01 (work in progress), July 2004. [15] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Barnes, et al. Expires June 24, 2005 [Page 17] Internet-Draft XCON Framework December 2004 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [18] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [19] Levin, O. and G. Camarillo, "The SDP (Session Description Protocol) Label Attribute", draft-ietf-mmusic-sdp-media-label-00 (work in progress), September 2004. [20] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), October 2004. [21] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Authors' Addresses Mary Barnes Nortel Networks 2380 Performance Drive Richardson, TX EMail: mary.barnes@nortelnetworks.com Chris Boulton Ubiquity Software Corporation Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA EMail: cboulton@ubiquitysoftware.com Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: oritl@microsoft.com Barnes, et al. Expires June 24, 2005 [Page 18] Internet-Draft XCON Framework December 2004 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 (2004). 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. Barnes, et al. Expires June 24, 2005 [Page 19]