[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-barnes-xcon-framework) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5239

XCON Working Group                                             M. Barnes
Internet-Draft                                                    Nortel
Expires: September 2, 2006                                    C. Boulton
                                           Ubiquity Software Corporation
                                                                O. Levin
                                                   Microsoft Corporation
                                                                Mar 2006


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines the framework for Centralized Conferencing.
   The framework allows participants using various call signaling
   protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
   a centralized unicast conference.  The Centralized Conferencing
   Framework defines logical entities and naming conventions, along with



Barnes, et al.          Expires September 2, 2006               [Page 1]

Internet-Draft               XCON Framework                     Mar 2006


   a conferencing data model.  The framework also outlines a set of
   conferencing protocols, which are complementary to the call signaling
   protocols, for building advanced conferencing applications.  The
   framework binds all the defined components together for the benefit
   of builders of conferencing systems.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Centralized Conferencing Data Model  . . . . . . . . . . . . . 10
     5.1.  Common Conference Information  . . . . . . . . . . . . . . 11
     5.2.  Conference Template  . . . . . . . . . . . . . . . . . . . 12
     5.3.  Conference policies  . . . . . . . . . . . . . . . . . . . 12
   6.  Centralized Conferencing Constructs and Identifiers  . . . . . 13
     6.1.  Conference Identifier  . . . . . . . . . . . . . . . . . . 13
     6.2.  Conference Object  . . . . . . . . . . . . . . . . . . . . 13
       6.2.1.  Conference Object Identifier . . . . . . . . . . . . . 15
     6.3.  Conference User Identifier . . . . . . . . . . . . . . . . 15
   7.  Conferencing System Realization  . . . . . . . . . . . . . . . 15
     7.1.  Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16
     7.2.  Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19
     7.3.  Advanced Example . . . . . . . . . . . . . . . . . . . . . 20
     7.4.  Scheduling a conference  . . . . . . . . . . . . . . . . . 23
   8.  Conferencing Mechanisms  . . . . . . . . . . . . . . . . . . . 26
     8.1.  Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26
     8.2.  Notifications  . . . . . . . . . . . . . . . . . . . . . . 26
     8.3.  Conference Control Protocol  . . . . . . . . . . . . . . . 26
       8.3.1.  CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
       8.3.2.  CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
       8.3.3.  SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.4.  Floor Control  . . . . . . . . . . . . . . . . . . . . . . 28
   9.  Conferencing Scenario Realizations . . . . . . . . . . . . . . 29
     9.1.  Conference Creation  . . . . . . . . . . . . . . . . . . . 29
     9.2.  Participant Manipulations  . . . . . . . . . . . . . . . . 31
     9.3.  Media Manipulations  . . . . . . . . . . . . . . . . . . . 33
     9.4.  Sidebar Manipulations  . . . . . . . . . . . . . . . . . . 34
     9.5.  Whispering or Private Messages . . . . . . . . . . . . . . 38
     9.6.  Conference Announcements and Recordings  . . . . . . . . . 39
   10. Relationships between SIPPING and Centralized Conferencing
       Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 40
     11.1. Authorization  . . . . . . . . . . . . . . . . . . . . . . 40
     11.2. Security and Privacy of Identity . . . . . . . . . . . . . 41
     11.3. Floor Control Server Authentication  . . . . . . . . . . . 42



Barnes, et al.          Expires September 2, 2006               [Page 2]

Internet-Draft               XCON Framework                     Mar 2006


   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 42
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
   14. Changes since last Version . . . . . . . . . . . . . . . . . . 43
   15. Appendix A - Conference Object Identifier  . . . . . . . . . . 47
     15.1. Conference Object URI Definition . . . . . . . . . . . . . 50
   16. Appendix B - Conference User Identifier  . . . . . . . . . . . 50
     16.1. Conference User Definition . . . . . . . . . . . . . . . . 52
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 52
     17.2. Informative References . . . . . . . . . . . . . . . . . . 52
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
   Intellectual Property and Copyright Statements . . . . . . . . . . 56







































Barnes, et al.          Expires September 2, 2006               [Page 3]

Internet-Draft               XCON Framework                     Mar 2006


1.  Introduction

   This document defines the framework for Centralized Conferencing.
   The framework allows participants using various call signaling
   protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media 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 Centralized Conferencing Framework defines logical entities and
   naming conventions, along with a conferencing data model.  The
   framework also outlines a set of conferencing protocols, which are
   complementary to the call signaling protocols, for building advanced
   conferencing applications.

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


2.  Conventions

   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.


3.  Overview

   A centralized conference is an association of endpoints, called
   conference participants, with a central endpoint, called a conference
   Focus.  The Focus has direct peer relationships with the participants
   by maintaining a separate call signaling interface with each.
   Consequently, in this centralized conferencing model, the call
   signaling graph is always a star.

   The most basic conference supported in this model 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 signaling functionality with a
   participant serving as the Focus; the SIPPING Conferencing Framework
   [9] together with the SIP Call Control Conferencing for User
   Agents[15] documents address these types of scenarios.



Barnes, et al.          Expires September 2, 2006               [Page 4]

Internet-Draft               XCON Framework                     Mar 2006


   In addition to the basic features, however, a 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 standard protocols for managing and 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 signaling protocols, including SIP.  Additional
   conferencing requirements are provided in [12], [13], and [14].

   The centralizing conferencing system proposed by this framework is
   built around a fundamental concept of a conference object.  A
   conference object provides the data representation of a conference
   during each of the various stages of a conference (e.g., creation,
   reservation, active, completed, etc.).  A conference object is
   accessed via the logical functional elements, with whom a
   conferencing client interfaces, using the various protocols
   identified in Figure 1.  The functional elements defined for a
   conferencing system described by the framework are a Conference
   Control Server, Floor Control Server, any number of Foci and a
   Notification Service.  A Conference Control Protocol (CCP) provides
   the interface between a conference and media control client and the
   conference control server.  A Binary Floor Control Protocol (BFCP)
   provides the interface between a floor control client and the floor
   control server.  A call signaling protocol (e.g., SIP, H.323, PSTN,
   etc.) provides the interface between a call signaling client and a
   Focus.  A notification protocol (e.g.  SIP Notify) provides the
   interface between the conferencing client and the Notification
   Service.

   A conferencing system can support a subset of the conferencing
   functions depicted in the 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 Notification Service.  For example,
   the notification service is used to correlate information, such as
   list of participants with their media streams, between the various
   other components.










Barnes, et al.          Expires September 2, 2006               [Page 5]

Internet-Draft               XCON Framework                     Mar 2006


   ...................................................................
   .  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       |Binary     |Call      |Notification
                 |Control          |Floor      |Signaling |Protocol
                 |Protocol         |Control    |Protocol  |
                 |                 |Protocol   |          |
                 |                 |           |          |
   ..............|.................|...........|..........|...........
   .             V                 V           V          V          .
   .  +----------------+  +------------+  +----------+ +------------+.
   .  | Conference     |  | Floor      |  | Call     | |Notification|.
   .  | and Media      |  | Control    |  | Signaling| | Client     |.
   .  | Control        |  | Client     |  | Client   | |            |.
   .  | Client         |  |            |  |          | |            |.
   .  +----------------+  +------------+  +----------+ +------------+.
   .                                                                 .
   . Conferencing Client                                             .
   ...................................................................


   Figure 1: Conferencing System Logical Decomposition.

   The media graph of a conference can be centralized, decentralized, or
   any combination of both and potentially differ per media type.  In
   the centralized case, the media sessions are established between a
   media mixer controlled by the focus and each one of the participants.
   In the decentralized (i.e., distributed) case, the media graph is a



