XCON Working Group                                             M. Barnes
Internet-Draft                                                    Nortel
Expires: January 16, April 4, 2006                                        C. Boulton
                                           Ubiquity Software Corporation
                                                                O. Levin
                                                   Microsoft Corporation
                                                           July 15,
                                                                Oct 2005

        A Framework and Data Model for Centralized Conferencing
                      draft-ietf-xcon-framework-01
                      draft-ietf-xcon-framework-02

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 January 16, April 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines the framework for Centralized Conferencing
   (XCON), which is applicable to Conferencing.
   The framework allows participants using different various call
   control signaling protocols
   protocols, such as SIP, H.323, Jabber and exchanging PSTN, to exchange media over networks with
   potentially different characteristics. in
   a centralized unicast conference.  The XCON Centralized Conferencing
   Framework defines
   the XCON data model, the XCON logical entities, the entities and naming conventions, and along with
   a conferencing data model.  The framework also outlines the standard a set of
   conferencing protocols
   (complementary protocols, which are complementary to the call control signalling protocols) signaling
   protocols, for building advanced conferencing applications.  The
   framework binds all the defined components together for the benefit
   of builders of conferencing system
   builders. systems.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions and Terminology  . . .  . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . .  7
   4.  XCON Data Model . . . . . . . . . . . . .  4
   4.  Terminology  . . . . . . . . . .  9
     4.1   Common Conference Information . . . . . . . . . . . . . . 11
     4.2   Conference Template .  7
   5.  Centralized Conferencing Data Model  . . . . . . . . . . . . . 10
     5.1.  Common Conference Information  . . . . . 12
     4.3   Conference policies . . . . . . . . . 11
     5.2.  Conference Template  . . . . . . . . . . 12
   5.  XCON Constructs and Identifiers . . . . . . . . . 12
     5.3.  Conference policies  . . . . . . 13
     5.1   Conference Identifier . . . . . . . . . . . . . 12
   6.  Centralized Conferencing Constructs and Identifiers  . . . . . 13
     5.2
     6.1.  Conference Instance  . Identifier  . . . . . . . . . . . . . . . . . . 13
     5.3
     6.2.  Conference Object  . . . . . . . . . . . . . . . . . . . . 14
       5.3.1 13
       6.2.1.  Conference Object Identifier . . . . . . . . . . . . . 16
     5.4 15
     6.3.  Conference User Identifier . . . . . . . . . . . . . . . . 17
   6. 15
   7.  Conferencing System Realization  . . . . . . . . . . . . . . . 18
     6.1 15
     7.1.  Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 19
     6.2 16
     7.2.  Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 21
     6.3 19
     7.3.  Advanced Example . . . . . . . . . . . . . . . . . . . . . 22
     6.4 20
     7.4.  Scheduling a 'Conference Object for Reservation' conference  . . . . . 24
   7. . . . . . . . . . . . . 22
   8.  Conferencing Mechanisms  . . . . . . . . . . . . . . . . . . . 28
     7.1 25
     8.1.  Call Control Signalling Signaling . . . . . . . . . . . . . . . . . 28
     7.2 . . . . . 25
     8.2.  Notifications  . . . . . . . . . . . . . . . . . . . . . . 28
     7.3 25
     8.3.  Conference Control Protocol  . . . . . . . . . . . . . . . 28
       7.3.1 25
       8.3.1.  CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 29
       7.3.2 26
       8.3.2.  CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 30
       7.3.3 27
       8.3.3.  CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 30
       7.3.4 27
       8.3.4.  NETCONF  . . . . . . . . . . . . . . . . . . . . . . . 30
       7.3.5 28
       8.3.5.  SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 31
     7.4 28
     8.4.  Floor Control  . . . . . . . . . . . . . . . . . . . . . . 31
   8. 28
   9.  Conferencing Scenario Realizations . . . . . . . . . . . . . . 33
     8.1 30
     9.1.  Conference Creation  . . . . . . . . . . . . . . . . . . . 30
     9.2.  Participant Manipulations  . . . . . . . . . . . . . . . . 33
     8.2 32
     9.3.  Media Manipulations  . . . . . . . . . . . . . . . . . . . 35
     8.3 34
     9.4.  Sidebar Manipulations  . . . . . . . . . . . . . . . . . . 36
     8.4 35
     9.5.  Whispering or Private Messages . . . . . . . . . . . . . . 38
     8.5 37
     9.6.  Conference Announcements and Recordings  . . . . . . . . . 38
   9. 37
   10. Relationships between SIPPING and XCON Centralized Conferencing
       Frameworks . . . . . . 38
   10.   Security Considerations . . . . . . . . . . . . . . . . . . 38 . . 37
   11.   IANA Security Considerations  . . . . . . . . . . . . . . . . . . . . 40
   12.   Acknowledgements 38
     11.1. Authorization  . . . . . . . . . . . . . . . . . . . . . . 40
   13.   Open Issues 38
     11.2. Security and Privacy of Identity . . . . . . . . . . . . . 39
     11.3. Floor Control Server Authentication  . . . . . . . . . . . 40
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 40
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 41 . . 40
   14. Changes since last Version . . . . . . . . . . . . . . . . . 41 . 40
   15. Appendix A - Conference Object Identifier  . . . . . . . . . . 44
     15.1. Conference Object URI Definition . . . . . . . . . . . . . 47
   16. Appendix B - Conference User Identifier  . . . . . . . . . . . 47
     16.1. Conference User Definition . . . . . . . . . . . . . . . . 49
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
     15.1 . 49
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 43
     15.2 49
     17.2. Informative References . . . . . . . . . . . . . . . . . . 43 49
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 . . 53
   Intellectual Property and Copyright Statements . . . . . . . . 47 . . 54

1.  Introduction

   This document defines the framework for Centralized Conferencing
   (XCON), which is applicable to Conferencing.
   The framework allows participants using various call
   signalling protocols (such signaling
   protocols, such as SIP, H.323, Jabber, HTML, or PSTN, etc.)
   and exchanging to exchange media over networks with potentially different
   characteristics. in
   a centralized unicast conference.  Other than references to general
   functionality (e.g., establishment and teardown), details of these
   call signaling protocols are outside the scope of this document

   The XCON Centralized Conferencing Framework defines the XCON data model, the XCON logical
   entities, the entities and
   naming conventions, and along with a conferencing data model.  The
   framework also outlines the standard a set of conferencing protocols (complementary protocols, which are
   complementary to the call control signalling
   protocols) signaling protocols, for building advanced
   conferencing applications.

   The
   framework binds all the defined components together for the benefit
   of conferencing system builders.

   The XCON Centralized Conferencing Framework is compatible with the
   functional model presented in the SIPPING Conferencing Framework [9] . [9].
   Section 9 10 of this document discusses the relationship between the XCON
   Centralized Conferencing Framework and the SIPPING Conferencing
   framework, in the context of the XCON
   architecture. Centralized Conferencing model
   presented in this document.

2.  Conventions and Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.

   The XCON Framework document both generalizes, when appropriate,  the
   SIPPING Conferencing Framework [9] terminology and introduces new
   concepts as listed below.

   Active Conference: The term Active Conference refers to

3.  Overview

   A centralized conference is an association of endpoints, called
   conference participants, with a Conference
      Object that's been created (for example, using central endpoint, called a "blueprint") and
      "activated" via the allocation of its identifiers (i.e.
      Conference Object Identifier, Conference Identifier)  and  the
      associated conference
   Focus.
   Call (Control) Signalling:  The protocol used between a participant
      and Focus has direct peer relationships with the participants
   by maintaining a Focus.  In separate call signaling interface with each.
   Consequently, in this context, centralized conferencing model, the term "call" means call
   signaling graph is always a  channel or
      session used for media streams establishment.  Protocol examples
      include, but are star.

   The most basic conference supported in this model would be an ad-hoc
   unmanaged conference, which would not limited to, SIP, H.323, MSRP, Jabber, HTML
      and PSTN signalling.  Other than references to general
      functionality required (e.g. establishment and teardown), details necessarily require any of these protocols are outside the scope of
   functionality defined within this document.

   Common Conference Information: The data type (i.e. framework.  For example, it could
   be supported using basic SIP signaling functionality with a
   participant serving as the XML schema)
      which is used to represent Focus; the fixed information part of a
      Conference Object.  It includes a common set of definitions SIPPING Conferencing Framework
   [9] together with the SIP Call Control Conferencing for User
   Agents[15] documents address these types of scenarios.

   In addition to the basic conference features, such as conference identifiers,
      membership, signalling, capabilities, media, etc.
   Conference Control Protocol (CCP): A protocol used by clients to
      manipulate however, a Conference Object [Section 7.3].
   Conference Factory: A logical entity that, upon request, generates
      unique URI(s) to identify and represent a conference Focus.  The
      Conference Factory is typically used conferencing system
   supporting the centralized conferencing model proposed in this
   framework document can offer richer functionality, by including
   dedicated conferencing applications with explicitly defined
   capabilities, reserved recurring conferences, along with providing
   the conference creation
      process via a signalling interface and non-signalling methods such
      as Conference Control Protocol [Section 7.3] standard protocols for managing and proprietary
      mechanisms.
   Conference Identifier(ID): controlling the different
   attributes of these conferences.

   The core requirements for centralized conferencing are outlined in
   [10].  These requirements are applicable for conferencing systems
   using various call signalling protocol-specific URI
      that uniquely identifies a conference Focus signaling protocols, including SIP.  Additional
   conferencing requirements are provided in [12], [13], and its associated
      Conference Instance.
   Conference Instance: An instantiation of a Conference Object. [14].

   The
      Conferencing System associates a Conference Instance with the
      Conference Identifier(s).  There centralizing conferencing system proposed by this framework is
   built around a one-to-one mapping between a
      Conference Instance and fundamental concept of a conference Focus.
   Conference Object: object.  A
   conference object provides the data representation of a conference at
   during each of the various stages of a certain
      stage (e.g. description upon conference (e.g., creation,
   reservation,
      activation, etc.), which active, completed, etc.).  A conference object is
   accessed via the logical functional elements, with whom a Conferencing System maintains in order
      to describe
   conferencing client interfaces, using the various protocols
   identified in Figure 1.  The functional elements defined for a
   conferencing system capabilities and to provide access to the
      available services provided described by the Conferencing System.  All
      Conference Objects framework are of type 'Conference Object Type' which is
      comprised of two distinct sub components; the 'Common a Conference
      Information'
   Control Server, Floor Control Server, any number of Foci and a
   Notification Service.  A Conference Control Protocol (CCP) provides
   the 'Conference Template' (see definitions in
      this section for details).
   Conference Object Identifier (ID): A [TBD schema name] URI which
      uniquly identifies interface between a Conference Object conference and is being used by a
      Conference media control client and the
   conference control server.  A Binary Floor Control Protocol [Section 7.3].
   Conference policies: A term which is used to collectively refer to (BFCP)
   provides the interface between a
      virtual set of rights, permissions floor control client and  limitations pertaining to
      operations being performed on the floor
   control server.  A call signaling protocol (e.g., SIP, H.323, PSTN,
   etc.) provides the interface between a certain Conference Object.  The
      term is described in more details in Section 4.3.
   Conference State: The state of call signaling client and a Conference Instance as represented
      using
   Focus.  A notification protocol (e.g.  SIP Notify) provides the
   interface between the Conference Package mechanism defined in [11].
   Conferencing System: The term used to refer to a conferencing
      solution (system) that is based on client and the set Notification
   Service.

   A conferencing system can support a subset of specifications and
      is built using the protocols and conferencing
   functions depicted in the data model defined conferencing system logical decomposition
   in Figure 1 and described in this document.  However, there are some
   essential components that would typically be used by most other
   advanced functions, such as the
      XCON working group within the IETF.
   Conference Template: The data type (i.e. Notification Service.  For example,
   the XML schema) which notification service is used to represent the variable information part correlate information, such as
   list of the Conference
      Object.  It can be included in the Conference Object to represent
      enhanced conferencing capabilities (e.g. participants with their media mixers, etc.)
      and/or user interface abstraction.

   Floor: A term which is used to refer to a set of data or resources
      associated with a streams, between the various
   other components.

   ...................................................................
   .  Conferencing System                                            .
   .                                                                 .
   .        +-----------------------------------------------------+  .
   .        |       C o  n  f  e  r  e n  c  e   o b  j  e  c  t  |  .
   .      +-+---------------------------------------------------+ |  .
   .      |       C o n f e r e n c e   o b j e c t             | |  .
   .    +-+---------------------------------------------------+ | |  .
   .    |       C o n f e r e n c e   o b j e c t             | | |  .
   .    |                                                     | | |  .
   .    |                                                     | |-+  .
   .    |                                                     |-+    .
   .    +-----------------------------------------------------+      .
   .              ^                  ^             ^        |        .
   .              |                  |             |        |        .
   .              v                  v             v        v        .
   .  +-------------------+ +--------------+ +-------+ +------------+.
   .  | Conference Instance, for which a conference
      participant (or group of participants) is granted temporary input
      access.
   Floor Chair: A Control| | 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 Control| |Foci   | |Notification|.
   .  | Server            | | Server       | |       | |Service     |.
   .  +-------------------+ +--------------+ +-------+ +------------+.
   .             ^                 ^           ^          |          .
   ..............|.................|...........|..........|...........
                 |                 |           |          |
                 |Conference       |Binary     |Call      |Notification
                 |Control          |Floor      |Signaling |Protocol
                 |Protocol         |Control    |Protocol  |
                 |                 |Protocol   |          |
                 |                 |           |          |
   ..............|.................|...........|..........|...........
   .             V                 V           V          V          .
   .  +----------------+  +------------+  +----------+ +------------+.
   .  | Conference
      Instance.
   Focus: Focus is a logical entity that maintains the call signalling
      interface between each participating client (i.e. participant)     |  | Floor      |  | Call     | |Notification|.
   .  | and
      the Conference Instance.  As such, the Focus acts as an endpoint
      for each of the supported signalling protocols and is responsible
      for all primary conference membership operations (e.g. join,
      leave, update the Conference Instance) and for Media      |  | Control    |  | Signaling| | Client     |.
   .  | Control        |  | Client     |  | Client   | |            |.
   .  | Client         |  |            |  |          | |            |.
   .  +----------------+  +------------+  +----------+ +------------+.
   .                                                                 .
   . Conferencing Client                                             .
   ...................................................................

   Figure 1: Conferencing System Logical Decomposition.

   The media negotiation/
      maintenance between graph of a conference participant can be centralized, decentralized, or
   any combination of both and potentially differ per media type.  In
   the Focus.  There
      is a one-to-one mapping centralized case, the media sessions are established between a
   media mixer controlled by the Focus focus and its Conference
      Instance.  Focus is addressed by explicitly associated unique
      conference URIs for each signalling protocol, supported for its
      Conference Instance.
   Media Graph: The logical representation one of the flow of participants.
   In the decentralized (i.e., distributed) case, the media for graph is a
      conference.
   Media Mixer: A logical entity that has
   multicast or multi-unicast mesh among the capability to combine
      media inputs of participants.
   Consequently, the same type (or/and transcode media processing (e.g., mixing) can be controlled
   either by the media) and
      distribute focus alone or by the result(s) participants.  The concepts in
   this framework document clearly map to a single or multiple outputs.  In this
      context, centralized media model.
   The concepts can also apply to the term "media" means any type of data being delivered
      over decentralized media case, however,
   the network using appropriate transport means, details of such as RTP/
      RTCP (defined in RFC 3550[7]), Message Session Relay Protocol
      (defined in [25]), etc.
   Registered Conference Document : An official standards are left for future study.

   Section 5 of this document (RFC)
      that defines and registers a Conference Template schema with provides more details on the
      appropriate standards body (IANA).  A 'Registered Conference
      Document' also includes any complimentary textual information in
      relation conference
   object.  Section 6 provides an overview of the identifiers necessary
   to address and manage the conference template schema objects, instances and its meaning.
   Role: Represents differing membership categories that a conference
      participant can assume within a conference.  Each category has users
   associated with a
      difference set conferencing system.  Section 7 of conference operations that this document
   describes how a participant can
      perform.  A default (e.g.  Standard Conference Participant) 'Role'
      will always exist which conferencing system is logically built using the
   defined data model and how the conference objects are maintained.
   Section 8 describes the fundamental conferencing mechanisms and
   provides a standard user with a set high level overview of
      basic the protocols.  Section 9 then
   provides realizations of various conferencing scenarios, detailing
   the manipulation of the conference operations.  Any user with appropriate
      authentication objects using the defined
   protocols.  Section 10 of this document summarizes the relationship
   between this Centralized Conferencing Framework and authorization may assume a role that has a
      wider set the SIPPING
   Conferencing Framework.

