idnits 2.17.1 draft-ietf-xcon-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2004. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2017. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 60 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 139 has weird spacing: '...r) and the...' == Line 182 has weird spacing: '...ons and limit...' == Line 513 has weird spacing: '...ons and limit...' == Line 522 has weird spacing: '... The permis...' == Line 538 has weird spacing: '...section provi...' == (22 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 15, 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD' on line 716 == Unused Reference: '3' is defined on line 1868, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1879, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1946, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '2') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '3') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '6') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. '8') (Obsoleted by RFC 5545) == Outdated reference: A later version (-05) exists of draft-ietf-xcon-conference-scenarios-04 == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-04 == Outdated reference: A later version (-04) exists of draft-levin-xcon-cccp-02 == Outdated reference: A later version (-03) exists of draft-jennings-xcon-media-control-02 == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-10 == Outdated reference: A later version (-02) exists of draft-jennings-xcon-cscp-00 == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-07 Summary: 4 errors (**), 0 flaws (~~), 19 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Expires: January 16, 2006 C. Boulton 5 Ubiquity Software Corporation 6 O. Levin 7 Microsoft Corporation 8 July 15, 2005 10 A Framework and Data Model for Centralized Conferencing 11 draft-ietf-xcon-framework-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 16, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document defines the framework for Centralized Conferencing 45 (XCON), which is applicable to participants using different call 46 control signaling protocols and exchanging media over networks with 47 potentially different characteristics. The XCON Framework defines 48 the XCON data model, the XCON logical entities, the naming 49 conventions, and outlines the standard conferencing protocols 50 (complementary to the call control signalling protocols) for building 51 advanced conferencing applications. The framework binds all the 52 defined components together for the benefit of conferencing system 53 builders. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. XCON Data Model . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1 Common Conference Information . . . . . . . . . . . . . . 11 62 4.2 Conference Template . . . . . . . . . . . . . . . . . . . 12 63 4.3 Conference policies . . . . . . . . . . . . . . . . . . . 12 64 5. XCON Constructs and Identifiers . . . . . . . . . . . . . . . 13 65 5.1 Conference Identifier . . . . . . . . . . . . . . . . . . 13 66 5.2 Conference Instance . . . . . . . . . . . . . . . . . . . 13 67 5.3 Conference Object . . . . . . . . . . . . . . . . . . . . 14 68 5.3.1 Conference Object Identifier . . . . . . . . . . . . . 16 69 5.4 Conference User Identifier . . . . . . . . . . . . . . . . 17 70 6. Conferencing System Realization . . . . . . . . . . . . . . . 18 71 6.1 Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 19 72 6.2 Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 21 73 6.3 Advanced Example . . . . . . . . . . . . . . . . . . . . . 22 74 6.4 Scheduling a 'Conference Object for Reservation' . . . . . 24 75 7. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 28 76 7.1 Call Control Signalling . . . . . . . . . . . . . . . . . 28 77 7.2 Notifications . . . . . . . . . . . . . . . . . . . . . . 28 78 7.3 Conference Control Protocol . . . . . . . . . . . . . . . 28 79 7.3.1 CPCP . . . . . . . . . . . . . . . . . . . . . . . . . 29 80 7.3.2 CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 30 81 7.3.3 CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 30 82 7.3.4 NETCONF . . . . . . . . . . . . . . . . . . . . . . . 30 83 7.3.5 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 7.4 Floor Control . . . . . . . . . . . . . . . . . . . . . . 31 85 8. Conferencing Scenario Realizations . . . . . . . . . . . . . . 33 86 8.1 Participant Manipulations . . . . . . . . . . . . . . . . 33 87 8.2 Media Manipulations . . . . . . . . . . . . . . . . . . . 35 88 8.3 Sidebar Manipulations . . . . . . . . . . . . . . . . . . 36 89 8.4 Whispering or Private Messages . . . . . . . . . . . . . . 38 90 8.5 Conference Announcements and Recordings . . . . . . . . . 38 91 9. Relationships between SIPPING and XCON Frameworks . . . . . . 38 92 10. Security Considerations . . . . . . . . . . . . . . . . . . 38 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 95 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 41 96 14. Changes since last Version . . . . . . . . . . . . . . . . . 41 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 98 15.1 Normative References . . . . . . . . . . . . . . . . . . . 43 99 15.2 Informative References . . . . . . . . . . . . . . . . . . 43 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 101 Intellectual Property and Copyright Statements . . . . . . . . 47 103 1. Introduction 105 This document defines the framework for Centralized Conferencing 106 (XCON), which is applicable to participants using various call 107 signalling protocols (such as SIP, H.323, Jabber, HTML, PSTN, etc.) 108 and exchanging media over networks with potentially different 109 characteristics. 111 The XCON Framework defines the XCON data model, the XCON logical 112 entities, the naming conventions, and outlines the standard 113 conferencing protocols (complementary to the call control signalling 114 protocols) for building advanced conferencing applications. The 115 framework binds all the defined components together for the benefit 116 of conferencing system builders. 118 The XCON Framework is compatible with the functional model presented 119 in the SIPPING Conferencing Framework [9] . Section 9 of this 120 document discusses the relationship between the XCON Framework and 121 the SIPPING Conferencing framework, in the context of the XCON 122 architecture. 124 2. Conventions and Terminology 126 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 127 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 128 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 129 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 130 compliant implementations. 132 The XCON Framework document both generalizes, when appropriate, the 133 SIPPING Conferencing Framework [9] terminology and introduces new 134 concepts as listed below. 136 Active Conference: The term Active Conference refers to a Conference 137 Object that's been created (for example, using a "blueprint") and 138 "activated" via the allocation of its identifiers (i.e. 139 Conference Object Identifier, Conference Identifier) and the 140 associated Focus. 141 Call (Control) Signalling: The protocol used between a participant 142 and a Focus. In this context, the term "call" means a channel or 143 session used for media streams establishment. Protocol examples 144 include, but are not limited to, SIP, H.323, MSRP, Jabber, HTML 145 and PSTN signalling. Other than references to general 146 functionality required (e.g. establishment and teardown), details 147 of these protocols are outside the scope of this document. 149 Common Conference Information: The data type (i.e. the XML schema) 150 which is used to represent the fixed information part of a 151 Conference Object. It includes a common set of definitions for 152 basic conference features, such as conference identifiers, 153 membership, signalling, capabilities, media, etc. 154 Conference Control Protocol (CCP): A protocol used by clients to 155 manipulate a Conference Object [Section 7.3]. 156 Conference Factory: A logical entity that, upon request, generates 157 unique URI(s) to identify and represent a conference Focus. The 158 Conference Factory is typically used in the conference creation 159 process via a signalling interface and non-signalling methods such 160 as Conference Control Protocol [Section 7.3] and proprietary 161 mechanisms. 162 Conference Identifier(ID): The call signalling protocol-specific URI 163 that uniquely identifies a conference Focus and its associated 164 Conference Instance. 165 Conference Instance: An instantiation of a Conference Object. The 166 Conferencing System associates a Conference Instance with the 167 Conference Identifier(s). There is a one-to-one mapping between a 168 Conference Instance and a conference Focus. 169 Conference Object: A representation of a conference at a certain 170 stage (e.g. description upon conference creation, reservation, 171 activation, etc.), which a Conferencing System maintains in order 172 to describe the system capabilities and to provide access to the 173 available services provided by the Conferencing System. All 174 Conference Objects are of type 'Conference Object Type' which is 175 comprised of two distinct sub components; the 'Common Conference 176 Information' and the 'Conference Template' (see definitions in 177 this section for details). 178 Conference Object Identifier (ID): A [TBD schema name] URI which 179 uniquly identifies a Conference Object and is being used by a 180 Conference Control Protocol [Section 7.3]. 181 Conference policies: A term which is used to collectively refer to a 182 virtual set of rights, permissions and limitations pertaining to 183 operations being performed on a certain Conference Object. The 184 term is described in more details in Section 4.3. 185 Conference State: The state of a Conference Instance as represented 186 using the Conference Package mechanism defined in [11]. 187 Conferencing System: The term used to refer to a conferencing 188 solution (system) that is based on the set of specifications and 189 is built using the protocols and the data model defined by the 190 XCON working group within the IETF. 191 Conference Template: The data type (i.e. the XML schema) which is 192 used to represent the variable information part of the Conference 193 Object. It can be included in the Conference Object to represent 194 enhanced conferencing capabilities (e.g. media mixers, etc.) 195 and/or user interface abstraction. 197 Floor: A term which is used to refer to a set of data or resources 198 associated with a Conference Instance, for which a conference 199 participant (or group of participants) is granted temporary input 200 access. 201 Floor Chair: A Floor control protocol compliant client (human 202 participant or automated entity) who is authorized to manage 203 access to one floor (grants, denies, or revokes a floor). The 204 floor chair does not have to be a participant in the Conference 205 Instance. 206 Focus: Focus is a logical entity that maintains the call signalling 207 interface between each participating client (i.e. participant) and 208 the Conference Instance. As such, the Focus acts as an endpoint 209 for each of the supported signalling protocols and is responsible 210 for all primary conference membership operations (e.g. join, 211 leave, update the Conference Instance) and for media negotiation/ 212 maintenance between a conference participant and the Focus. There 213 is a one-to-one mapping between the Focus and its Conference 214 Instance. Focus is addressed by explicitly associated unique 215 conference URIs for each signalling protocol, supported for its 216 Conference Instance. 217 Media Graph: The logical representation of the flow of media for a 218 conference. 219 Media Mixer: A logical entity that has the capability to combine 220 media inputs of the same type (or/and transcode the media) and 221 distribute the result(s) to a single or multiple outputs. In this 222 context, the term "media" means any type of data being delivered 223 over the network using appropriate transport means, such as RTP/ 224 RTCP (defined in RFC 3550[7]), Message Session Relay Protocol 225 (defined in [25]), etc. 226 Registered Conference Document : An official standards document (RFC) 227 that defines and registers a Conference Template schema with the 228 appropriate standards body (IANA). A 'Registered Conference 229 Document' also includes any complimentary textual information in 230 relation to the conference template schema and its meaning. 231 Role: Represents differing membership categories that a conference 232 participant can assume within a conference. Each category has a 233 difference set of conference operations that a participant can 234 perform. A default (e.g. Standard Conference Participant) 'Role' 235 will always exist which provides a standard user with a set of 236 basic conference operations. Any user with appropriate 237 authentication and authorization may assume a role that has a 238 wider set of conference operations that are otherwise not 239 available (to a standard Conference Participant) - e.g. A 'Role' 240 called 'Conference Moderator' may exist that has additional 241 conference operations such as 'modify conference end time'. 243 Sidebar: TBD. 244 Whisper: TBD. 246 3. Overview 248 A centralized conference is an association of endpoints (called 249 conference participants) with a central endpoint (called a conference 250 Focus) where the Focus has direct peer-wise relationships with the 251 participants by maintaining a separate call control signalling 252 interface with each. Consequently, in this tightly coupled model, 253 the call control signalling graph is always a star. 255 The most basic conference supported would be an ad-hoc unmanaged 256 conference, which would not necessarily require any of the 257 functionality defined within this framework. For example, it could 258 be supported using basic SIP signalling functionality with a 259 participant serving as the Focus; the SIPPING Conferencing Framework 260 [9] together with the SIP Call Control Conferencing for User 261 Agents[15] documents address these types of scenarios. 263 An XCON-compliant Conferencing System, in addition to the basic 264 features, can offer richer functionality including dedicated 265 conferencing applications with explicitly defined capabilities, 266 reserved reoccurring conferences, and the standard protocols for 267 managing and controlling different conference aspects. 269 The core requirements for tightly managed centralized conferencing 270 are outlined in [10]. These requirements are applicable for 271 conferencing systems using various call control signalling protocols, 272 not restricted to SIP alone. Additional conferencing requirements 273 are provided in [12], [13], and [14]. 275 The XCON architecture is built around a fundamental concept of a 276 Conference Object. A Conference Object is a logical representation 277 of a Conference Instance. For conference creation, a Conference 278 Object provides a "blueprint" representing the System Capabilities. 279 A conference object also provides the logical representation of a 280 conference during each of the various stages of a conference (e.g. 281 reservation, active, completed, etc.). A Conference Object is 282 accessible using XCON protocols (e.g. a Conference Control Protocol 283 [Section 7.3]. 285 A Conferencing System can support any subset of the conferencing 286 functions depicted in the Conferencing System logical decomposition 287 in Figure 1 and described in this document. Nevertheless, typically 288 advanced functions could not be implemented without implementing 289 others. For example, the Notification Service is an essential 290 component required for implementing almost any advanced functionality 291 and being used, among other things, for correlation of information 292 (such as list of participants with their media streams) between 293 otherwise distinct functions. 295 ...................................................................... 296 . Conferencing System . 297 . . 298 . +-----------------------------------------------------+ . 299 . | C O N F E R E N C E O B J E C T | . 300 . +-+---------------------------------------------------+ | . 301 . | C O N F E R E N C E O B J E C T | | . 302 . +-+---------------------------------------------------+ | | . 303 . | C O N F E R E N C E O B J E C T | | | . 304 . | | | | . 305 . | | |-+ . 306 . | |-+ . 307 . +-----------------------------------------------------+ . 308 . ^ ^ ^ | . 309 . | | | | . 310 . v v v v . 311 . +-------------------+ +--------------+ +-------+ +------------+ . 312 . | Conference Control| | Floor Control| |Foci | |Notification| . 313 . | Server | | Server | | | |Service | . 314 . +-------------------+ +--------------+ +-------+ +------------+ . 315 . ^ ^ ^ | . 316 ................|.................|...........|..........|............ 317 | | | | 318 |Conference |BFCP |SIP/ |SIP NOTIFY/ 319 |Control | |PSTN/ |Etc. 320 |Protocol | |H.323/ | 321 | | |T.120/ | 322 | | |Etc. | 323 ................|.................|...........|..........|............ 324 . V V V V . 325 . +----------------+ +------------+ +----------+ +------------+ . 326 . | Conference | | Floor | | Call | |Notification| . 327 . | Control | | Control | | Control | | Client | . 328 . | Client | | Client | | Client | | | . 329 . +----------------+ +------------+ +----------+ +------------+ . 330 . . 331 . Conferencing Client . 332 ...................................................................... 334 Figure 1: Conferencing System Logical Decomposition. 336 The media graph of a conference can be centralized, de-centralized, 337 or any combination of both and potentially differ per media type. In 338 the centralized case, the media sessions are established between a 339 media mixer controlled by the focus and each one of the participants. 340 In the de-centralized (i.e. distributed) case, the media graph is a 341 (multicast or multi-unicast) mesh among the participants. 342 Consequently, the media processing (e.g. mixing) can be controlled 343 either by the focus alone or by the participants. The concepts in 344 this framework document clearly map to a centralized media model. 345 The concepts can also apply to the de-centralized media case, 346 however, the details of such are left for future study by the XCON WG 347 charter. 349 Section 4 of this document provides more details on the Conference 350 Object. Section 5 provides an overview of the identifiers necessary 351 to address and manage the Conference Objects, Instances and Users 352 associated with a Conferencing System. Section 6 of this document 353 describes how a Conferencing System is logically built using the 354 defined data model and how the Conference Objects are maintained. 355 Section 7 describes the fundamental conferencing mechanisms and 356 provides a high level overview of the XCON protocols. Section 8 then 357 provides realizations of various conferencing scenarios, detailing 358 the manipulation of the Conference Objects using XCON defined 359 protocols. Section 9 of this document summarizes the relationship 360 between the XCON Framework and the SIPPING Conferencing Framework. 362 4. XCON Data Model 364 The XCON data model defined in this framework has no strict 365 separation between conference membership, conference media 366 information and the related policies (i.e. the capabilities and 367 limitations for each). This approach meets the requirement in many 368 conference control operations to enable synchronized access to the 369 conference policies as a whole, to the conference state as a whole, 370 and for receiving notifications about changes to either. 372 A Conference Object is of type 'Conference Object Type' which is 373 comprised of two distinct components: the 'Common Conference 374 Information Type' and the 'Conference Template Type', as illustrated 375 in Figure 2. Each of these types is a placeholder for including 376 potentially multiple sub-types. 378 +------------------------------------------------------+ 379 | C O N F E R E N C E O B J E C T T Y P E | 380 | | 381 | +--------------------------------------------------+ | 382 | | COMMON CONFERENCE INFORMATION TYPE | | 383 | | | | 384 | | +----------------------------------------------+ | | 385 | | | Conference Description | | | 386 | | +----------------------------------------------+ | | 387 | | +----------------------------------------------+ | | 388 | | | Membership (Roles, Capacity, Names) | | | 389 | | +----------------------------------------------+ | | 390 | | +----------------------------------------------+ | | 391 | | | Signaling (Protocol, Direction, Status) | | | 392 | | +----------------------------------------------+ | | 393 | | +----------------------------------------------+ | | 394 | | | Floor Information | | | 395 | | +----------------------------------------------+ | | 396 | | +----------------------------------------------+ | | 397 | | | Sidebars, Etc. | | | 398 | | +----------------------------------------------+ | | 399 | | | | 400 | +--------------------------------------------------+ | 401 | +--------------------------------------------------+ | 402 | | CONFERENCE TEMPLATE TYPE | | 403 | | | | 404 | | - Mixer algorithm, inputs, and outputs | | 405 | | - Floor controls | | 406 | | - User Control Interface | | 407 | | - User's View | | 408 | | - Etc. | | 409 | +--------------------------------------------------+ | 410 | | 411 +------------------------------------------------------+ 413 Figure 2: Conference Object Type Decomposition. 415 Since, in an XCON-compliant system the same Conference Object Type is 416 used for representation of a conference for different purposes, such 417 as expressing Conferencing System capabilities, reserving 418 conferencing resources or reflecting the state of ongoing 419 conferences, each of the two components (i.e., the Common Conference 420 Information and the Conference Template) is syntactically optional to 421 be included in a particular Conference Object. Section 6 describes 422 the usage semantics of the Conference Objects. 424 [Editor's Note: The exact XML schema of the Conference Object (i.e. 426 the organization of the Common Conference Information and the 427 Conference Template) is an open issue (Discussion Point 4 on the 428 mailing list), which has been summarized as the three potential 429 alternatives below: 431 1. The top-level information is the template section, and it 432 contains a subsection that is the common conference information. 433 This has the advantage that the schema can all be well defined: 434 because the common conference information is known at the time the 435 template is developed, the appropriate schema definition can be 436 inserted into the template schema. The downside is that this setup 437 requires navigation of the template information to get to the common 438 information, which is likely to be manipulated most frequently. 440 2. The top-level information is the common conference information, 441 which contains the template information. This has the advantage that 442 clients don't even need to care about the template being used to 443 allow rendering and control over basic conference functionality(which 444 will suffice for many clients (e.g. those with limited screen). The 445 downside is that the common conference information schema must 446 include an extension point to allow new templates to hook into the 447 schema. This may make schema validation more difficult. 449 3. The template information and common conference information are 450 conveyed as two separate objects (e.g. using multipart MIME). This 451 provides the benefits of allowing completely separate schema, 452 straightforward schema validation, and easy access to the common 453 conference information. The downside is that any mechanism for 454 separating the schema is going to add some amount of protocol 455 complexity and the need for synchronization between the two data 456 objects. Note that it has been argued that it is increasingly 457 difficult to find a potential client of the XCON protocols that 458 doesn't already support multipart MIME). 460 The model put forth in this document is the result of the consensus 461 reached during the XCON second interim meeting in Boston and depicts 462 option 2 above. With slight adaptations it can also support option 463 3. ] 465 4.1 Common Conference Information 467 The common conference information section contains the core 468 information that is utilized in any conference and can be abstracted 469 regardless of the specific conference media nature (e.g. the mixing 470 algorithms performed, the advanced floor control applied, etc.). 471 Typically, participants with read-only access to the conference 472 information would be interested in this common information only. 474 The basic common conference information can be represented using the 475 conference-info-type schema as defined in [11]. This schema contains 476 the definitions for representation of the Conference Object 477 capabilities, membership, roles, call control signalling and media 478 statuses relevant to different stages of the conference life-cycle. 480 New XCON specifications can extend the basic conference-info-type and 481 introduce additional schemas to be used within the common conference 482 information type placeholder. 484 4.2 Conference Template 486 The concept of a "Conference Template" is introduced to abstract the 487 complexity and the details of the "mixer" and other conferencing 488 features and to allow for easy user interface abstraction for 489 advanced Conferencing Systems. 491 Each Conference Template needs to be registered with IANA. The IANA 492 registration needs to point to an RFC having the text description of 493 the feature behavior and optionally the XML definition allowing the 494 feature presentation, configuration, and management. RFCs of this 495 kind are referred by XCON documents as a "Registered Conference 496 Document". 498 Typically, a conference template would contain the information about 499 the specific media mixing details, the associated client roles and 500 the available floor controls. This information would allow 501 authorized clients to manipulate mixer's behavior and the resultant 502 distribution of the media to all or individual participants. By 503 doing so, a client can change its own state and/or state of other 504 participants in the conference. 506 A conference template can also include an abstract user interface 507 definition in terms of sliders, radio boxes, etc. for simplifying 508 user interaction with a specific non-trivial feature. 510 4.3 Conference policies 512 Conference policies is the term used to collectively refer to a 513 virtual set of rights, permissions and limitations pertaining to 514 operations being performed on a certain Conference Object. 516 The virtual set of rights describes the read/write access privileges 517 for the Conference Object as a whole. This access would usually be 518 granted and defined in terms of giving the read-only or read-write 519 access to clients with certain roles in the conference. For details 520 see [TBD]. 522 The permissions and limits are specified as an integral part of the 523 Conference Object Type, with data objects containing the allowed 524 ranges for other data objects (e.g. maximum number of participants) 525 and lists of clients allowed to perform certain operations on a 526 conference object. For example, the "allowed to join" list of 527 participants is consulted to decide who is allowed to join. The 528 entries in the list can specify the identity of an individual user 529 (joe@example.com), a role, a domain (*@example.com), etc. For 530 details see [TBD]. 532 A more general rule mechanism, beyond the functionality provided by 533 the permissions and limits, is an item for future study for the XCON 534 WG. 536 5. XCON Constructs and Identifiers 538 This section provides details of the identifiers associated with the 539 XCON constructs (e.g. Conference Object and Conference Instance) and 540 the identifiers necessary to address and manage the clients 541 associated with a Conferencing System. An overview of the 542 allocation, characteristics and functional role of the identifiers is 543 provided. 545 5.1 Conference Identifier 547 The Conference Identifier (ID) is the call signalling protocol- 548 specific URI that uniquely identifies a Conference Instance and a 549 conference Focus. The Conference Factory is the logical entity that 550 generates the unique Conference ID to identify and represent a 551 conference Focus. The Conference Factory is typically used in the 552 conference creation process via a signalling interface and non- 553 signalling methods such as Conference Control Protocol [Section 7.3] 554 and proprietary mechanisms. 556 5.2 Conference Instance 558 A Conference Instance is an internal implementation construct of a 559 conference, which is accessible by call signalling means, thus no 560 explicit identifier is required. Note that a Conference Instance can 561 have more than a single Conference Identifier, for example, for each 562 call signalling protocol supported. There is a one-to-one mapping 563 between a Conference Instance and a conference Focus. The Focus is 564 addressed by explicitly associating unique Conference IDs for each 565 signalling protocol supported by its Conference Instance. 567 A single Conference Instance can be internally mapped to a single or 568 multiple Conference Objects; each of them accessible by a Call 569 Control protocol. 571 5.3 Conference Object 573 A Conference Object is the logical representation of a Conference 574 Instance at a certain stage, such as a "blueprint" representing a 575 Conferencing System's capabilities, the data representing a reserved 576 or scheduled conference, or the conference state during an active 577 conference. The Conferencing System exposes this data as separate 578 objects to allow independent access. Consequently, the XCON 579 specifications allow the association of multiple Conference Objects 580 with a single Conference Instance. 582 Figure 3 illustrates the relationships between the Conference 583 Identifier, the Focus and the Conference Object Identifier within the 584 context of a logical Conference Instance, with the Conference Object 585 corresponding to an ongoing conference (i.e. a conference in the 586 active state). The Conference Object is identified by a single or a 587 set of call signaling Conference Identifiers, with a one-to-one 588 mapping, as shown in the figure. 590 The Conference Objects corresponding to additional conference stages 591 are addressing using CCP [Section 7.3]. CCP will define the 592 necessary logical naming conventions for addressing additional 593 Conference Objects, within the context of the cloning tree concept 594 introduced in Section 6. 596 ...................................................................... 597 . Conference Instance . 598 . . 599 . . 600 . +---------------------------------------------------+ . 601 . | Conference Object Identifier | . 602 . | | . 603 . | | . 604 . +---------------------------------------------------+ . 605 . ^ ^ . 606 . | | . 607 . v | . 608 . ................................................... | . 609 . . Focus . | . 610 . . . | . 611 . . +----------------------------------+ . | . 612 . . |Conference Identifier (Protocol Y)| . | . 613 . . +------------------------------------+ | . | . 614 . . | Conference Identifier (PSTN) | | . | . 615 . . +--------------------------------------+ |-+ . | . 616 . . | Conference Identifier (SIP) | |^ . | . 617 . . | |-+| . | . 618 . . | |^ | . | . 619 . . +--------------------------------------+| | . | . 620 . ............^...............................|.|.... | . 621 . | | | | . 622 ................|...............................|.|......|............ 623 | | | | 624 |SIP | | |Conference 625 | PSTN | |Y |Control 626 | | | |Protocol 627 | +---------------+ | | 628 | | | | 629 | | | | 630 v v v v 631 +----------------+ +--------------+ +---------------+ 632 | Conferencing | | Conferencing | | Conference | 633 | Client | | Client | | Client | 634 | 1 | | 2 | | X | 635 +----------------+ +--------------+ +---------------+ 637 Figure 3: Conference Identifer, Focus, Conference Instance and 638 Conference Object Identifier Relationships. 640 5.3.1 Conference Object Identifier 642 In order to make each Conference Object externally accessible, the 643 Conferencing System allocates a unique URI per distinct Conference 644 Object in the system, as defined in [ref:TBD]. A Conference Control 645 Protocol [as outlined in Section 7.3] can then be used for directly 646 manipulating a particular Conference Object and for obtaining its 647 current state. 649 The Conference Object URI acts as a top level identifier for an 650 'umbrella style' construct within the Conference System for the 651 purpose of identifying incoming connections for complimentary XCON 652 protocols (e.g. BFCP). This implicit binding provides a structured 653 mapping of the various XCON protocols with the associated Conference 654 Object Identifier. As an example, Figure 4 illustrates how BFCP 655 connections fall under the general Conference Object identifier 656 umbrella. 658 +--------------+ 659 | Conference | 660 | Object | 661 | Identifier | 662 +--------------+ 663 | 664 | 665 | 666 +-------+-------+ 667 | BFCP 'confid' | 668 +-------+-------+ 669 | 670 | 671 +---------------+---------------+ 672 | | 673 +-------+-------+ +-------+-------+ 674 |BFCP 'floorid' | |BFCP 'floorid' | 675 +-------+-------+ +-------+-------+ 677 Figure 4: Conference Object Mapping. 679 In Figure 4, the Conference Object Identifier acts as the top level 680 key in the identification process. The BFCP protocol, as defined in 681 [24], defines the 'conf-id' identifier which represents a conference 682 instance within Floor Control. BFCP also defines the 'floorid' 683 identifier for specific floors within a Conference instance. When 684 created within the Conference System, the 'conf-id' has a 1:1 mapping 685 to the unique XCON Conference Object Identifier. Using the BFCP 686 example, the Conference System is able to map the floor request to 687 the associated Conference Object. 689 This umbrella style association can be applied to any supplementary 690 mechanisms that are applied to the XCON model defined in this 691 document as long as a unique reference per conference instance is 692 available that can be mapped to a Conference Object. 694 [Editor's Note: The URI schema name per TBD must be registered with 695 IANA.] 697 5.4 Conference User Identifier 699 Section 5.3.1 discusses the concept of an umbrella mechanism for 700 associating various protocol identifiers with a top level XCON 701 identifier. This section outlines a similar umbrella mechanism for 702 the purpose of correlating users of supplementary XCON protocols 703 under one universal XCON identity within an XCON Conference System. 705 It is important to emphasize that the Conference User Identifier 706 being described must be in the context of the Conference System. 707 This is due to the requirement for identity of Conference System 708 users who may not be participating in a Conference Instance. 709 Examples being a non participating 'Floor Control Chair' or 'Media 710 Policy' Controller. Users can then be associated with Conference 711 Objects as defined in Section 5.3.1. This association enables the 712 Conference System to associate and enforce user level policies at 713 both a system level and Conference Object level. 715 Each user within a Conference System is allocated a unique Conference 716 User Identifier, as defined in [TBD]. This identifier acts as a top 717 level identifier, in a similar fashion to that defined for the 718 Conference Object Identifier described in Section 5.3.1. User 719 identifiers defined in other protocols that are used within a 720 Conference Instance fall underneath the top level identifier and 721 enable the Conference System to correlate and map authentication 722 under the single user umbrella. 724 Figure 5 illustrates an example using the Conference User Identifier 725 in association with the user identity defined for BFCP and SIP Digest 726 user identity as defined in RFC3261[4] 727 +---------------+ 728 | Conference | 729 | User | 730 | Identifier | 731 +-------+-------+ 732 | 733 | 734 | 735 +---------------+---------------+ 736 | | 737 +-------+-------+ +-------+-------+ 738 | BFCP | | SIP Digest | 739 | 'UserID' | | Username | 740 +---------------+ +-------+-------+ 742 Figure 5: Conference Object Mapping. 744 Within a Conference System, a user is identified by a single 745 Conference User Identifier. Any other XCON mechanisms that contain a 746 protocol specific user ID can be associated with the 'Conference User 747 Identifier', as illustrated in Figure 5. This mechanism allows 748 conference systems to manage and relate system wide user identities 749 in relation to specific Conference Objects and helps in the 750 enforcement of system wide policies. 752 6. Conferencing System Realization 754 XCON-compliant implementations can range from systems supporting ad- 755 hoc conferences, with default behavior only, to sophisticated systems 756 with the ability to schedule re-occurring conferences (each with 757 distinct characteristics), being integrated with external resource 758 reservation tools, and providing snapshots of the conference 759 information at any of the stages of the conference life-cycle. 761 A Conference Object is the logical representation of a Conference 762 Instance at a certain stage, such as capabilities description upon 763 conference creation, reservation, activation, etc., which a 764 Conferencing System maintains in order to describe the system 765 capabilities and to provide access to the available services provided 766 by the Conferencing System. 768 Consequently, the XCON specifications don't mandate the actual usage 769 of the Conference Object, but rather defines the general cloning tree 770 concept and the mechanisms required for its realization, which is 771 described in detail in Section 6.1. 773 Adhoc and advanced conferencing examples are provided in Section 6.2 774 and Section 6.3, with the latter providing additional description of 775 the Conference Object in terms of the stages of a conference, to 776 support scheduled and other advanced conference capabilites. 778 The scheduling of a conference based on these concepts and mechanisms 779 is then detailed in Section 6.4 781 6.1 Cloning Tree 783 The concept defined in this section is a logical representation only, 784 as it is reflected through the XCON mechanisms: the URIs and the 785 protocols. Of course, the actual system realization can differ from 786 the presented model and doesn't require physical copying of the 787 information, etc. 789 Any Conference Object in a Conferencing System is created by either 790 being explicitly cloned from an existing parent object or being 791 implicitly cloned from a default system object. This document uses 792 the "cloning" metaphor instead of the "inheritance" metaphor because 793 it more closely fits the object replication and extension concept, 794 rather than data type re-usage and extension concept. 796 The cloning operation needs to specify whether the link between the 797 parent and the child needs to be maintained in the system or not. If 798 no link between the parent and the child exists, the objects become 799 independent and are not impacted by any operations on the parent 800 object nor subject to any limitations of the parent object. 802 By default, all the data existing in the parent object is copied to 803 the newly created object. 805 Once the new object is created, it can be addressed by a unique 806 Conference Object URI assigned by the system, as described in 807 Section 5.3.1 809 By default, the newly created object can expand the data it contains, 810 within the schema types supported by the parent. It can also 811 restrict the read/write access to its objects. However, unless the 812 object is independent, it cannot relax the access relative to its 813 parent's access. 815 Any piece of data in the child object can be independently accessed 816 and, by default, can be independently modified without affecting the 817 parent data. 819 Unless the object is independent, the parent object can enforce a 820 different policy by marking certain data elements as "parent 821 enforceable". The values of these data objects can not be changed by 822 directly accessing the child object; neither can they be expanded in 823 the child object alone. 825 In the future, XCON specifications may introduce logical 826 relationships, in addition to the "parent enforceable", between 827 elements being cloned from one another. 829 +---+-----------------------+ 830 | p | | 831 | o | P A R E N T A | 832 | l | | 833 | i | C O N F E R E N C E | 834 | c | | 835 | i | O B J E C T | 836 | e | | 837 +-s-+-----------------------+ 838 | 839 \| / 840 \/ INDEPENDENT 841 /\ 842 /| \ 843 V 844 +---+-----------------------+ 845 | p | | 846 | o | P A R E N T B | 847 | l | | 848 | i | C O N F E R E N C E | 849 | c | | 850 | i | O B J E C T | 851 | e | | 852 +-s-+-----------------------+ 853 | | 854 | | 855 | --------------------------- 856 | | 857 V V 858 +---+-----------------------+ +---+-----------------------+ 859 | p | | | p | | 860 | o | C H I L D 1 | | o | C H I L D 2 | 861 | i | | | l | | 862 | l | C O N F E R E N C E | | i | C O N F E R E N C E | 863 | i | | | c | | 864 | c | O B J E C T | | i | O B J E C T | 865 | i | | | e | | 866 +-s-+-----------------------+ +-s-+-----------------------+ 867 Figure 6: The Cloning Tree. 869 Using the defined cloning model and its tools, the following sections 870 show examples of how different XCON-compliant systems can be 871 realized. 873 6.2 Ad-hoc Example 875 Figure 7 illustrates how an ad-hoc conference can be created and 876 managed in a conferencing system. 878 A client can create a conference by establishing a call control 879 signalling channel with a Conference Factory as specified in 880 Section 5.1. The Conference Factory can internally select one of the 881 system supported Conference Object blueprints based on the requesting 882 client privileges and the media lines included in the SDP body. 884 The selected blueprint with its default values is copied by the 885 server into a newly created Conference Object, referred to as an 886 'Active Conference'. At this point the Conference Object becomes 887 independent from its blueprint. A new Conference Object Identifier, 888 a new Conference Identifier and a new focus are allocated by the 889 server. 891 During the conference lifetime, an authorized client can manipulate 892 the Conference Object (such as adding participants) using the 893 Conference Control Protocol [Section 7.3]. 895 +---+-----------------------+ 896 | p | | 897 | o | C O N F E R E N C E | 898 | l | | 899 | i | S Y S T E M | 900 | c | | 901 | i | D E F A U L T | 902 | e | | 903 +-s-+-----------------------+ 904 | 905 \| / 906 \/ 907 /\ 908 /| \ 909 V 910 +---+-----------------------+ 911 | p | | 912 | o | A C T I V E | 913 | l | | 914 | i | C O N F E R E N C E | 915 | c | | 916 | i | | 917 | e | | 918 +-s-+-----------------------+ 920 Figure 7: Conference Ad-hoc Creation and Lifetime. 922 6.3 Advanced Example 924 Figure 8 illustrates how a recurring conference can be specified 925 according to system capabilities, scheduled, reserved, and managed in 926 a conferencing system. 928 Firstly, a client would query a Conferencing System for its 929 capabilities. This can be done by requesting a list of the 930 Conference Object "blueprints" (or templates) the system supports. 931 Each blueprint can contain a specific combination of capabilities and 932 limitations of the conference server in terms of supported media 933 types (audio, video, text, or combinations of these), participant 934 roles, maximum number of participants of each role, availability of 935 floor control, controls available for participants, availability and 936 type of sidebars, the definitions and names of media streams, etc. 938 A Client may need to query any templates that it doesn't understand 939 and then make a decision on compatibility. Interface hints need to 940 be included as per [21]. The client then selects which specific 941 template to use and retrieves the template from the server itself 942 (and NOT from some centralized repository). 944 The selected blueprint with its default values is copied by the 945 client into a newly created Conference Object, referred to as a 946 'Conference Object for Reservation', that specifies the resources 947 needed from the system for this Conference Instance. At this point 948 the 'Conference Object for Reservation' becomes independent from its 949 blueprint. The client can also change the default values (within the 950 system ranges) and add additional information (such as the list of 951 participants and the conference start time) to the 'Conference Object 952 for Reservation'. 954 At this point the client can ask the conference server to create a 955 new conference reservation by attaching the 'Conference Object for 956 Reservation' to the request. As a result, the server can allocate 957 the needed resources, create the additional Conference Objects for 958 each conference occurrence (referred to as a 'Conference Object for 959 Occurrence') and allocate the Conference Object identifiers for all - 960 the 'Conference Object for Reservation' and for each 'Conference 961 Object for Occurrence'. 963 From this point on, any authorized client is able to access and 964 modify each of the Conference Objects independently. By default, 965 changes to an individual 'Conference Object for Occurrence' will 966 affect neither the 'Conference Object for Reservation' nor its 967 siblings. 969 On the other hand, some of the conference sub-objects, such as the 970 maximum number of participants and the participants list, can be 971 defined by the system as parent-forcible. As a result, these objects 972 can be modified by accessing the 'Conference Object for Reservation' 973 only. The changes to these objects can be applied automatically to 974 each of the 'Conference Object for Occurrence's (subject to local 975 policy). 977 +---+-----------------------+ 978 | p | | 979 | o | S E L E C T E D | 980 | l | | 981 | i | C O N F E R E N C E | 982 | c | | 983 | i | B L U E P R I N T | 984 | e | | 985 +-s-+-----------------------+ 986 | 987 \| / 988 \/ 989 /\ 990 /| \ 991 V 992 +---+-----------------------+ 993 | p | | 994 | o | C O N F E R E N C E | 995 | l | | 996 | i | R E S E R V A T I O N | 997 | c | | 998 | i | | 999 | e | | 1000 +-s-+-----------------------+ 1001 | | | 1002 | | | 1003 | | | 1004 | | | 1005 +---|--|--V-----------------+ 1006 +-+---|--V------------------+ | 1007 +-+-+---V-------------------+ | | 1008 | p | | | | 1009 | o | C O N F E R E N C E | | | 1010 | l | | | | 1011 | i | O C C U R R E N C E | | | 1012 | c | | | | 1013 | i | | |-+ 1014 | e | |-+ 1015 +-s-+-----------------------+ 1017 Figure 8: Advanced Conference Definition, Creation, and Lifetime. 1019 6.4 Scheduling a 'Conference Object for Reservation' 1021 Scheduling conferences forms an important part of the Conferencing 1022 System solution. The concept of an individual Conference Instance 1023 and its relationship to a specific Conference Object is introduced in 1024 Section 5.2 and Section 5.3. A basic Conference Instance represents 1025 a single occurrence that has a specified 'start' and 'end' time, with 1026 the times being specified relative to a single specified 'fixed' 1027 time (e.g. 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system 1028 considerations . In most advanced conferencing solutions it is 1029 possible to not only schedule an individual conference instance, but 1030 also schedule a series of related conferences (e.g. A weekly meeting 1031 that starts on Thursday at 09.00 GMT). 1033 To be able to achieve such functionality, a Conferencing System needs 1034 to be able to appropriately schedule and maintain Conference 1035 Instances that form part of a recurring conference schedule. The 1036 mechanism proposed in this document makes use of the 'Internet 1037 Calendaring and Scheduling Core Object' specification defined in 1038 RFC2445[8] in union with the concepts introduced in Section 4 for the 1039 purpose of achieving advanced conference scheduling capability. 1041 Figure 9 illustrates a simplified view of a Client interacting with a 1042 Conference System. The Client is using the Conference Control 1043 Protocol (Section 7.3) to add a new Conference Instance to the 1044 Conference System by interfacing with the Conference Control Server. 1045 A Conference Control Protocol request contains a valid 'Conference 1046 Object for Reservation' and reference by value to an 'iCal' object 1047 which contains scheduling information about the conference instance 1048 (e.g. start time, end time). 1050 +--------------+ +-------Conferencing System-----------------+ 1051 | Generic ICAL | | | 1052 | Resource | | ..Conference Instance.... | 1053 +--------------+ | . . +-----------+| 1054 ^ ^ | . +-------------------+ . | Conference|| 1055 | | | . |Conference Objects |<--| Control || 1056 | ----------------->. +-------------------+ . | Server || 1057 | | . . +-----------+| 1058 | | ......................... ^ | 1059 | | ^ | | 1060 +-----|--------------+ | | | 1061 | v | | | 1062 | +--------------+ | | | 1063 | | Resource |<------------------+ | | 1064 | | Scheduler | | | 1065 | +--------------+ | | 1066 | | | 1067 +---------------------------------------------------------|------+ 1068 | 1069 | 1070 +-Request-+ 1071 | | 1072 +----+ | 1073 |ICAL| | 1074 +----+----+ 1075 | 1076 | 1077 | 1078 Conference Control| 1079 Protocol | 1080 | 1081 +-------------+ 1082 | Conferencing| 1083 | Client | 1084 +-------------+ 1086 Figure 9: Resource Scheduling 1088 A successful creation of a Conference Instance using the Conference 1089 Control Protocol results in a new 'Conference Object for 1090 Reservation'. A Conference Control Protocol request is validated, 1091 including the associated iCal object, and the resultant 'Conference 1092 Object for Reservation' is created. The Conference Object is 1093 uniquely represented within the Conference System by Conference 1094 Object Identifier (e.g. xcon:hd87928374) as discussed in 1095 Section 5.3. The unique URI is returned to the client and can be 1096 used to reference the 'Conference Object for Reservation' 1097 representation if any future manipulations are required (e.g. Alter 1098 start time) using a Conference Control Protocol. 1100 The previous example explains how a client creates a basic 1101 'Conference Object for Reservation' using an iCal reference in 1102 association with a Conference Control Protocol. Figure 9 can also be 1103 applied when explaining how a series of Conferences are scheduled in 1104 the system. The description is almost identical with the exception 1105 that the iCal definition that is included in a Conference Control 1106 Request represents a series of recurring Conference Instances (e.g. 1107 conference start time, end time, occur weekly). The Conference 1108 system will treat this request the same as the first example. The 1109 protocol request will be validated, along with the associated iCal 1110 object, and the 'Conference Object for Reservation' will be created. 1111 The 'Conference Object for Reservation' and the Conference Object ID 1112 created for this example represent the entire series of recurring 1113 Conference Instances rather than a single Conference. If the client 1114 uses the Conference Object ID provided and a Conference Control 1115 Protocol to adjust the 'Conference Object for Reservation', every 1116 Conference Instance in the series will be altered. This includes all 1117 future occurrences, such as a conference scheduled as an infinite 1118 series, subject to the limitations of the available calendaring 1119 interface. 1121 A Conferencing System that supports the scheduling of a series of 1122 Conference Instances should also be able to support manipulation 1123 within a series range. A good example might be that a 'Conference 1124 Object for Reservation' has been scheduled to occur every Monday at 1125 09.00 GMT. For the next three weeks only, the meeting has been 1126 altered to occur at 10.00 GMT in an alternative venue. With 1127 Figure 9 in mind, the client will construct a Conference Control 1128 request whose purpose is to modify the existing 'Conference Object 1129 for Reservation' representing the recurring Conference Instance. The 1130 Client will include the Conference Object ID provided by the 1131 Conference System to explicitly reference the 'Conference Object for 1132 Reservation' within the Conference System. A Conference Control 1133 request will contain all the required changes to the 'Conference 1134 Object for Reservation'(e.g. Change of venue). The Conference 1135 System matches the incoming request to the existing 'Conference 1136 Object for Reservation' but identifies that the associated iCal 1137 object only refers to a range of the existing series. The Conference 1138 System creates a child clone of the original 'Conference Object for 1139 Reservation' to represent the altered Conference Instances within 1140 the Series. The cloned 'Conference Object for Reservation' 1141 representing the altered series of Conference Instances has its own 1142 associated Conference Object ID which is returned to the Client using 1143 a Conference Control Protocol. This Conference Object ID is then 1144 used by the client to make any future alterations on the newly 1145 defined sub-series. This process can be repeated any number of times 1146 as the newly returned Conference Object ID representing an altered 1147 (cloned) series of Conference Instances, can itself be manipulated 1148 using the Conference Control Protocol and the newly created 1149 Conference Object ID representation. This provides a flexible 1150 approach to the scheduling of recurring Conference instances. 1152 7. Conferencing Mechanisms 1154 7.1 Call Control Signalling 1156 The focus is the central component of the conference. Participants 1157 interface with the focus using an appropriate Call Control Signalling 1158 protocol. Participants request to establish or join a conference 1159 using the Call control signalling interface. A focus then either 1160 accepts (after checking the policies), sends a progress indication 1161 (e.g. for a parked call while awaiting moderator approval to join) or 1162 rejects that request using the call control signalling interface. 1164 During an active conference, a Conference Control Protocol 1165 [Section 7.3] can be used to affect the conference state. For 1166 example, Conference Control Protocol requests to add and delete 1167 participants will be communicated to the focus and checked against 1168 the conference policies. If approved, the participants will be added 1169 or deleted using the call signalling to/from the focus. 1171 7.2 Notifications 1173 A Conferencing System is responsible for implementing a Conference 1174 Notification Service. The Conference Notification Service provides 1175 updates about the Conference Instance state to authorized parties 1176 (e.g. participants) according to [11]. 1178 The Conference User Identifier and associated Role are used by the 1179 conferencing system to filter the notifications such that they 1180 contain only information that is allowed to be sent to that user. 1182 7.3 Conference Control Protocol 1184 The XCON working group charter includes the development of a protocol 1185 or a set of protocols for controlling the state of a Conference 1186 Object and for retrieving its state. The nature of this protocol is 1187 currently under discussion in the XCON working group. The proposals 1188 span from data manipulation (management-like) protocols (CPCP and 1189 NETCONF) to semantic-oriented (CCCP and CSCP) . Details of the 1190 proposed protocols are in the sections below. The following 1191 paragraphs summarize the fundamental issues around the selection of 1192 the protocol(s). [Editor's Note: Discussion Point 5 on the XCON WG 1193 mailing list]. 1195 It is recognized that semantic manipulations make for a cleaner 1196 protocol design, with the disadvantage that extensions to the 1197 underlying data model require extensions to the protocol used to 1198 manipulate it. Syntactic manipulations allow for extensions to the 1199 data model without requiring protocol extensions, with the 1200 disadvantage that the server generally has to infer intent from data 1201 manipulations instead of having intent explicitly signaled. 1203 It is worth noting that one portion of the data to be manipulated, 1204 the Common Conference Information, will not be extended, and would 1205 naturally lend itself to semantic manipulation. Another part of the 1206 data, the Conference Template, is intended to be extended, and would 1207 naturally lend itself to syntactic manipulation. However, there has 1208 been a stated desire to use a single protocol (and presumably a 1209 single mode of operation within this protocol) to manipulate all 1210 conference object state (common and template). 1212 The third statement in the paragraph above makes the first two 1213 solution options mutually exclusive. A proposal was made that by 1214 allowing more than one protocol, a hybrid approach could be taken 1215 such that CPCP and CSCP can both be used, since they are based on 1216 other protocols that are likely to be supported by the clients (XCAP 1217 and BFCP, respectively). However, the very rough consensus of the WG 1218 supports a single protocol for Conference Control and SOAP has most 1219 recently been put forth as that protocol. A basic overview of SOAP 1220 in the context of Conference control is provided in Section 7.3.5 1222 7.3.1 CPCP 1224 A Conference Policy Control Protocol (CPCP) is a data manipulation 1225 protocol being proposed as a standard means of storing and 1226 manipulating the conference policy. According to CPCP, the 1227 conference policy is comprised of the rules associated with a 1228 specific Conference Instance. Requirements for the CPCP are defined 1229 in the CPCP Requirements document [13]. The Conference Policy 1230 Control Protocol document [17] defines the XML Schema for the 1231 conference policy data elements. 1233 The privileges as to which users are allowed to read and/or 1234 manipulate a specific Conference Instance are defined in a separate 1235 Extensible Markup Language (XML) Schema[19]. This schema is based on 1236 the common policy model being used for geographic privacy information 1237 and for presence information. 1239 A separate document [18] proposes XCAP as one protocol mechanism for 1240 storing and manipulating this conferencing policy data. XCAP is a 1241 HTTP 1.1 based protocol that allows clients to read, write, modify 1242 and delete application data stored in XML format on a server. One of 1243 the main advantages of XCAP is that it maps XML document elements and 1244 attributes to HTTP URIs that can be directly accessed by HTTP. 1246 7.3.2 CCCP 1248 A Centralized Conferencing Control Protocol [20] is a semantic- 1249 oriented protocol defined to allow participants or otherwise 1250 authorized entities to directly manipulate an active Conference 1251 Instance. CCCP is defined as a set of transactions issued over a 1252 reliable transport protocol. A transaction consists of a Request 1253 carrying the required information in an XML body and a corresponding 1254 Response carrying an appropriate XML body. 1256 CCCP requests are submitted to the CCCP server and can be prioritized 1257 and queued, based on the CCCP client Role and the requested 1258 primitives. CCCP requires no single lock per document, and the CCCP 1259 server can locally implement an optimization strategy independent of 1260 CCCP client behavior. 1262 7.3.3 CSCP 1264 A Conference State Change protocol [26] is a client server protocol 1265 used to change the state of a conference object. CSCP extends the 1266 BFCP protocol [16] with new commands. A client sends the server a 1267 request representing a sequence of commands. Each command can set, 1268 get, add, or delete a single field in the conference object. Changes 1269 to the conference object are performed on a hierarchal set of 1270 elements and unique attributes within those elements. A series of 1271 changes can be pipelined in a single BFCP message. The server 1272 executes each action in series. If one of them fails, the server 1273 returns an error for the action that failed and does not execute any 1274 of the actions after that. Each individual action is atomic but the 1275 pipelined series is not. 1277 The item to which a command applies is specified by a unique ID and, 1278 where appropriate, attribute name. The ID is an unsigned 32 bit 1279 integer called the Element ID. The server discovery of the Element 1280 ID is outside of CSCP. Typically this is done by using the 1281 conference notification service per Section 7.2. Each field in the 1282 data received in the notification contains a unique field ID 1283 attribute that can be used in BFCP requests. 1285 7.3.4 NETCONF 1287 The Network Configuration (NETFCONF) protocol [27] defines a simple 1288 mechanism through which a network device can be managed, 1289 configuration data information can be retrieved, and new 1290 configuration data can be uploaded and manipulated. The protocol 1291 allows the device to expose a full, formal, application programming 1292 interface (API). 1294 NETCONF is proposed as the mechanism for object content manipulation 1295 and state retrieval for the XCON data. NETCONF provides a flexible 1296 configuration retrieval mechanism, with extensibility. It allows for 1297 incremental configuration and commits. NETCONF supports stored 1298 configurations (e.g. for startup, running, etc.). It also supports 1299 XPath and subtree filtering. With NETCONF, there are no constraints 1300 on the configuration content. 1302 7.3.5 SOAP 1304 The SOAP protocol is fundamentally an XML messaging scheme, capable 1305 of supporting remote procedure calls. SOAP defines a simple message 1306 format composed of a "header" and a "body" contained within an 1307 "envelope". The "header" contains meta-information relating to the 1308 message, and can be used to indicate such things as store-and-forward 1309 behaviour or transactional characteristics. In addition, SOAP 1310 encoding is optimized for ease of automated deserialization. 1312 SOAP is proposed as the mechanism for object content manipulation and 1313 state retrieval for the XCON data. In general, SOAP is a good fit 1314 for Conference Control, essentially because of its remote procedure 1315 call characteristics and its inherently synchronous and client-driven 1316 nature. 1318 7.4 Floor Control 1320 [Editor's Note: This text still requires further updating to reflect 1321 new model and pending new WG agreements. Amongst the things TODO 1322 are: 1324 1. Need to be able to fetch from the Conference Object the 1325 credentials required for BFCP. This includes the conference id, user 1326 id, and password. 1328 4. Evaluation of an alternative proposal [TBD as a stand alone draft 1329 as well] for using Templates as the means for correlating Floor 1330 Control identifiers. 1332 5. Still need to condense this section - propose to add a scenario 1333 to section 8 and thus remove some of the details, leaving this 1334 description a very basic overview and mapping of the identifiers. 1336 ] 1337 A mechanism for floor control within a Conferencing System is defined 1338 in the 'Binary Floor Control Protocol' specification [16]. Floor 1339 control is not a mandatory mechanism for a Conferencing System 1340 implementation but provides advanced media input control features for 1341 participants. 1343 An XCON compliant client supporting floor control needs to obtain 1344 information for connecting to a floor control server to enable it to 1345 issue floor requests. This connection information can be retrieved 1346 using information provided by mechanisms such as negotiation using 1347 the SDP[2] offer/answer[5] exchange on the signalling interface with 1348 the focus. 1350 As well as the Client --> Floor Server connection information, a 1351 client wishing to interact with a Floor Control server requires 1352 access to additional information. This information associates Floor 1353 Control interactions with the appropriate Floor instance. Once a 1354 connection has been established and authenticated (see [16] for 1355 authentication details), a specific floor control message requires 1356 detailed information to uniquely identify a user, a floor and a 1357 conference. This information, defined in the next set of bullet 1358 points, can be obtained using methods such as negotiation using the 1359 SDP offer/answer exchange on the signalling interface with the focus: 1361 o Conference Object ID - Each Conference Object has a unique 1362 identifier per Section 5.3.1, obtained from the Conference 1363 server, which MUST be included in all Floor messages. When the 1364 SDP model is used as described in [24] this identifier maps to the 1365 'confid' SDP attribute. 1366 o Conference User Identifier - Each user has a unique identifier 1367 within the Conference Object per Section 5.4, obtained from the 1368 Conference server, which MUST be included in all Floor messages. 1369 When using SDP offer/answer exchange to negotiate a Floor control 1370 connection with the focus using the call control signalling 1371 interface, the unique conference identifier is contained in the 1372 'userid' SDP attribute, as defined in [24] 1373 o Floor ID - A media session with a Conferencing System can have any 1374 number of 'Floors' (0 or more) that are represented by a unique 1375 identifier within the Conference Instance (as represented by 1376 Conference ID). When using SDP offer/answer exchange to negotiate 1377 a Floor control connection with the focus using the call control 1378 signalling interface, the unique conference identifier is 1379 contained in the 'floorid' SDP attribute, as defined in [24] 1380 e.g.a=floorid:1 m-stream:10 . Each 'floorid' attribute, 1381 representing a unique floor, has an 'm-stream' tag containing one 1382 or more identifiers. The identifiers represent individual SDP 1383 media sessions (as defined using 'm=' from SDP) using the SDP 1384 'Label' attribute as defined in [23]. 1386 Clients can authenticate a BFCP server using the TLS certificates. 1387 Requests submitted on a successfully created BFCP connection may 1388 additionally require digest authentication within the BFCP protocol 1389 to authenticate the Floor control client to the server. For this to 1390 take place a shared secret needs to be exchanged between the BFCP 1391 client/server entities. This can be achieved out of band using a 1392 mechanism such as the 'k=' SDP attribute. The shared secret can also 1393 be exchanged using un-specified 'out of band' mechanisms. When using 1394 Digest authentication of BFCP client messages the exchange of an 1395 active 'Nonce' is also required. This can be achieved using a BFCP 1396 request response interaction as defined in BFCP (A request is 1397 submitted without a Nonce TLV and the server generates an error 1398 response with either an Error Code 7 (DIGEST TLV Required) or 6 1399 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value 1400 can also be obtained 'out of band' using information provided in the 1401 Offer/Answer exchange. As with the other SDP Floor attributes 1402 referenced in this section and defined in [24], the 'nonce' attribute 1403 can be inserted in the SIP response e.g. a=nonce:dhsa8hd0dwqj. 1405 8. Conferencing Scenario Realizations 1407 This section addresses how advanced conferencing scenarios, many of 1408 which have been described in [14], are realized using this XCON 1409 framework. The objective of this section is to further illustrate 1410 the model, mechanisms and protocols presented in the previous 1411 sections and also serves to validate that the model, mechanisms and 1412 protocols are sufficient to support advanced conferencing scenarios. 1414 Section 6.2 and Section 6.3 provide examples of the creation of a 1415 basic adhoc conference and a more advanced scheduled conference. 1417 8.1 Participant Manipulations 1419 There are different ways to affect a participant state in a 1420 conference. A participant can join and leave the conference using 1421 call signalling means only, such as SIP. This kind of operation is 1422 called "1st party signalling" and does not affect the state of other 1423 participants in the conference. 1425 Limited operations for controlling other conference participants (a 1426 so called "3rd party control") through the Focus, using call 1427 signalling only, may also be available for some signalling protocols. 1428 For example, "Conferencing for SIP User Agents" [15] shows how SIP 1429 with REFER can be used to achieve this functionality. 1431 In order to perform richer conference control a user client needs to 1432 implement a conference control protocol client. By using a 1433 conference control protocol, the client can affect its own state, 1434 state of other participants, and state of various resources (such as 1435 media mixers) which may indirectly affect the state of any of the 1436 conference participants. 1438 Figure 11 provides an example of one client "Alice" impacting the 1439 state of another client "Bob". This example assumes an established 1440 conference. In this example, "Alice" wants to add "Bob" to the 1441 conference. 1443 It should be noted that not all entities impacted by the request are 1444 shown in the diagram (e.g. Focus), but rather the emphasis is on the 1445 new entities introduced by XCON. 1447 +--------------------------------+ 1448 | Conference System | 1449 "Alice" | +---------+--+| 1450 +--------+ | |policies | || 1451 | |CCP Request < | +-----------+ +---------+ || 1452 | Client |-------------------------->|Conference | |Conference || 1453 | | Conference Object ID, | |Control |~~~>|Object of || 1454 +--------+ Add, "Bob" > | |Server | |occurrence || 1455 | +-----------+ +-------+ || 1456 | |"Alice"| || 1457 "Bud" | ' ' '| 1458 +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| 1459 | |<-------------------------|Notification|<~~~| || 1460 | Client |. . ||Service | +-------+ || 1461 +--------+--+ . || | |"Bob" | || 1462 | |<----------------------| | +-------+----+| 1463 | Client |NOTIFY <"Bob"="added">|+------------+ | 1464 +--------+ +--------------------------------+ 1465 "Bob" 1467 Figure 10: Client Manipulation of Conference - Add a party 1469 Upon receipt of the Conference Control Protocol request to "add" a 1470 party ("Bob") in the specific conference as identified by the 1471 Conference Object ID, the Conference System ensures that "Alice" has 1472 the appropriate authority based on the policies associated with that 1473 specific Conference Object to perform the operation. The Conference 1474 System must also determine whether "Bob" is already a user of this 1475 Conference System or whether he is a new user. 1477 If "Bob" is a new user for this conference system, a Conference User 1478 Identifier is created for Bob. Based upon the addressing information 1479 provided for "Bob" by "Alice", the call signalling to add "Bob" to 1480 the conference is instigated through the Focus. 1482 Once the call signalling indicates that "Bob" has been successfully 1483 added to the specific conference, per updates to the state, and 1484 depending upon the policies, other participants (including "Bob") may 1485 be notified of the addition of "Bob" to the conference via the 1486 Conference Notification Service. 1488 8.2 Media Manipulations 1490 There are different ways to manipulate the media in a conference. 1492 A participant can change its own media streams by, for example, 1493 sending re-INVITE with new SDP content using SIP only. This kind of 1494 operations is called "1st party signalling" and they do not affect 1495 the state of other participants in the conference. 1497 In order to perform richer conference control a user client needs to 1498 implement a conference control protocol client. By using a 1499 conference control protocol, the client can manipulate the state of 1500 various resources, such as media mixers, which may indirectly affect 1501 the state of any of the conference participants. 1503 Figure 11 provides an example of one client "Alice" impacting the 1504 media state of another client "Bob". This example assumes an 1505 established conference. In this example, the Client, "Alice" whose 1506 Role is "moderator" of the conference, wants to mute "Bob" on a 1507 medium-size multi-party conference, as his device is not muted (and 1508 he's obviously not listening to the call) and background noise in 1509 his office environment is disruptive to the conference. 1511 It should be noted that only entities impacted by the request are 1512 shown in the diagram (e.g. there is no Focus shown). 1514 +--------------------------------+ 1515 | Conference System | 1516 "Alice" | +---------+--+| 1517 +--------+ | |policies | || 1518 | |CCP Request < | +-----------+ +---------+ || 1519 | Client |-------------------------->|Conference | |Conference || 1520 | | Conference Object ID, | |Control |~~~>|Object of || 1521 +--------+ Mute, "Bob" > | |Server | |occurrence || 1522 | +-----------+ +-------+ || 1523 | |"Alice"| || 1524 | ' ' '| 1525 +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| 1526 | |<-------------------------|Notification|<~~~| || 1527 | Client |. . ||Service | +-------+ || 1528 +--------+--+ . || | |"Bob" | || 1529 | |<----------------------| | +-------+----+| 1530 | Client | NOTIFY <"Bob"=mute">|+------------+ | 1531 +--------+ +--------------------------------+ 1533 Figure 11: Client Manipulation of Conference - Mute a party 1535 Upon receipt of the Conference Control Protocol request to "mute" a 1536 party ("Bob") in the specific conference as identified by the 1537 Conference Object ID, the Conference Server ensures that "Alice" has 1538 the appropriate authority based on the policies associated with that 1539 specific Conference Object to perform the operation. "Bob's" status 1540 is marked as "recvonly" and the Conference Template of the Conference 1541 Object (if included) is updated to reflect that "Bob's" media is not 1542 to be "mixed" with the conference media. 1544 Depending upon the policies, other participants (including "Bob") may 1545 be notified of this change via the Conference Notification Service. 1547 8.3 Sidebar Manipulations 1549 A sidebar can be viewed as a separate Conference instance that only 1550 exists within the context of a parent Conference instance. Although 1551 viewed as an independent Conference instance, it can not exist 1552 without a parent. A Sidebar is created using the same mechanisms 1553 employed for a standard conference as described in Section 6.1 A 1554 Conference object representing a Sidebar is created by cloning the 1555 parent associated with the existing conference, copying the 1556 information from the parent and updating any information specific to 1557 the sidebar. A Sidebar Conference Object is implicitly linked to the 1558 parent Conference Object (i.e. it is not an independent object). A 1559 Conference System manages and enforces the parent and appropriate 1560 localized restrictions on the Sidebar Conference Object (e.g. No 1561 members from outside the parent conference instance can join, Sidebar 1562 conference can not exist if parent Conference is terminated, etc.). 1563 The Sidebar mechanism uses the umbrella approach for association of 1564 XCON Conference Object Identifiers as introduced in other sections of 1565 this document. 1567 +--------------+ 1568 | Conference | 1569 | Object | 1570 | Identifier | 1571 +--------------+ 1572 | 1573 | 1574 | 1575 +---------------------+---------------------+ 1576 | | | 1577 +-------+-------+ +-------+-------+ +-------+-------+ 1578 | Sidebar | | Sidebar | | Sidebar | 1579 | Conference | | Conference | | Conference | 1580 | Object | | Object | | Object | 1581 | Identifier | | Identifier | | Identifier | 1582 +-------+-------+ +-------+-------+ +---------------+ 1584 Figure 12: Conference Object Mapping. 1586 Figure 12 illustrates the relationship between a Conference Object 1587 and associated Sidebar Conference Objects within a Conference System. 1588 Each Sidebar Conference Object has a unique Conference Object 1589 Identifier as described in Section 5.3.1. The main Conference Object 1590 Identifier acts as a top level identifier for associated Sidebars. 1592 A sidebar Conference Object Identifier follows many of the concepts 1593 outlined in the Cloning tree model described in Section 6.1. A 1594 Sidebar Conference Object contains a subset of members from the 1595 original Conference object. Properties of the Sidebar Conference 1596 Object can be manipulated by a Conference Control Protocol 1597 (Section 7.3 using the unique Conference Object identifier for the 1598 sidebar. It is also possible for the top level Conference Object to 1599 enforce policy on the Sidebar Object (similar to parent enforceable 1600 as discussed in Section 6.1). 1602 [Editor's Note: this needs more detail - especially around cloning 1603 tree.] 1605 8.4 Whispering or Private Messages 1607 [Editor's Note: TBD. Once we get full agreement on terminology and 1608 the basic ideas in the other sections, we'll tackle this.] 1610 8.5 Conference Announcements and Recordings 1612 [Editor's note: TBD. Use Cullen's comments on the previous version 1613 of the doc .] 1615 9. Relationships between SIPPING and XCON Frameworks 1617 The SIPPING Conferencing Framework [9] provides an overview of a wide 1618 range of centralized conferencing solutions known today in the 1619 conferencing industry. The document introduces a terminology and 1620 logical entities in order to systemize the overview and to show the 1621 common core of many of these systems. The logical entities and the 1622 listed scenarios in the SIPPING Conferencing Framework are being used 1623 to illustrate how SIP [4] can be used as a signalling means in these 1624 conferencing systems. SIPPING Conferencing Framework does not define 1625 new conference control protocols to be used by the general 1626 conferencing system. It uses only basic SIP [4], the SIP 1627 Conferencing for User Agents [15], and the SIPPING Conference 1628 Package [9] for basic SIP conferencing realization. 1630 The XCON framework defines a particular centralized Conferencing 1631 System and the logical entities implementing it. It also defines a 1632 particular XCON Data Model and refers to the standard protocols 1633 (beyond call signalling means) being defined by the XCON WG to be 1634 used among the XCON logical entities for implementing advanced 1635 conferencing features. The purpose of XCON working group and this 1636 framework is to achieve interoperability between the XCON entities 1637 from different vendors for controlling different aspects of advanced 1638 conferencing applications. 1640 The logical entities defined in the two frameworks are not intended 1641 to be mapped one-to-one. The two frameworks differ in the 1642 interpretation of the internal conferencing system decomposition and 1643 the corresponding operations. Nevertheless, the basic SIP [4], the 1644 SIP Conferencing for User Agents [15], and the SIPPING Conference 1645 Package [9] are fully compatible with both Framework documents. 1647 10. Security Considerations 1649 There are a wide variety of potential attacks related to 1650 conferencing, due to the natural involvement of multiple endpoints 1651 and the many, often user-invoked, capabilities provided by the 1652 conferencing system. Examples of attacks include the following: an 1653 endpoint attempting to listen to conferences in which it is not 1654 authorized to participate, an endpoint attempting to disconnect or 1655 mute other users, and theft of service, by an endpoint, in attempting 1656 to create conferences it is not allowed to create. 1658 There are several issues surrounding security of this conferencing 1659 framework. One set of issues involves securing the actual protocols 1660 and the associated authorization mechanisms. This first set of 1661 issues should be addressed in the specificiations specific to the 1662 protocols described in Section 7. The protocols used for 1663 manipulation and retrieval of confidential information MUST support a 1664 confidentiality and integrity mechanism. Similar requirements apply 1665 for the floor control protocols. 1667 There are also security issues associated with the authorization to 1668 perform actions on the conferencing system to invoke specific 1669 capabilities. Section 4.3 discusses the policies associated with the 1670 Conference Object to ensure that only authorized entities are able to 1671 manipulate the data to access the capabilities. The final set of 1672 issues involves the privacy and security of the identity of a user in 1673 the conference. 1675 Many policy authorization decisions are based on the identity of the 1676 user or the Role that a user may have. There are several ways that a 1677 user might authenticate its identity to the system. The conferencing 1678 system may know about specific users and assign passwords to the 1679 users. The users may also be authenticated by knowing a particular 1680 Conference ID and a PIN for it. Sometimes, a PIN is not required and 1681 the Conference ID is used as a shared secret. The call signalling 1682 means can provide a trusted form of the user identity or it might 1683 just provide a hint of the possible identity and the user still needs 1684 to provide some authentication to prove it has the identity that was 1685 provided as a hint in the call signalling. This may be in the form 1686 of an IVR system or other means. The goal for the Conferencing 1687 System is to figure out a user identity and a Role for any attempt to 1688 send a request to the Conferencing System. 1690 When a Conferencing System presents the identity of authorized users, 1691 it may choose to provide information about the way the identity was 1692 proven to or verified by the system. A user may also come as a 1693 completely unauthenticated user into the system - this fact needs 1694 also be communicated to interested parties. 1696 When guest users interact with the system, it is often in the context 1697 of a particular conference. In this case the user may provide a PIN 1698 or a password that is specific to the conferences and authenticates 1699 the user to take on a certain role in that conference. The guest 1700 user can then perform actions that are allowed to any user with that 1701 Role. 1703 The term password is used to mean the usual, that is to say a 1704 reasonable sized, in number of bits, hard to predict shared secret. 1705 Today users often have passwords with more than 30 bits of randomness 1706 in them. PIN is a special password case - a shared secret that is 1707 only numeric and often contains a fairly small number of bits (often 1708 as few as 10 bits). When Conferencing Systems are used for audio on 1709 the PSTN, there is often a need to authenticate using a PIN. 1710 Typically if the user fails to provide the correct PIN a few times in 1711 a row, the PSTN call is disconnected. The rate of making the calls 1712 and getting to the point to enter a PIN makes is fairly hard to do an 1713 exhaustive search of the PIN space even for 4 digit PINs. When using 1714 a high speed interface to connect to a Conferencing System, it is 1715 often possible to do thousands of attempts per second and the PIN 1716 space could quickly be searched. Because of this, it is not 1717 appropriate to use PINs for authorization on any of the interfaces 1718 that provide fast queries or many simultaneous queries. 1720 This conferencing system has an idea of the identity of a user but 1721 this does not mean it can reveal this identity to other users, due to 1722 privacy considerations. Users can set select various options for 1723 revealing their identity to other users. A user can be "hidden" such 1724 that other users can not see they are involved in the conference, or 1725 they can be "anonymous" such that users can see that another user is 1726 there, but not see the identity of the user, or they can be "public" 1727 where other users can see their identity. If there are multiple 1728 "anonymous" users, other parties will be able to see them as 1729 independent "anonymous" parties and will be able to tell how many 1730 "anonymous" parties are in the conference. Note, that the visibility 1731 to other participants is dependent on their Roles. For example, 1732 users' visibility (including "anonymous" and "hidden") may be 1733 displayed to the moderator or administrator, subject to a 1734 Conferencing System's local policies. "Hidden" status is often used 1735 by robot participants of a conference and is also used in many call 1736 center conference situations. 1738 11. IANA Considerations 1740 This is an informational draft, with no IANA considerations required. 1742 12. Acknowledgements 1744 This document is a result of architectural discussions among IETF 1745 XCON working group participants. The authors would like to thank 1746 Henning Schulzrinne for the "Conference Object Tree" proposal, Cullen 1747 Jennings for providing input for the "Security Considerations" 1748 section and Keith Lantz for his careful reviews and constructive 1749 input. 1751 13. Open Issues 1753 Several open issues are identified in the body of the document. This 1754 list is intended as a summary to facilitate the tracking of the 1755 primary open issues that require WG input. 1757 1. DP4. Object Schema structure and Template definition. 1758 Clarification of Templates versus Blueprints and details of XML 1759 schema. 1761 2. DP5. CCP Protocol. 1763 14. Changes since last Version 1765 Changes from WG 00 to 01:: 1767 - Section 2 (Conventions and Terminology). Slight modifications to 1768 definitions of Call (control) signalling, Conference Identifer, 1769 Conference Instance, Conference Object. 1771 - Section 2 (Conventions and Terminology).Renaming of term 1772 "Registered Template Definition" to "Registered Conference Document" 1773 (per agreement at interim meeting). 1775 - Section 3 (Next to the last paragraph on the media model). 1776 Clarified the text such that it doesn't read that the focus performs 1777 media mixing. Changed "focus" to "media mixer controlled by the 1778 focus" in the 2nd sentence and "performed" to "controlled" in the 1779 4th. 1781 - Section 5. Rearranged the sub-sections a bit for better flow. 1782 First describe the Conference ID, then the Conference Instance, 1783 followed by the Conference Object, with the Conference Object 1784 Identifer described in a subsection of the Conference Object 1785 section. Added a diagram showing the relationship between Conference 1786 Identifer/Focus and Conference Object Identifier, within the context 1787 of a Conference Instance to the Conference Object section. 1789 - Section 6.1 (Cloning Tree). Rewording to clarify which operations 1790 apply to independent objects (and non-independent). 1792 - Section 6.3 (Advanced Example). Added additional text with regards 1793 to future conferences, introducing the concept of infinite series 1794 (which would be limited by calendaring interface). 1796 - Section 7.3 (Conference Control Protocol). Updated to include 1797 reference to SOAP option. 1799 - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit 1800 about the XCON FW constructs used. 1802 Changes from individual 02 to WG 00: 1804 - few minor editorial changes 1806 - Section 2. Removed second sentence of definition of Conference 1807 ID, as that's now included/described in context in new Identifier 1808 section. 1810 - Section 3. Clarified that TBD in Figure 1 is "Conference Control 1811 Protocol" (per Keith's comment to be more explicit). 1813 - Section 4.1. Identifiers. Moved this to a new section ( 1814 Section 5). 1816 - New section for Identifiers ( Section 5), thus all section 1817 references beyond 4 are incremented in the new version. 1819 - Section 4. Since section 4.1 was removed, section 4.2 became the 1820 body text for section 4. 1822 - Section 4.2. Added "Floor Information" to Figure 2 as part of 1823 Common Conference Information, also added "Floor Control" to 1824 Conference Template (per text and Cullen's draft). 1826 - Section 4.5. Conference policies. Reworded to not introduce new 1827 terms, but use the general terms identified in the 1st paragraph. 1829 - Section 5.2. Removed "Instance" from "Active Conference Instance" 1830 in Figure 4. 1832 - Section 5.3. Added text clarifying that templates are retrieved 1833 from server (not central repository) (per DP3 conclusion). 1835 - Section 5.4. Added text that there is a single time and that the 1836 times are all relative the one time (per DP1 conclusion). 1838 - Section 5.4. Added text clarifying that changes to a series impact 1839 "all future occurrences (per DP1 discussion/conclusion). 1841 - Section 6.3 - Added subsections for discussion of CSCP and NETCONF 1842 as the CCP. 1844 - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. 1846 Condensed the text only slightly, but added explicit references to 1847 new identifier section. 1849 - Section 6.4.1 Moved to new Identifier section ( Section 5) 1851 - Section 7.1 - moved example to 7.2. Included a new (more 1852 appropriate example) in 7.1, although this may be too basic. 1854 - Section 7.3 - added some proposed text for Sidebars. 1856 15. References 1858 15.1 Normative References 1860 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1861 Levels", BCP 14, RFC 2119, March 1997. 1863 15.2 Informative References 1865 [2] Handley, M. and V. Jacobson, "SDP: Session Description 1866 Protocol", RFC 2327, April 1998. 1868 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1869 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1870 August 1998. 1872 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1873 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1874 Session Initiation Protocol", RFC 3261, June 2002. 1876 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1877 Session Description Protocol (SDP)", RFC 3264, June 2002. 1879 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1880 Notification", RFC 3265, June 2002. 1882 [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1883 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1884 RFC 3550, July 2003. 1886 [8] Dawson, F. and Stenerson, D., "Internet Calendaring and 1887 Scheduling Core Object Specification (iCalendar)", RFC 2445, 1888 November 1998. 1890 [9] Rosenberg, J., "A Framework for Conferencing with the Session 1891 Initiation Protocol", 1892 draft-ietf-sipping-conferencing-framework-05 (work in 1893 progress), May 2005. 1895 [10] Levin, O. and R. Even, "High Level Requirements for Tightly 1896 Coupled SIP Conferencing", 1897 draft-ietf-sipping-conferencing-requirements-01 (work in 1898 progress), October 2004. 1900 [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1901 Package for Conference State", 1902 draft-ietf-sipping-conference-package-12 (work in progress), 1903 July 2005. 1905 [12] Schulzrinne, H., "Requirements for Floor Control Protocol", 1906 draft-ietf-xcon-floor-control-req-03 (work in progress), 1907 January 2005. 1909 [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference 1910 Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in 1911 progress), August 2004. 1913 [14] Even, R. and N. Ismail, "Conferencing Scenarios", 1914 draft-ietf-xcon-conference-scenarios-04 (work in progress), 1915 April 2005. 1917 [15] Johnston, A. and O. Levin, "Session Initiation Protocol Call 1918 Control - Conferencing for User Agents", 1919 draft-ietf-sipping-cc-conferencing-07 (work in progress), 1920 June 2005. 1922 [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 1923 draft-ietf-xcon-bfcp-04 (work in progress), May 2005. 1925 [17] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", 1926 draft-ietf-xcon-cpcp-01 (work in progress), October 2004. 1928 [18] Khartabil, H., "An Extensible Markup Language (XML) 1929 Configuration Access Protocol (XCAP) Usages for Conference 1930 Policy Manipulation and Conference Policy Privelges 1931 Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress), 1932 October 2004. 1934 [19] Khartabil, H. and A. Niemi, "Privileges for Manipulating a 1935 Conference Policy", 1936 draft-ietf-xcon-conference-policy-privileges-01 (work in 1937 progress), October 2004. 1939 [20] Levin, O. and G. Kimchi, "Centralized Conference Data Model", 1940 draft-levin-xcon-cccp-02 (work in progress), February 2005. 1942 [21] Jennings, C., "Media Conference Server Control for XCON", 1943 draft-jennings-xcon-media-control-02 (work in progress), 1944 February 2005. 1946 [22] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", 1947 draft-rosen-xcon-conf-sidebars-01 (work in progress), 1948 July 2004. 1950 [23] Levin, O. and G. Camarillo, "The SDP (Session Description 1951 Protocol) Label Attribute", 1952 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 1953 January 2005. 1955 [24] Camarillo, G., "Session Description Protocol (SDP) Format for 1956 Binary Floor Control Protocol (BFCP) Streams", 1957 draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), 1958 October 2004. 1960 [25] Campbell, B., "The Message Session Relay Protocol", 1961 draft-ietf-simple-message-sessions-10 (work in progress), 1962 February 2005. 1964 [26] Jennings, C. and A. Roach, "Conference State Change Protocol 1965 (CSCP)", draft-jennings-xcon-cscp-00 (work in progress), 1966 February 2005. 1968 [27] Enns, R., "NETCONF Configuration Protocol", 1969 draft-ietf-netconf-prot-07 (work in progress), June 2005. 1971 Authors' Addresses 1973 Mary Barnes 1974 Nortel 1975 2201 Lakeside Blvd 1976 Richardson, TX 1978 Email: mary.barnes@nortel.com 1980 Chris Boulton 1981 Ubiquity Software Corporation 1982 Building 3 1983 Wern Fawr Lane 1984 St Mellons 1985 Cardiff, South Wales CF3 5EA 1987 Email: cboulton@ubiquitysoftware.com 1988 Orit Levin 1989 Microsoft Corporation 1990 One Microsoft Way 1991 Redmond, WA 98052 1993 Email: oritl@microsoft.com 1995 Intellectual Property Statement 1997 The IETF takes no position regarding the validity or scope of any 1998 Intellectual Property Rights or other rights that might be claimed to 1999 pertain to the implementation or use of the technology described in 2000 this document or the extent to which any license under such rights 2001 might or might not be available; nor does it represent that it has 2002 made any independent effort to identify any such rights. Information 2003 on the procedures with respect to rights in RFC documents can be 2004 found in BCP 78 and BCP 79. 2006 Copies of IPR disclosures made to the IETF Secretariat and any 2007 assurances of licenses to be made available, or the result of an 2008 attempt made to obtain a general license or permission for the use of 2009 such proprietary rights by implementers or users of this 2010 specification can be obtained from the IETF on-line IPR repository at 2011 http://www.ietf.org/ipr. 2013 The IETF invites any interested party to bring to its attention any 2014 copyrights, patents or patent applications, or other proprietary 2015 rights that may cover technology that may be required to implement 2016 this standard. Please address the information to the IETF at 2017 ietf-ipr@ietf.org. 2019 Disclaimer of Validity 2021 This document and the information contained herein are provided on an 2022 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2023 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2024 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2025 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2026 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2027 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2029 Copyright Statement 2031 Copyright (C) The Internet Society (2005). This document is subject 2032 to the rights, licenses and restrictions contained in BCP 78, and 2033 except as set forth therein, the authors retain all their rights. 2035 Acknowledgment 2037 Funding for the RFC Editor function is currently provided by the 2038 Internet Society.