Barnes, et al.          Expires September 2, 2006               [Page 6]

Internet-Draft               XCON Framework                     Mar 2006


   multicast or multi-unicast mesh among the participants.
   Consequently, the media processing (e.g., mixing) can be controlled
   either by the focus alone or by the participants.  The concepts in
   this framework document clearly map to a centralized media model.
   The concepts can also apply to the decentralized media case, however,
   the details of such are left for future study.

   Section 5 of this document provides more details on the conference
   object.  Section 6 provides an overview of the identifiers necessary
   to address and manage the conference objects, instances and users
   associated with a conferencing system.  Section 7 of this document
   describes how a 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 high level overview of the protocols.  Section 9 then
   provides realizations of various conferencing scenarios, detailing
   the manipulation of the conference objects using the defined
   protocols.  Section 10 of this document summarizes the relationship
   between this Centralized Conferencing Framework and 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 the new terms and concepts are provided in the
   subsequent sections of this document.

   Active conference: The term active conference refers to a conference
      cbject that has been created and activated via the allocation of
      its identifiers (e.g., conference object identifier and conference
      identifier) and the associated focus.  An active conference is
      created based on either a system default conference blueprint or a
      specific conference reservation.
   Call Signaling protocol: The call signaling protocol is used between
      a participant and a focus.  In this context, the term "call" means
      a channel or session used for media streams.
   Common conference information: The common conference information is
      the data type (i.e., the XML schema) which is used to represent
      the core set of information for a conference object.  This core
      information includes a common set of definitions for basic
      conference features, such as conference identifiers, membership,
      signaling, capabilities and media types, applicable to a wide
      range of conferencing applications.





Barnes, et al.          Expires September 2, 2006               [Page 7]

Internet-Draft               XCON Framework                     Mar 2006


   Conference blueprint: A conference blueprint is a static conference
      object within a conferencing system, which describes a typical
      conference setting supported by the system.  A conference
      blueprint is the basis for creation of dynamic conference objects.
      A system may maintain multiple blueprints.  Each blueprint is
      comprised of the initial values and ranges for the elements in the
      object, conformant to the data schemas for the common conference
      information and the specific template associated with the
      blueprint.
   Conference control protocol (CCP): A conference 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 identifier (ID): A conference identifier is a call
      signaling protocol-specific URI that identifies a conference focus
      and its associated conference instance.
   Conference instance: A conference instance refers to an internal
      implementation of a specific conference, represented as a set of
      logical conference objects and 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 order to describe the system capabilities and to
      provide access to the services available for each object
      independently.  The conference object schema is comprised of two
      distinct sub components; the common conference information and the
      conference template(s).
   Conference object identifier (ID): A conference object identifier is
      a URI which uniquely identifies a conference object and is used by
      a conference control protocol to access and modify the conference
      information.
   Conference policies: Conference policies collectively refers to a set
      of rights, permissions and limitations pertaining to operations
      being performed on a certain conference object.
   Conference reservation: A conference reservation is a conference
      object, which is created from either a system default or client
      selected blueprint.
   Conference state: The conference state reflects the state of a
      conference instance and is represented using 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 built using the protocol specifications referenced in
      this framework document.




Barnes, et al.          Expires September 2, 2006               [Page 8]

Internet-Draft               XCON Framework                     Mar 2006


   Conference template: The conference template refers to the data type
      (i.e. the XML schema) which is used to represent the media or
      application specific part of the 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 data or resources associated with a
      conference instance, for which a conference participant, or group
      of participants, is granted temporary access.
   Floor chair: A floor chair is a floor control protocol compliant
      client, either a human participant or automated entity, who is
      authorized to 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 instance.
   Focus: A focus is a logical entity that maintains the call signalling
      interface with each participating client and the conference object
      representing the active state.  As such, the focus acts as an
      endpoint for each of the supported signaling protocols and is
      responsible for all primary conference membership operations
      (e.g., join, leave, update the conference instance) and for media
      negotiation/maintenance between a conference participant and the
      focus.
   Media graph: The media graph is the logical representation of the
      flow of media for a 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 [24]).
   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: A sidebar is a separate Conference instance that only exists
      within the context of a parent conference instance.






Barnes, et al.          Expires September 2, 2006               [Page 9]

Internet-Draft               XCON Framework                     Mar 2006


   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          |
   |                                                      |
   | +--------------------------------------------------+ |
   | | Common conference information type               | |
   | |                                                  | |
   | | +----------------------------------------------+ | |
   | | | Conference description  (times, duration)    | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Membership (roles, capacity, names)          | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Signaling (protocol, direction, status)      | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Floor information                            | | |
   | | +----------------------------------------------+ | |
   | | +----------------------------------------------+ | |
   | | | Sidebars, Etc.                               | | |
   | | +----------------------------------------------+ | |
   | |                                                  | |
   | +--------------------------------------------------+ |
   | +--------------------------------------------------+ |
   | | Conference template type                         | |
   | |                                                  | |
   | |   - Mixer algorithm, inputs, and outputs         | |
   | |   - Floor controls                               | |
   | |   - User Control Interface                       | |
   | |   - User's View                                  | |
   | |   - Etc.                                         | |
   | +--------------------------------------------------+ |
   |                                                      |
   +------------------------------------------------------+




Barnes, et al.          Expires September 2, 2006              [Page 10]

Internet-Draft               XCON Framework                     Mar 2006


   Figure 2: Conference Object Type Decomposition.

   In a system based on this conferencing framework, the same conference
   object type is used for representation of a conference during
   different stages of a conference, such as expressing conferencing
   system capabilities, reserving conferencing resources or reflecting
   the state of ongoing conferences.  Thus, each of the two components
   (i.e., the common conference information and the conference template)
   may be optionally included in a particular conference object.
   Section 7 describes the usage semantics of the 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, including the
   organization of the Common Conference Information and the Conference
   Templates, are detailed in separate documents [ref: TBD].

5.1.  Common Conference Information

   The common conference information section contains the core
   information that is utilized in any conference and is independent 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 conference information only.

   The common conference information may be represented using the
   conference-type as defined in [11].  The conference-type contains the
   definitions for representation of the conference object capabilities,
   membership, roles, call signaling and media status relevant to
   different stages of the conference life-cycle.

   New centralized conferencing specifications can extend the basic
   conference-type and introduce additional data elements to be used
   within the common conference information type.





Barnes, et al.          Expires September 2, 2006              [Page 11]

Internet-Draft               XCON Framework                     Mar 2006


5.2.  Conference Template

   The concept of a conference template is introduced to separate the
   complexity and the details of the "mixer" and other enhanced
   conferencing features from the common conference information 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 the XML definition allowing the feature
   presentation, configuration, and management.  The RFCs defining these
   templates are referred to as a registered 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.

   The addition of new elements or the modification of the controls
   within an element of an existing template requires the definition of
   a new template.