4.  Terminology

   This Centralized Conferencing Framework document generalizes, when
   appropriate, the SIPPING Conferencing Framework [9] terminology and
   introduces new concepts, as listed below.  Further details and
   clarification of conference operations that the new terms and concepts are otherwise not
      available (to provided in the
   subsequent sections of this document.

   Active conference: The term active conference refers to a standard Conference Participant) - e.g.  A 'Role'
      called 'Conference Moderator' may exist conference
      cbject that has additional been created and activated via the allocation of
      its identifiers (e.g., conference operations such as 'modify object identifier and conference end time'.

   Sidebar: TBD.
   Whisper: TBD.

3.  Overview

   A centralized
      identifier) and the associated focus.  An active conference is an association of endpoints (called
   conference participants) with a central endpoint (called
      created based on either a system default conference
   Focus) where the Focus has direct peer-wise relationships with the
   participants by maintaining blueprint or a separate
      specific conference reservation.
   Call Signaling protocol: The call control signalling
   interface with each.  Consequently, in signaling protocol is used between
      a participant and a focus.  In this tightly coupled model, context, the call control signalling graph is always term "call" means
      a star. channel or session used for media streams.
   Common conference information: The most basic common conference supported would be an ad-hoc unmanaged
   conference, which would not necessarily require any of the
   functionality defined within this framework.  For example, it could
   be supported using basic SIP signalling functionality with a
   participant serving as the Focus; information is
      the SIPPING Conferencing Framework
   [9] together with data type (i.e., the SIP Call Control Conferencing for User
   Agents[15] documents address these types of scenarios.

   An XCON-compliant Conferencing System, in addition XML schema) which is used to represent
      the basic
   features, can offer richer functionality including dedicated
   conferencing applications with explicitly defined capabilities,
   reserved reoccurring conferences, and the standard protocols core set of information for
   managing and controlling different a conference aspects.

   The object.  This core requirements
      information includes a common set of definitions for tightly managed centralized conferencing
   are outlined in [10].  These requirements are basic
      conference features, such as conference identifiers, membership,
      signaling, capabilities and media types, applicable for
   conferencing systems using various call control signalling protocols,
   not restricted to SIP alone.  Additional conferencing requirements
   are provided in [12], [13], and [14].

   The XCON architecture is built around a fundamental concept wide
      range of a conferencing applications.

   Conference Object. blueprint: A Conference Object conference blueprint is a logical representation
   of a Conference Instance.  For static conference creation, a Conference
   Object provides
      object within a "blueprint" representing conferencing system, which describes a typical
      conference setting supported by the System Capabilities. system.  A conference object also provides
      blueprint is the logical representation basis for creation of a dynamic conference during objects.
      A system may maintain multiple blueprints, each comprised of the various stages
      common conference information, along with any number of a templates.
   Conference control protocol (CCP): A conference (e.g.
   reservation, active, completed, etc.). control protocol
      provides the interface for data manipulation and state retrieval
      for the centralized conferencing data, represented by the
      conference object.
   Conference factory: A conference factory is a logical entity, that
      generates upon request, unique URI(s) to identify and represent a
      conference focus.
   Conference Object identifier (ID): A conference identifier is
   accessible using XCON protocols (e.g. a call
      signaling protocol-specific URI that identifies a conference focus
      and its associated conference instance.
   Conference Control Protocol
   [Section 7.3]. instance: A Conferencing System can support any subset conference instance refers to an internal
      implementation of a specific conference, represented as a set of the conferencing
   functions depicted in the Conferencing System
      logical decomposition
   in Figure 1 conference objects and described associated identifiers.
   Conference object: A conference object represents a conference at a
      certain stage (e.g., description upon conference creation,
      reservation, activation, etc.), which a conferencing system
      maintains in this document.  Nevertheless, typically
   advanced functions could not be implemented without implementing
   others.  For example, order to describe the Notification Service is an essential
   component required for implementing almost any advanced functionality system capabilities and being used, among other things, to
      provide access to the services available for correlation of information
   (such as list each object
      independently.  The conference object schema is comprised of participants with their media streams) between
   otherwise two
      distinct functions.

   ......................................................................
   .  Conferencing System                                               .
   .                                                                    .
   .        +-----------------------------------------------------+     .
   .        |       C O N F E R E N C E   O B J E C T             |     .
   .      +-+---------------------------------------------------+ |     .
   .      |       C O N F E R E N C E   O B J E C T             | |     .
   .    +-+---------------------------------------------------+ | |     .
   .    |       C O N F E R E N C E   O B J E C T             | | |     .
   .    |                                                     | | |     .
   .    |                                                     | |-+     .
   .    |                                                     |-+       .
   .    +-----------------------------------------------------+         .
   .              ^                  ^             ^        |           .
   .              |                  |             |        |           .
   .              v                  v             v        v           .
   .    +-------------------+ +--------------+ +-------+ +------------+ .
   .    | Conference Control| | Floor Control| |Foci   | |Notification| .
   .    | Server            | | Server       | |       | |Service     | .
   .    +-------------------+ +--------------+ +-------+ +------------+ .
   .               ^                 ^           ^          |           .
   ................|.................|...........|..........|............
                   |                 |           |          |
                   |Conference       |BFCP       |SIP/      |SIP NOTIFY/
                   |Control          |           |PSTN/     |Etc.
                   |Protocol         |           |H.323/    |
                   |                 |           |T.120/    |
                   |                 |           |Etc.      |
   ................|.................|...........|..........|............
   .               V                 V           V          V           .
   .    +----------------+  +------------+  +----------+ +------------+ .
   .    | Conference     |  | Floor      |  | Call     | |Notification| .
   .    | Control        |  | Control    |  | Control  | | Client     | .
   .    | Client         |  | Client     |  | Client   | |            | .
   .    +----------------+  +------------+  +----------+ +------------+ .
   .                                                                    .
   .  Conferencing Client                                               .
   ......................................................................

           Figure 1: Conferencing System Logical Decomposition.

   The media graph of a sub components; the common conference can be centralized, de-centralized,
   or any combination of both information and potentially differ per media type.  In the centralized case, the media sessions are established between
      conference template(s).
   Conference object identifier (ID): A conference object identifier is
      a
   media mixer controlled by the focus URI which uniquely identifies a conference object and each one of the participants.
   In the de-centralized (i.e. distributed) case, the media graph is a
   (multicast or multi-unicast) mesh among the participants.
   Consequently, the media processing (e.g. mixing) can be controlled
   either by the focus alone or used by the participants.  The concepts in
   this framework document clearly map to
      a centralized media model.
   The concepts can also apply conference control protocol to access and modify the de-centralized media case,
   however, the details of such are left for future study by the XCON WG
   charter.

   Section 4 of this document provides more details on the conference
      information.
   Conference
   Object.  Section 5  provides an overview of the identifiers necessary policies: Conference policies collectively refers to address a set
      of rights, permissions and manage the limitations pertaining to operations
      being performed on a certain conference object.
   Conference Objects, Instances and Users
   associated with reservation: A conference reservation is a Conferencing System.  Section 6 conference
      object, which is created from either a system default or client
      selected blueprint.
   Conference state: The conference state reflects the state of this document
   describes how a Conferencing System
      conference instance and is logically built represented using the a specific, well-
      defined schema.
   Conferencing system: Conferencing system refers to a conferencing
      solution based on the data model discussed in this framework
      document and how built using the protocol specifications referenced in
      this framework document.

   Conference Objects are maintained.
   Section 7 describes template: The conference template refers to the fundamental conferencing mechanisms and
   provides a high level overview of data type
      (i.e. the XCON protocols.  Section 8 then
   provides realizations of various conferencing scenarios, detailing XML schema) which is used to represent the manipulation media or
      application specific part of the Conference Objects using XCON defined
   protocols.  Section 9 conference object.  This
      information represents enhanced conferencing features or
      capabilities, such as media mixers, and/or user interface
      abstractions.
   Floor: Floor refers to a set of this document summarizes the relationship
   between the XCON Framework and the SIPPING Conferencing Framework.

4.  XCON Data Model

   The XCON data model defined in this framework has no strict
   separation between conference membership, or resources associated with a
      conference media
   information and the related policies (i.e. the capabilities and
   limitations instance, for each).  This approach meets the requirement in many which a conference participant, or group
      of participants, is granted temporary access.
   Floor chair: A floor chair is a floor control operations protocol compliant
      client, either a human participant or automated entity, who is
      authorized to enable synchronized manage access to one floor and can grant, deny or
      revoke access.  The floor chair does not have to be a participant
      in the conference policies as instance.
   Focus: A focus is a whole, to logical entity that maintains the call signalling
      interface with each participating client and the conference state object
      representing the active state.  As such, the focus acts as a whole,
   and an
      endpoint for receiving notifications about changes to either.

   A Conference Object is each of type 'Conference Object Type' which the supported signaling protocols and is
   comprised of two distinct components:
      responsible for all primary conference membership operations
      (e.g., join, leave, update the 'Common Conference
   Information Type' conference instance) and for media
      negotiation/maintenance between a conference participant and the 'Conference Template Type', as illustrated
   in Figure 2.  Each of these types
      focus.
   Media graph: The media graph is the logical representation of the
      flow of media for a placeholder conference.
   Media mixer: A media mixer is the logical entity with the capability
      to combine media inputs of the same type, transcode the media and
      distribute the result(s) to a single or multiple outputs.  In this
      context, the term "media" means any type of data being delivered
      over the network using appropriate transport means, such as RTP/
      RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol
      (defined in [25]).
   Registered conference document : A standards track document (i.e.,
      RFC) that defines and registers a conference template schema with
      the appropriate organization (e.g., IANA).  A registered
      conference document also includes any complementary textual
      information.
   Role: A role provides the context for the set of conference
      operations that a participant can perform.  A default role (e.g.,
      standard conference participant) will always exist, providing a
      user with a set of basic conference operations.  Based on system
      specific authentication and authorization, a user may take on
      alternate roles, such as conference moderator, allowing access to
      a wider set of conference operations.
   Sidebar: TBD.

   Whisper: TBD.

5.  Centralized Conferencing Data Model

   The centralized conference data model is logically represented by the
   conference object.  A conference object is of type 'Conference object
   type', which is comprised of two distinct components: the 'Common
   conference information type' and the 'Conference template type', as
   illustrated in Figure 2.  Each of these types is extensible for
   including potentially multiple sub-types.

   +------------------------------------------------------+
   | C O N F E R E N C E   O B J E C T   T Y P E o n f e r e n c e   o b j e c t   t y p e          |
   |                                                      |
   | +--------------------------------------------------+ |
   | | COMMON CONFERENCE INFORMATION TYPE Common conference information type               | |
   | |                                                  | |
   | | +----------------------------------------------+ | |
   | | | Conference Description description  (times, duration)    | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Membership (Roles, Capacity, Names) (roles, capacity, names)          | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Signaling (Protocol, Direction, Status) (protocol, direction, status)      | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Floor Information information                            | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Sidebars, Etc.                               | | |
   | | +----------------------------------------------+ | |
   | |                                                  | |
   | +--------------------------------------------------+ |
   | +--------------------------------------------------+ |
   | | CONFERENCE TEMPLATE TYPE Conference template type                         | |
   | |                                                  | |
   | |   - Mixer algorithm, inputs, and outputs         | |
   | |   - Floor controls                               | |
   | |   - User Control Interface                       | |
   | |   - User's View                                  | |
   | |   - Etc.                                         | |
   | +--------------------------------------------------+ |
   |                                                      |
   +------------------------------------------------------+
   Figure 2: Conference Object Type Decomposition.

   Since, in an XCON-compliant

   In a system the same Conference Object Type based on this conferencing framework, the same conference
   object type is used for representation of a conference for during
   different purposes, stages of a conference, such as expressing Conferencing System conferencing
   system capabilities, reserving conferencing resources or reflecting
   the state of ongoing
   conferences, conferences.  Thus, each of the two components
   (i.e., the Common Conference
   Information common conference information and the Conference Template) is syntactically optional to conference template)
   may be optionally included in a particular Conference Object. conference object.
   Section 6 7 describes the usage semantics of the Conference Objects.

   [Editor's Note: conference objects.

   The centralized conferencing data model defined in this framework has
   no strict separation between conference membership, conference media
   information and the related policies.  The policies are an integral
   part of the data model and are realized by local, system level
   boundaries associated with specific data elements, such as the
   membership, and by the ranges and limitations on other data elements.
   Additional policy considerations for a system realization based on
   this data model are discussed in Section 5.3.  The integration of the
   data in this model meets the requirement of many conference control
   operations to enable synchronized access to the integral conference
   policies, to the conference state as a whole, and for receiving
   notifications about changes to either using the same interface.

   The exact XML schema of the Conference Object (i.e. Object, including the
   organization of the Common Conference Information and the Conference Template) is an open issue (Discussion Point 4 on the
   mailing list), which has been summarized as the three potential
   alternatives below:

   1.
   Templates, are detailed in separate documents [ref: TBD].

5.1.  Common Conference Information

   The top-level common conference information is the template section, and it section contains a subsection the core
   information that is utilized in any conference and is independent of
   the common specific conference information.
   This has media nature (e.g., the advantage that mixing algorithms
   performed, the schema can all be well defined:
   because advanced floor control applied, etc.).  Typically,
   participants with read-only access to the conference information
   would be interested in this common conference information is known at the time the
   template is developed, the appropriate schema definition can only.

   The common conference information may be
   inserted into represented using the template schema.
   conference-type as defined in [11].  The downside is that this setup
   requires navigation conference-type contains the
   definitions for representation of the template information to get conference object capabilities,
   membership, roles, call signaling and media status relevant to
   different stages of the common
   information, which is likely conference life-cycle.

   New centralized conferencing specifications can extend the basic
   conference-type and introduce additional data elements to be manipulated most frequently.

   2.  The top-level information is used
   within the common conference information,
   which contains the information type.

5.2.  Conference Template

   The concept of a conference template information.  This has the advantage that
   clients don't even need is introduced to care about separate the template being used to
   allow rendering
   complexity and control over basic conference functionality(which
   will suffice for many clients (e.g. those with limited screen).  The
   downside is that the common conference information schema must
   include an extension point to allow new templates to hook into details of the
   schema.  This may make schema validation more difficult.

   3.  The template information "mixer" and other enhanced
   conferencing features from the common conference information are
   conveyed as two separate objects (e.g. using multipart MIME).  This
   provides the benefits of allowing completely separate schema,
   straightforward schema validation, and easy access to the common
   allow for easy user interface abstraction for advanced conferencing
   systems.

   Each conference information. template needs to be registered with IANA.  The downside is that any mechanism for
   separating the schema is going IANA
   registration needs to add some amount point to an RFC having the text description of protocol
   complexity
   the feature behavior and the need for synchronization between XML definition allowing the two data
   objects.  Note that it has been argued that it is increasingly
   difficult feature
   presentation, configuration, and management.  The RFCs defining these
   templates are referred to find as a potential client of the XCON protocols that
   doesn't already support multipart MIME).

   The model put forth in this document is the result of the consensus
   reached during the XCON second interim meeting in Boston and depicts
   option 2 above.  With slight adaptations it can also support option
   3. ]

4.1  Common Conference Information

   The common conference information section contains the core
   information that is utilized in any conference and can be abstracted
   regardless of the specific conference media nature (e.g. the mixing
   algorithms performed, the advanced floor control applied, etc.).
   Typically, participants with read-only access to the conference
   information would be interested in this common information only.

   The basic common conference information can be represented using the
   conference-info-type schema as defined in [11].  This schema contains
   the definitions for representation of the Conference Object
   capabilities, membership, roles, call control signalling and media
   statuses relevant to different stages of the conference life-cycle.

   New XCON specifications can extend the basic conference-info-type and
   introduce additional schemas to be used within the common conference
   information type placeholder.

4.2  Conference Template

   The concept of a "Conference Template" is introduced to abstract the
   complexity and the details of the "mixer" and other conferencing
   features and to allow for easy user interface abstraction for
   advanced Conferencing Systems.

   Each Conference Template needs to be registered with IANA.  The IANA
   registration needs to point to an RFC having the text description of
   the feature behavior and optionally the XML definition allowing the
   feature presentation, configuration, and management.  RFCs of this
   kind are referred by XCON documents as a "Registered Conference
   Document". conference document.

   Typically, a conference template would contain the information about
   the specific media mixing details, the associated client roles and
   the available floor controls.  This information would allow
   authorized clients to manipulate the mixer's behavior via the focus,
   and the resultant distribution of the media to all or individual
   participants.  By doing so, a client can change its own state and/or
   state of other participants in the conference.

   A conference template can also include an abstract user interface
   definition in terms of sliders, radio boxes, etc. for simplifying
   user interaction with a specific non-trivial feature.

4.3

5.3.  Conference policies

   Conference policies is the term used to collectively refer refers to a
   virtual set of rights,
   permissions and limitations pertaining to operations being performed
   on a certain Conference Object. conference object.

   The virtual set of rights describes the read/write access privileges for the Conference Object
   conference object as a whole.  This access would usually be granted
   and defined in terms of giving the read-only or read-write access to
   clients with certain roles in the conference.  For details
   see [TBD].  As such, the policies
   represented by the set of rights aren't explicitly defined within the
   data model, but rather are reflected in the system realization
   (Section 7).

   The permissions and limits limits, however, are specified as an integral
   part of the
   Conference Object Type, conference object type, with data objects containing the
   allowed ranges for other data objects (e.g. (e.g., maximum number of
   participants) and lists of clients allowed to perform certain
   operations on a conference object.  For example, the "allowed to
   join" list of participants is consulted to decide who is allowed to
   join.  The entries in the list can specify the identity of an
   individual user (joe@example.com), a role, a domain (*@example.com),
   etc.  For
   details see [TBD]. further details, refer to the detailed data model [ref:
   TBD].

   A more general rule mechanism, beyond the functionality provided by
   the permissions and limits, is an item for future study for the XCON
   WG.

5.  XCON study.

6.  Centralized Conferencing Constructs and Identifiers

   This section provides details of the identifiers associated with the
   XCON
   centralized conferencing framework constructs (e.g.  Conference Object and Conference Instance) and the identifiers
   necessary to address and manage the clients associated with a Conferencing System.
   conferencing system.  An overview of the allocation, characteristics
   and functional role of the identifiers is provided.

5.1

6.1.  Conference Identifier

   The Conference Identifier (ID) conference identifier (conference ID) is the a call signalling protocol-
   specific signaling
   protocol-specific URI that uniquely identifies a Conference Instance specific conference focus and a
   its associated conference Focus.  The Conference Factory instance.  A conference factory is the logical entity that
   generates the one
   method for generating a unique Conference ID conference ID, to identify and represent address
   a conference Focus.  The Conference Factory is typically used focus, using a call signaling interface.  Details on the
   use of a conference factory for SIP signaling can be found in [15].
   The conference identifier can also be obtained using the conference creation process via a signalling interface and non-
   signalling methods such as Conference Control Protocol
   control protocol [Section 7.3]
   and proprietary 8.3] or other, including proprietary, out-
   of-band mechanisms.

5.2

6.2.  Conference Instance Object

   A Conference Instance is an internal implementation construct object provides the logical representation of a
   conference, which is accessible by call signalling means, thus no
   explicit identifier is required.  Note that
   conference iInstance in a Conference Instance can
   have more than certain stage, such as a single Conference Identifier, for example, for each
   call signalling protocol supported.  There is conference
   blueprint representing a one-to-one mapping
   between conferencing system's capabilities, the data
   representing a Conference Instance conference reservation, and a the conference Focus.  The Focus state
   during an active conference.  Each conference object is
   addressed by explicitly associating unique Conference IDs for each
   signalling independently
   addressable through the conference control protocol supported by its Conference Instance.

   A single Conference Instance can be internally mapped to a single or
   multiple Conference Objects; each of them accessible by a Call
   Control protocol.

5.3  Conference Object

   A Conference Object is the logical representation of a Conference
   Instance at a certain stage, such as a "blueprint" representing a
   Conferencing System's capabilities, the data representing a reserved
   or scheduled conference, or  the conference state during an active
   conference.  The Conferencing System exposes this data as separate
   objects to allow independent access.  Consequently, the XCON
   specifications allow the association of multiple Conference Objects
   with a single Conference Instance. interface
   [Section 8.3].

   Figure 3 illustrates the relationships between the Conference
   Identifier, conference
   identifier, the Focus focus and the Conference Object Identifier conference object ID within the context
   of a logical Conference Instance, conference instance, with the Conference Object conference object
   corresponding to an ongoing active conference.

   A conference (i.e. object representing a conference in the active state).  The Conference Object is identified by a single or a
   set of state can
   have multiple call signaling Conference Identifiers, with signalling conference identifiers; for example,
   for each call signalling protocol supported.  There is a one-to-one
   mapping, as shown in the figure.
   mapping between an active conference object and a conference focus.
   The Conference Objects corresponding to additional focus is addressed by explicitly associating unique conference stages
   are  addressing using  CCP [Section 7.3].  CCP will define the
   necessary logical naming conventions
   IDs for addressing additional
   Conference Objects, within the context of each signaling protocol supported by the cloning tree concept
   introduced in Section 6. active conference
   object.

      ......................................................................
      .  Conference Instance                                               .
      .                                                                    .
      .                                                                    .
      .        +---------------------------------------------------+       .
      .        |       Conference Object Identifier                |       .
      .        |                                                   |       .
      .        |                                                   |       .
      .        +---------------------------------------------------+       .
      .                           ^                            ^           .
      .                           |                            |           .
      .                           v                            |           .
      .   ...................................................  |           .
      .   . Focus                                           .  |           .
      .   .                                                 .  |           .
      .   .           +----------------------------------+  .  |           .
      .   .           |Conference Identifier (Protocol Y)|  .  |           .
      .   .       +------------------------------------+ |  .  |           .
      .   .       |  Conference Identifier (PSTN)      | |  .  |           .
      .   .   +--------------------------------------+ |-+  .  |           .
      .   .   |     Conference Identifier (SIP)      | |^   .  |           .
      .   .   |                                      |-+|   .  |           .
      .   .   |                                      |^ |   .  |           .
      .   .   +--------------------------------------+| |   .  |           .
      .   ............^...............................|.|....  |           .
      .               |                               | |      |           .
      ................|...............................|.|......|............
                      |                               | |      |
                      |SIP                            | |      |Conference
                      |                          PSTN | |Y     |Control
                      |                               | |      |Protocol
                      |               +---------------+ |      |
                      |               |                 |      |
                      |               |                 |      |
                      v               v                 v      v
           +----------------+  +--------------+  +---------------+
           | Conferencing   |  | Conferencing |  | Conference    |
           | Client         |  | Client       |  | Client        |
           | 1              |  | 2            |  | X             |
           +----------------+  +--------------+  +---------------+

   Figure 3: Conference Identifer, Focus, Conference Instance and
                Conference Object Identifier Relationships.

5.3.1 Relationships for an Active Conference.

6.2.1.  Conference Object Identifier

   In order to make each Conference Object conference object externally accessible, the
   Conferencing System
   conferencing system allocates a unique URI per distinct Conference
   Object conference
   object in the system, as defined in [ref:TBD]. system.  A Conference Control
   Protocol [as outlined in Section 7.3] can then be used conference control protocol includes the
   conference object identifier in requests for directly manipulating a
   particular Conference Object conference object and for obtaining its current state.
   The Conference Object URI acts as a top level conference object identifier for an
   'umbrella style' construct within logically maps to other protocol
   specific identifiers associated with the Conference System for conference instance, such as
   the
   purpose of identifying incoming connections for complimentary XCON
   protocols (e.g.  BFCP).  This implicit binding provides a structured
   mapping BFCP 'confid'.  A full description and semantics of the various XCON protocols with the associated Conference
   Object Identifier.  As an example, Figure 4 illustrates how BFCP
   connections fall under the general Conference Object
   conference object identifier
   umbrella.

                                   +--------------+
                                   |  Conference  |
                                   |    Object    |
                                   |  Identifier  |
                                   +--------------+
                                          |
                                          |
                                          |
                                  +-------+-------+
                                  | BFCP 'confid' |
                                  +-------+-------+
                                          |
                                          |
                          +---------------+---------------+
                          |                               |
                  +-------+-------+               +-------+-------+
                  |BFCP 'floorid' |               |BFCP 'floorid' |
                  +-------+-------+               +-------+-------+

                   Figure 4: Conference Object Mapping.

   In Figure 4, the is created and used is defined in
   Section 15.

6.3.  Conference Object User Identifier acts as the top level
   key in the identification process.

   Each user within a conferencing system is allocated a unique
   conference user identifier.  The BFCP protocol, as defined user identifier is used in
   [24], defines
   association with the 'conf-id' conference object identifier which represents to uniquely
   identify a conference
   instance user within Floor Control.  BFCP also defines the 'floorid'
   identifier scope of conferencing system.  There is
   also a requirement for specific floors within identifying conferencing system users who may
   not be participating in a Conference conference instance.  When
   created within the Conference System, the 'conf-id' has  Examples of these
   users would be a 1:1 mapping non participating 'Floor Control Chair' or 'Media
   Policy Controller'.  The conference user identifier is required in
   conference control protocol requests to the unique XCON Conference Object Identifier.  Using the BFCP
   example, the Conference System uniquely determine who is able to map the floor request to
   the associated Conference Object.

   This umbrella style association
   issuing commands, so that appropriate policies can be applied to any supplementary
   mechanisms that are applied to the XCON model defined in this
   document as long as a unique reference per
   requested command.  The conference instance user identifer is
   available that can be mapped to a Conference Object.

   [Editor's Note: The URI schema name per TBD must be registered logically
   associated with
   IANA.]

5.4  Conference User Identifier

   Section 5.3.1 discusses the concept of an umbrella mechanism for
   associating various protocol other user identifiers with a top level XCON
   identifier.  This section outlines a similar umbrella mechanism for assigned to the purpose of correlating users of supplementary XCON protocols
   under one universal XCON identity within
   conferencing client for other protocol interfaces, such as an XCON Conference System.

   It
   authenticated SIP user.  A full description and semantics of the
   conference user identifier is important provided in Section 16

7.  Conferencing System Realization

   Implementations based on this centralized conferencing framework can
   range from systems supporting ad-hoc conferences, with default
   behavior only, to emphasize that sophisticated systems with the Conference User Identifier ability to schedule
   recurring conferences, each with distinct characteristics, being described must be in
   integrated with external resource reservation tools, and providing
   snapshots of the context conference information at any of the Conference System.
   This stages of the
   conference life-cycle.

   A conference object is due to the requirement for identity logical representation of Conference System
   users who may not be participating in a Conference Instance.
   Examples being conference
   instance at a non participating 'Floor Control Chair' or 'Media
   Policy' Controller.  Users can then be associated with Conference
   Objects certain stage, such as defined in Section 5.3.1.  This association enables the
   Conference System to associate and enforce user level policies at
   both capabilities description upon
   conference creation, reservation, activation, etc., which a
   conferencing system level maintains in order to describe the system
   capabilities and Conference Object level.

   Each user within a Conference System is allocated a unique Conference
   User Identifier, to provide access to the available services provided
   by the conferencing system.  Consequently, this centralized
   conferencing framework does not mandate the actual usage of the
   conference object, but rather defines the general cloning tree
   concept and the mechanisms required for its realization, as defined described
   in [TBD].  This identifier acts as a top
   level identifier, detail in a similar fashion to that defined for Section 7.1.

   Adhoc and advanced conferencing examples are provided in Section 7.2
   and Section 7.3, with the latter providing additional description of
   the Conference Object Identifier described in terms of the stages of a conference, to
   support scheduled and other advanced conference capabilities.  The
   scheduling of a conference based on these concepts and mechanisms is
   then detailed in Section 5.3.1.  User
   identifiers defined 7.4

   As discussed in other protocols that Section 5.3, there are used within a
   Conference Instance fall underneath the top level identifier conference policies implicit
   in and
   enable derivable from the Conference System to correlate data in the conference objects and map authentication
   under there
   are also policies applying to the single user umbrella.

   Figure 5 illustrates an example using conference objects as a whole.  In
   the Conference User Identifier examples in association this section, these latter policies are shown
   logically associated with the user identity defined for BFCP and SIP Digest
   user identity conference objects, however, it is an
   implementation specific mechansim as defined in RFC3261[4]
                                  +---------------+
                                  |  Conference   |
                                  |     User      |
                                  |   Identifier  |
                                  +-------+-------+
                                          |
                                          |
                                          |
                          +---------------+---------------+
                          |                               |
                  +-------+-------+               +-------+-------+
                  |     BFCP      |               |   SIP Digest  |
                  |   'UserID'    |               |    Username   |
                  +---------------+               +-------+-------+

                   Figure 5: Conference Object Mapping.

   Within a Conference System, a user is identified by a single
   Conference User Identifier.  Any other XCON mechanisms that contain a
   protocol specific user ID can be associated with the 'Conference User
   Identifier', as illustrated in Figure 5.  This mechanism allows
   conference systems to manage how these policies are
   managed and relate system wide user identities
   in relation applied to specific Conference Objects and helps the conference objects.

7.1.  Cloning Tree

   The concept defined in this section is a logical representation only,
   as it is reflected through the
   enforcement of centralized conferencing mechanisms:
   the URIs and the protocols.  Of course, the actual system wide policies.

6.  Conferencing System Realization

   XCON-compliant implementations realization
   can range differ from systems supporting ad-
   hoc conferences, with default behavior only, to sophisticated systems
   with the ability presented model.  The intent is to schedule re-occurring conferences (each with
   distinct characteristics), being integrated with external resource
   reservation tools, and providing snapshots of illustrate the conference
   information at any
   role of the stages of logical elements in providing an interface to the conference life-cycle.

   A Conference Object is data,
   based on conferencing system and conferencing client actions, and
   describe the logical representation of resultant protocol implications

   Any conference object in a Conference
   Instance at conferencing system is created by either
   being explicitly cloned from an existing parent object or being
   implicitly cloned from a certain stage, such as capabilities description upon default system conference creation, reservation, activation, etc., which blueprint.  A
   conference blueprint is a
   Conferencing System maintains in order static conference object used to describe a
   typical conference setting supported by the system.  Each system
   capabilities and to provide access to the available services provided
   by the Conferencing System.

   Consequently, the XCON specifications don't mandate the actual usage
   of the Conference Object, but rather defines the general cloning tree
   concept and the mechanisms required for its realization, which is
   described in detail in Section 6.1.

   Adhoc and advanced can
   maintain multiple blueprints, typically each describing a different
   conferencing examples are provided in Section 6.2
   and Section 6.3, with the latter providing additional description of
   the Conference Object in terms of type using the stages of a conference,  to
   support scheduled and other advanced conference capabilites.

   The scheduling of a common conference based on these concepts and mechanisms
   is then detailed  in Section 6.4

6.1  Cloning Tree

   The concept defined in this section is a logical representation only,
   as it is reflected through the XCON mechanisms: the URIs and the
   protocols.  Of course, the actual system realization can differ from
   the presented model and doesn't require physical copying information format,
   along with any number of the
   information, etc.

   Any Conference Object in a Conferencing System is created by either
   being explicitly cloned from an existing parent object or being
   implicitly cloned from a default system object. template definitions This document uses the
   "cloning" metaphor instead of the "inheritance" metaphor because it
   more closely fits the idea of object replication and extension concept, replication, rather than a data
   type re-usage and extension concept.

   The cloning operation needs to specify whether the link between the
   parent and the child needs to be maintained in the system or not.  If
   no link between the parent and the child exists, the objects become
   independent and are not impacted by any operations on the parent
   object nor subject to any limitations of the parent object.

   By default, all the data existing in the parent object is copied to
   the newly created object.

   Once the new object is created, it can be addressed by a unique
   Conference Object
   conference object URI assigned by the system, as described in
   Section 5.3.1 15 /[ref:TBD].  By default, the newly created object contains
   all the data existing in the parent object.  The newly created object
   can expand the data it contains, within the schema types supported by
   the parent.  It can also restrict the read/write access to its
   objects.  However, unless the object is independent, it cannot relax
   the access relative to its parent's access.

   Any piece of data in the child object can be independently accessed
   and, by default, can be independently modified without affecting the
   parent data.

   Unless the object is independent, the parent object can enforce a
   different policy by marking certain data elements as "parent
   enforceable".  The values of these data objects elements can not be changed
   by directly accessing the child object; neither can they be expanded
   in the child object alone.

   In the future, XCON specifications may introduce logical
   relationships, in addition to the "parent enforceable",  between
   elements being cloned from one another.

   +---+-----------------------+
   | p |

   Figure 4 illustrates an example of a conference (Parent B), which is
   created independent of its Parent (Parent A).  Parent B creates two
   child objects, Child 1 and Child 2.  Any of the data elements of
   Parent B can be modified (i.e. there are no "parent enforceable" data
   elements) and depending upon the element, the changes will be
   reflected in Child 1 and Child 2 , whereas changes to Parent A will
   not impact the data elements of Parent B. Any "parent enforceable"
   data elements as defined by Parent B cannot be modified in the child
   objects.

   +---+-----------------------+
   | p |                       |
   | o |   P A R E N T  A      |
   | l |                       |
   | i |   C O N F E R E N C E |
   | c |                       |
   | i |   O B J E C T         |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/  INDEPENDENT
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o |   P A R E N T  B      |
   | l |                       |
   | i |   C O N F E R E N C E |
   | c |                       |
   | i |   O B J E C T         |
   | e |                       |
   +-s-+-----------------------+
           |    |
           |    |
           |    ---------------------------
           |                              |
           V                              V
   +---+-----------------------+    +---+-----------------------+
   | p |                       |    | p |                       |
   | o |   C H I L D  1        |    | o |   C H I L D  2        |
   | i |                       |    | l |                       |
   | l |   C O N F E R E N C E |    | i |   C O N F E R E N C E |
   | i |                       |    | c |                       |
   | c |   O B J E C T         |    | i |   O B J E C T         |
   | i |                       |    | e |                       |
   +-s-+-----------------------+    +-s-+-----------------------+

   Figure 6: 4: The Cloning Tree.

   Using the defined cloning model and its tools, defined cloning model and its tools, the following sections
   show examples of how different systems based on this framework can be
   realized.

7.2.  Ad-hoc Example

   Figure 5 illustrates how an ad-hoc conference can be created and
   managed in a conferencing system.  A client can create a conference
   by establishing a call signaling channel with a conference factory as
   specified in Section 6.1.  The conference factory can internally
   select one of the system supported conference blueprints based on the
   requesting client privileges and the media lines included in the SDP
   body.

   The selected blueprint with its default values is copied by the
   server into a newly created conference object, referred to as an
   'Active Conference'.  At this point the conference object becomes
   independent from its blueprint.  A new conference object identifier,
   a new conference identifier and a new focus are allocated by the
   server.

   During the conference lifetime, an authorized client can manipulate
   the conference object, such as adding participants, using the
   Conference Control Protocol [Section 8.3].

   +---+-----------------------+
   | p |                       |
   | o |   System  Default     |
   | l |                       |
   | i |   Conference          |
   | c |                       |
   | i |   Blueprint           |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o |  Active               |
   | l |                       |
   | i |  Conference           |
   | c |                       |
   | i |                       |
   | e |                       |
   +-s-+-----------------------+
   Figure 5: Conference Ad-hoc Creation and Lifetime.

7.3.  Advanced Example

   Figure 6 illustrates how a recurring conference can be specified
   according to system capabilities, scheduled, reserved, and managed in
   a conferencing system.  A client would first query a conferencing
   system for its capabilities.  This can be done by requesting a list
   of the conference blueprints the system supports.  Each blueprint
   contains a specific combination of capabilities and limitations of
   the conference server in terms of supported media types (e.g., audio,
   video, text, or combinations of these), participant roles, maximum
   number of participants of each role, availability of floor control,
   controls available for participants, availability and type of
   sidebars, the definitions and names of media streams, etc.

   A client may need to query any templates in the blueprints that it
   doesn't understand and then make a decision on compatibility.
   Interface hints need to be included as per [21].  The client then
   selects which specific templates to use and retrieves the templates
   from the server itself, rather than from a centralized repository.

   The selected blueprint with its default values is cloned by the
   client into a newly created conference object, referred to as a
   conference reservation, that specifies the resources needed from the
   system for this conference instance.  At this point the conference
   reservation becomes independent from its blueprint.  The client can
   also change the default values, within the system ranges, and add
   additional information, such as the list of participants and the
   conference start time, to the conference reservation.

   At this point the client can ask the conference server to create new
   conference reservations by attaching the conference reservation to
   the request.  As a result, the server can allocate the needed
   resources, create the additional conference objects for the child
   conference reservations and allocate the conference object
   identifiers for all - the original conference reservation and for
   each child conference reservation.

   From this point on, any authorized client is able to access and
   modify each of the conference objects independently.  By default,
   changes to an individual child conference reservation will affect
   neither the parent conference reservation, from which it was created,
   nor its siblings.

   On the other hand, some of the conference sub-objects, such as the
   maximum number of participants and the participants list, can be
   defined by the system as parent enforceable.  As a result, these
   objects can be modified by accessing the parent conference
   reservation only.  The changes to these objects can be applied
   automatically to each of the child reservations, subject to local
   policy.

   +---+-----------------------+
   | p |                       |
   | o |   Selected            |
   | l |                       |
   | i |   Conference          |
   | c |                       |
   | i |   Blueprint           |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o | Conference            |
   | l |                       |
   | i | Reservation           |
   | c |                       |
   | i |                       |
   | e |                       |
   +-s-+-----------------------+
           |  |  |
           |  |  |
           |  |  |
           |  |  |
       +---|--|--V-----------------+
     +-+---|--V------------------+ |
   +-+-+---V-------------------+ | |
   | p |                       | | |
   | o | Child Conference      | | |
   | l |                       | | |
   | i | Reservation           | | |
   | c |                       | | |
   | i |                       | |-+
   | e |                       |-+
   +-s-+-----------------------+

   Figure 6: Advanced Conference Definition, Creation, and Lifetime.

   When the time comes to schedule the conference reservation, either
   via the system determination that the 'start' time has been reached
   or via client invocation, an active conference is cloned based on the
   conference reservation.  As in the adhoc example, the active
   conference is independent from the parent and changes to the
   conference reservation will not impact the active conference.  Any
   desired changes must be targeted towards the active conference.  An
   example of this interaction is shown in Section 9.1

7.4.  Scheduling a conference

   The capability to schedule conferences forms an important part of the
   conferencing system solution.  An individual conference reservation
   typically has a specified 'start' and 'end' time, with the times
   being specified relative to a single specified 'fixed' time (e.g.,
   'start' = 09.00 GMT, 'end'= 'start'+2), subject to system
   considerations.  In most advanced conferencing solutions it is
   possible to not only schedule an individual occurrence of a
   conference reservation, but also schedule a series of related
   conferences (e.g., a weekly meeting that starts on Thursday at 09.00
   GMT).

   To be able to achieve such functionality, a conferencing system needs
   to be able to appropriately schedule and maintain conference
   reservations that form part of a recurring conference.  The mechanism
   proposed in this document makes use of the 'Internet Calendaring and
   Scheduling Core Object' specification defined in RFC2445[8] in union
   with the concepts introduced in Section 5 for the purpose of
   achieving advanced conference scheduling capability.

   Figure 7 illustrates a simplified view of a client interacting with a
   conferencing system.  The client is using the Conference Control
   Protocol (Section 8.3) to add a new conference reservation to the
   conferencing system by interfacing with the conference control
   server.  A CCP request contains a valid conference reservation and
   reference by value to an 'iCal' object which contains scheduling
   information about the conference (e.g., start time, end time).

   +--------------+     +-------Conferencing System-----------------+
   | Generic ICAL |     |                                           |
   |   Resource   |     |    ..Conference Instance....              |
   +--------------+     |    .                       . +-----------+|
         ^ ^            |    . +-------------------+ . | Conference||
         | |            |    . |Conference Objects |<--| Control   ||
         | ----------------->. +-------------------+ . | Server    ||
         |              |    .                       . +-----------+|
         |              |    .........................       ^      |
         |              |                ^                   |      |
   +-----|--------------+                |                   |      |
   |     v                               |                   |      |
   |  +--------------+                   |                   |      |
   |  |   Resource   |<------------------+                   |      |
   |  |   Scheduler  |                                       |      |
   |  +--------------+                                       |      |
   |                                                         |      |
   +---------------------------------------------------------|------+
                                                             |
                                                             |
                                                        +-Request-+
                                                        |         |
                                                        +----+    |
                                                        |ICAL|    |
                                                        +----+----+
                                                             |
                                                             |
                                                             |
                                           Conference Control|
                                               Protocol      |
                                                             |
                                                    +-------------+
                                                    | Conferencing|
                                                    | Client      |
                                                    +-------------+

   Figure 7: Resource Scheduling

   A CCP request to create a new conference reservation is validated,
   including the associated iCal object, and the resultant conference
   reservation is created.  The conference reservation is uniquely
   represented within the conferencing system by a conference object
   identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and
   defined in [ref:TBD].  This unique URI is returned to the client and
   can be used to reference the conference reservation, if any future
   manipulations are required (e.g., alter start time), using a CCP
   request.

   The previous example explains how a client creates a basic conference
   reservation using an iCal reference in association with a conference
   control protocol.  Figure 7 can also be applied when explaining how a
   series of conferences are scheduled in the system.  The description
   is almost identical with the exception that the iCal definition that
   is included in a CCP request represents a series of recurring
   conference instances (e.g., conference start time, end time, occur
   weekly).  The conferencing system will treat this request the same as
   the first example.  The CCP request will be validated, along with the
   associated iCal object, and the conference reservation is created.
   The conference reservation and its conference object ID created for
   this example represent the entire series of recurring conference
   instances rather than a single Conference.  If the client uses the
   conference object ID provided and a CCP request to adjust the
   conference reservation, every conference instance in the series will
   be altered.  This includes all future occurrences, such as a
   conference scheduled as an infinite series, subject to the
   limitations of the available calendaring interface.

   A conferencing system that supports the following sections
   show examples scheduling of how different XCON-compliant systems can a series of
   conference instances should also be
   realized.

6.2  Ad-hoc Example able to support manipulation
   within a specific range of the series.  A good example is a
   conference reservation that has been scheduled to occur every Monday
   at 09.00 GMT.  For the next three weeks only, the meeting has been
   altered to occur at 10.00 GMT in an alternative venue.  With Figure 7 illustrates how an ad-hoc conference can be created and
   managed
   in mind, the client will construct a CCP request whose purpose is to
   modify the existing conference reservation for the recurring
   conference instance.  The client will include the conference object
   ID provided by the conferencing system to explicitly reference the
   conference reservation within the conferencing system.  A client can create a CCP request
   will contain all the required changes to the conference by establishing a call control
   signalling channel with a Conference Factory as specified in
   Section 5.1. reservation
   (e.g., change of venue).

   The Conference Factory can internally select one conferencing system matches the incoming CCP request to the
   existing conference reservation but identifies that the associated
   iCal object only refers to a range of the existing series.  The
   conferencing system supported Conference Object blueprints based on creates a child, by cloning the requesting
   client privileges and original
   conference reservation, to represent the media lines included in altered conference instances
   within the SDP body. series.  The selected blueprint with its default values cloned child object is copied by not independent of the
   server into
   original parent object, thus preventing any potential conflicts in
   scheduling (e.g., a newly created Conference Object, referred change to as an
   'Active Conference'.  At this point the Conference Object becomes
   independent from whole series 'start time').  The
   cloned conference reservation, representing the altered series of
   conference instances, has its blueprint.  A new Conference Object Identifier,
   a new Conference Identifier and own associated conference object ID
   which is returned to the client using a new focus are allocated CCP response.  This
   conference object ID is then used by the
   server.

   During client to make any future
   alterations on the newly defined sub-series.  This process can be
   repeated any number of times as the newly returned conference lifetime, object
   ID representing an authorized client altered (cloned) series of conference instances,
   can manipulate
   the Conference Object (such as adding participants) itself be manipulated using a CCP request for the
   Conference Control Protocol [Section 7.3].

   +---+-----------------------+
   | p |                       |
   | o |   C O N F E R E N C E |
   | l |                       |
   | i |   S Y S T E M         |
   | c |                       |
   | i |   D E F A U L T       |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o |  A C T I V E          |
   | l |                       |
   | i |  C O N F E R E N C E  |
   | c |                       |
   | i |                       |
   | e |                       |
   +-s-+-----------------------+

            Figure 7: Conference Ad-hoc Creation and Lifetime.

6.3  Advanced Example

   Figure 8 illustrates how newly created
   conference object ID .  This provides a flexible approach to the
   scheduling of recurring conference can be specified
   according instances.

8.  Conferencing Mechanisms

8.1.  Call Signaling

   The focus is the central component of the conference.  Participants
   interface with the focus using an appropriate call signaling
   protocol.  Participants request to system capabilities, scheduled, reserved, and managed in establish or join a conferencing system.

   Firstly, conference
   using the call interface.  After checking the applicable policies, a client would query
   focus then either accepts the request, sends a Conferencing System progress indication
   related to the status of the request (e.g., for its
   capabilities.  This can be done by requesting a list of parked call while
   awaiting moderator approval to join) or rejects that request using
   the call signaling interface.

   During an active conference, a Conference Object "blueprints" (or templates) Control Protocol
   [Section 8.3] can be used to affect the conference state.  For
   example, CCP requests to add and delete participants are communicated
   to the focus and checked against the conference policies.  If
   approved, the participants are added or deleted using the call
   signaling to/from the focus.

8.2.  Notifications

   A conferencing system supports.
   Each blueprint can contain is responsible for implementing a specific combination of capabilities and
   limitations of Conference
   Notification Service.  The Conference Notification Service provides
   updates about the conference server instance state to authorized parties,
   including participants.  A model for notifications using SIP is
   defined in terms of supported media
   types (audio, video, text, or combinations of these), participant
   roles, maximum number of participants of each role, availability of
   floor control, controls available [11].

   The conference user identifier and associated role are used by the
   conferencing system to filter the notifications such that they
   contain only information that is allowed to be sent to that user.

8.3.  Conference Control Protocol

   The conference control protocol provides for participants, availability data manipulation and
   type
   state retrieval for the centralized conferencing data, represented by
   the conference object.  The details of sidebars, the definitions conference control
   protocol are detailed in separate documents [references TBD].

   [Editor's note: The remaining paragraphs and names subsections of media streams, etc.

   A Client may need to query any templates that it doesn't understand
   and then make a decision on compatibility.  Interface hints need to this
   section should be included as per [21].  The client then selects which specific
   template to use removed from this document once the WG reaches
   consensus and retrieves a high level overview of the template from requirements for the server itself
   conference control protocol should be provided here.  However, until
   the WG reaches that consensus (and NOT from some centralized repository).

   The selected blueprint with its default values is copied by agrees the
   client into a newly created Conference  Object, referred fundamental
   requirements) it seems premature to as a
   'Conference Object remove these details from this
   document.]

   The proposals for Reservation', that specifies the resources
   needed conference control protocol under discussion
   span from data manipulation (management-like) protocols (CPCP and
   NETCONF) to semantic-oriented (CCCP and CSCP) .  Details of the system for this Conference Instance.  At this point
   proposed protocols are in the 'Conference Object for Reservation' becomes independent from its
   blueprint. sections below.  The client can also change the default values (within following
   paragraphs summarize the
   system ranges) and add additional information (such as fundamental issues around the list selection of
   participants and
   the conference start time) to protocol(s).  [Editor's Note: Discussion Point 5 on the 'Conference Object XCON WG
   mailing list].

   It is recognized that semantic manipulations make for Reservation'.

   At this point a cleaner
   protocol design, with the client can ask disadvantage that extensions to the conference server
   underlying data model require extensions to create a
   new conference reservation by attaching the 'Conference Object protocol used to
   manipulate it.  Syntactic manipulations allow for
   Reservation' extensions to the request.  As a result,
   data model without requiring protocol extensions, with the server can allocate
   disadvantage that the needed resources, create server generally has to infer intent from data
   manipulations instead of having intent explicitly signaled.

   It is worth noting that one portion of the additional Conference Objects for
   each conference occurrence (referred data to as a 'Conference Object for
   Occurrence') and allocate be manipulated,
   the Common Conference Object identifiers for all -
   the 'Conference Object for Reservation' Information, will not be extended, and for each  'Conference
   Object for Occurrence'.

   From this point on, any authorized client is able would
   naturally lend itself to access and
   modify each semantic manipulation.  Another part of the
   data, the Conference Objects independently.  By default,
   changes Template, is intended to an individual  'Conference Object for Occurrence' will
   affect neither the 'Conference Object for Reservation' nor its
   siblings.

   On the other hand, some be extended, and would
   naturally lend itself to syntactic manipulation.  However, there has
   been a stated desire to use a single protocol (and presumably a
   single mode of the operation within this protocol) to manipulate all
   conference sub-objects, such as the
   maximum number of participants object state (common and template).

   The third statement in the participants list, can be
   defined by paragraph above makes the system as parent-forcible.  As first two
   solution options mutually exclusive.  A proposal was made that by
   allowing more than one protocol, a result, these objects hybrid approach could be taken
   such that CPCP and CSCP can both be modified by accessing the 'Conference Object for Reservation'
   only.  The changes used, since they are based on
   other protocols that are likely to these objects can be applied automatically to
   each supported by the clients (XCAP
   and BFCP, respectively).  However, the very rough consensus of the 'Conference Object WG
   supports a single protocol for Occurrence's (subject to local
   policy).

   +---+-----------------------+
   | p |                       |
   | o |   S E L E C T E D     |
   | l |                       |
   | i |   C O N F E R E N C E |
   | c |                       |
   | i |   B L U E P R I N T   |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o |  C O N F E R E N C E  |
   | l |                       |
   | i | R E S E R V A T I O N |
   | c |                       |
   | i |                       |
   | e |                       |
   +-s-+-----------------------+
           |  |  |
           |  |  |
           |  |  |
           |  |  |
       +---|--|--V-----------------+
     +-+---|--V------------------+ |
   +-+-+---V-------------------+ | |
   | p |                       | | |
   | o |   C O N F E R E N C E | | |
   | l |                       | | |
   | i |   O C C U R R E N C E | | |
   | c |                       | | |
   | i |                       | |-+
   | e |                       |-+
   +-s-+-----------------------+

     Figure 8: Advanced Conference Definition, Creation, Control and Lifetime.

6.4  Scheduling a 'Conference Object for Reservation'

   Scheduling conferences forms an important part SOAP has most
   recently been put forth as that protocol.  A basic overview of SOAP
   in the Conferencing
   System solution.  The concept context of an individual Conference Instance
   and its relationship to a specific Conference Object control is introduced provided in Section 5.2 and Section 5.3. 8.3.5

8.3.1.  CPCP

   A basic Conference Instance represents Policy Control Protocol (CPCP) is a single occurrence that has data manipulation
   protocol being proposed as a specified 'start' standard means of storing and 'end' time, with
   manipulating the times being specified relative to a single specified 'fixed'
   time (e.g. 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system
   considerations .  In most advanced conferencing solutions it is
   possible conference policy.  According to not only schedule an individual CPCP, the
   conference instance, but
   also schedule a series policy is comprised of related conferences (e.g.  A weekly meeting
   that starts on Thursday at 09.00 GMT).

   To be able to achieve such functionality, the rules associated with a Conferencing System needs
   specific conference instance.  Requirements for the CPCP are defined
   in the CPCP Requirements document [13].  The Conference Policy
   Control Protocol document [17] defines the XML Schema for the
   conference policy data elements.

   The privileges as to be able which users are allowed to appropriately schedule and maintain Conference
   Instances that form part of read and/or
   manipulate a recurring specific conference schedule.  The
   mechanism proposed instance are defined in this document makes use of a separate
   Extensible Markup Language (XML) Schema[19].  This schema is based on
   the 'Internet
   Calendaring common policy model being used for geographic privacy information
   and for presence information.

   A separate document [18] 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 Scheduling Core Object' specification defined in
   RFC2445[8] in union with the concepts introduced delete application data stored in Section 4 for the
   purpose of achieving advanced conference scheduling capability.

   Figure 9 illustrates XML format on a simplified view server.  One of a Client interacting with a
   Conference System.  The Client is using
   the Conference Control
   Protocol (Section 7.3)  to add a new Conference Instance main advantages of XCAP is that it maps XML document elements and
   attributes to the
   Conference System HTTP URIs that can be directly accessed by interfacing with the Conference Control Server. HTTP.

8.3.2.  CCCP

   A Conference Centralized Conferencing Control Protocol request contains [20] is a valid 'Conference
   Object for Reservation' and reference by value semantic-
   oriented protocol defined to allow participants or otherwise
   authorized entities to directly manipulate an 'iCal' object
   which contains scheduling information about the conference instance
   (e.g. start time, end time).

   +--------------+     +-------Conferencing System-----------------+
   | Generic ICAL |     |                                           |
   |   Resource   |     |    ..Conference Instance....              |
   +--------------+     |    .                       . +-----------+|
         ^ ^            |    . +-------------------+ . | Conference||
         | |            |    . |Conference Objects |<--| Control   ||
         | ----------------->. +-------------------+ . | Server    ||
         |              |    .                       . +-----------+|
         |              |    .........................       ^      |
         |              |                ^                   |      |
   +-----|--------------+                |                   |      |
   |     v                               |                   |      |
   |  +--------------+                   |                   |      |
   |  |   Resource   |<------------------+                   |      |
   |  |   Scheduler  |                                       |      |
   |  +--------------+                                       |      |
   |                                                         |      |
   +---------------------------------------------------------|------+
                                                             |
                                                             |
                                                        +-Request-+
                                                        |         |
                                                        +----+    |
                                                        |ICAL|    |
                                                        +----+----+
                                                             |
                                                             |
                                                             |
                                           Conference Control|
                                               Protocol      |
                                                             |
                                                    +-------------+
                                                    | Conferencing|
                                                    | Client      |
                                                    +-------------+

                       Figure 9: Resource Scheduling active conference
   instance.  CCCP is defined as a set of transactions issued over a
   reliable transport protocol.  A successful creation transaction consists of a Conference Instance using Request
   carrying the Conference
   Control Protocol results required information in an XML body and a new 'Conference Object for
   Reservation'.  A Conference Control Protocol request is validated,
   including corresponding
   Response carrying an appropriate XML body.

   CCCP requests are submitted to the associated iCal object, CCCP server and can be prioritized
   and queued, based on the resultant 'Conference
   Object for Reservation' is created.  The Conference Object is
   uniquely represented within CCCP client Role and the requested
   primitives.  CCCP requires no single lock per document, and the CCCP
   server can locally implement an optimization strategy independent of
   CCCP client behavior.

8.3.3.  CSCP

   A Conference System by Conference
   Object Identifier (e.g. xcon:hd87928374) as  discussed in
   Section 5.3.  The unique URI State Change protocol [26] is returned to the a client and can be server protocol
   used to reference change the 'Conference Object for Reservation'
   representation if any future manipulations are required (e.g.  Alter
   start time) using a Conference Control Protocol.

   The previous example explains how state of a conference object.  CSCP extends the
   BFCP protocol [16] with new commands.  A client creates sends the server a basic
   'Conference Object for Reservation' using an iCal reference in
   association with
   request representing a Conference Control Protocol.  Figure 9 sequence of commands.  Each command can also be
   applied when explaining how set,
   get, add, or delete a single field in the conference object.  Changes
   to the conference object are performed on a hierarchal set of
   elements and unique attributes within those elements.  A series of Conferences are scheduled
   changes can be pipelined in a single BFCP message.  The server
   executes each action in series.  If one of them fails, the system.  The description is almost identical with server
   returns an error for the exception action that failed and does not execute any
   of the iCal definition that actions after that.  Each individual action is included in a Conference Control
   Request represents a atomic but the
   pipelined series of recurring Conference Instances (e.g.
   conference start time, end time, occur weekly). is not.

   The Conference
   system will treat this request the same as the first example. item to which a command applies is specified by a unique ID and,
   where appropriate, attribute name.  The
   protocol request will be validated, along with the associated iCal
   object, and ID is an unsigned 32 bit
   integer called the 'Conference Object for Reservation' will be created. Element ID.  The 'Conference Object for Reservation' and server discovery of the Conference Object Element
   ID
   created for is outside of CSCP.  Typically this example represent is done by using the entire series of recurring
   Conference Instances rather than a single Conference.  If
   conference notification service per Section 8.2.  Each field in the client
   uses
   data received in the Conference Object ID provided and notification contains a Conference Control
   Protocol to adjust the 'Conference Object for Reservation', every
   Conference Instance unique field ID
   attribute that can be used in the series will BFCP requests.

8.3.4.  NETCONF

   The Network Configuration (NETFCONF) protocol [27] defines a simple
   mechanism through which a network device can be altered.  This includes all
   future occurrences, such as managed,
   configuration data information can be retrieved, and new
   configuration data can be uploaded and manipulated.  The protocol
   allows the device to expose a conference scheduled full, formal, application programming
   interface (API).

   NETCONF is proposed as an infinite
   series, subject to the limitations of mechanism for object content manipulation
   and state retrieval for the available calendaring
   interface.

   A Conferencing System that centralized conferencing data.  NETCONF
   provides a flexible configuration retrieval mechanism, with
   extensibility.  It allows for incremental configuration and commits.
   NETCONF supports stored configurations (e.g., for startup, running,
   etc.).  It also supports XPath and subtree filtering.  With NETCONF,
   there are no constraints on the scheduling configuration content.

8.3.5.  SOAP

   The SOAP protocol is fundamentally an XML messaging scheme, capable
   of supporting remote procedure calls.  SOAP defines a series simple message
   format composed of
   Conference Instances should also be able to support manipulation
   within a series range.  A good example might be that "header" and a 'Conference
   Object for Reservation' has been scheduled "body" contained within an
   "envelope".  The "header" contains meta-information relating to occur every Monday at
   09.00 GMT.  For the next three weeks only, the meeting has been
   altered
   message, and can be used to occur at 10.00 GMT  in an alternative venue.  With
   Figure 9 in mind, the  client will construct a Conference Control
   request whose purpose indicate such things as store-and-forward
   behaviour or transactional characteristics.  In addition, SOAP
   encoding is to modify the existing 'Conference Object optimized for Reservation' representing the recurring Conference Instance.  The
   Client will include the Conference Object ID provided by the
   Conference System to explicitly reference ease of automated deserialization.

   SOAP is proposed as the 'Conference Object mechanism for object content manipulation and
   state retrieval for
   Reservation' within the centralized conferencing data.  In general,
   SOAP is a good fit for Conference System.  A Conference Control, essentially because of its
   remote procedure call characteristics and its inherently synchronous
   and client-driven nature.

8.4.  Floor Control
   request will contain all the required changes

   A floor control protocol allows an authorized client to the 'Conference
   Object for Reservation'(e.g.  Change manage access
   to a specific floor and to grant, deny or revoke access of venue).  The Conference
   System matches the incoming request other
   conference users to the existing 'Conference
   Object for Reservation' but identifies that the associated iCal
   object only refers to floor.  Floor control is not a range of the existing series.  The Conference
   System creates mandatory
   mechanism for a child clone of the original 'Conference Object conferencing system implementation but provides
   advanced media input control features for
   Reservation'  to represent the altered Conference Instances conference users.  A
   mechanism for floor control within a conferencing system is defined
   in the Series.  The cloned 'Conference Object Binary Floor Control Protocol specification [16].  [Editor's
   note: Evaluation of an alternative proposal, as a stand alone draft,
   for Reservation'
   representing using Templates as the altered series of Conference Instances means for correlating Floor Control
   identifiers has its own
   associated Conference Object ID which been proposed.  If/when this work is returned done, it needs
   to the Client using be introduced and referenced here].

   Within this framework, a Conference Control Protocol.  This Conference Object ID is then
   used by the client supporting floor control needs to make any future alterations on the newly
   defined sub-series.
   obtain information for connecting to a floor control server to enable
   it to issue floor requests.  This process connection information can be repeated any number of times
   retrieved using information provided by mechanisms such as the newly returned Conference Object ID representing an altered
   (cloned) series of Conference Instances, can itself be manipulated
   negotiation using the Conference Control Protocol and SDP[2] offer/answer[5] exchange on the newly created
   Conference Object ID representation.  This
   signaling interface with the focus.  Section 11.3 provides a flexible
   approach to the scheduling
   discussion of recurring Conference instances.

