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