5.3.  Conference policies

   Conference policies collectively refers to a set of rights,
   permissions and limitations pertaining to operations being performed
   on a certain conference object.

   The set of rights describes the read/write access privileges for the
   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.  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, however, are specified as an integral
   part of the conference object type, with data objects containing the
   allowed ranges for other data objects (e.g., maximum number of
   participants) and lists of clients allowed to perform certain



Barnes, et al.          Expires September 2, 2006              [Page 12]

Internet-Draft               XCON Framework                     Mar 2006


   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 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.


6.  Centralized Conferencing Constructs and Identifiers

   This section provides details of the identifiers associated with the
   centralized conferencing framework constructs and the identifiers
   necessary to address and manage the clients associated with a
   conferencing system.  An overview of the allocation, characteristics
   and functional role of the identifiers is provided.

6.1.  Conference Identifier

   The conference identifier (conference ID) is a call signaling
   protocol-specific URI that identifies a specific conference focus and
   its associated conference instance.  A conference factory is one
   method for generating a unique conference ID, to identify and address
   a conference 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
   control protocol [Section 8.3] or other, including proprietary, out-
   of-band mechanisms.

6.2.  Conference Object

   A Conference object provides the logical representation of a
   conference iInstance in a certain stage, such as a conference
   blueprint representing a conferencing system's capabilities, the data
   representing a conference reservation, and the conference state
   during an active conference.  Each conference object is independently
   addressable through the conference control protocol interface
   [Section 8.3].

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

   A conference object representing a conference in the active state can
   have multiple call signalling conference identifiers; for example,



Barnes, et al.          Expires September 2, 2006              [Page 13]

Internet-Draft               XCON Framework                     Mar 2006


   for each call signalling protocol supported.  There is a one-to-one
   mapping between an active conference object and a conference focus.
   The focus is addressed by explicitly associating unique conference
   IDs for each signaling protocol supported by the 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             |
           +----------------+  +--------------+  +---------------+





Barnes, et al.          Expires September 2, 2006              [Page 14]

Internet-Draft               XCON Framework                     Mar 2006


   Figure 3: Identifier Relationships for an Active Conference.

6.2.1.  Conference Object Identifier

   In order to make each conference object externally accessible, the
   conferencing system allocates a unique URI per distinct conference
   object in the system.  A conference control protocol includes the
   conference object identifier in requests for directly manipulating a
   particular conference object and for obtaining its current state.
   The conference object identifier logically maps to other protocol
   specific identifiers associated with the conference instance, such as
   the BFCP 'confid'.  A full description and semantics of how the
   conference object identifier is created and used is defined in
   Section 15.

6.3.  Conference User Identifier

   Each user within a conferencing system is allocated a unique
   conference user identifier.  The user identifier is used in
   association with the conference object identifier to uniquely
   identify a user within the scope of conferencing system.  There is
   also a requirement for identifying conferencing system users who may
   not be participating in a conference instance.  Examples of these
   users would be a non participating 'Floor Control Chair' or 'Media
   Policy Controller'.  The conference user identifier is required in
   conference control protocol requests to uniquely determine who is
   issuing commands, so that appropriate policies can be applied to the
   requested command.  The conference user identifer is logically
   associated with the other user identifiers assigned to the
   conferencing client for other protocol interfaces, such as an
   authenticated SIP user.  A full description and semantics of the
   conference user identifier is 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 sophisticated systems with the ability to schedule
   recurring conferences, each with distinct characteristics, being
   integrated with external resource reservation tools, and providing
   snapshots of the conference information at any of the stages of the
   conference life-cycle.

   A conference object is the logical representation of a conference
   instance at a certain stage, such as capabilities description upon
   conference creation, reservation, activation, etc., which a
   conferencing system maintains in order to describe the system



Barnes, et al.          Expires September 2, 2006              [Page 15]

Internet-Draft               XCON Framework                     Mar 2006


   capabilities and 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 described
   in detail in 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 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 7.4

   As discussed in Section 5.3, there are conference policies implicit
   in and derivable from the data in the conference objects and there
   are also policies applying to the conference objects as a whole.  In
   the examples in this section, these latter policies are shown
   logically associated with the conference objects, however, it is an
   implementation specific mechansim as to how these policies are
   managed and applied to the conference objects.

7.1.  Cloning Tree

   The concept defined in this section is a logical representation only,
   as it is reflected through the centralized conferencing mechanisms:
   the URIs and the protocols.  Of course, the actual system realization
   can differ from the presented model.  The intent is to illustrate the
   role of the logical elements in providing an interface to the data,
   based on conferencing system and conferencing client actions, and
   describe the resultant protocol implications

   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 conference blueprint.  A
   conference blueprint is a static conference object used to describe a
   typical conference setting supported by the system.  Each system can
   maintain multiple blueprints, typically each describing a different
   conferencing type using the common conference information format,
   along with any number of template definitions This document uses the
   "cloning" metaphor instead of the "inheritance" metaphor because it
   more closely fits the idea of object 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



Barnes, et al.          Expires September 2, 2006              [Page 16]

Internet-Draft               XCON Framework                     Mar 2006


   object nor subject to any limitations of the parent object.

   Once the new object is created, it can be addressed by a unique
   conference object URI assigned by the system, as described in
   Section 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 elements can not be changed
   by directly accessing the child object; neither can they be expanded
   in the child object alone.

   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.





















Barnes, et al.          Expires September 2, 2006              [Page 17]

Internet-Draft               XCON Framework                     Mar 2006


   +---+-----------------------+
   | 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 4: The Cloning Tree.

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






Barnes, et al.          Expires September 2, 2006              [Page 18]

Internet-Draft               XCON Framework                     Mar 2006


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-+-----------------------+





Barnes, et al.          Expires September 2, 2006              [Page 19]

Internet-Draft               XCON Framework                     Mar 2006


   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.  As defined within this framework, a blueprint is
   comprised of the common conference information and a template.  A
   blueprint consists of a single template, as the template approach
   allows for defining combinations of media types in a single template
   [ref].  Whether a blueprint needs to additionally support multiple
   templates, and the associated mechanism, is for future study.

   The template within the blueprint can either be included by-value or
   by-reference depending upon the system implementation.  In the case
   of a template included by-reference within a blueprint, a client may
   need to query a template that it doesn't understand and then make a
   decision on compatibility.  Interface hints need to be included as
   per [20].  In this case, a client selects the specific blueprint to
   use and retrieves the associated template from the conferencing
   system 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.



Barnes, et al.          Expires September 2, 2006              [Page 20]

Internet-Draft               XCON Framework                     Mar 2006


   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.






































Barnes, et al.          Expires September 2, 2006              [Page 21]

Internet-Draft               XCON Framework                     Mar 2006


   +---+-----------------------+
   | 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



Barnes, et al.          Expires September 2, 2006              [Page 22]

Internet-Draft               XCON Framework                     Mar 2006


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



















Barnes, et al.          Expires September 2, 2006              [Page 23]