7.  Conferencing Mechanisms

7.1  Call Control Signalling

   The focus is the central component client authentication of a floor control server.

   As well as the conference.  Participants
   interface with client to the focus using an appropriate Call Control Signalling
   protocol.  Participants request floor control server connection
   information, a client wishing to establish or join interact with a conference
   using the Call floor control signalling interface.  A focus then either
   accepts (after checking server
   requires access to additional information.  This information
   associates floor control interactions with the policies), sends appropriate floor
   instance.  Once a progress indication
   (e.g. connection has been established and authenticated
   (see [16] for authentication details), a parked call while awaiting moderator approval to join) or
   rejects that request using the call specific floor control signalling interface.

   During an active
   message requires detailed information to uniquely identify a
   conference, a Conference Control Protocol
   [Section 7.3] can user and a floor.

   The conference is uniquely identifed by the conference object ID per
   Section 6.2.1.  This conference object ID must be included in all
   floor control messages.  When the SDP model is used as described in
   [24] this identifier maps to affect the 'confid' SDP attribute.

   Each authorized user associated with a conference state.  For
   example, Conference Control Protocol requests to add and delete
   participants will object is uniquely
   represented by a conference user ID per Section 6.3.  This conference
   user ID must be communicated included in all floor control messages.  When using
   SDP offer/answer exchange to negotiate a Floor control connection
   with the focus and checked against using the call signaling interface, the unique
   conference identifier is contained in the 'userid' SDP attribute, as
   defined in [24]

   A media session witin a conferencing system can have any number of
   floors (0 or more) that are represented by the conference policies.  If approved, identifer.
   When using SDP offer/answer exchange to negotiate a floor control
   connection with the participants will be added
   or deleted focus using the call signalling to/from signaling interface, the focus.

7.2  Notifications

   A Conferencing System
   unique conference identifier is responsible for implementing contained in the 'floorid' SDP
   attribute, as defined in [24] e.g., a=floorid:1 m-stream:10 .  Each
   'floorid' attribute, representing a Conference
   Notification Service. unique floor, has an 'm-stream'
   tag containing one or more identifiers.  The Conference Notification Service provides
   updates about identifiers represent
   individual SDP media sessions (as defined using 'm=' from SDP) using
   the Conference Instance state SDP 'Label' attribute as defined in [23].

9.  Conferencing Scenario Realizations

   This section addresses how advanced conferencing scenarios, many of
   which have been described in [14], are realized using this
   centralized conferencing framework.  The objective of this section is
   to authorized parties
   (e.g. participants) according further illustrate the model, mechanisms and protocols presented
   in the previous sections and also serves to [11].

   The Conference User Identifier validate that the model,
   mechanisms and associated Role protocols are used by the sufficient to support advanced
   conferencing system scenarios.

9.1.  Conference Creation

   There are different ways to filter the notifications create a conference.  A participant can
   create a conference using call signaling means only, such that they
   contain only information  that is allowed to be sent as SIP and
   detailed in [15].  For a conferencing client to that user.

7.3  Conference Control Protocol

   The XCON working group charter includes have more flexibility
   in defining the development charaterisitics and capabilities of a conference, a
   conferencing client would implement a conference control protocol
   or
   client.  By using a set of protocols for controlling conference control protocol, the state client can
   determine the capabilities of a Conference
   Object conferencing system and for retrieving its state.  The nature various
   resources.

   Figure 8 provides an example of this protocol is
   currently under discussion in one client "Alice" determining the XCON working group.  The proposals
   span from data manipulation (management-like) protocols (CPCP and
   NETCONF)  to semantic-oriented (CCCP
   conference blueprints available for a particular conferencing system
   and CSCP) .  Details of creating a conference based on the
   proposed protocols desired blueprint.  It should
   be noted that not all entities impacted by the request are shown in
   the sections below.  The following
   paragraphs summarize diagram (e.g., Focus), but rather the fundamental issues around emphasis is on the selection new
   entities introduced by this centralized conferencing framework.

                                      +--------------------------------+
                                      |   Conferencing System          |
    "Alice"                           |                  +------------+|
   +--------+                         |                  |            ||
   |        |CCP Request <blueprints> | +-----------+    |            ||
   | Client |-------------------------->|Conference |    |Conference  ||
   |        |<--------------------------|Control    |~~~>|Blueprint(s)||
   +--------+CCP Response<blueprintA, | |Server     |    |            ||
                             ...      | +-----------+    +------------+|
                          blueprintZ, |                                |
                          confUserID> |                                |
   "Alice"                            |
   +--------+                         |                                |
   |        |CCP Request <reserve,    |                  +------------+|
   |        |     blueprintAConfObjID,| +-----------+    |            ||
   | Client |-------------------------->|Conference |    |Conference  ||
   |        |    confUserID>          | |Control    |~~~>|BlueprintA  ||
   |        |<--------------------------|Server     |    |            ||
   |        |CCP Response             | |           |    +------------+|
   +--------+  <reservationConfObjID, | |           |          \|/     |
                          confID>     | |           |          /|\     |
                                      | |           |           V      |
                                      | |           |    +------------+|
                                      | |           |~~~>|Conference  ||
                                      | |           |    |Reservation ||
                                      | +-----------+    +------------+|
   "Alice"                            |                         |      |
   +--------+                         |                         |      |
   |        |CCP Request <add,        |                         V      |
   |        |reservationConfObjID,    | +-----------+    +------------+|
   | Client |-------------------------->|Conference |    |Active      ||
   |        |     confID,confUserID>  | |Control    |~~~>|Conference  ||
   |        |<--------------------------|Server     |    |            ||
   |        |CCP Response             | |           |    +------------+|
   +--------+   <activeConfObjID,     | |           |                  |
                 confID>              | +-----------+                  |
                                      +--------------------------------+

   Figure 8: Client Creation of Conference using Blueprints

   Upon receipt of the protocol(s).  [Editor's Note: Discussion Point 5 on the XCON WG
   mailing list].

   It is recognized that semantic manipulations make Conference Control Protocol request for a cleaner
   protocol design, with
   blueprints, the disadvantage conferencing system would first authenticate "Alice"
   (and allocate a conference user identifier, if necessary) and then
   ensure that extensions to the
   underlying data model require extensions to "Alice" has the protocol used appropriate authority based on system
   policies to
   manipulate it.  Syntactic manipulations allow for extensions receive any blueprints supported by that system.  Any
   blueprints that "Alice" is authorized to the
   data model without requiring protocol extensions, use are returned in a
   response, along with the
   disadvantage that  the server generally has to infer intent from data
   manipulations instead  of having intent explicitly signaled.

   It is worth noting that one portion conference user ID.

   Upon receipt of the data to be manipulated,
   the Common Conference Information, will not be extended, and would
   naturally lend itself to semantic manipulation.  Another part of Control Protocol response containing
   the
   data, blueprints, "Alice" determines which blueprint to use for the Conference Template, is intended
   conference to be extended, created.  "Alice" creates a conference object based
   on the blueprint (i.e., clones) and would
   naturally lend itself to syntactic manipulation.  However, there has
   been modifies applicable fields, such
   as membership list and start time.  "Alice" then sends a stated desire request to use a single protocol (and presumably
   the conferencing system to create a
   single mode conference reservation based upon
   the updated blueprint.

   Upon receipt of operation within this protocol) the Conference Control Protocol request to manipulate all "reserve"
   a conference object state (common and template).

   The third statement based upon the blueprint in the paragraph above makes request, the first two
   solution options mutually exclusive.  A proposal was made
   conferencing system ensures that by
   allowing more than one protocol, blueprint received is a hybrid approach could be taken
   such that CPCP and CSCP can both be used, since they valid
   blueprint (i.e. the values of the various field are within range).
   The conferencing system determines the appropriate read/write access
   of any users to be added to a conference based on
   other protocols that are likely this blueprint
   (using membership, roles, etc.).  The conferencing system uses the
   received blueprint to clone a conference reservation.  The
   conferencing system also reserves or allocates a conference ID to be supported by the clients (XCAP
   and BFCP, respectively).  However,
   used for any subsequent protocol requests from any of the very rough consensus members of
   the WG
   supports a single protocol for Conference Control conference.  The conferencing system maintains the mapping
   between this conference ID and SOAP has most
   recently been put forth as that protocol.  A basic overview of SOAP
   in the context conference object ID associated
   with the reservation through the conference instance.

   Upon receipt of Conference the conference control is provided in  Section 7.3.5