Internet-Draft               XCON Framework                     Mar 2006


   +--------------+     +-------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.



Barnes, et al.          Expires September 2, 2006              [Page 24]

Internet-Draft               XCON Framework                     Mar 2006


   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 scheduling of a series of
   conference instances should also be 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
   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 CCP request
   will contain all the required changes to the conference reservation
   (e.g., change of venue).

   The 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 creates a child, by cloning the original
   conference reservation, to represent the altered conference instances
   within the series.  The cloned child object is not independent of the
   original parent object, thus preventing any potential conflicts in
   scheduling (e.g., a change to the whole series 'start time').  The
   cloned conference reservation, representing the altered series of
   conference instances, has its own associated conference object ID
   which is returned to the client using a CCP response.  This
   conference object ID is then used by the 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 object
   ID representing an altered (cloned) series of conference instances,



Barnes, et al.          Expires September 2, 2006              [Page 25]

Internet-Draft               XCON Framework                     Mar 2006


   can itself be manipulated using a CCP request for the newly created
   conference object ID .  This provides a flexible approach to the
   scheduling of recurring conference 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 establish or join a conference
   using the call interface.  After checking the applicable policies, a
   focus then either accepts the request, sends a progress indication
   related to the status of the request (e.g., for a parked call while
   awaiting moderator approval to join) or rejects that request using
   the call signaling interface.

   During an active conference, a Conference 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 is responsible for implementing a Conference
   Notification Service.  The Conference Notification Service provides
   updates about the conference instance state to authorized parties,
   including participants.  A model for notifications using SIP is
   defined in [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 data manipulation and
   state retrieval for the centralized conferencing data, represented by
   the conference object.  The details of the conference control
   protocol are detailed in separate documents [references TBD].

   [Editor's note: The remaining paragraphs and subsections of this
   section, detailing the various protocol options should be pruned from
   this document, once the WG reaches consensus on the conference
   control protocol.]



Barnes, et al.          Expires September 2, 2006              [Page 26]

Internet-Draft               XCON Framework                     Mar 2006


8.3.1.  CCCP

   A Centralized Conferencing Control Protocol [19] is a semantic-
   oriented protocol defined to allow participants or otherwise
   authorized entities to directly manipulate an active conference
   instance.  CCCP is defined as a set of transactions issued over a
   reliable transport protocol.  A transaction consists of a Request
   carrying the required information in an XML body and a corresponding
   Response carrying an appropriate XML body.

   CCCP requests are submitted to the CCCP server and can be prioritized
   and queued, based on the 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.2.  CSCP

   A Conference State Change protocol [25] is a client server protocol
   used to change the state of a conference object.  CSCP extends the
   BFCP protocol [16] with new commands.  A client sends the server a
   request representing a sequence of commands.  Each command can 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
   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 the action that failed and does not execute any
   of the actions after that.  Each individual action is atomic but the
   pipelined series is not.

   The item 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 the Element ID.  The server discovery of the Element
   ID is outside of CSCP.  Typically this is done by using the
   conference notification service per Section 8.2.  Each field in the
   data received in the notification contains a unique field ID
   attribute that can be used in BFCP requests.

8.3.3.  SOAP

   The SOAP protocol is fundamentally an XML messaging scheme, capable
   of supporting remote procedure calls.  SOAP defines a simple message
   format composed of a "header" and a "body" contained within an
   "envelope".  The "header" contains meta-information relating to the
   message, and can be used to indicate such things as store-and-forward
   behaviour or transactional characteristics.  In addition, SOAP
   encoding is optimized for ease of automated deserialization.



Barnes, et al.          Expires September 2, 2006              [Page 27]

Internet-Draft               XCON Framework                     Mar 2006


   SOAP [17] and [18] is proposed as the mechanism for object content
   manipulation and state retrieval for the centralized conferencing
   data.  In general, SOAP is a good fit for Conference Control,
   essentially because of its remote procedure call characteristics and
   its inherently synchronous and client-driven nature.

8.4.  Floor Control

   A floor control protocol allows an authorized client to manage access
   to a specific floor and to grant, deny or revoke access of other
   conference users to that floor.  Floor control is not a mandatory
   mechanism for a conferencing system implementation but provides
   advanced media input control features for conference users.  A
   mechanism for floor control within a conferencing system is defined
   in the Binary Floor Control Protocol specification [16].  [Editor's
   note: Evaluation of an alternative proposal, as a stand alone draft,
   for using Templates as the means for correlating Floor Control
   identifiers has been proposed.  If/when this work is done, it needs
   to be introduced and referenced here].

   Within this framework, a client supporting floor control needs to
   obtain information for connecting to a floor control server to enable
   it to issue floor requests.  This connection information can be
   retrieved using information provided by mechanisms such as
   negotiation using the SDP[2] offer/answer[5] exchange on the
   signaling interface with the focus.  Section 11.3 provides a
   discussion of client authentication of a floor control server.

   As well as the client to the floor control server connection
   information, a client wishing to interact with a floor control server
   requires access to additional information.  This information
   associates floor control interactions with the appropriate floor
   instance.  Once a connection has been established and authenticated
   (see [16] for authentication details), a specific floor control
   message requires detailed information to uniquely identify a
   conference, a 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
   [23] this identifier maps to the 'confid' SDP attribute.

   Each authorized user associated with a conference object is uniquely
   represented by a conference user ID per Section 6.3.  This conference
   user ID must be included in all floor control messages.  When using
   SDP offer/answer exchange to negotiate a Floor control connection
   with the focus using the call signaling interface, the unique
   conference identifier is contained in the 'userid' SDP attribute, as



Barnes, et al.          Expires September 2, 2006              [Page 28]

Internet-Draft               XCON Framework                     Mar 2006


   defined in [23]

   A media session witin a conferencing system can have any number of
   floors (0 or more) that are represented by the conference identifer.
   When using SDP offer/answer exchange to negotiate a floor control
   connection with the focus using the call signaling interface, the
   unique conference identifier is contained in the 'floorid' SDP
   attribute, as defined in [23] 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 in [22].


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 further illustrate the model, mechanisms and protocols presented
   in the previous sections and also serves to validate that the model,
   mechanisms and protocols are sufficient to support advanced
   conferencing scenarios.

   The details shown in the messages are for illustrative purposes only
   and don't reflect the structure of the conference control protocol
   messages, but rather provide a high level primitive view of the
   necessary operations and general logic flow, including the data
   manipulation aspects.  It should be noted that not all entities
   impacted by the request are shown in the diagram (e.g., Focus), but
   rather the emphasis is on the new entities introduced by this
   centralized conferencing framework.

9.1.  Conference Creation

   There are different ways to create a conference.  A participant can
   create a conference using call signaling means only, such as SIP and
   detailed in [15].  For a conferencing client to have more flexibility
   in defining the charaterisitics and capabilities of a conference, a
   conferencing client would implement a conference control protocol
   client.  By using a conference control protocol, the client can
   determine the capabilities of a conferencing system and its various
   resources.

   Figure 8 provides an example of one client "Alice" determining the
   conference blueprints available for a particular conferencing system
   and creating a conference based on the desired blueprint.




Barnes, et al.          Expires September 2, 2006              [Page 29]

Internet-Draft               XCON Framework                     Mar 2006


                                      +--------------------------------+
                                      |   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 Conference Control Protocol request for
   blueprints, the conferencing system would first authenticate "Alice"
   (and allocate a conference user identifier, if necessary) and then



Barnes, et al.          Expires September 2, 2006              [Page 30]

Internet-Draft               XCON Framework                     Mar 2006


   ensure that "Alice" has the appropriate authority based on system
   policies to receive any blueprints supported by that system.  Any
   blueprints that "Alice" is authorized to use are returned in a
   response, along with the conference user ID.

   Upon receipt of the Conference Control Protocol response containing
   the blueprints, "Alice" determines which blueprint to use for the
   conference to be created.  "Alice" creates a conference object based
   on the blueprint (i.e., clones) and modifies applicable fields, such
   as membership list and start time.  "Alice" then sends a request to
   the conferencing system to create a conference reservation based upon
   the updated blueprint.

   Upon receipt of the Conference Control Protocol request to "reserve"
   a conference based upon the blueprint in the request, the
   conferencing system ensures that the blueprint received is a 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 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
   used for any subsequent protocol requests from any of the members of
   the conference.  The conferencing system maintains the mapping
   between this conference ID and the conference object ID associated
   with the reservation through the conference instance.

   Upon receipt of the conference control protocol 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
   meetme conference bridge.  Thus, "Alice" provides the conference
   information, including the necessary conference ID, to desired
   participants.  When the first participant, including "Alice",
   requests to be added to the conference, an active conference and
   focus are created.  The focus is associated with the conference ID
   received in the request.  Any participants that have the authority to
   manipulate the conference would receive the conference object
   identifier of the active conference in the response.

9.2.  Participant Manipulations

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




Barnes, et al.          Expires September 2, 2006              [Page 31]

Internet-Draft               XCON Framework                     Mar 2006


   Limited operations for controlling other conference participants (a
   so called "3rd party control") through the Focus, using call
   signaling only, may also be available for some signaling 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 a user client needs to
   implement a conference control protocol client.  By using a
   conference control protocol, the client can affect its own state,
   state of other participants, and state of various resources (such as
   media mixers) which may indirectly affect the state of any of the
   conference participants.

   Figure 9 provides an example of one client "Alice" impacting the
   state of another client "Bob".  This example assumes an established
   conference.  In this example, "Alice" wants to add "Bob" to the
   conference.




                                      +--------------------------------+
                                      |   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 Conference - Add a party

   Upon receipt of the Conference Control Protocol request to "add" a
   party ("Bob") in the specific conference as identified by the



Barnes, et al.          Expires September 2, 2006              [Page 32]

Internet-Draft               XCON Framework                     Mar 2006


   conference object ID, the conferencing system ensures that "Alice"
   has the appropriate authority based on the policies associated with
   that specific conference object to perform the operation.  The
   conferencing system must also determine whether "Bob" is already a
   user of this conferencing system or whether he is 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 "Alice", the call signaling to add
   "Bob" to the conference is instigated through the Focus.

   Once the call signaling indicates that "Bob" has been successfully
   added to the specific conference, per updates to the state, and
   depending upon the policies, other participants (including "Bob") may
   be notified of the addition of "Bob" to the conference via the
   Conference Notification Service.

9.3.  Media Manipulations

   There are different ways to manipulate the media in a 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
   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 user client needs to
   implement a conference control protocol client.  By using a
   conference control protocol, the client can manipulate the state of
   various resources, such as 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 this example, the client, "Alice" whose
   Role is "moderator" of 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 call) and background noise in his
   office environment is disruptive to the conference.