7.3.1  CPCP

   A Conference Policy Control Protocol (CPCP) is a data manipulation protocol being proposed as response to reserve
   the conference, "Alice" can now create an active conference using
   that reservation or create additional reservations based upon the
   existing reservations.  In this example, "Alice" has reserved a standard means of storing and
   manipulating
   meetme conference bridge.  Thus, "Alice" provides the conference policy.  According
   information, including the necessary conference ID, to CPCP, desired
   participants.  When the first participant, including "Alice",
   requests to be added to the conference, an active conference policy and
   focus are created.  The focus is comprised of the rules associated with a
   specific Conference Instance.  Requirements for the CPCP are defined conference ID
   received in the CPCP Requirements document [13].  The Conference Policy
   Control Protocol document [17] defines request.  Any participants that have the XML Schema for authority to
   manipulate the conference policy data elements.

   The privileges as to which users would receive the conference object
   identifier of the active conference in the response.

9.2.  Participant Manipulations

   There are allowed different ways to read and/or
   manipulate affect a specific Conference Instance are defined participant state in a separate
   Extensible Markup Language (XML) Schema[19].
   conference.  A participant can join and leave the conference using
   call signaling means only, such as SIP.  This schema kind of operation is based on
   called "1st party signaling" and does not affect the common policy model being used state of other
   participants in the conference.

   Limited operations for geographic privacy information
   and controlling other conference participants (a
   so called "3rd party control") through the Focus, using call
   signaling only, may also be available for presence information.

   A separate document [18] proposes XCAP as one protocol mechanism some signaling protocols.
   For example, "Conferencing for
   storing and manipulating SIP User Agents" [15] shows how SIP
   with REFER can be used to achieve this conferencing policy data.  XCAP is a
   HTTP 1.1 based protocol that allows clients functionality.

   In order to read, write, modify
   and delete application data stored in XML format on perform richer conference control 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.

7.3.2  CCCP

   A Centralized Conferencing Control Protocol [20] is user client needs to
   implement a semantic-
   oriented conference control protocol defined to allow participants or otherwise
   authorized entities to directly manipulate an active Conference
   Instance.  CCCP is defined as client.  By using a set
   conference control protocol, the client can affect its own state,
   state of transactions issued over a
   reliable transport protocol.  A transaction consists other participants, and state of a Request
   carrying various resources (such as
   media mixers) which may indirectly affect the required information in state of any of the
   conference participants.

   Figure 9 provides an XML body and a corresponding
   Response carrying example of one client "Alice" impacting the
   state of another client "Bob".  This example assumes an appropriate XML body.

   CCCP requests are submitted established
   conference.  In this example, "Alice" wants to add "Bob" to the CCCP server and can
   conference.

   It should be prioritized
   and queued, based on noted that not all entities impacted by the CCCP client Role and request are
   shown in the requested
   primitives.  CCCP requires no single lock per document, and diagram (e.g., Focus), but rather the CCCP
   server can locally implement an optimization strategy independent emphasis is on the
   new entities introduced by this centralized conferencing framework.

                                      +--------------------------------+
                                      |   Conferencing System          |
    "Alice"                           |                  +---------+--+|
   +--------+                         |                  |policies |  ||
   |        |CCP Request <            | +-----------+    +---------+  ||
   | Client |-------------------------->|Conference |    | Active     ||
   |        |  Conference Object ID,  | |Control    |~~~>|Conference  ||
   +--------+  Add, "Bob" >           | |Server     |    |            ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
    "Bud"                             |                  '       '    '|
   +--------+  NOTIFY <"Bob"="added"> |+------------+    '       '    '|
   |        |<-------------------------|Notification|<~~~|            ||
   | Client |.          .             ||Service     |    +-------+    ||
   +--------+--+          .           ||            |    |"Bob"  |    ||
      |        |<----------------------|            |    +-------+----+|
      | Client |NOTIFY <"Bob"="added">|+------------+                  |
      +--------+                      +--------------------------------+
        "Bob"
   Figure 9: Client Manipulation of
   CCCP client behavior.

7.3.3  CSCP

   A Conference State Change protocol [26] is - Add a client server protocol
   used to change the state party

   Upon receipt of a conference object.  CSCP extends the
   BFCP protocol [16] with new commands.  A client sends the server a Conference Control Protocol request representing a sequence of commands.  Each command can set,
   get, add, or delete to "add" a single field
   party ("Bob") in the specific conference object.  Changes
   to as identified by the
   conference object are performed on a hierarchal set of
   elements and unique attributes within those elements.  A series of
   changes can be pipelined in a single BFCP message.  The server
   executes each action in series.  If one of them fails, the server
   returns an error for ID, the action conferencing system ensures that failed and does not execute any
   of "Alice"
   has the actions after that.  Each individual action is atomic but appropriate authority based on the
   pipelined series is not.

   The item policies associated with
   that specific conference object to which a command applies  is specified by a unique ID and,
   where appropriate, attribute name.  The ID is an unsigned 32 bit
   integer called perform the Element ID. operation.  The server discovery of  the Element
   ID
   conferencing system must also determine whether "Bob" is outside already a
   user of CSCP.  Typically this conferencing system or whether he is done a new user.

   If "Bob" is a new user for this conferencing system, a Conference
   User Identifier is created for Bob. Based upon the addressing
   information provided for "Bob" by using "Alice", the call signaling to add
   "Bob" to the conference  notification service per Section 7.2.  Each field in is instigated through the
   data received in Focus.

   Once the notification contains a unique field ID
   attribute call signaling indicates that can be used in BFCP requests.

7.3.4  NETCONF

   The Network Configuration (NETFCONF)  protocol [27] defines a simple
   mechanism through which a network device can be managed,
   configuration data information can be retrieved, "Bob" has been successfully
   added to the specific conference, per updates to the state, and new
   configuration data can
   depending upon the policies, other participants (including "Bob") may
   be uploaded and manipulated.  The protocol
   allows notified of the device addition of "Bob" to expose a full, formal, application programming
   interface (API).

   NETCONF is proposed as the mechanism for object content manipulation
   and state retrieval for conference via the XCON data.  NETCONF provides a flexible
   configuration retrieval mechanism, with extensibility.  It allows for
   incremental configuration and commits.  NETCONF supports stored
   configurations (e.g. for startup, running, etc.).  It also supports
   XPath and subtree filtering.  With NETCONF, there
   Conference Notification Service.

9.3.  Media Manipulations

   There are no constraints
   on different ways to manipulate the configuration content.