Barnes, et al.          Expires September 2, 2006              [Page 33]

Internet-Draft               XCON Framework                     Mar 2006


                                      +--------------------------------+
                                      |   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 - Mute a party

   Upon receipt of the Conference Control Protocol request to "mute" a
   party ("Bob") in the specific conference as identified by the
   conference object ID, the Conference Server ensures that "Alice" has
   the appropriate authority based on the policies associated with that
   specific conference object to perform the operation.  "Bob's" status
   is marked as "recvonly" and the Conference Template of the Conference
   Object (if included) is updated to reflect that "Bob's" media is not
   to 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 viewed as a separate Conference instance that only
   exists within the 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 same mechanisms
   employed for a standard conference as described in Section 7.1.

   A conference object representing a sidebar is created by cloning the
   parent associated with the existing conference and updating any
   information specific to the sidebar.  A sidebar conference object is



Barnes, et al.          Expires September 2, 2006              [Page 34]

Internet-Draft               XCON Framework                     Mar 2006


   implicitly linked to the parent conference object (i.e. it is not an
   independent object) and is associated with the parent conference
   object identifier as as shown in Figure 11.  A conferencing system
   manages and enforces the parent and appropriate localized
   restrictions on the sidebar conference object (e.g., no members from
   outside the 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     |     |    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 conference
   object Identifier as described in Section 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 concepts
   outlined in the cloning tree model described in Section 7.1.  A
   Sidebar conference object contains a subset of members from the
   original Conference object.  Properties of the sidebar conference
   object can be manipulated by a Conference Control Protocol
   (Section 8.3) using the unique conference object identifier for the
   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 7.1).

   Figure 12 provides an example of one client "Alice" involved in
   active conference with "Bob" and "Bud".  "Alice" wants to create a



Barnes, et al.          Expires September 2, 2006              [Page 35]

Internet-Draft               XCON Framework                     Mar 2006


   sidebar to have a side discussion with "Bob" while still viewing the
   video associated with the main conference.  "Alice" initiates the
   sidebar by sending a request to the conferencing system to create a
   conference reservation based upon the active conference object.















































Barnes, et al.          Expires September 2, 2006              [Page 36]

Internet-Draft               XCON Framework                     Mar 2006


                                      +--------------------------------+
                                      |   Conferencing System          |
                                      |                  +---------+--+|
                                      |                  |policies |  ||
                                      |                  +---------+  ||
                                      |                  |Active      ||
                                      |                  |Conference  ||
   "Alice"                            |                  +-------+    ||
   +--------+                         |                  |"Alice"|    ||
   |        |CCP Req <createSidebar,  |                  +-------+    ||
   |        |     activeConfObjID,    | +-----------+    |"Bob"  |    ||
   | Client |-------------------------->|Conference |    +-------+    ||
   |        |    confUserID>          | |Control    |~~~>|"Bud"  |    ||
   |        |<--------------------------|Server     |    +-------+----+|
   |        |CCP Response             | |           |           |      |
   +--------+  <sidebarResvConfObjID, | |           |           |      |
                          confID>     | |           |           V      |
                                      | |           |    +---------+--+|
                                      | |           |    |policies |  ||
                                      | |           |~~~>+---------+  ||
                                      | |           |    |            ||
                                      | +-----------+    |            ||
    "Alice"                           |                  | Sidebar    ||
   +--------+                         |                  | Reservation||
   |        |CCP Request <update,     | +-----------+    |            ||
   |        |    sidebarResvConfObjID,| |           |    |            ||
   | Client |-------------------------->|           |~~~>|            ||
   |        |  confID,confUserID,     | |           |    +------------+|
   |        |  video=parent,          | |           |           |      |
   |        |  audio=sidebar>         | |Conference |           |      |
   |        |                         | |Control    |           V      |
   |        |                         | |Server     |    +---------+--+|
   |        |CCP Response             | |           |    |policies |  ||
   |        |    <activeSideConfObjID,| |           |    +---------+  ||
   |        |<--------------------------|           |    |Active      ||
   +--------+    confID>              | |           |    |Sidebar     ||
                                      | |           |    |Conference  ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
     "Bob"                            |                  |       |    ||
   +--------+  NOTIFY <"Bob"=added>   |+------------+    +-------+    ||
   |        |<-------------------------|Notification|<~~~|       |    ||
   | Client |                         ||Service     |    |"Bob"  |    ||
   +--------+                         ||            |    +-------+----+|
                                      |+------------+                  |
                                      +--------------------------------+





Barnes, et al.          Expires September 2, 2006              [Page 37]

Internet-Draft               XCON Framework                     Mar 2006


   Figure 12: Client Creation of a Sidebar Conference

   Upon receipt of the Conference Control Protocol request to "reserve"
   a new sidebar conference, based upon the active conference received
   in the request, the conferencing system uses the received active
   conference to clone a conference reservation for the sidebar.  As
   discussed previously, the sidebar reservation is NOT independent of
   the active conference (i.e., parent).  The conferencing system also
   reserves or allocates a conference ID to be used for any subsequent
   protocol requests from any of the members of the conference.  The
   conferencing system maintains the mapping between this conference ID
   and the conference object ID associated with the sidebar reservation
   through the conference instance.

   Upon receipt of the conference control protocol 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" wants only "Bob" to
   be involved in the sidebar, thus she manipulates the membership.
   Alice also only wants the video from the original conference and
   wants the audio to be restricted to the participants in the sidebar.
   Alice sends a conference control protocol request to update the
   information in the reservation and to create an active conference.

   Upon receipt of the conference control protocol request to update the
   reservation and to create an active conference for the sidebar, as
   identified by the conference object ID, the conferencing system
   ensures that "Alice" has the appropriate authority based on the
   policies associated with that specific conference object to perform
   the operation.  The conferencing system must also validate the
   updated information in the reservation, ensuring whether members like
   "Bob" are already a user of this conferencing system or whether he is
   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 "Alice", the call
   signaling to add "Bob" to the conference is instigated through the
   Focus.

   Depending upon the policies, the participants in the sidebar (i.e.,
   "Bob") may be notified of his addition to the sidebar via the
   conference notification service.

9.5.  Whispering or Private Messages

   The case of private messages can be handled as a sidebar with just
   two participants, similar to the example in section Section 9.4, but
   rather than using audio within the sidebar, "Alice" could add an
   additional text based media stream to the sidebar.  The other



Barnes, et al.          Expires September 2, 2006              [Page 38]

Internet-Draft               XCON Framework                     Mar 2006


   context, referred to as whisper, in this document refers to
   situations such as when a announcement server injects a message
   targetted to specific user(s).  The details of this mechanism within
   the context of the framework are TBD.

9.6.  Conference Announcements and Recordings

   Each participant can require a different type of announcement and/or
   recording service from the system.  For example, "Alice", the
   conference chair, could be listening to a roll call while "Bob" may
   be using a telephony user interface to create a sidebar.  The
   conferencing system would also need to have the capability to monitor
   for DTMF from each individual participant.

   Further details of conference announcements and recordings, within
   the context of this framework, are TBD.


10.  Relationships between SIPPING and Centralized Conferencing
     Frameworks

   The SIPPING Conferencing Framework [9] provides an overview of a wide
   range of centralized conferencing solutions known today in the
   conferencing industry.  The document introduces a terminology and
   logical entities in order to systemize the overview and to show the
   common core of many 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 a signaling means in 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 SIP
   Conferencing for User Agents [15], and the SIPPING Conference Package
   [9] for basic SIP conferencing realization.

   This centralized conferencing framework document defines a particular
   centralized conferencing system and the logical entities implementing
   it.  It also defines a particular data model and refers to the set of
   protocols (beyond call signaling means) being defined by the XCON WG
   to be used among the logical entities for implementing advanced
   conferencing features.  The purpose of the XCON working group and
   this framework is to achieve interoperability between the logical
   entities from different vendors for controlling different aspects of
   advanced conferencing applications.

   The logical entities defined in the two frameworks are not intended
   to be mapped one-to-one.  The two frameworks differ in the
   interpretation of the internal conferencing system decomposition and
   the corresponding operations.  Nevertheless, the basic SIP [4], the



Barnes, et al.          Expires September 2, 2006              [Page 39]

Internet-Draft               XCON Framework                     Mar 2006


   SIP Conferencing for User Agents [15], and the 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 natural involvement of multiple endpoints
   and the many, often user-invoked, capabilities provided by the
   conferencing system.  Examples of attacks include the following: an
   endpoint attempting to listen to conferences in which it is not
   authorized to participate, an endpoint attempting to disconnect or
   mute other users, and theft of service, by an endpoint, in attempting
   to create conferences it is not allowed 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 the 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 security issues associated with the authorization to
   perform actions on the conferencing system to invoke specific
   capabilities.  Section 5.3 discusses the policies associated with the
   conference object to ensure that only authorized entities are able to
   manipulate the data to access the capabilities.  The final set of
   issues involves the privacy and security of the identity of a user in
   the conference, which is discussed in Section 11.2

11.1.  Authorization

   Many policy authorization decisions are based on the identity of the
   user or the role that a user may have.  There are several ways that a
   user might authenticate its identity to 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 ID and a PIN for it.  Sometimes, a PIN is not required and
   the conference ID is used as a shared secret.  The call signaling
   means can provide a trusted form of the user identity or it might
   just provide a hint of the possible identity and the user still needs
   to provide some authentication to prove it has the identity that was
   provided as a hint in the call signaling.  This may be in the form of
   an IVR system or other means.  The goal for the conferencing system
   is to figure out a user identity and a role for any attempt to send a



Barnes, et al.          Expires September 2, 2006              [Page 40]

Internet-Draft               XCON Framework                     Mar 2006


   request to the conferencing system.

   When a 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 system - this fact needs
   also be communicated to interested parties.

   When guest users interact with the system, it is often in the context
   of a particular conference.  In this case, the user may provide a PIN
   or a password that is specific to the conferences and authenticates
   the 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
   role.

   The term password is used to mean the usual, that is to say a
   reasonable sized, in number of bits, hard to predict shared secret.
   Today users often have passwords with more than 30 bits of randomness
   in them.  PIN is a special password case - a shared secret that is
   only numeric and often contains a fairly small number of bits (often
   as few as 10 bits).  When conferencing systems are used for audio on
   the PSTN, there is often a 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 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 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 of attempts per second and the PIN
   space could quickly be searched.  Because of this, it is not
   appropriate to use PINs for authorization on any of the interfaces
   that provide fast queries or many simultaneous queries.