7.3.5  SOAP

   The SOAP  protocol is fundamentally an XML messaging scheme, capable
   of supporting remote procedure calls.  SOAP defines media in a simple message
   format composed conference.  A
   participant can change its own media streams by, for example, sending
   re-INVITE with new SDP content using SIP only.  This kind of a "header"
   operations is called "1st party signaling" and they do not affect the
   state of other participants in the conference.

   In order to perform richer conference control a "body" contained within an
   "envelope".  The "header" contains meta-information relating user client needs to
   implement a conference control protocol client.  By using a
   conference control protocol, the
   message, and client can be used to indicate manipulate the state of
   various resources, such things as store-and-forward
   behaviour or transactional characteristics. media mixers, which may indirectly affect
   the state of any of the conference participants.

   Figure 10 provides an example of one client "Alice" impacting the
   media state of another client "Bob".  This example assumes an
   established conference.  In addition, SOAP
   encoding this example, the client, "Alice" whose
   Role is optimized for ease "moderator" of automated deserialization.

   SOAP is proposed the conference, wants to mute "Bob" on a
   medium-size multi-party conference, as his device is not muted (and
   he's obviously not listening to the mechanism for object content manipulation call) and
   state retrieval for background noise in his
   office environment is disruptive to the XCON data.  In general, SOAP conference.

   It should be noted that only entities impacted by the request are
   shown in the diagram (e.g., there is a good fit
   for no Focus shown).

                                      +--------------------------------+
                                      |   Conferencing System          |
    "Alice"                           |                  +---------+--+|
   +--------+                         |                  |policies |  ||
   |        |CCP Request <            | +-----------+    +---------+  ||
   | Client |-------------------------->|Conference |    |Active      ||
   |        |  Conference Object ID,  | |Control    |~~~>|Conference  ||
   +--------+  Mute, "Bob" >          | |Server     |    |            ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
                                      |                  '       '    '|
   +--------+  NOTIFY <"Bob"=mute">   |+------------+    '       '    '|
   |        |<-------------------------|Notification|<~~~|            ||
   | Client |.          .             ||Service     |    +-------+    ||
   +--------+--+          .           ||            |    |"Bob"  |    ||
      |        |<----------------------|            |    +-------+----+|
      | Client |  NOTIFY <"Bob"=mute">|+------------+                  |
      +--------+                      +--------------------------------+

   Figure 10: Client Manipulation of Conference Control, essentially because - Mute a party

   Upon receipt of its remote procedure
   call characteristics and its inherently synchronous and client-driven
   nature.

7.4  Floor the Conference Control

   [Editor's Note: This text still requires further updating Protocol request to reflect
   new model and pending new WG agreements.  Amongst "mute" a
   party ("Bob") in the things TODO
   are:

   1.  Need to be able to fetch from specific conference as identified by the
   conference object ID, the Conference Object Server ensures that "Alice" has
   the
   credentials required for BFCP.  This includes appropriate authority based on the policies associated with that
   specific conference id, user
   id, and password.

   4.  Evaluation of an alternative proposal [TBD as a stand alone draft
   as well] for using Templates as the means for correlating Floor
   Control identifiers.

   5.  Still need to condense this section - propose to add a scenario object to section 8 and thus remove some of perform the details, leaving this
   description a very basic overview operation.  "Bob's" status
   is marked as "recvonly" and mapping the Conference Template of the identifiers.

   ]
   A mechanism for floor control within a Conferencing System Conference
   Object (if included) is defined
   in the 'Binary Floor Control Protocol' specification [16].  Floor
   control updated to reflect that "Bob's" media is not a mandatory mechanism for a Conferencing System
   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 be "mixed" with the conference media.

   Depending upon the policies, other participants (including "Bob") may
   be notified of this change via the Conference Notification Service.

9.4.  Sidebar Manipulations

   A sidebar can be retrieved
   using information provided by mechanisms such viewed as negotiation using
   the SDP[2] offer/answer[5] exchange on the signalling interface with a separate Conference instance that only
   exists within the focus.

   As well context of a parent conference instance.  Although
   viewed as an independent conference instance, it can not exist
   without a parent.  A sidebar is created using the Client --> Floor Server connection information, same mechanisms
   employed for a
   client wishing to interact with standard conference as described in Section 7.1.

   A conference object representing a Floor Control server requires
   access to additional information.  This information associates Floor
   Control interactions sidebar is created by cloning the
   parent associated with the appropriate Floor instance.  Once a
   connection has been established existing conference and authenticated (see [16] for
   authentication details), a specific floor control message requires
   detailed updating any
   information specific to uniquely identify a user, a floor the sidebar.  A sidebar conference object is
   implicitly linked to the parent conference object (i.e. it is not an
   independent object) and a
   conference.  This information, defined in is associated with the next set of bullet
   points, can be obtained using methods such parent conference
   object identifier as negotiation using as shown in Figure 11.  A conferencing system
   manages and enforces the
   SDP offer/answer exchange parent and appropriate localized
   restrictions on the signalling interface with sidebar conference object (e.g., no members from
   outside the focus:

   o parent conference instance can join, sidebar conference
   can not exist if parent conference is terminated, etc.).

                            +--------------+
                            |  Conference  |
                            |    Object    |
                            |  Identifier  |
                            +--------------+
                                   |
                                   |
                                   |
             +---------------------+---------------------+
             |                     |                     |
     +-------+-------+     +-------+-------+     +-------+-------+
     |    Sidebar    |     |    Sidebar    |     |    Sidebar    |
     |  Conference   |     |  Conference   |     |  Conference   |
     |    Object ID - Each     |     |    Object     |     |    Object     |
     |  Identifier   |     |   Identifier  |     |   Identifier  |
     +-------+-------+     +-------+-------+     +---------------+

   Figure 11: Conference Object Mapping.

   Figure 11 illustrates the relationship between a conference object
   and associated Sidebar conference objects within a conferencing
   system.  Each Sidebar conference object has a unique
      identifier per conference
   object Identifier as described in Section 5.3.1,   obtained from 6.2.1.  The main conference
   object identifier acts as a top level identifier for associated
   sidebars.

   A sidebar conference object Identifier follows many of the Conference
      server, which MUST be included concepts
   outlined in all Floor messages.  When the
      SDP cloning tree model is used as described in [24] this identifier maps to Section 7.1.  A
   Sidebar conference object contains a subset of members from the
      'confid' SDP attribute.
   o
   original Conference User Identifier - Each user has object.  Properties of the sidebar conference
   object can be manipulated by a Conference Control Protocol
   (Section 8.3) using the unique conference object identifier
      within for the Conference Object per
   sidebar.  It is also possible for the top level conference object to
   enforce policy on the sidebar object (similar to parent enforceable
   as discussed in Section 5.4, obtained 7.1).

   [Editor's Note: this needs more detail - especially around cloning
   tree, including an example scenario such as a sidebar which still
   receives the visual media from the
      Conference server,  which MUST be included main conference, but has audio
   within the sidebar.  The example would use some of the mechanisms
   shown in all Floor messages.
      When using SDP offer/answer exchange to negotiate previous sections (e.g. create a Floor control
      connection with new sidebar conference,
   cloned from the existing active conference, manipulate the media, add
   participants.]

9.5.  Whispering or Private Messages

   [Editor's Note: TBD.  Once we get full agreement on terminology and
   the focus using basic ideas in the call control signalling
      interface, other sections, we'll tackle this.]

9.6.  Conference Announcements and Recordings

   [Editor's note: TBD.  Use Cullen's comments on the unique conference identifier is contained in previous version
   of the
      'userid' SDP attribute, as defined in [24]
   o  Floor ID - A media session with a doc .]

10.  Relationships between SIPPING and Centralized Conferencing System can have any
      number
     Frameworks

   The SIPPING Conferencing Framework [9] provides an overview of 'Floors' (0 or more) that are represented by a unique
      identifier within wide
   range of centralized conferencing solutions known today in the Conference Instance (as represented by
      Conference ID).  When using SDP offer/answer exchange to negotiate
   conferencing industry.  The document introduces a Floor control connection with terminology and
   logical entities in order to systemize the focus using overview and to show the call control
      signalling interface,
   common core of many of these systems.  The logical entities and the unique conference identifier is
      contained
   listed scenarios in the 'floorid' SDP attribute, SIPPING Conferencing Framework are being used
   to illustrate how SIP [4] can be used as defined in [24]
      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 (as defined using 'm=' from SDP) using the SDP
      'Label' attribute as defined signaling means in [23].

   Clients can authenticate a BFCP server using these
   conferencing systems.  SIPPING Conferencing Framework does not define
   new conference control protocols to be used by the general
   conferencing system.  It uses only basic SIP [4], the TLS certificates.
   Requests submitted on SIP
   Conferencing for User Agents [15], and the SIPPING Conference Package
   [9] for basic SIP conferencing realization.

   This centralized conferencing framework document defines a successfully created BFCP connection may
   additionally require digest authentication within particular
   centralized conferencing system and the BFCP protocol logical entities implementing
   it.  It also defines a particular data model and refers to authenticate the Floor control client set of
   protocols (beyond call signaling means) being defined by the XCON WG
   to be used among the server.  For logical entities for implementing advanced
   conferencing features.  The purpose of the XCON working group and
   this framework is to
   take place a shared secret needs to be exchanged achieve interoperability between the BFCP
   client/server entities.  This can be achieved out logical
   entities from different vendors for controlling different aspects of band using a
   mechanism such as the 'k=' SDP attribute.
   advanced conferencing applications.

   The shared secret can also
   be exchanged using un-specified 'out of band' mechanisms.  When using
   Digest authentication of BFCP client messages logical entities defined in the exchange of an
   active 'Nonce' is also required.  This can two frameworks are not intended
   to be achieved using a BFCP
   request response interaction as defined mapped one-to-one.  The two frameworks differ in BFCP (A request is
   submitted without a Nonce TLV the
   interpretation of the internal conferencing system decomposition and
   the server generates an error
   response with either an Error Code 7 (DIGEST TLV Required) or 6
   (Invalid Nonce) containing corresponding operations.  Nevertheless, the valid nonce).  The BFCP 'Nonce' value
   can also be obtained 'out of band' using information provided in basic SIP [4], the
   SIP Conferencing for User Agents [15], and the
   Offer/Answer exchange.  As SIPPING Conference
   Package [9] are fully compatible with both Framework documents.

11.  Security Considerations

   There are a wide variety of potential attacks related to
   conferencing, due to the other SDP Floor attributes
   referenced in this section natural involvement of multiple endpoints
   and defined in [24], the 'nonce' attribute
   can be inserted in many, often user-invoked, capabilities provided by the SIP response e.g. a=nonce:dhsa8hd0dwqj.

8.  Conferencing Scenario Realizations

   This section addresses how advanced
   conferencing scenarios, many system.  Examples of attacks include the following: an
   endpoint attempting to listen to conferences in which have been described it is not
   authorized to participate, an endpoint attempting to disconnect or
   mute other users, and theft of service, by an endpoint, in  [14], attempting
   to create conferences it is not allowed to create.

   There are realized using several issues surrounding security of this XCON conferencing
   framework.  The objective  One set of this section  is to further illustrate issues involves securing the model, mechanisms and actual protocols presented
   and the associated authorization mechanisms.  This first set of
   issues should be addressed in the previous
   sections specifications specific to the
   protocols described in Section 8.  The protocols used for
   manipulation and retrieval of confidential information MUST support a
   confidentiality and integrity mechanism.  Similar requirements apply
   for the floor control protocols.  Section 11.3 discusses an approach
   for client authentication of a floor control server.

   There are also serves security issues associated with the authorization to validate that
   perform actions on the model, mechanisms and
   protocols conferencing system to invoke specific
   capabilities.  Section 5.3 discusses the policies associated with the
   conference object to ensure that only authorized entities are sufficient able to
   manipulate the data to support advanced conferencing scenarios.

   Section 6.2 access the capabilities.  The final set of
   issues involves the privacy and Section 6.3 provide examples security of the creation identity of a
   basic adhoc conference and a more advanced scheduled conference.

8.1  Participant Manipulations

   There are different ways to affect a participant state user in a
   conference.  A participant can join and leave
   the conference using
   call signalling means only, such as  SIP.  This kind of operation conference, which is
   called "1st party signalling" and does not affect discussed in Section 11.2

11.1.  Authorization

   Many policy authorization decisions are based on the state identity of other
   participants in the conference.

   Limited operations for controlling other conference participants (a
   so called "3rd party control") through
   user or the Focus, using call
   signalling only, role that a user may also be available for some signalling protocols.
   For example, "Conferencing for SIP User Agents" [15] shows how SIP
   with REFER can be used to achieve this functionality.

   In order to perform richer conference control have.  There are several ways that a
   user client needs might authenticate its identity to
   implement the system.  The conferencing
   system may know about specific users and assign passwords to the
   users.  The users may also be authenticated by knowing a particular
   conference control protocol client.  By using ID and a
   conference control protocol, the client can affect its own state,
   state of other participants, PIN for it.  Sometimes, a PIN is not required and state of various resources (such as
   media mixers) which may indirectly affect the state of any of
   the conference participants.

   Figure 11  provides an example ID is used as a shared secret.  The call signaling
   means can provide a trusted form of one client "Alice"  impacting the
   state user identity or it might
   just provide a hint of another client "Bob".  This example assumes an established
   conference.  In this example, "Alice" wants the possible identity and the user still needs
   to add "Bob" provide some authentication to prove it has the
   conference.

   It should be noted identity that not all entities impacted by was
   provided as a hint in the request are
   shown call signaling.  This may be in the diagram (e.g.  Focus), but rather form of
   an IVR system or other means.  The goal for the emphasis conferencing system
   is on to figure out a user identity and a role for any attempt to send a
   request to the
   new entities introduced by XCON.

                                      +--------------------------------+
                                      |   Conference System            |
    "Alice"                           |                  +---------+--+|
   +--------+                         |                  |policies |  ||
   |        |CCP Request <            | +-----------+    +---------+  ||
   | Client |-------------------------->|Conference |    |Conference  ||
   |        |  Conference Object ID,  | |Control    |~~~>|Object of   ||
   +--------+  Add, "Bob" >           | |Server     |    |occurrence  ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
    "Bud"                             |                  '       '    '|
   +--------+  NOTIFY <"Bob"="added"> |+------------+    '       '    '|
   |        |<-------------------------|Notification|<~~~|            ||
   | Client |.          .             ||Service     |    +-------+    ||
   +--------+--+          .           ||            |    |"Bob"  |    ||
      |        |<----------------------|            |    +-------+----+|
      | Client |NOTIFY <"Bob"="added">|+------------+                  |
      +--------+                      +--------------------------------+
        "Bob"

        Figure 10: Client Manipulation of Conference - Add conferencing system.

   When a party

   Upon receipt conferencing system presents the identity of authorized users,
   it may choose to provide information about the way the identity was
   proven to or verified by the system.  A user may also come as a
   completely unauthenticated user into the Conference Control Protocol request system - this fact needs
   also be communicated to "add" a
   party ("Bob") in interested parties.

   When guest users interact with the specific conference as identified by system, it is often in the
   Conference Object ID, context
   of a particular conference.  In this case, the Conference System ensures user may provide a PIN
   or a password that "Alice" has is specific to the appropriate authority based on conferences and authenticates
   the policies associated user to take on a certain role in that conference.  The guest
   user can then perform actions that are allowed to any user with that
   specific Conference Object
   role.

   The term password is used to perform mean the operation.  The Conference
   System must also determine whether "Bob" usual, that is already to say a user
   reasonable sized, in number of this
   Conference System or whether he bits, hard to predict shared secret.
   Today users often have passwords with more than 30 bits of randomness
   in them.  PIN is a new user.

   If "Bob" special password case - a shared secret that is
   only numeric and often contains a new user fairly small number of bits (often
   as few as 10 bits).  When conferencing systems are used for this conference system, audio on
   the PSTN, there is often a Conference User
   Identifier need to authenticate using a PIN.
   Typically if the user fails to provide the correct PIN a few times in
   a row, the PSTN call is created for Bob. Based upon disconnected.  The rate of making the calls
   and getting to the point to enter a PIN makes it fairly hard to do an
   exhaustive search of the addressing information
   provided PIN space even for "Bob" by "Alice", the call signalling 4 digit PINs.  When using
   a high speed interface to add "Bob" connect to
   the conference a conferencing system, it is instigated through the Focus.

   Once the call signalling indicates that "Bob" has been successfully
   added
   often possible to the specific conference, do thousands of attempts per updates to the state, second and
   depending upon the policies, other participants (including "Bob") may PIN
   space could quickly be notified of the addition searched.  Because of "Bob" this, it is not
   appropriate to use PINs for authorization on any of the conference via the
   Conference Notification Service.

8.2  Media Manipulations

   There are different ways to manipulate interfaces
   that provide fast queries or many simultaneous queries.

11.2.  Security and Privacy of Identity

   This conferencing system has an idea of the media in identity of a conference.

   A participant user but
   this does not mean it can change its own media streams by, reveal this identity to other users, due to
   privacy considerations.  Users can set select various options for example,
   sending re-INVITE with new SDP content using SIP only.  This kind of
   operations is called "1st party signalling" and
   revealing their identity to other users.  A user can be "hidden" such
   that other users can not see they do are involved in the conference, or
   they can be "anonymous" such that users can see that another user is
   there, but not affect see the identity of the user, or they can be "public"
   where other users can see their identity.  If there are multiple
   "anonymous" users, other parties will be able to see them as
   independent "anonymous" parties and will be able to tell how many
   "anonymous" parties are in the state of conference.  Note, that the visibility
   to other participants in is dependent on their roles.  For example,
   users' visibility (including "anonymous" and "hidden") may be
   displayed to the conference.

   In order moderator or administrator, subject to perform richer conference control a user client needs to
   implement
   conferencing system's local policies.  "Hidden" status is often used
   by robot participants of a conference (e.g., call recording) and is
   also used in many call center situations.

11.3.  Floor Control Server Authentication

   Clients can authenticate a floor control protocol client.  By server using the TLS
   certificates.  Requests submitted on a
   conference successfully created
   connection between the client and floor control protocol, server may
   additionally require digest authentication within the BFCP protocol
   to authenticate the floor control client can manipulate to the state server.  For this to
   take place, a shared secret needs to be exchanged between the floor
   control client/server entities.  This can be achieved out of
   various resources, band
   using a mechanism such as media mixers, which may indirectly affect the state of any 'k=' SDP attribute.  The shared secret
   can also be exchanged using un-specified 'out of the conference participants.

   Figure 11  provides an example band' mechanisms.
   When using Digest authentication of one floor control client "Alice"  impacting messages the
   media state
   exchange of another client "Bob".  This example assumes an
   established conference.  In this example, the Client,  "Alice" whose
   Role active 'Nonce' is "moderator" also required.  This can be achieved
   using a BFCP request response interaction as defined in BFCP (A
   request is submitted without a Nonce TLV and the server generates an
   error response with either an Error Code 7 (DIGEST TLV Required) or 6
   (Invalid Nonce) containing the valid nonce).  The BFCP 'Nonce' value
   can also be obtained 'out of band' using information provided in the conference,  wants to mute "Bob" on a
   medium-size multi-party conference,  as his device is not muted (and
   he's obviously not listening to
   offer/answer exchange.  As with the call) other SDP Floor attributes
   referenced in this section and background noise defined in
   his office environment is disruptive to [24], the conference.

   It should 'nonce' attribute
   can be noted that only entities impacted by the request are
   shown inserted in the diagram (e.g. there SIP response e.g., a=nonce:dhsa8hd0dwqj.

   [Editor's Note: May need more specifics on fetching from the
   conference object the credentials required for BFCP.  This includes
   the conference id, user id, and password.]

12.  IANA Considerations

   This is an informational draft, with no Focus shown).

                                      +--------------------------------+
                                      |   Conference System            |
    "Alice"                           |                  +---------+--+|
   +--------+                         |                  |policies |  ||
   |        |CCP Request <            | +-----------+    +---------+  ||
   | Client |-------------------------->|Conference |    |Conference  ||
   |        |  Conference Object ID,  | |Control    |~~~>|Object of   ||
   +--------+  Mute, "Bob" >          | |Server     |    |occurrence  ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
                                      |                  '       '    '|
   +--------+  NOTIFY <"Bob"=mute">   |+------------+    '       '    '|
   |        |<-------------------------|Notification|<~~~|            ||
   | Client |.          .             ||Service     |    +-------+    ||
   +--------+--+          .           ||            |    |"Bob"  |    ||
      |        |<----------------------|            |    +-------+----+|
      | Client |  NOTIFY <"Bob"=mute">|+------------+                  |
      +--------+                      +--------------------------------+

        Figure 11: Client Manipulation of Conference - Mute IANA considerations required.

13.  Acknowledgements

   This document is a party

   Upon receipt result of architectural discussions among IETF
   XCON working group participants.  The authors would like to thank
   Henning Schulzrinne for the Conference Control Protocol request to "mute" a
   party ("Bob") in the specific conference as identified by the
   Conference "Conference Object ID, the Conference Server ensures that "Alice" has
   the appropriate authority based on Tree" proposal and
   general feedback, Cullen Jennings for providing input for the policies associated with that
   specific Conference Object
   "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
   Novo, Roni Even, Umesh Chandra and Avshalom Houri for their reviews
   and constructive input.

14.  Changes since last Version

   Changes from WG 01 to perform the operation.  "Bob's" status
   is marked as "recvonly" 02::

   - Editorial nits -i.e. consistent terminology, capatilization, etc.

   - Revamped abstract and the Conference Template introduction

   - Global removal of XCON as a qualifier (we had previously done this
   in a previous version with all the Conference
   Object (if included) is updated to reflect that  "Bob's" media is not identifiers).

   - Global change of "call control signalling" to be "mixed" with "call signaling"

   - Moved the conference media.

   Depending upon terminology section after the policies, other participants (including "Bob") may
   be notified of this change via Overview section:

   - - Modified the Conference Notification Service.

8.3  Sidebar Manipulations

   A sidebar can definitions to be viewed as a separate Conference instance that only
   exists within the context more concise and per some of a parent Conference instance.  Although
   viewed as an independent Conference instance, it can not exist
   without a parent.  A Sidebar is created using the same mechanisms
   employed
   Henning's recommendations.

   - - Added definitions for a standard blueprint and conference reservation.

   - Clarified the definition of policy and added more explicit text as described in Section 6.1 A
   Conference object representing a Sidebar
   to how policy is created by cloning the
   parent associated with the existing conference, copying the
   information from accomplished via the parent data model and updating any information specific to system
   realization (section 4.3 and 6.1)

   - Removed the Editor's note/text in section 4 about the sidebar.  A Sidebar Conference Object is implicitly linked options for
   the schema; added a reference to a TBD schema document.

   - Section 5:

   - - clarified the
   parent Conference Object (i.e. it is not an independent object).  A
   Conference System manages and enforces identifiers.  Kept the parent and appropriate
   localized restrictions logical definition as
   "identifiers", although most will be realized as URIs.

   - - deleted the section on conference instance.

   - - removed the Sidebar Conference Object (e.g.  No
   members term "umbrella" from outside the parent sections conference instance can join, Sidebar User and
   conference can not exist if parent Conference is terminated, etc.).
   The Sidebar mechanism uses the umbrella approach for association of
   XCON Conference Object Identifiers as introduced in other object identifier sections

   - - moved alot of
   this document.

                            +--------------+
                            |  Conference  |
                            |    Object    |
                            |  Identifier  |
                            +--------------+
                                   |
                                   |
                                   |
             +---------------------+---------------------+
             |                     |                     |
     +-------+-------+     +-------+-------+     +-------+-------+
     |    Sidebar    |     |    Sidebar    |     |    Sidebar    |
     |  Conference   |     |  Conference   |     | detail from Conference   |
     |    Object     |     |    Object     |     |    Object     |
     |  Identifier   |     |   Identifier  |     | User Identifier  |
     +-------+-------+     +-------+-------+     +---------------+

                   Figure 12: Conference Object Mapping.

   Figure 12 illustrates the relationship between a Conference Object and associated Sidebar Conference Objects within a Conference System.
   Each Sidebar Conference Object has a unique Conference Object
   Identifier as described in Section 5.3.1.  The main Conference Object
   Identifier acts as a top level identifier for associated Sidebars.

   A sidebar Conference
   conference Object Identifier follows many of the concepts
   outlined in sections into appendices, and added
   additional detail, that will become the Cloning tree model described in Section 6.1.  A
   Sidebar Conference Object contains basis for separate documents.

   - In section 6:

   - - added a subset bit of members from explanation as to the
   original Conference object.  Properties intent of the Sidebar Conference
   Object can be manipulated by a Conference Control Protocol
   (Section 7.3 using cloning tree
   model - it's not implementation binding, but rather to illustrate the unique Conference Object identifier
   data model and context for the
   sidebar.  It is also possible for protocol interactions.

   - - removed the top level Conference Object to
   enforce policy on term copying altogether.  Cloning is the Sidebar Object (similar to parent enforceable
   as discussed in Section 6.1).

   [Editor's Note: this needs more detail - especially around cloning
   tree.]

8.4  Whispering or Private Messages

   [Editor's Note: TBD.  Once we get full agreement on terminology model and
   the basic ideas in idea is that the other sections, we'll tackle this.]

8.5  Conference Announcements and Recordings

   [Editor's note: TBD.  Use Cullen's comments on cloned object contains data indentical to the previous version
   of
   parent when it was created (whether it gets "copied" or whatever from
   the doc .]

9.  Relationships between SIPPING and XCON Frameworks

   The SIPPING Conferencing Framework [9] provides parent is an overview of a wide
   range of centralized conferencing solutions known today in implementation issue).

   - - introduce the
   conferencing industry.  The document introduces a terminology and
   logical entities blueprint concept in order section 6.1 prior to systemize the overview its
   implied usage in 6.2 and to show 6.3.

   - - removed the
   common core of many usage of these systems.  The logical entities and the
   listed scenarios in the SIPPING Conferencing Framework are being used
   to illustrate how SIP [4] can be used as term occurrence (which is just a signalling means in these
   conferencing systems.  SIPPING Conferencing Framework does not define
   new conference control protocols child
   reservation).

   - Removed security related details from Floor Control section and
   moved those to be used by the general
   conferencing system.  It uses only basic SIP [4], security section.  As a result removed most of the SIP
   Conferencing for User Agents [15],
   editorial notes from the front of the Floor control section and
   integrated the SIPPING Conference
   Package [9] remaining ones inline into that section, where the
   resolution should be documented.

   - Section 8:

   - - Added new example 8.1 - conference creation

   - - Added a placeholder for basic SIP conferencing realization.

   The XCON framework defines a particular centralized Conferencing
   System and more detailed example to the logical entities implementing it.  It also defines a
   particular XCON Data Model and refers sidebar
   section to show a sidebar which has some media specifically
   associated with the standard protocols
   (beyond call signalling means) being defined by sidebar (i.e. audio), yet still use the XCON WG main
   conference for other media (visual presentation).

   - Section 11: As a result of adding additional information to be
   used among the XCON logical entities
   security section, divided this section into subsections for implementing advanced
   conferencing features.  The purpose clarity.

   Changes from WG 00 to 01::

   - Section 2 (Conventions and Terminology).  Slight modifications to
   definitions of XCON working group Call (control) signaling, Conference Identifer,
   Conference Instance, Conference Object.

   - Section 2 (Conventions and this
   framework is Terminology).Renaming of term
   "Registered Template Definition" to "Registered Conference Document"
   (per agreement at interim meeting).

   - Section 3 (Next to achieve interoperability between the XCON entities
   from different vendors for controlling different aspects of advanced
   conferencing applications.

   The logical entities defined last paragraph on the media model).
   Clarified the text such that it doesn't read that the focus performs
   media mixing.  Changed "focus" to "media mixer controlled by the
   focus" in the two frameworks are not intended 2nd sentence and "performed" to be mapped one-to-one.  The two frameworks differ "controlled" in the
   interpretation of the internal conferencing system decomposition and
   4th.

   - Section 5.  Rearranged the corresponding operations.  Nevertheless, sub-sections a bit for better flow.
   First describe the basic SIP [4], Conference ID, then the
   SIP Conferencing for User Agents [15], and Conference Instance,
   followed by the SIPPING Conference
   Package [9] are fully compatible Object, with both Framework documents.

10.  Security Considerations

   There are the Conference Object
   Identifer described in a wide variety subsection of potential attacks related to
   conferencing, due to the natural involvement of multiple endpoints
   and Conference Object section.
   Added a diagram showing the many, often user-invoked, capabilities provided by relationship between Conference
   Identifer/Focus and Conference Object Identifier, within the
   conferencing system.  Examples context
   of attacks include the following: an
   endpoint attempting a Conference Instance to listen the Conference Object section.

   - Section 6.1 (Cloning Tree).  Rewording to conferences in clarify which  it  is not
   authorized operations
   apply to participate, an endpoint attempting independent objects (and non-independent).

   - Section 6.3 (Advanced Example).  Added additional text with regards
   to disconnect or
   mute other users, and theft future conferences, introducing the concept of service, infinite series
   (which would be limited by an endpoint, in attempting calendaring interface).

   - Section 7.3 (Conference Control Protocol).  Updated to create conferences it is not allowed include
   reference to SOAP option.

   - Section 8.3 (sidebars) - reworded 1st paragraph to create.

   There are several issues surrounding security of this conferencing
   framework.  One set of issues involves securing the actual protocols
   and the associated authorization mechanisms.  This first set of
   issues should be addressed in more explicit
   about the specificiations specific XCON FW constructs used.

   Changes from individual 02 to the
   protocols described in WG 00:

   - few minor editorial changes

   - Section 7.  The protocols used for
   manipulation and retrieval 2.  Removed second sentence of confidential information MUST support definition of Conference ID,
   as that's now included/described in context in new Identifier
   section.

   - Section 3.  Clarified that TBD in Figure 1 is "Conference Control
   Protocol" (per Keith's comment to be more explicit).

   - Section 4.1.  Identifiers.  Moved this to a
   confidentiality and integrity mechanism.  Similar requirements apply new section (
   Section 6).

   - New section for the floor control protocols.

   There Identifiers ( Section 6), thus all section
   references beyond 4 are also security issues associated with the authorization to
   perform actions on incremented in the conferencing system to invoke specific
   capabilities. new version.

   - Section 4.3 discusses the policies associated with the
   Conference Object to ensure that only authorized entities are able to
   manipulate 4.  Since section 4.1 was removed, section 4.2 became the data
   body text for section 4.

   - Section 4.2.  Added "Floor Information" to access the capabilities.  The final set Figure 2 as part of
   issues involves the privacy
   Common Conference Information, also added "Floor Control" to
   Conference Template (per text and security of Cullen's draft).

   - Section 4.5.  Conference policies.  Reworded to not introduce new
   terms, but use the identity of a user general terms identified in the conference.

   Many policy authorization decisions 1st paragraph.

   - Section 5.2.  Removed "Instance" from "Active Conference Instance"
   in Figure 4.

   - Section 5.3.  Added text clarifying that templates are based on the identity of the
   user or the Role retrieved
   from server (not central repository) (per DP3 conclusion).

   - Section 5.4.  Added text that there is a user may have.  There single time and that the
   times are several ways all relative the one time (per DP1 conclusion).

   - Section 5.4.  Added text clarifying that a
   user might authenticate its identity changes to a series impact
   "all future occurrences (per DP1 discussion/conclusion).

   - Section 6.3 - Added subsections for discussion of CSCP and NETCONF
   as the system.  The conferencing
   system may know about specific users CCP.

   - Section 6.4 - Floor Control.  Removed Editor's notes 2 and assign passwords to 3.
   Condensed the
   users.  The users text only slightly, but added explicit references to
   new identifier section.

   - Section 6.4.1 Moved to new Identifier section ( Section 6)

   - Section 7.1 - moved example to 7.2.  Included a new (more
   appropriate example) in 7.1, although this may also be authenticated by knowing a particular
   Conference ID and a PIN too basic.

   - Section 7.3 - added some proposed text for it.  Sometimes, a PIN is not required and
   the Sidebars.

15.  Appendix A - Conference ID is used as a shared secret.  The call signalling
   means can provide Object Identifier

   [Editors Note: This appendix will be incorporated in a trusted form of separate
   specification in the user identity or it might
   just provide a hint next release of the possible identity this document and the user still needs
   to provide some authentication will include
   all relevant detail.]

   The conference object URI can be viewed as a key to prove it has accessing a
   specific conference object.  It is used by the identity that was
   provided Conference Control
   Protocol as a hint in the call signalling.  This may be described in the form
   of an IVR system or other means.  The goal for the Conferencing
   System is Section 8.3 to figure out a user identity access, manipulate and delete
   a Role for any attempt to
   send conference object associated with a  request specific conference instance.
   A conference object identifier is provided to the Conferencing System.

   When a Conferencing System presents the identity of authorized users,
   it may choose Conference Control
   Client to provide information about the way the identity was
   proven enable such functions to or verified by be carried out.  This can either
   be returned through the system.  A user may also come as Conference Control Protocol while creating a
   completely unauthenticated user into
   conference object, be provided by the system - this fact needs
   also conference notification service
   or through out-of-band mechanisms (e.g.  E-Mail).

   [Editors Note: Previous section to be communicated expanded and more detail
   included.  It also needs to interested parties.

   When guest users interact link up with the other drafts and explicitly
   reference.]

   A centralized conferencing system, it is often as defined in the context
   of a particular conference.  In this case the user may provide a PIN
   or Conference
   Framework [ref] has potential to expose a password that range of interfaces and
   protocols.  It is specific also possible that future centralized conferencing
   enhancements might place requirements to the conferences provide further additional
   protocols and authenticates
   the user to take on a certain role in that conference.  The guest
   user interfaces.  A conference object can then perform actions that are allowed to any user consist and be
   associated with many identifiers that
   Role.

   The term password is used to mean the usual, that is are in some way related to say a
   reasonable sized, in number of bits, hard
   conference object.  Good examples include the Binary Floor Control
   Protocol (BFCP)[24] and call signaling protocols, such as SIP.  Each
   use unique identifiers to predict shared secret.
   Today users often have passwords represent a protocol instance associated
   with more than 30 bits of randomness
   in them.  PIN is a special password case - conference object.

   A conferencing system may maintain a shared secret that is
   only numeric relationship between the
   conference object URIs and often contains a fairly small number the identifiers associated with each of bits (often
   as few
   the complementary centralized conferencing protocols (e.g., call
   signaling protocols, BFCP, etc.).  To facilitate the maintenance of
   these relationships, the conference object URI acts as 10 bits).  When Conferencing Systems are used a top level
   identifier within the conferencing system for audio on the PSTN, there is often a need to authenticate using purpose of
   identifying the interfaces for these other protocols.  This implicit
   binding provides a PIN.
   Typically if structured mapping of the user fails to provide various protocols with
   the correct PIN a few times in
   a row, associated conference object identifier.  Figure 12 illustrates
   the PSTN call is disconnected.  The rate of making relationship between the calls identifiers used for the protocols
   within this framework and getting to the point to enter a PIN makes is fairly hard to do general conference object identifier.

                              +--------------+
                              |  Conference  |
                              |    Object    |
                              |  Identifier  |
                              +------+-------+
                                     |
                                     |
                                     |
                   +-----------------+---------------+
                   |                                 |
           +-------+---------+               +-------+-------+
           |CSP Conference ID|               | BFCP 'confid' |
           +-----------------+               +---------------+

   Figure 12: Conference Object Mapping.

   In Figure 12, the conference object identifier acts as the top level
   key in the identification process.  The call signaling protocols have
   an
   exhaustive search of associated conference ID representation in the PIN space even for 4 digit PINs.  When using
   a high speed interface to connect to a Conferencing System, it is
   often possible to do thousands form of attempts per second and URIs.  The
   binary floor control protocol, as defined in [24], defines the PIN
   space could quickly be searched.  Because of this, it is not
   appropriate to use PINs for authorization on any of
   'conf-id' identifier which represents a conference instance within
   floor control.  When created within the interfaces
   that provide fast queries or many simultaneous queries.

   This conferencing system has an idea of system, the identity of
   'conf-id' has a user but
   this does not mean it can reveal this identity to other users, due to
   privacy considerations.  Users can set select various options for
   revealing their identity 1:1 mapping to other users.  A user can be "hidden" such
   that other users can not see they the unique conference object
   Identifier.  Operations associated with the Conference Control
   Protocols are involved in directly associated with the conference, or
   they can be "anonymous" such that users can see that another user is
   there,  but not see conference object, thus
   the identity of primary identifier associated with these protocols is the user, or they can be "public"
   where other users can see their identity.  If there are multiple
   "anonymous" users, other parties will be able to see them as
   independent "anonymous" parties
   conference object identifier.  The mappings between additional
   protocols/interface is not strictly 1:1 and will be able to tell how many
   "anonymous" parties are in the conference.  Note, does allow for multiple
   occurrences.  For example, multiple call signaling protocols will
   each have a representation that the visibility
   to other participants is dependent on their Roles.  For implicitly linked to the top level
   conference object identifier, for example,
   users' visibility (including "anonymous" H323 and "hidden") may SIP URIs that
   represent a conference instance.  It should be
   displayed to the moderator or administrator, subject to noted that a
   Conferencing System's local policies.  "Hidden" status
   conferencing system is often used
   by robot participants of a conference free to structure such relationships as
   required and this information is also used just included as a guideline that
   can be used.

   The following example illustrates the representation and
   relationships that might occur in many call
   center a typical conference situations.

11.  IANA Considerations

   This is an informational draft, with no IANA considerations required.

12.  Acknowledgements

   This document is instance.  The
   table in Figure 13 lists a result of architectural discussions among IETF
   XCON working group participants. typical conference instance and related
   properties.

   +----------------------+------------------------+----------------------+
   |     Conf Obj URI     |       CSP URI          |       BFCP Conf-ID   |
   +----------------------+------------------------+----------------------+
   |     xcon:Ji092i      | sip:Ji092i@example.com |        Ji092i        |
   |                      | tel:+44(0)2920930033   |                      |
   |                      | h323:Ji092i@example.com|                      |
   +----------------------+------------------------+----------------------+

   Figure 13: Conference Table Representation

   The authors would like information from Figure 13 can then be applied to thank
   Henning Schulzrinne for the "Conference Object Tree" proposal, Cullen
   Jennings for providing input for the "Security Considerations"
   section and Keith Lantz for his careful reviews and constructive
   input.

13.  Open Issues

   Several open issues are identified
   representation introduced in the body of the document. Figure 12.  This
   list is intended as a summary results in Figure 14.

                              +--------------+
                              |  Conference  |
                              |    Object    |
                              |  Identifier  |
                              +--------------+
                              |  xcon:Ji092i |
                              +------+-------+
                                     |
                                     |
                                     |
                   +-----------------+---------------+
                   |                                 |
       +-----------+-----------+             +-------+-------+
       |   CSP Conference IDs  |             | BFCP 'confid' |
       +-----------------------+             +---------------+
       |h323:Ji092i@example.com|             |    Ji092i     |
       |tel:+44(0)2920930033   |             +-------+-------+
       |sip:Ji092i@example.com |                     |
       +-----------------------+             +-------|-------+
                                             | BFCP 'floorid |
                                             +---------------+
                                             |    UEK78d     |
                                             |    09cnJk     |
                                             +---------------+
   Figure 14: Conference Tree Representation

   Further elements can be added to facilitate the tracking of the
   primary open  issues that require WG input.

   1.  DP4.  Object Schema structure and Template definition.
   Clarification of Templates versus Blueprints and details of XML
   schema.

   2.  DP5.  CCP Protocol.

14.  Changes since last Version

   Changes from WG 00 to 01::

   - Section 2 (Conventions and Terminology).  Slight modifications tree representation in Figure 14
   to
   definitions enable a complete representation of  Call (control) signalling,  Conference Identifer,
   Conference Instance, Conference Object.

   - Section 2 (Conventions and Terminology).Renaming a conference instance within a
   conferencing system.

   This style of term
   "Registered Template Definition" to "Registered Conference Document"
   (per agreement at interim meeting).

   - Section 3 (Next association can be applied to the last paragraph on the media model).
   Clarified the text such that it doesn't read any supplementary
   protocols or conferencing mechanisms that the focus performs
   media mixing.  Changed "focus" are applied to "media mixer controlled by the
   focus"
   centralized conferencing model defined in the 2nd sentence and "performed" this document as long as a
   unique reference per conference instance is available that can be
   mapped to "controlled" in a conference object.

15.1.  Conference Object URI Definition

   [Editors Note: When the
   4th.

   - Section 5.  Rearranged appendix split from the sub-sections Framework document,
   full URI definition will be included.

16.  Appendix B - Conference User Identifier

   [Editors Note: This appendix will be incorporated in a bit for better flow.
   First describe separate
   specification in the Conference ID, then next release of this document and will include
   all relevant detail.]

   Each user within a conferencing system is allocated a unique
   conference user identifier.  The user identifier is used in
   association with the Conference Instance,
   followed conference object identifier defined in
   Section 15, and by the Conference Object, with the Conference Object
   Identifer described in conference control protocol to uniquely
   identify a  subsection user within the scope of conferencing system.  The
   conference control protocol uses the Conference Object
   section.  Added a diagram showing user identifier to uniquely
   determine who is issuing commands.  Appropriate policies can then be
   applied to the relationship between Conference
   Identifer/Focus and Conference Object Identifier, within requested command.

   As with the context conference object identifier, a number of supplementary
   user identifiers defined in other protocols are used within a Conference Instance to
   conference instance.  Such user identifiers can be associated with
   this conference user identifier and enable the Conference Object section.

   - Section 6.1 (Cloning Tree).  Rewording conferencing system to clarify which operations
   apply
   correlate and map these multiple authenticated user identities to independent objects (and non-independent).

   - Section 6.3 (Advanced Example).  Added additional text the
   single user identifier.

   Figure 15 illustrates an example using the conference user identifier
   in association with regards
   to future conferences, introducing the concept of infinite series
   (which user identity defined for BFCP and SIP Digest
   user identity as defined in RFC3261[4], which would be limited by calendaring interface).

   - Section 7.3 (Conference Control Protocol).  Updated to include
   reference to SOAP option.

   - Section 8.3 (sidebars) - reworded 1st paragraph used when SIP
   is the call signaling protocol.  It should be noted that a
   conferencing system is free to structure such relationships as
   required and this information is just included as a guideline that
   can be more explicit
   about the XCON FW constructs used.

   Changes from individual 02 to WG 00:

   - few minor editorial changes

   -  Section 2.  Removed second sentence of definition of

                                  +---------------+
                                  |  Conference
   ID, as that's now included/described in context in new   |
                                  |     User      |
                                  |   Identifier
   section.

   - Section 3.  Clarified  |
                                  +-------+-------+
                                          |
                                          |
                                          |
                          +---------------+---------------+
                          |                               |
                  +-------+-------+               +-------+-------+
                  |     BFCP      |               |   SIP Digest  |
                  |   'UserID'    |               |    Username   |
                  +---------------+               +-------+-------+

   Figure 15: Conference User Identifier

   Within a conferencing system, a user is identified by a single
   conference user identifier.  Any additional conferencing mechanisms
   that TBD contain a protocol specific user ID can be associated with the
   conference user identifier, as illustrated in Figure 1 is "Conference Control
   Protocol" (per Keith's comment 15.  This
   mechanism allows conferencing systems to be more explicit).

   - Section 4.1.  Identifiers.  Moved this manage and relate system
   wide user identities in relation to a new section (
   Section 5).

   - New section for Identifiers  ( Section 5), thus all section
   references beyond 4 are incremented specific conference objects and
   helps in the new version.

   - Section 4.  Since section 4.1 was removed, section 4.2 became enforcement of system wide policies.

   The following example illustrates the
   body text for section 4.

   - Section 4.2.  Added "Floor Information" representation and
   relationships that might occur in a typical conference instance.  The
   table in Figure 16 lists a typical representation of user identifier
   hierarchy and associations.

   +----------------+----------------+---------------+----------------+
   |  Conf User ID  |  BFCP User ID  |  SIP User ID  |  H323 User ID  |
   +----------------+----------------+---------------+----------------+
   |     John       |   HK37ihdaj    |    123674     |    928373      |
   +----------------+----------------+---------------+----------------+

   Figure 16: User Identitier Representation

   The information from Figure 16 can then be applied to the
   representation introduced in Figure 15.  This results in Figure 17.

                              +--------------+
                              |  Conference  |
                              |     User     |
                              |  Identifier  |
                              +--------------+
                              |    John      |
                              +------+-------+
                                     |
                                     |
                                     |
               +---------------------+---------------------+
               |                     |                     |
       +-------+--------+    +-------+-------+    +--------+-------+
       |  BFCP User ID  |    |  SIP User ID  |    |  H323 User ID  |
       +----------------+    +---------------+    +----------------+
       |   HK37ihdaj    |    |    123674     |    |     928373     |
       +----------------+    +-------+-------+    +----------------+

   Figure 2 as part of
   Common Conference Information, also 17: User ID Tree Representation

   Further elements can be added "Floor Control" to
   Conference Template (per text and Cullen's draft).

   - Section 4.5.  Conference policies.  Reworded to not introduce new
   terms, but use the general terms identified in the 1st paragraph.

   - Section 5.2.  Removed "Instance" from "Active Conference Instance" tree representation in Figure 4.

   - Section 5.3.  Added text clarifying that templates are retrieved
   from server (not central repository) (per DP3 conclusion).

   - Section 5.4.  Added text that there is a single time and that the
   times are all relative the one time (per DP1 conclusion).

   - Section 5.4.  Added text clarifying that changes 14
   to enable a series impact
   "all future occurrences (per DP1 discussion/conclusion).

   - Section 6.3 - Added subsections for discussion complete representation of CSCP and NETCONF
   as a conference instance within a
   conferencing system.

16.1.  Conference User Definition

   [Editors Note: When the CCP.

   -  Section 6.4 - Floor Control.  Removed Editor's notes 2 and 3.

   Condensed appendix is split from the text only slightly, but added explicit references to
   new identifier section.

   - Section 6.4.1 Moved to new Identifier section  ( Section 5)

   - Section 7.1 - moved example to 7.2.  Included a new (more
   appropriate example) in 7.1, although this may Framework
   document, full definition will be too basic.

   - Section 7.3 - added some proposed text for Sidebars.

15. included.

17.  References

15.1

17.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

15.2

17.2.  Informative References

   [2]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [3]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [4]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [5]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [6]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [7]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [8]   Dawson, F. and Stenerson, D., "Internet Calendaring and
         Scheduling Core Object Specification (iCalendar)", RFC 2445,
         November 1998.

   [9]   Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-ietf-sipping-conferencing-framework-05 (work in
         progress), May 2005.

   [10]  Levin, O. and R. Even, "High Level Requirements for Tightly
         Coupled SIP Conferencing",
         draft-ietf-sipping-conferencing-requirements-01 (work in
         progress), October 2004.

   [11]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
         Package for Conference State",
         draft-ietf-sipping-conference-package-12 (work in progress),
         July 2005.

   [12]  Schulzrinne, H., "Requirements for Floor Control Protocol",
         draft-ietf-xcon-floor-control-req-03 (work in progress),
         January
         October 2005.

   [13]  Koskelainen, P. and H. Khartabil, "Requirements for Conference
         Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in
         progress), August 2004.

   [14]  Even, R. and N. Ismail, "Conferencing Scenarios",
         draft-ietf-xcon-conference-scenarios-04
         draft-ietf-xcon-conference-scenarios-05 (work in progress),
         April
         September 2005.

   [15]  Johnston, A. and O. Levin, "Session Initiation Protocol Call
         Control - Conferencing for User Agents",
         draft-ietf-sipping-cc-conferencing-07 (work in progress),
         June 2005.

   [16]  Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
         draft-ietf-xcon-bfcp-04
         draft-ietf-xcon-bfcp-05 (work in progress), May July 2005.

   [17]  Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
         draft-ietf-xcon-cpcp-01 (work in progress), October 2004.

   [18]  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.

   [19]  Khartabil, H. and A. Niemi, "Privileges for Manipulating a
         Conference Policy",
         draft-ietf-xcon-conference-policy-privileges-01 (work in
         progress), October 2004.

   [20]  Levin, O. and G. Kimchi, "Centralized Conference Data Model",
         draft-levin-xcon-cccp-02 (work in progress), February 2005.

   [21]  Jennings, C., C. and B. Rosen, "Media Conference Server Control for
         XCON",
         draft-jennings-xcon-media-control-02 draft-jennings-xcon-media-control-03 (work in progress),
         February
         July 2005.

   [22]  Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars",
         draft-rosen-xcon-conf-sidebars-01 (work in progress),
         July 2004.

   [23]  Levin, O. and G. Camarillo, "The SDP (Session Description
         Protocol) Label Attribute",
         draft-ietf-mmusic-sdp-media-label-01 (work in progress),
         January 2005.

   [24]  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.

   [25]  Campbell, B., "The Message Session Relay Protocol",
         draft-ietf-simple-message-sessions-10
         draft-ietf-simple-message-sessions-12 (work in progress),
         February
         October 2005.

   [26]  Jennings, C. and A. Roach, "Conference State Change Protocol
         (CSCP)", draft-jennings-xcon-cscp-00 draft-jennings-xcon-cscp-01 (work in progress),
         February
         July 2005.

   [27]  Enns, R., "NETCONF Configuration Protocol",
         draft-ietf-netconf-prot-07
         draft-ietf-netconf-prot-09 (work in progress), June October 2005.

Authors' Addresses

   Mary Barnes
   Nortel
   2201 Lakeside Blvd
   Richardson, TX

   Email: mary.barnes@nortel.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

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 (2005).  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.