11.2.  Security and Privacy of Identity

   This conferencing system has an idea of the identity of 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 to other users.  A user can be "hidden" such
   that other users can not see they are involved in the conference, or
   they can be "anonymous" such that users can see that another user is
   there, but not 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 conference.  Note, that the visibility
   to other participants is dependent on their roles.  For example,
   users' visibility (including "anonymous" and "hidden") may be
   displayed to the moderator or administrator, subject to a



Barnes, et al.          Expires September 2, 2006              [Page 41]

Internet-Draft               XCON Framework                     Mar 2006


   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 server using the TLS
   certificates.  Requests submitted on a successfully created
   connection between the client and floor control server may
   additionally require digest authentication within the BFCP protocol
   to authenticate the floor control client to the 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 band
   using a mechanism such as the 'k=' SDP attribute.  The shared secret
   can also be exchanged using un-specified 'out of band' mechanisms.
   When using Digest authentication of floor control client messages the
   exchange of an active 'Nonce' is 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
   offer/answer exchange.  As with the other SDP Floor attributes
   referenced in this section and defined in [23], the 'nonce' attribute
   can be inserted in the 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 IANA considerations required.


13.  Acknowledgements

   This document is a result of architectural discussions among IETF
   XCON working group participants.  The authors would like to thank
   Henning Schulzrinne for the "Conference Object Tree" proposal and
   general feedback, Cullen Jennings for providing input for the
   "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
   Novo, Roni Even, Umesh Chandra and Avshalom Houri for their reviews
   and constructive input.






Barnes, et al.          Expires September 2, 2006              [Page 42]

Internet-Draft               XCON Framework                     Mar 2006


14.  Changes since last Version

   Changes from WG 02 to 03:

   - Updated the definition of Blueprint (per DP 4/4.1 discussions)

   - Added definition for Sidebar.

   - Section 5.2 Added text indicating that adding new elements or
   modifying elements requires the definition of a new template. (per
   DP4.2 conclusion).

   - Section 7.3.  Added text reiterating that the blueprint comprises
   both the common conference information and a template (per DP4/4.1
   discussions.

   - Section 7.3.  Added text per resolution of DP 4.3 indicating that a
   blueprint is common conference information + one template and that
   multiple templates is FFS.

   - Section 8.3 - Updated Conference Control Protocol section to
   include the protocols on the table for WG discussion as of 31 Dec
   2005 deadline.

   - Section 9.4 - Sidebars - added Ascii art to show FW interactions

   - Section 9.5 - Whisper - Added some text, reflecting past WG
   discussions.  Basic definition and further details/example still
   needed.

   - Section 9.6 - Conf Anncs and Recordings - Added some basic text.
   Further details/example still needed.

   Changes from WG 01 to 02:

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

   - Revamped abstract and introduction

   - Global removal of XCON as a qualifier (we had previously done this
   in a previous version with all the identifiers).

   - Global change of "call control signalling" to "call signaling"

   - Moved the terminology section after the Overview section:

   - - Modified the definitions to be more concise and per some of
   Henning's recommendations.



Barnes, et al.          Expires September 2, 2006              [Page 43]

Internet-Draft               XCON Framework                     Mar 2006


   - - Added definitions for blueprint and conference reservation.

   - Clarified the definition of policy and added more explicit text as
   to how policy is accomplished via the data model and system
   realization (section 4.3 and 6.1)

   - Removed the Editor's note/text in section 4 about the options for
   the schema; added a reference to a TBD schema document.

   - Section 5:

   - - clarified the identifiers.  Kept the logical definition as
   "identifiers", although most will be realized as URIs.

   - - deleted the section on conference instance.

   - - removed the term "umbrella" from sections conference User and
   conference object identifier sections

   - - moved alot of detail from Conference User Identifier and
   conference Object Identifier sections into appendices, and added
   additional detail, that will become the basis for separate documents.

   - In section 6:

   - - added a bit of explanation as to the intent of the cloning tree
   model - it's not implementation binding, but rather to illustrate the
   data model and context for the protocol interactions.

   - - removed the term copying altogether.  Cloning is the model and
   the idea is that the cloned object contains data indentical to the
   parent when it was created (whether it gets "copied" or whatever from
   the parent is an implementation issue).

   - - introduce the blueprint concept in section 6.1 prior to its
   implied usage in 6.2 and 6.3.

   - - removed the usage of the term occurrence (which is just a child
   reservation).

   - Removed security related details from Floor Control section and
   moved those to the security section.  As a result removed most of the
   editorial notes from the front of the Floor control section and
   integrated the remaining ones inline into that section, where the
   resolution should be documented.

   - Section 8:




Barnes, et al.          Expires September 2, 2006              [Page 44]

Internet-Draft               XCON Framework                     Mar 2006


   - - Added new example 8.1 - conference creation

   - - Added a placeholder for a more detailed example to the sidebar
   section to show a sidebar which has some media specifically
   associated with the sidebar (i.e. audio), yet still use the main
   conference for other media (visual presentation).

   - Section 11: As a result of adding additional information to the
   security section, divided this section into subsections for clarity.

   Changes from WG 00 to 01::

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

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

   - Section 3 (Next to the 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 2nd sentence and "performed" to "controlled" in the
   4th.

   - Section 5.  Rearranged the sub-sections a bit for better flow.
   First describe the Conference ID, then the Conference Instance,
   followed by the Conference Object, with the Conference Object
   Identifer described in a subsection of the Conference Object section.
   Added a diagram showing the relationship between Conference
   Identifer/Focus and Conference Object Identifier, within the context
   of a Conference Instance to the Conference Object section.

   - Section 6.1 (Cloning Tree).  Rewording to clarify which operations
   apply to independent objects (and non-independent).

   - Section 6.3 (Advanced Example).  Added additional text with regards
   to future conferences, introducing the concept of infinite series
   (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 to be more explicit
   about the XCON FW constructs used.

   Changes from individual 02 to WG 00:



Barnes, et al.          Expires September 2, 2006              [Page 45]

Internet-Draft               XCON Framework                     Mar 2006


   - few minor editorial changes

   - Section 2.  Removed second sentence of 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 new section (
   Section 6).

   - New section for Identifiers ( Section 6), thus all section
   references beyond 4 are incremented in the new version.

   - Section 4.  Since section 4.1 was removed, section 4.2 became the
   body text for section 4.

   - Section 4.2.  Added "Floor Information" to Figure 2 as part of
   Common Conference Information, also 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"
   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 to a series impact
   "all future occurrences (per DP1 discussion/conclusion).

   - Section 6.3 - Added subsections for discussion of CSCP and NETCONF
   as the CCP.

   - Section 6.4 - Floor Control.  Removed Editor's notes 2 and 3.
   Condensed the 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 be too basic.



Barnes, et al.          Expires September 2, 2006              [Page 46]

Internet-Draft               XCON Framework                     Mar 2006


   - Section 7.3 - added some proposed text for Sidebars.


15.  Appendix A - Conference Object Identifier

   [Editors Note: This appendix will be incorporated in a separate
   specification in the next release of this document and will include
   all relevant detail.]

   The conference object URI can be viewed as a key to accessing a
   specific conference object.  It is used by the Conference Control
   Protocol as described in Section 8.3 to access, manipulate and delete
   a conference object associated with a specific conference instance.
   A conference object identifier is provided to the Conference Control
   Client to enable such functions to be carried out.  This can either
   be returned through the Conference Control Protocol while creating a
   conference object, be provided by the conference notification service
   or through out-of-band mechanisms (e.g.  E-Mail).

   [Editors Note: Previous section to be expanded and more detail
   included.  It also needs to link up with other drafts and explicitly
   reference.]

   A centralized conferencing system, as defined in the Conference
   Framework [ref] has potential to expose a range of interfaces and
   protocols.  It is also possible that future centralized conferencing
   enhancements might place requirements to provide further additional
   protocols and interfaces.  A conference object can consist and be
   associated with many identifiers that are in some way related to a
   conference object.  Good examples include the Binary Floor Control
   Protocol (BFCP)[23] and call signaling protocols, such as SIP.  Each
   use unique identifiers to represent a protocol instance associated
   with a conference object.

   A conferencing system may maintain a relationship between the
   conference object URIs and the identifiers associated with each of
   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 a top level
   identifier within the conferencing system for the purpose of
   identifying the interfaces for these other protocols.  This implicit
   binding provides a structured mapping of the various protocols with
   the associated conference object identifier.  Figure 13 illustrates
   the relationship between the identifiers used for the protocols
   within this framework and the general conference object identifier.






Barnes, et al.          Expires September 2, 2006              [Page 47]

Internet-Draft               XCON Framework                     Mar 2006


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



   Figure 13: Conference Object Mapping.

   In Figure 13, the conference object identifier acts as the top level
   key in the identification process.  The call signaling protocols have
   an associated conference ID representation in the form of URIs.  The
   binary floor control protocol, as defined in [23], defines the
   'conf-id' identifier which represents a conference instance within
   floor control.  When created within the conferencing system, the
   'conf-id' has a 1:1 mapping to the unique conference object
   Identifier.  Operations associated with the Conference Control
   Protocols are directly associated with the conference object, thus
   the primary identifier associated with these protocols is the
   conference object identifier.  The mappings between additional
   protocols/interface is not strictly 1:1 and does allow for multiple
   occurrences.  For example, multiple call signaling protocols will
   each have a representation that is implicitly linked to the top level
   conference object identifier, for example, H323 and SIP URIs that
   represent a conference instance.  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 used.

   The following example illustrates the representation and
   relationships that might occur in a typical conference instance.  The
   table in Figure 14 lists a typical conference instance and related
   properties.









Barnes, et al.          Expires September 2, 2006              [Page 48]

Internet-Draft               XCON Framework                     Mar 2006


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


   Figure 14: Conference Table Representation

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


                              +--------------+
                              |  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 15: Conference Tree Representation

   Further elements can be added to the tree representation in Figure 15
   to enable a complete representation of a conference instance within a
   conferencing system.



Barnes, et al.          Expires September 2, 2006              [Page 49]

Internet-Draft               XCON Framework                     Mar 2006


   This style of association can be applied to any supplementary
   protocols or conferencing mechanisms that are applied to the
   centralized conferencing model defined in this document as long as a
   unique reference per conference instance is available that can be
   mapped to a conference object.

15.1.  Conference Object URI Definition

   [Editors Note: When the appendix split from the Framework document,
   full URI definition will be included.


16.  Appendix B - Conference User Identifier

   [Editors Note: This appendix will be incorporated in a separate
   specification in the 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 object identifier defined in
   Section 15, and by the conference control protocol to uniquely
   identify a user within the scope of conferencing system.  The
   conference control protocol uses the user identifier to uniquely
   determine who is issuing commands.  Appropriate policies can then be
   applied to the requested command.

   As with the conference object identifier, a number of supplementary
   user identifiers defined in other protocols are used within a
   conference instance.  Such user identifiers can be associated with
   this conference user identifier and enable the conferencing system to
   correlate and map these multiple authenticated user identities to the
   single user identifier.

   Figure 16 illustrates an example using the conference user identifier
   in association with the user identity defined for BFCP and SIP Digest
   user identity as defined in RFC3261[4], which would be 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 used.










Barnes, et al.          Expires September 2, 2006              [Page 50]

Internet-Draft               XCON Framework                     Mar 2006


                                  +---------------+
                                  |  Conference   |
                                  |     User      |
                                  |   Identifier  |
                                  +-------+-------+
                                          |
                                          |
                                          |
                          +---------------+---------------+
                          |                               |
                  +-------+-------+               +-------+-------+
                  |     BFCP      |               |   SIP Digest  |
                  |   'UserID'    |               |    Username   |
                  +---------------+               +-------+-------+


   Figure 16: Conference User Identifier

   Within a conferencing system, a user is identified by a single
   conference user identifier.  Any additional conferencing mechanisms
   that contain a protocol specific user ID can be associated with the
   conference user identifier, as illustrated in Figure 16.  This
   mechanism allows conferencing systems to manage and relate system
   wide user identities in relation to specific conference objects and
   helps in the enforcement of system wide policies.

   The following example illustrates the representation and
   relationships that might occur in a typical conference instance.  The
   table in Figure 17 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 17: User Identitier Representation

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








Barnes, et al.          Expires September 2, 2006              [Page 51]

Internet-Draft               XCON Framework                     Mar 2006


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



   Figure 18: User ID Tree Representation

   Further elements can be added to the tree representation in Figure 15
   to enable a complete representation of a conference instance within a
   conferencing system.

16.1.  Conference User Definition

   [Editors Note: When the appendix is split from the Framework
   document, full definition will be included.


17.  References

17.1.  Normative References

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

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.




Barnes, et al.          Expires September 2, 2006              [Page 52]

Internet-Draft               XCON Framework                     Mar 2006


   [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),
         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-05 (work in progress),
         September 2005.

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



Barnes, et al.          Expires September 2, 2006              [Page 53]

Internet-Draft               XCON Framework                     Mar 2006


         June 2005.

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

   [17]  Schulzrinne, H., "COMP: Conference Object Manipulation
         Protocol", draft-schulzrinne-xcon-comp-00 (work in progress),
         January 2006.

   [18]  Boulton, C. and M. Barnes, "Centralized Conferencing
         Manipulation Protocol", draft-barnes-xcon-ccmp-00 (work in
         progress), January 2006.

   [19]  Levin, O., "Centralized Conference Control Protocol",
         draft-levin-xcon-cccp-04 (work in progress), January 2006.

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

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

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

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

   [24]  Campbell, B., "The Message Session Relay Protocol",
         draft-ietf-simple-message-sessions-14 (work in progress),
         February 2006.

   [25]  Jennings, C., "Conference State Change Protocol (CSCP)",
         draft-jennings-xcon-cscp-02 (work in progress), December 2005.

   [26]  Enns, R., "NETCONF Configuration Protocol",
         draft-ietf-netconf-prot-11 (work in progress), February 2006.








Barnes, et al.          Expires September 2, 2006              [Page 54]

Internet-Draft               XCON Framework                     Mar 2006


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

























Barnes, et al.          Expires September 2, 2006              [Page 55]

Internet-Draft               XCON Framework                     Mar 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Barnes, et al.          Expires September 2, 2006              [Page 56]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/