idnits 2.17.1 draft-ietf-xcon-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2406. ** 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 35 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (Mar 2006) is 6614 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) == Unused Reference: '3' is defined on line 2263, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2274, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2335, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 2356, 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 (-04) exists of draft-barnes-xcon-ccmp-00 == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-14 == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-11 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Expires: September 2, 2006 C. Boulton 5 Ubiquity Software Corporation 6 O. Levin 7 Microsoft Corporation 8 Mar 2006 10 A Framework and Data Model for Centralized Conferencing 11 draft-ietf-xcon-framework-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 2, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document defines the framework for Centralized Conferencing. 45 The framework allows participants using various call signaling 46 protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in 47 a centralized unicast conference. The Centralized Conferencing 48 Framework defines logical entities and naming conventions, along with 49 a conferencing data model. The framework also outlines a set of 50 conferencing protocols, which are complementary to the call signaling 51 protocols, for building advanced conferencing applications. The 52 framework binds all the defined components together for the benefit 53 of builders of conferencing systems. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Centralized Conferencing Data Model . . . . . . . . . . . . . 10 62 5.1. Common Conference Information . . . . . . . . . . . . . . 11 63 5.2. Conference Template . . . . . . . . . . . . . . . . . . . 12 64 5.3. Conference policies . . . . . . . . . . . . . . . . . . . 12 65 6. Centralized Conferencing Constructs and Identifiers . . . . . 13 66 6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13 67 6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13 68 6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15 69 6.3. Conference User Identifier . . . . . . . . . . . . . . . . 15 70 7. Conferencing System Realization . . . . . . . . . . . . . . . 15 71 7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 16 72 7.2. Ad-hoc Example . . . . . . . . . . . . . . . . . . . . . . 19 73 7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 20 74 7.4. Scheduling a conference . . . . . . . . . . . . . . . . . 23 75 8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26 76 8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26 77 8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 78 8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26 79 8.3.1. CCCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 8.3.2. CSCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 8.3.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 28 83 9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 29 84 9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 29 85 9.2. Participant Manipulations . . . . . . . . . . . . . . . . 31 86 9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 33 87 9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 34 88 9.5. Whispering or Private Messages . . . . . . . . . . . . . . 38 89 9.6. Conference Announcements and Recordings . . . . . . . . . 39 90 10. Relationships between SIPPING and Centralized Conferencing 91 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 39 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 93 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 40 94 11.2. Security and Privacy of Identity . . . . . . . . . . . . . 41 95 11.3. Floor Control Server Authentication . . . . . . . . . . . 42 97 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 98 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 99 14. Changes since last Version . . . . . . . . . . . . . . . . . . 43 100 15. Appendix A - Conference Object Identifier . . . . . . . . . . 47 101 15.1. Conference Object URI Definition . . . . . . . . . . . . . 50 102 16. Appendix B - Conference User Identifier . . . . . . . . . . . 50 103 16.1. Conference User Definition . . . . . . . . . . . . . . . . 52 104 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 105 17.1. Normative References . . . . . . . . . . . . . . . . . . . 52 106 17.2. Informative References . . . . . . . . . . . . . . . . . . 52 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 108 Intellectual Property and Copyright Statements . . . . . . . . . . 56 110 1. Introduction 112 This document defines the framework for Centralized Conferencing. 113 The framework allows participants using various call signaling 114 protocols, such as SIP, H.323, Jabber, or PSTN, to exchange media in 115 a centralized unicast conference. Other than references to general 116 functionality (e.g., establishment and teardown), details of these 117 call signaling protocols are outside the scope of this document 119 The Centralized Conferencing Framework defines logical entities and 120 naming conventions, along with a conferencing data model. The 121 framework also outlines a set of conferencing protocols, which are 122 complementary to the call signaling protocols, for building advanced 123 conferencing applications. 125 The Centralized Conferencing Framework is compatible with the 126 functional model presented in the SIPPING Conferencing Framework [9]. 127 Section 10 of this document discusses the relationship between the 128 Centralized Conferencing Framework and the SIPPING Conferencing 129 framework, in the context of the Centralized Conferencing model 130 presented in this document. 132 2. Conventions 134 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 135 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 136 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 137 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 138 compliant implementations. 140 3. Overview 142 A centralized conference is an association of endpoints, called 143 conference participants, with a central endpoint, called a conference 144 Focus. The Focus has direct peer relationships with the participants 145 by maintaining a separate call signaling interface with each. 146 Consequently, in this centralized conferencing model, the call 147 signaling graph is always a star. 149 The most basic conference supported in this model would be an ad-hoc 150 unmanaged conference, which would not necessarily require any of the 151 functionality defined within this framework. For example, it could 152 be supported using basic SIP signaling functionality with a 153 participant serving as the Focus; the SIPPING Conferencing Framework 154 [9] together with the SIP Call Control Conferencing for User 155 Agents[15] documents address these types of scenarios. 157 In addition to the basic features, however, a conferencing system 158 supporting the centralized conferencing model proposed in this 159 framework document can offer richer functionality, by including 160 dedicated conferencing applications with explicitly defined 161 capabilities, reserved recurring conferences, along with providing 162 the standard protocols for managing and controlling the different 163 attributes of these conferences. 165 The core requirements for centralized conferencing are outlined in 166 [10]. These requirements are applicable for conferencing systems 167 using various call signaling protocols, including SIP. Additional 168 conferencing requirements are provided in [12], [13], and [14]. 170 The centralizing conferencing system proposed by this framework is 171 built around a fundamental concept of a conference object. A 172 conference object provides the data representation of a conference 173 during each of the various stages of a conference (e.g., creation, 174 reservation, active, completed, etc.). A conference object is 175 accessed via the logical functional elements, with whom a 176 conferencing client interfaces, using the various protocols 177 identified in Figure 1. The functional elements defined for a 178 conferencing system described by the framework are a Conference 179 Control Server, Floor Control Server, any number of Foci and a 180 Notification Service. A Conference Control Protocol (CCP) provides 181 the interface between a conference and media control client and the 182 conference control server. A Binary Floor Control Protocol (BFCP) 183 provides the interface between a floor control client and the floor 184 control server. A call signaling protocol (e.g., SIP, H.323, PSTN, 185 etc.) provides the interface between a call signaling client and a 186 Focus. A notification protocol (e.g. SIP Notify) provides the 187 interface between the conferencing client and the Notification 188 Service. 190 A conferencing system can support a subset of the conferencing 191 functions depicted in the conferencing system logical decomposition 192 in Figure 1 and described in this document. However, there are some 193 essential components that would typically be used by most other 194 advanced functions, such as the Notification Service. For example, 195 the notification service is used to correlate information, such as 196 list of participants with their media streams, between the various 197 other components. 199 ................................................................... 200 . Conferencing System . 201 . . 202 . +-----------------------------------------------------+ . 203 . | C o n f e r e n c e o b j e c t | . 204 . +-+---------------------------------------------------+ | . 205 . | C o n f e r e n c e o b j e c t | | . 206 . +-+---------------------------------------------------+ | | . 207 . | C o n f e r e n c e o b j e c t | | | . 208 . | | | | . 209 . | | |-+ . 210 . | |-+ . 211 . +-----------------------------------------------------+ . 212 . ^ ^ ^ | . 213 . | | | | . 214 . v v v v . 215 . +-------------------+ +--------------+ +-------+ +------------+. 216 . | Conference Control| | Floor Control| |Foci | |Notification|. 217 . | Server | | Server | | | |Service |. 218 . +-------------------+ +--------------+ +-------+ +------------+. 219 . ^ ^ ^ | . 220 ..............|.................|...........|..........|........... 221 | | | | 222 |Conference |Binary |Call |Notification 223 |Control |Floor |Signaling |Protocol 224 |Protocol |Control |Protocol | 225 | |Protocol | | 226 | | | | 227 ..............|.................|...........|..........|........... 228 . V V V V . 229 . +----------------+ +------------+ +----------+ +------------+. 230 . | Conference | | Floor | | Call | |Notification|. 231 . | and Media | | Control | | Signaling| | Client |. 232 . | Control | | Client | | Client | | |. 233 . | Client | | | | | | |. 234 . +----------------+ +------------+ +----------+ +------------+. 235 . . 236 . Conferencing Client . 237 ................................................................... 239 Figure 1: Conferencing System Logical Decomposition. 241 The media graph of a conference can be centralized, decentralized, or 242 any combination of both and potentially differ per media type. In 243 the centralized case, the media sessions are established between a 244 media mixer controlled by the focus and each one of the participants. 245 In the decentralized (i.e., distributed) case, the media graph is a 246 multicast or multi-unicast mesh among the participants. 247 Consequently, the media processing (e.g., mixing) can be controlled 248 either by the focus alone or by the participants. The concepts in 249 this framework document clearly map to a centralized media model. 250 The concepts can also apply to the decentralized media case, however, 251 the details of such are left for future study. 253 Section 5 of this document provides more details on the conference 254 object. Section 6 provides an overview of the identifiers necessary 255 to address and manage the conference objects, instances and users 256 associated with a conferencing system. Section 7 of this document 257 describes how a conferencing system is logically built using the 258 defined data model and how the conference objects are maintained. 259 Section 8 describes the fundamental conferencing mechanisms and 260 provides a high level overview of the protocols. Section 9 then 261 provides realizations of various conferencing scenarios, detailing 262 the manipulation of the conference objects using the defined 263 protocols. Section 10 of this document summarizes the relationship 264 between this Centralized Conferencing Framework and the SIPPING 265 Conferencing Framework. 267 4. Terminology 269 This Centralized Conferencing Framework document generalizes, when 270 appropriate, the SIPPING Conferencing Framework [9] terminology and 271 introduces new concepts, as listed below. Further details and 272 clarification of the new terms and concepts are provided in the 273 subsequent sections of this document. 275 Active conference: The term active conference refers to a conference 276 cbject that has been created and activated via the allocation of 277 its identifiers (e.g., conference object identifier and conference 278 identifier) and the associated focus. An active conference is 279 created based on either a system default conference blueprint or a 280 specific conference reservation. 281 Call Signaling protocol: The call signaling protocol is used between 282 a participant and a focus. In this context, the term "call" means 283 a channel or session used for media streams. 284 Common conference information: The common conference information is 285 the data type (i.e., the XML schema) which is used to represent 286 the core set of information for a conference object. This core 287 information includes a common set of definitions for basic 288 conference features, such as conference identifiers, membership, 289 signaling, capabilities and media types, applicable to a wide 290 range of conferencing applications. 292 Conference blueprint: A conference blueprint is a static conference 293 object within a conferencing system, which describes a typical 294 conference setting supported by the system. A conference 295 blueprint is the basis for creation of dynamic conference objects. 296 A system may maintain multiple blueprints. Each blueprint is 297 comprised of the initial values and ranges for the elements in the 298 object, conformant to the data schemas for the common conference 299 information and the specific template associated with the 300 blueprint. 301 Conference control protocol (CCP): A conference control protocol 302 provides the interface for data manipulation and state retrieval 303 for the centralized conferencing data, represented by the 304 conference object. 305 Conference factory: A conference factory is a logical entity, that 306 generates upon request, unique URI(s) to identify and represent a 307 conference focus. 308 Conference identifier (ID): A conference identifier is a call 309 signaling protocol-specific URI that identifies a conference focus 310 and its associated conference instance. 311 Conference instance: A conference instance refers to an internal 312 implementation of a specific conference, represented as a set of 313 logical conference objects and associated identifiers. 314 Conference object: A conference object represents a conference at a 315 certain stage (e.g., description upon conference creation, 316 reservation, activation, etc.), which a conferencing system 317 maintains in order to describe the system capabilities and to 318 provide access to the services available for each object 319 independently. The conference object schema is comprised of two 320 distinct sub components; the common conference information and the 321 conference template(s). 322 Conference object identifier (ID): A conference object identifier is 323 a URI which uniquely identifies a conference object and is used by 324 a conference control protocol to access and modify the conference 325 information. 326 Conference policies: Conference policies collectively refers to a set 327 of rights, permissions and limitations pertaining to operations 328 being performed on a certain conference object. 329 Conference reservation: A conference reservation is a conference 330 object, which is created from either a system default or client 331 selected blueprint. 332 Conference state: The conference state reflects the state of a 333 conference instance and is represented using a specific, well- 334 defined schema. 335 Conferencing system: Conferencing system refers to a conferencing 336 solution based on the data model discussed in this framework 337 document and built using the protocol specifications referenced in 338 this framework document. 340 Conference template: The conference template refers to the data type 341 (i.e. the XML schema) which is used to represent the media or 342 application specific part of the conference object. This 343 information represents enhanced conferencing features or 344 capabilities, such as media mixers, and/or user interface 345 abstractions. 346 Floor: Floor refers to a set of data or resources associated with a 347 conference instance, for which a conference participant, or group 348 of participants, is granted temporary access. 349 Floor chair: A floor chair is a floor control protocol compliant 350 client, either a human participant or automated entity, who is 351 authorized to manage access to one floor and can grant, deny or 352 revoke access. The floor chair does not have to be a participant 353 in the conference instance. 354 Focus: A focus is a logical entity that maintains the call signalling 355 interface with each participating client and the conference object 356 representing the active state. As such, the focus acts as an 357 endpoint for each of the supported signaling protocols and is 358 responsible for all primary conference membership operations 359 (e.g., join, leave, update the conference instance) and for media 360 negotiation/maintenance between a conference participant and the 361 focus. 362 Media graph: The media graph is the logical representation of the 363 flow of media for a conference. 364 Media mixer: A media mixer is the logical entity with the capability 365 to combine media inputs of the same type, transcode the media and 366 distribute the result(s) to a single or multiple outputs. In this 367 context, the term "media" means any type of data being delivered 368 over the network using appropriate transport means, such as RTP/ 369 RTCP (defined in RFC 3550[7]) or Message Session Relay Protocol 370 (defined in [24]). 371 Registered conference document : A standards track document (i.e., 372 RFC) that defines and registers a conference template schema with 373 the appropriate organization (e.g., IANA). A registered 374 conference document also includes any complementary textual 375 information. 376 Role: A role provides the context for the set of conference 377 operations that a participant can perform. A default role (e.g., 378 standard conference participant) will always exist, providing a 379 user with a set of basic conference operations. Based on system 380 specific authentication and authorization, a user may take on 381 alternate roles, such as conference moderator, allowing access to 382 a wider set of conference operations. 383 Sidebar: A sidebar is a separate Conference instance that only exists 384 within the context of a parent conference instance. 386 Whisper: TBD. 388 5. Centralized Conferencing Data Model 390 The centralized conference data model is logically represented by the 391 conference object. A conference object is of type 'Conference object 392 type', which is comprised of two distinct components: the 'Common 393 conference information type' and the 'Conference template type', as 394 illustrated in Figure 2. Each of these types is extensible for 395 including potentially multiple sub-types. 397 +------------------------------------------------------+ 398 | C o n f e r e n c e o b j e c t t y p e | 399 | | 400 | +--------------------------------------------------+ | 401 | | Common conference information type | | 402 | | | | 403 | | +----------------------------------------------+ | | 404 | | | Conference description (times, duration) | | | 405 | | +----------------------------------------------+ | | 406 | | +----------------------------------------------+ | | 407 | | | Membership (roles, capacity, names) | | | 408 | | +----------------------------------------------+ | | 409 | | +----------------------------------------------+ | | 410 | | | Signaling (protocol, direction, status) | | | 411 | | +----------------------------------------------+ | | 412 | | +----------------------------------------------+ | | 413 | | | Floor information | | | 414 | | +----------------------------------------------+ | | 415 | | +----------------------------------------------+ | | 416 | | | Sidebars, Etc. | | | 417 | | +----------------------------------------------+ | | 418 | | | | 419 | +--------------------------------------------------+ | 420 | +--------------------------------------------------+ | 421 | | Conference template type | | 422 | | | | 423 | | - Mixer algorithm, inputs, and outputs | | 424 | | - Floor controls | | 425 | | - User Control Interface | | 426 | | - User's View | | 427 | | - Etc. | | 428 | +--------------------------------------------------+ | 429 | | 430 +------------------------------------------------------+ 431 Figure 2: Conference Object Type Decomposition. 433 In a system based on this conferencing framework, the same conference 434 object type is used for representation of a conference during 435 different stages of a conference, such as expressing conferencing 436 system capabilities, reserving conferencing resources or reflecting 437 the state of ongoing conferences. Thus, each of the two components 438 (i.e., the common conference information and the conference template) 439 may be optionally included in a particular conference object. 440 Section 7 describes the usage semantics of the conference objects. 442 The centralized conferencing data model defined in this framework has 443 no strict separation between conference membership, conference media 444 information and the related policies. The policies are an integral 445 part of the data model and are realized by local, system level 446 boundaries associated with specific data elements, such as the 447 membership, and by the ranges and limitations on other data elements. 448 Additional policy considerations for a system realization based on 449 this data model are discussed in Section 5.3. The integration of the 450 data in this model meets the requirement of many conference control 451 operations to enable synchronized access to the integral conference 452 policies, to the conference state as a whole, and for receiving 453 notifications about changes to either using the same interface. 455 The exact XML schema of the Conference Object, including the 456 organization of the Common Conference Information and the Conference 457 Templates, are detailed in separate documents [ref: TBD]. 459 5.1. Common Conference Information 461 The common conference information section contains the core 462 information that is utilized in any conference and is independent of 463 the specific conference media nature (e.g., the mixing algorithms 464 performed, the advanced floor control applied, etc.). Typically, 465 participants with read-only access to the conference information 466 would be interested in this common conference information only. 468 The common conference information may be represented using the 469 conference-type as defined in [11]. The conference-type contains the 470 definitions for representation of the conference object capabilities, 471 membership, roles, call signaling and media status relevant to 472 different stages of the conference life-cycle. 474 New centralized conferencing specifications can extend the basic 475 conference-type and introduce additional data elements to be used 476 within the common conference information type. 478 5.2. Conference Template 480 The concept of a conference template is introduced to separate the 481 complexity and the details of the "mixer" and other enhanced 482 conferencing features from the common conference information and to 483 allow for easy user interface abstraction for advanced conferencing 484 systems. 486 Each conference template needs to be registered with IANA. The IANA 487 registration needs to point to an RFC having the text description of 488 the feature behavior and the XML definition allowing the feature 489 presentation, configuration, and management. The RFCs defining these 490 templates are referred to as a registered conference document. 492 Typically, a conference template would contain the information about 493 the specific media mixing details, the associated client roles and 494 the available floor controls. This information would allow 495 authorized clients to manipulate the mixer's behavior via the focus, 496 and the resultant distribution of the media to all or individual 497 participants. By doing so, a client can change its own state and/or 498 state of other participants in the conference. 500 A conference template can also include an abstract user interface 501 definition in terms of sliders, radio boxes, etc. for simplifying 502 user interaction with a specific non-trivial feature. 504 The addition of new elements or the modification of the controls 505 within an element of an existing template requires the definition of 506 a new template. 508 5.3. Conference policies 510 Conference policies collectively refers to a set of rights, 511 permissions and limitations pertaining to operations being performed 512 on a certain conference object. 514 The set of rights describes the read/write access privileges for the 515 conference object as a whole. This access would usually be granted 516 and defined in terms of giving the read-only or read-write access to 517 clients with certain roles in the conference. As such, the policies 518 represented by the set of rights aren't explicitly defined within the 519 data model, but rather are reflected in the system realization 520 (Section 7). 522 The permissions and limits, however, are specified as an integral 523 part of the conference object type, with data objects containing the 524 allowed ranges for other data objects (e.g., maximum number of 525 participants) and lists of clients allowed to perform certain 526 operations on a conference object. For example, the "allowed to 527 join" list of participants is consulted to decide who is allowed to 528 join. The entries in the list can specify the identity of an 529 individual user (joe@example.com), a role, a domain (*@example.com), 530 etc. For further details, refer to the detailed data model [ref: 531 TBD]. 533 A more general rule mechanism, beyond the functionality provided by 534 the permissions and limits, is an item for future study. 536 6. Centralized Conferencing Constructs and Identifiers 538 This section provides details of the identifiers associated with the 539 centralized conferencing framework constructs and the identifiers 540 necessary to address and manage the clients associated with a 541 conferencing system. An overview of the allocation, characteristics 542 and functional role of the identifiers is provided. 544 6.1. Conference Identifier 546 The conference identifier (conference ID) is a call signaling 547 protocol-specific URI that identifies a specific conference focus and 548 its associated conference instance. A conference factory is one 549 method for generating a unique conference ID, to identify and address 550 a conference focus, using a call signaling interface. Details on the 551 use of a conference factory for SIP signaling can be found in [15]. 552 The conference identifier can also be obtained using the conference 553 control protocol [Section 8.3] or other, including proprietary, out- 554 of-band mechanisms. 556 6.2. Conference Object 558 A Conference object provides the logical representation of a 559 conference iInstance in a certain stage, such as a conference 560 blueprint representing a conferencing system's capabilities, the data 561 representing a conference reservation, and the conference state 562 during an active conference. Each conference object is independently 563 addressable through the conference control protocol interface 564 [Section 8.3]. 566 Figure 3 illustrates the relationships between the conference 567 identifier, the focus and the conference object ID within the context 568 of a logical conference instance, with the conference object 569 corresponding to an active conference. 571 A conference object representing a conference in the active state can 572 have multiple call signalling conference identifiers; for example, 573 for each call signalling protocol supported. There is a one-to-one 574 mapping between an active conference object and a conference focus. 575 The focus is addressed by explicitly associating unique conference 576 IDs for each signaling protocol supported by the active conference 577 object. 579 ...................................................................... 580 . Conference Instance . 581 . . 582 . . 583 . +---------------------------------------------------+ . 584 . | Conference Object Identifier | . 585 . | | . 586 . | | . 587 . +---------------------------------------------------+ . 588 . ^ ^ . 589 . | | . 590 . v | . 591 . ................................................... | . 592 . . Focus . | . 593 . . . | . 594 . . +----------------------------------+ . | . 595 . . |Conference Identifier (Protocol Y)| . | . 596 . . +------------------------------------+ | . | . 597 . . | Conference Identifier (PSTN) | | . | . 598 . . +--------------------------------------+ |-+ . | . 599 . . | Conference Identifier (SIP) | |^ . | . 600 . . | |-+| . | . 601 . . | |^ | . | . 602 . . +--------------------------------------+| | . | . 603 . ............^...............................|.|.... | . 604 . | | | | . 605 ................|...............................|.|......|............ 606 | | | | 607 |SIP | | |Conference 608 | PSTN | |Y |Control 609 | | | |Protocol 610 | +---------------+ | | 611 | | | | 612 | | | | 613 v v v v 614 +----------------+ +--------------+ +---------------+ 615 | Conferencing | | Conferencing | | Conference | 616 | Client | | Client | | Client | 617 | 1 | | 2 | | X | 618 +----------------+ +--------------+ +---------------+ 620 Figure 3: Identifier Relationships for an Active Conference. 622 6.2.1. Conference Object Identifier 624 In order to make each conference object externally accessible, the 625 conferencing system allocates a unique URI per distinct conference 626 object in the system. A conference control protocol includes the 627 conference object identifier in requests for directly manipulating a 628 particular conference object and for obtaining its current state. 629 The conference object identifier logically maps to other protocol 630 specific identifiers associated with the conference instance, such as 631 the BFCP 'confid'. A full description and semantics of how the 632 conference object identifier is created and used is defined in 633 Section 15. 635 6.3. Conference User Identifier 637 Each user within a conferencing system is allocated a unique 638 conference user identifier. The user identifier is used in 639 association with the conference object identifier to uniquely 640 identify a user within the scope of conferencing system. There is 641 also a requirement for identifying conferencing system users who may 642 not be participating in a conference instance. Examples of these 643 users would be a non participating 'Floor Control Chair' or 'Media 644 Policy Controller'. The conference user identifier is required in 645 conference control protocol requests to uniquely determine who is 646 issuing commands, so that appropriate policies can be applied to the 647 requested command. The conference user identifer is logically 648 associated with the other user identifiers assigned to the 649 conferencing client for other protocol interfaces, such as an 650 authenticated SIP user. A full description and semantics of the 651 conference user identifier is provided in Section 16 653 7. Conferencing System Realization 655 Implementations based on this centralized conferencing framework can 656 range from systems supporting ad-hoc conferences, with default 657 behavior only, to sophisticated systems with the ability to schedule 658 recurring conferences, each with distinct characteristics, being 659 integrated with external resource reservation tools, and providing 660 snapshots of the conference information at any of the stages of the 661 conference life-cycle. 663 A conference object is the logical representation of a conference 664 instance at a certain stage, such as capabilities description upon 665 conference creation, reservation, activation, etc., which a 666 conferencing system maintains in order to describe the system 667 capabilities and to provide access to the available services provided 668 by the conferencing system. Consequently, this centralized 669 conferencing framework does not mandate the actual usage of the 670 conference object, but rather defines the general cloning tree 671 concept and the mechanisms required for its realization, as described 672 in detail in Section 7.1. 674 Adhoc and advanced conferencing examples are provided in Section 7.2 675 and Section 7.3, with the latter providing additional description of 676 the Conference Object in terms of the stages of a conference, to 677 support scheduled and other advanced conference capabilities. The 678 scheduling of a conference based on these concepts and mechanisms is 679 then detailed in Section 7.4 681 As discussed in Section 5.3, there are conference policies implicit 682 in and derivable from the data in the conference objects and there 683 are also policies applying to the conference objects as a whole. In 684 the examples in this section, these latter policies are shown 685 logically associated with the conference objects, however, it is an 686 implementation specific mechansim as to how these policies are 687 managed and applied to the conference objects. 689 7.1. Cloning Tree 691 The concept defined in this section is a logical representation only, 692 as it is reflected through the centralized conferencing mechanisms: 693 the URIs and the protocols. Of course, the actual system realization 694 can differ from the presented model. The intent is to illustrate the 695 role of the logical elements in providing an interface to the data, 696 based on conferencing system and conferencing client actions, and 697 describe the resultant protocol implications 699 Any conference object in a conferencing system is created by either 700 being explicitly cloned from an existing parent object or being 701 implicitly cloned from a default system conference blueprint. A 702 conference blueprint is a static conference object used to describe a 703 typical conference setting supported by the system. Each system can 704 maintain multiple blueprints, typically each describing a different 705 conferencing type using the common conference information format, 706 along with any number of template definitions This document uses the 707 "cloning" metaphor instead of the "inheritance" metaphor because it 708 more closely fits the idea of object replication, rather than a data 709 type re-usage and extension concept. 711 The cloning operation needs to specify whether the link between the 712 parent and the child needs to be maintained in the system or not. If 713 no link between the parent and the child exists, the objects become 714 independent and are not impacted by any operations on the parent 715 object nor subject to any limitations of the parent object. 717 Once the new object is created, it can be addressed by a unique 718 conference object URI assigned by the system, as described in 719 Section 15 /[ref:TBD]. By default, the newly created object contains 720 all the data existing in the parent object. The newly created object 721 can expand the data it contains, within the schema types supported by 722 the parent. It can also restrict the read/write access to its 723 objects. However, unless the object is independent, it cannot relax 724 the access relative to its parent's access. 726 Any piece of data in the child object can be independently accessed 727 and, by default, can be independently modified without affecting the 728 parent data. 730 Unless the object is independent, the parent object can enforce a 731 different policy by marking certain data elements as "parent 732 enforceable". The values of these data elements can not be changed 733 by directly accessing the child object; neither can they be expanded 734 in the child object alone. 736 Figure 4 illustrates an example of a conference (Parent B), which is 737 created independent of its Parent (Parent A). Parent B creates two 738 child objects, Child 1 and Child 2. Any of the data elements of 739 Parent B can be modified (i.e. there are no "parent enforceable" data 740 elements) and depending upon the element, the changes will be 741 reflected in Child 1 and Child 2 , whereas changes to Parent A will 742 not impact the data elements of Parent B. Any "parent enforceable" 743 data elements as defined by Parent B cannot be modified in the child 744 objects. 746 +---+-----------------------+ 747 | p | | 748 | o | P A R E N T A | 749 | l | | 750 | i | C O N F E R E N C E | 751 | c | | 752 | i | O B J E C T | 753 | e | | 754 +-s-+-----------------------+ 755 | 756 \| / 757 \/ INDEPENDENT 758 /\ 759 /| \ 760 V 761 +---+-----------------------+ 762 | p | | 763 | o | P A R E N T B | 764 | l | | 765 | i | C O N F E R E N C E | 766 | c | | 767 | i | O B J E C T | 768 | e | | 769 +-s-+-----------------------+ 770 | | 771 | | 772 | --------------------------- 773 | | 774 V V 775 +---+-----------------------+ +---+-----------------------+ 776 | p | | | p | | 777 | o | C H I L D 1 | | o | C H I L D 2 | 778 | i | | | l | | 779 | l | C O N F E R E N C E | | i | C O N F E R E N C E | 780 | i | | | c | | 781 | c | O B J E C T | | i | O B J E C T | 782 | i | | | e | | 783 +-s-+-----------------------+ +-s-+-----------------------+ 785 Figure 4: The Cloning Tree. 787 Using the defined cloning model and its tools, the following sections 788 show examples of how different systems based on this framework can be 789 realized. 791 7.2. Ad-hoc Example 793 Figure 5 illustrates how an ad-hoc conference can be created and 794 managed in a conferencing system. A client can create a conference 795 by establishing a call signaling channel with a conference factory as 796 specified in Section 6.1. The conference factory can internally 797 select one of the system supported conference blueprints based on the 798 requesting client privileges and the media lines included in the SDP 799 body. 801 The selected blueprint with its default values is copied by the 802 server into a newly created conference object, referred to as an 803 'Active Conference'. At this point the conference object becomes 804 independent from its blueprint. A new conference object identifier, 805 a new conference identifier and a new focus are allocated by the 806 server. 808 During the conference lifetime, an authorized client can manipulate 809 the conference object, such as adding participants, using the 810 Conference Control Protocol [Section 8.3]. 812 +---+-----------------------+ 813 | p | | 814 | o | System Default | 815 | l | | 816 | i | Conference | 817 | c | | 818 | i | Blueprint | 819 | e | | 820 +-s-+-----------------------+ 821 | 822 \| / 823 \/ 824 /\ 825 /| \ 826 V 827 +---+-----------------------+ 828 | p | | 829 | o | Active | 830 | l | | 831 | i | Conference | 832 | c | | 833 | i | | 834 | e | | 835 +-s-+-----------------------+ 836 Figure 5: Conference Ad-hoc Creation and Lifetime. 838 7.3. Advanced Example 840 Figure 6 illustrates how a recurring conference can be specified 841 according to system capabilities, scheduled, reserved, and managed in 842 a conferencing system. A client would first query a conferencing 843 system for its capabilities. This can be done by requesting a list 844 of the conference blueprints the system supports. 846 Each blueprint contains a specific combination of capabilities and 847 limitations of the conference server in terms of supported media 848 types (e.g., audio, video, text, or combinations of these), 849 participant roles, maximum number of participants of each role, 850 availability of floor control, controls available for participants, 851 availability and type of sidebars, the definitions and names of media 852 streams, etc. As defined within this framework, a blueprint is 853 comprised of the common conference information and a template. A 854 blueprint consists of a single template, as the template approach 855 allows for defining combinations of media types in a single template 856 [ref]. Whether a blueprint needs to additionally support multiple 857 templates, and the associated mechanism, is for future study. 859 The template within the blueprint can either be included by-value or 860 by-reference depending upon the system implementation. In the case 861 of a template included by-reference within a blueprint, a client may 862 need to query a template that it doesn't understand and then make a 863 decision on compatibility. Interface hints need to be included as 864 per [20]. In this case, a client selects the specific blueprint to 865 use and retrieves the associated template from the conferencing 866 system itself, rather than from a centralized repository. 868 The selected blueprint with its default values is cloned by the 869 client into a newly created conference object, referred to as a 870 conference reservation, that specifies the resources needed from the 871 system for this conference instance. At this point the conference 872 reservation becomes independent from its blueprint. The client can 873 also change the default values, within the system ranges, and add 874 additional information, such as the list of participants and the 875 conference start time, to the conference reservation. 877 At this point the client can ask the conference server to create new 878 conference reservations by attaching the conference reservation to 879 the request. As a result, the server can allocate the needed 880 resources, create the additional conference objects for the child 881 conference reservations and allocate the conference object 882 identifiers for all - the original conference reservation and for 883 each child conference reservation. 885 From this point on, any authorized client is able to access and 886 modify each of the conference objects independently. By default, 887 changes to an individual child conference reservation will affect 888 neither the parent conference reservation, from which it was created, 889 nor its siblings. 891 On the other hand, some of the conference sub-objects, such as the 892 maximum number of participants and the participants list, can be 893 defined by the system as parent enforceable. As a result, these 894 objects can be modified by accessing the parent conference 895 reservation only. The changes to these objects can be applied 896 automatically to each of the child reservations, subject to local 897 policy. 899 +---+-----------------------+ 900 | p | | 901 | o | Selected | 902 | l | | 903 | i | Conference | 904 | c | | 905 | i | Blueprint | 906 | e | | 907 +-s-+-----------------------+ 908 | 909 \| / 910 \/ 911 /\ 912 /| \ 913 V 914 +---+-----------------------+ 915 | p | | 916 | o | Conference | 917 | l | | 918 | i | Reservation | 919 | c | | 920 | i | | 921 | e | | 922 +-s-+-----------------------+ 923 | | | 924 | | | 925 | | | 926 | | | 927 +---|--|--V-----------------+ 928 +-+---|--V------------------+ | 929 +-+-+---V-------------------+ | | 930 | p | | | | 931 | o | Child Conference | | | 932 | l | | | | 933 | i | Reservation | | | 934 | c | | | | 935 | i | | |-+ 936 | e | |-+ 937 +-s-+-----------------------+ 939 Figure 6: Advanced Conference Definition, Creation, and Lifetime. 941 When the time comes to schedule the conference reservation, either 942 via the system determination that the 'start' time has been reached 943 or via client invocation, an active conference is cloned based on the 944 conference reservation. As in the adhoc example, the active 945 conference is independent from the parent and changes to the 946 conference reservation will not impact the active conference. Any 947 desired changes must be targeted towards the active conference. An 948 example of this interaction is shown in Section 9.1 950 7.4. Scheduling a conference 952 The capability to schedule conferences forms an important part of the 953 conferencing system solution. An individual conference reservation 954 typically has a specified 'start' and 'end' time, with the times 955 being specified relative to a single specified 'fixed' time (e.g., 956 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system 957 considerations. In most advanced conferencing solutions it is 958 possible to not only schedule an individual occurrence of a 959 conference reservation, but also schedule a series of related 960 conferences (e.g., a weekly meeting that starts on Thursday at 09.00 961 GMT). 963 To be able to achieve such functionality, a conferencing system needs 964 to be able to appropriately schedule and maintain conference 965 reservations that form part of a recurring conference. The mechanism 966 proposed in this document makes use of the 'Internet Calendaring and 967 Scheduling Core Object' specification defined in RFC2445[8] in union 968 with the concepts introduced in Section 5 for the purpose of 969 achieving advanced conference scheduling capability. 971 Figure 7 illustrates a simplified view of a client interacting with a 972 conferencing system. The client is using the Conference Control 973 Protocol (Section 8.3) to add a new conference reservation to the 974 conferencing system by interfacing with the conference control 975 server. A CCP request contains a valid conference reservation and 976 reference by value to an 'iCal' object which contains scheduling 977 information about the conference (e.g., start time, end time). 979 +--------------+ +-------Conferencing System-----------------+ 980 | Generic ICAL | | | 981 | Resource | | ..Conference Instance.... | 982 +--------------+ | . . +-----------+| 983 ^ ^ | . +-------------------+ . | Conference|| 984 | | | . |Conference Objects |<--| Control || 985 | ----------------->. +-------------------+ . | Server || 986 | | . . +-----------+| 987 | | ......................... ^ | 988 | | ^ | | 989 +-----|--------------+ | | | 990 | v | | | 991 | +--------------+ | | | 992 | | Resource |<------------------+ | | 993 | | Scheduler | | | 994 | +--------------+ | | 995 | | | 996 +---------------------------------------------------------|------+ 997 | 998 | 999 +-Request-+ 1000 | | 1001 +----+ | 1002 |ICAL| | 1003 +----+----+ 1004 | 1005 | 1006 | 1007 Conference Control| 1008 Protocol | 1009 | 1010 +-------------+ 1011 | Conferencing| 1012 | Client | 1013 +-------------+ 1015 Figure 7: Resource Scheduling 1017 A CCP request to create a new conference reservation is validated, 1018 including the associated iCal object, and the resultant conference 1019 reservation is created. The conference reservation is uniquely 1020 represented within the conferencing system by a conference object 1021 identifier (e.g., xcon:hd87928374) as introduced in Section 6.2 and 1022 defined in [ref:TBD]. This unique URI is returned to the client and 1023 can be used to reference the conference reservation, if any future 1024 manipulations are required (e.g., alter start time), using a CCP 1025 request. 1027 The previous example explains how a client creates a basic conference 1028 reservation using an iCal reference in association with a conference 1029 control protocol. Figure 7 can also be applied when explaining how a 1030 series of conferences are scheduled in the system. The description 1031 is almost identical with the exception that the iCal definition that 1032 is included in a CCP request represents a series of recurring 1033 conference instances (e.g., conference start time, end time, occur 1034 weekly). The conferencing system will treat this request the same as 1035 the first example. The CCP request will be validated, along with the 1036 associated iCal object, and the conference reservation is created. 1037 The conference reservation and its conference object ID created for 1038 this example represent the entire series of recurring conference 1039 instances rather than a single Conference. If the client uses the 1040 conference object ID provided and a CCP request to adjust the 1041 conference reservation, every conference instance in the series will 1042 be altered. This includes all future occurrences, such as a 1043 conference scheduled as an infinite series, subject to the 1044 limitations of the available calendaring interface. 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 specific range of the series. A good example is a 1049 conference reservation that has been scheduled to occur every Monday 1050 at 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 Figure 7 1052 in mind, the client will construct a CCP request whose purpose is to 1053 modify the existing conference reservation for the recurring 1054 conference instance. The client will include the conference object 1055 ID provided by the conferencing system to explicitly reference the 1056 conference reservation within the conferencing system. A CCP request 1057 will contain all the required changes to the conference reservation 1058 (e.g., change of venue). 1060 The conferencing system matches the incoming CCP request to the 1061 existing conference reservation but identifies that the associated 1062 iCal object only refers to a range of the existing series. The 1063 conferencing system creates a child, by cloning the original 1064 conference reservation, to represent the altered conference instances 1065 within the series. The cloned child object is not independent of the 1066 original parent object, thus preventing any potential conflicts in 1067 scheduling (e.g., a change to the whole series 'start time'). The 1068 cloned conference reservation, representing the altered series of 1069 conference instances, has its own associated conference object ID 1070 which is returned to the client using a CCP response. This 1071 conference object ID is then used by the client to make any future 1072 alterations on the newly defined sub-series. This process can be 1073 repeated any number of times as the newly returned conference object 1074 ID representing an altered (cloned) series of conference instances, 1075 can itself be manipulated using a CCP request for the newly created 1076 conference object ID . This provides a flexible approach to the 1077 scheduling of recurring conference instances. 1079 8. Conferencing Mechanisms 1081 8.1. Call Signaling 1083 The focus is the central component of the conference. Participants 1084 interface with the focus using an appropriate call signaling 1085 protocol. Participants request to establish or join a conference 1086 using the call interface. After checking the applicable policies, a 1087 focus then either accepts the request, sends a progress indication 1088 related to the status of the request (e.g., for a parked call while 1089 awaiting moderator approval to join) or rejects that request using 1090 the call signaling interface. 1092 During an active conference, a Conference Control Protocol 1093 [Section 8.3] can be used to affect the conference state. For 1094 example, CCP requests to add and delete participants are communicated 1095 to the focus and checked against the conference policies. If 1096 approved, the participants are added or deleted using the call 1097 signaling to/from the focus. 1099 8.2. Notifications 1101 A conferencing system is responsible for implementing a Conference 1102 Notification Service. The Conference Notification Service provides 1103 updates about the conference instance state to authorized parties, 1104 including participants. A model for notifications using SIP is 1105 defined in [11]. 1107 The conference user identifier and associated role are used by the 1108 conferencing system to filter the notifications such that they 1109 contain only information that is allowed to be sent to that user. 1111 8.3. Conference Control Protocol 1113 The conference control protocol provides for data manipulation and 1114 state retrieval for the centralized conferencing data, represented by 1115 the conference object. The details of the conference control 1116 protocol are detailed in separate documents [references TBD]. 1118 [Editor's note: The remaining paragraphs and subsections of this 1119 section, detailing the various protocol options should be pruned from 1120 this document, once the WG reaches consensus on the conference 1121 control protocol.] 1123 8.3.1. CCCP 1125 A Centralized Conferencing Control Protocol [19] is a semantic- 1126 oriented protocol defined to allow participants or otherwise 1127 authorized entities to directly manipulate an active conference 1128 instance. CCCP is defined as a set of transactions issued over a 1129 reliable transport protocol. A transaction consists of a Request 1130 carrying the required information in an XML body and a corresponding 1131 Response carrying an appropriate XML body. 1133 CCCP requests are submitted to the CCCP server and can be prioritized 1134 and queued, based on the CCCP client Role and the requested 1135 primitives. CCCP requires no single lock per document, and the CCCP 1136 server can locally implement an optimization strategy independent of 1137 CCCP client behavior. 1139 8.3.2. CSCP 1141 A Conference State Change protocol [25] is a client server protocol 1142 used to change the state of a conference object. CSCP extends the 1143 BFCP protocol [16] with new commands. A client sends the server a 1144 request representing a sequence of commands. Each command can set, 1145 get, add, or delete a single field in the conference object. Changes 1146 to the conference object are performed on a hierarchal set of 1147 elements and unique attributes within those elements. A series of 1148 changes can be pipelined in a single BFCP message. The server 1149 executes each action in series. If one of them fails, the server 1150 returns an error for the action that failed and does not execute any 1151 of the actions after that. Each individual action is atomic but the 1152 pipelined series is not. 1154 The item to which a command applies is specified by a unique ID and, 1155 where appropriate, attribute name. The ID is an unsigned 32 bit 1156 integer called the Element ID. The server discovery of the Element 1157 ID is outside of CSCP. Typically this is done by using the 1158 conference notification service per Section 8.2. Each field in the 1159 data received in the notification contains a unique field ID 1160 attribute that can be used in BFCP requests. 1162 8.3.3. SOAP 1164 The SOAP protocol is fundamentally an XML messaging scheme, capable 1165 of supporting remote procedure calls. SOAP defines a simple message 1166 format composed of a "header" and a "body" contained within an 1167 "envelope". The "header" contains meta-information relating to the 1168 message, and can be used to indicate such things as store-and-forward 1169 behaviour or transactional characteristics. In addition, SOAP 1170 encoding is optimized for ease of automated deserialization. 1172 SOAP [17] and [18] is proposed as the mechanism for object content 1173 manipulation and state retrieval for the centralized conferencing 1174 data. In general, SOAP is a good fit for Conference Control, 1175 essentially because of its remote procedure call characteristics and 1176 its inherently synchronous and client-driven nature. 1178 8.4. Floor Control 1180 A floor control protocol allows an authorized client to manage access 1181 to a specific floor and to grant, deny or revoke access of other 1182 conference users to that floor. Floor control is not a mandatory 1183 mechanism for a conferencing system implementation but provides 1184 advanced media input control features for conference users. A 1185 mechanism for floor control within a conferencing system is defined 1186 in the Binary Floor Control Protocol specification [16]. [Editor's 1187 note: Evaluation of an alternative proposal, as a stand alone draft, 1188 for using Templates as the means for correlating Floor Control 1189 identifiers has been proposed. If/when this work is done, it needs 1190 to be introduced and referenced here]. 1192 Within this framework, a client supporting floor control needs to 1193 obtain information for connecting to a floor control server to enable 1194 it to issue floor requests. This connection information can be 1195 retrieved using information provided by mechanisms such as 1196 negotiation using the SDP[2] offer/answer[5] exchange on the 1197 signaling interface with the focus. Section 11.3 provides a 1198 discussion of client authentication of a floor control server. 1200 As well as the client to the floor control server connection 1201 information, a client wishing to interact with a floor control server 1202 requires access to additional information. This information 1203 associates floor control interactions with the appropriate floor 1204 instance. Once a connection has been established and authenticated 1205 (see [16] for authentication details), a specific floor control 1206 message requires detailed information to uniquely identify a 1207 conference, a user and a floor. 1209 The conference is uniquely identifed by the conference object ID per 1210 Section 6.2.1. This conference object ID must be included in all 1211 floor control messages. When the SDP model is used as described in 1212 [23] this identifier maps to the 'confid' SDP attribute. 1214 Each authorized user associated with a conference object is uniquely 1215 represented by a conference user ID per Section 6.3. This conference 1216 user ID must be included in all floor control messages. When using 1217 SDP offer/answer exchange to negotiate a Floor control connection 1218 with the focus using the call signaling interface, the unique 1219 conference identifier is contained in the 'userid' SDP attribute, as 1220 defined in [23] 1222 A media session witin a conferencing system can have any number of 1223 floors (0 or more) that are represented by the conference identifer. 1224 When using SDP offer/answer exchange to negotiate a floor control 1225 connection with the focus using the call signaling interface, the 1226 unique conference identifier is contained in the 'floorid' SDP 1227 attribute, as defined in [23] e.g., a=floorid:1 m-stream:10 . Each 1228 'floorid' attribute, representing a unique floor, has an 'm-stream' 1229 tag containing one or more identifiers. The identifiers represent 1230 individual SDP media sessions (as defined using 'm=' from SDP) using 1231 the SDP 'Label' attribute as defined in [22]. 1233 9. Conferencing Scenario Realizations 1235 This section addresses how advanced conferencing scenarios, many of 1236 which have been described in [14], are realized using this 1237 centralized conferencing framework. The objective of this section is 1238 to further illustrate the model, mechanisms and protocols presented 1239 in the previous sections and also serves to validate that the model, 1240 mechanisms and protocols are sufficient to support advanced 1241 conferencing scenarios. 1243 The details shown in the messages are for illustrative purposes only 1244 and don't reflect the structure of the conference control protocol 1245 messages, but rather provide a high level primitive view of the 1246 necessary operations and general logic flow, including the data 1247 manipulation aspects. It should be noted that not all entities 1248 impacted by the request are shown in the diagram (e.g., Focus), but 1249 rather the emphasis is on the new entities introduced by this 1250 centralized conferencing framework. 1252 9.1. Conference Creation 1254 There are different ways to create a conference. A participant can 1255 create a conference using call signaling means only, such as SIP and 1256 detailed in [15]. For a conferencing client to have more flexibility 1257 in defining the charaterisitics and capabilities of a conference, a 1258 conferencing client would implement a conference control protocol 1259 client. By using a conference control protocol, the client can 1260 determine the capabilities of a conferencing system and its various 1261 resources. 1263 Figure 8 provides an example of one client "Alice" determining the 1264 conference blueprints available for a particular conferencing system 1265 and creating a conference based on the desired blueprint. 1267 +--------------------------------+ 1268 | Conferencing System | 1269 "Alice" | +------------+| 1270 +--------+ | | || 1271 | |CCP Request | +-----------+ | || 1272 | Client |-------------------------->|Conference | |Conference || 1273 | |<--------------------------|Control |~~~>|Blueprint(s)|| 1274 +--------+CCP Response | | 1278 "Alice" | 1279 +--------+ | | 1280 | |CCP Request |Conference | |Conference || 1283 | | confUserID> | |Control |~~~>|BlueprintA || 1284 | |<--------------------------|Server | | || 1285 | |CCP Response | | | +------------+| 1286 +--------+ | | | /|\ | 1288 | | | V | 1289 | | | +------------+| 1290 | | |~~~>|Conference || 1291 | | | |Reservation || 1292 | +-----------+ +------------+| 1293 "Alice" | | | 1294 +--------+ | | | 1295 | |CCP Request |Conference | |Active || 1298 | | confID,confUserID> | |Control |~~~>|Conference || 1299 | |<--------------------------|Server | | || 1300 | |CCP Response | | | +------------+| 1301 +--------+ | +-----------+ | 1303 +--------------------------------+ 1305 Figure 8: Client Creation of Conference using Blueprints 1307 Upon receipt of the Conference Control Protocol request for 1308 blueprints, the conferencing system would first authenticate "Alice" 1309 (and allocate a conference user identifier, if necessary) and then 1310 ensure that "Alice" has the appropriate authority based on system 1311 policies to receive any blueprints supported by that system. Any 1312 blueprints that "Alice" is authorized to use are returned in a 1313 response, along with the conference user ID. 1315 Upon receipt of the Conference Control Protocol response containing 1316 the blueprints, "Alice" determines which blueprint to use for the 1317 conference to be created. "Alice" creates a conference object based 1318 on the blueprint (i.e., clones) and modifies applicable fields, such 1319 as membership list and start time. "Alice" then sends a request to 1320 the conferencing system to create a conference reservation based upon 1321 the updated blueprint. 1323 Upon receipt of the Conference Control Protocol request to "reserve" 1324 a conference based upon the blueprint in the request, the 1325 conferencing system ensures that the blueprint received is a valid 1326 blueprint (i.e. the values of the various field are within range). 1327 The conferencing system determines the appropriate read/write access 1328 of any users to be added to a conference based on this blueprint 1329 (using membership, roles, etc.). The conferencing system uses the 1330 received blueprint to clone a conference reservation. The 1331 conferencing system also reserves or allocates a conference ID to be 1332 used for any subsequent protocol requests from any of the members of 1333 the conference. The conferencing system maintains the mapping 1334 between this conference ID and the conference object ID associated 1335 with the reservation through the conference instance. 1337 Upon receipt of the conference control protocol response to reserve 1338 the conference, "Alice" can now create an active conference using 1339 that reservation or create additional reservations based upon the 1340 existing reservations. In this example, "Alice" has reserved a 1341 meetme conference bridge. Thus, "Alice" provides the conference 1342 information, including the necessary conference ID, to desired 1343 participants. When the first participant, including "Alice", 1344 requests to be added to the conference, an active conference and 1345 focus are created. The focus is associated with the conference ID 1346 received in the request. Any participants that have the authority to 1347 manipulate the conference would receive the conference object 1348 identifier of the active conference in the response. 1350 9.2. Participant Manipulations 1352 There are different ways to affect a participant state in a 1353 conference. A participant can join and leave the conference using 1354 call signaling means only, such as SIP. This kind of operation is 1355 called "1st party signaling" and does not affect the state of other 1356 participants in the conference. 1358 Limited operations for controlling other conference participants (a 1359 so called "3rd party control") through the Focus, using call 1360 signaling only, may also be available for some signaling protocols. 1361 For example, "Conferencing for SIP User Agents" [15] shows how SIP 1362 with REFER can be used to achieve this functionality. 1364 In order to perform richer conference control a user client needs to 1365 implement a conference control protocol client. By using a 1366 conference control protocol, the client can affect its own state, 1367 state of other participants, and state of various resources (such as 1368 media mixers) which may indirectly affect the state of any of the 1369 conference participants. 1371 Figure 9 provides an example of one client "Alice" impacting the 1372 state of another client "Bob". This example assumes an established 1373 conference. In this example, "Alice" wants to add "Bob" to the 1374 conference. 1376 +--------------------------------+ 1377 | Conferencing System | 1378 "Alice" | +---------+--+| 1379 +--------+ | |policies | || 1380 | |CCP Request < | +-----------+ +---------+ || 1381 | Client |-------------------------->|Conference | | Active || 1382 | | Conference Object ID, | |Control |~~~>|Conference || 1383 +--------+ Add, "Bob" > | |Server | | || 1384 | +-----------+ +-------+ || 1385 | |"Alice"| || 1386 "Bud" | ' ' '| 1387 +--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '| 1388 | |<-------------------------|Notification|<~~~| || 1389 | Client |. . ||Service | +-------+ || 1390 +--------+--+ . || | |"Bob" | || 1391 | |<----------------------| | +-------+----+| 1392 | Client |NOTIFY <"Bob"="added">|+------------+ | 1393 +--------+ +--------------------------------+ 1394 "Bob" 1396 Figure 9: Client Manipulation of Conference - Add a party 1398 Upon receipt of the Conference Control Protocol request to "add" a 1399 party ("Bob") in the specific conference as identified by the 1400 conference object ID, the conferencing system ensures that "Alice" 1401 has the appropriate authority based on the policies associated with 1402 that specific conference object to perform the operation. The 1403 conferencing system must also determine whether "Bob" is already a 1404 user of this conferencing system or whether he is a new user. 1406 If "Bob" is a new user for this conferencing system, a Conference 1407 User Identifier is created for Bob. Based upon the addressing 1408 information provided for "Bob" by "Alice", the call signaling to add 1409 "Bob" to the conference is instigated through the Focus. 1411 Once the call signaling indicates that "Bob" has been successfully 1412 added to the specific conference, per updates to the state, and 1413 depending upon the policies, other participants (including "Bob") may 1414 be notified of the addition of "Bob" to the conference via the 1415 Conference Notification Service. 1417 9.3. Media Manipulations 1419 There are different ways to manipulate the media in a conference. A 1420 participant can change its own media streams by, for example, sending 1421 re-INVITE with new SDP content using SIP only. This kind of 1422 operations is called "1st party signaling" and they do not affect the 1423 state of other participants in the conference. 1425 In order to perform richer conference control a user client needs to 1426 implement a conference control protocol client. By using a 1427 conference control protocol, the client can manipulate the state of 1428 various resources, such as media mixers, which may indirectly affect 1429 the state of any of the conference participants. 1431 Figure 10 provides an example of one client "Alice" impacting the 1432 media state of another client "Bob". This example assumes an 1433 established conference. In this example, the client, "Alice" whose 1434 Role is "moderator" of the conference, wants to mute "Bob" on a 1435 medium-size multi-party conference, as his device is not muted (and 1436 he's obviously not listening to the call) and background noise in his 1437 office environment is disruptive to the conference. 1439 +--------------------------------+ 1440 | Conferencing System | 1441 "Alice" | +---------+--+| 1442 +--------+ | |policies | || 1443 | |CCP Request < | +-----------+ +---------+ || 1444 | Client |-------------------------->|Conference | |Active || 1445 | | Conference Object ID, | |Control |~~~>|Conference || 1446 +--------+ Mute, "Bob" > | |Server | | || 1447 | +-----------+ +-------+ || 1448 | |"Alice"| || 1449 | ' ' '| 1450 +--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '| 1451 | |<-------------------------|Notification|<~~~| || 1452 | Client |. . ||Service | +-------+ || 1453 +--------+--+ . || | |"Bob" | || 1454 | |<----------------------| | +-------+----+| 1455 | Client | NOTIFY <"Bob"=mute">|+------------+ | 1456 +--------+ +--------------------------------+ 1458 Figure 10: Client Manipulation of Conference - Mute a party 1460 Upon receipt of the Conference Control Protocol request to "mute" a 1461 party ("Bob") in the specific conference as identified by the 1462 conference object ID, the Conference Server ensures that "Alice" has 1463 the appropriate authority based on the policies associated with that 1464 specific conference object to perform the operation. "Bob's" status 1465 is marked as "recvonly" and the Conference Template of the Conference 1466 Object (if included) is updated to reflect that "Bob's" media is not 1467 to be "mixed" with the conference media. 1469 Depending upon the policies, other participants (including "Bob") may 1470 be notified of this change via the Conference Notification Service. 1472 9.4. Sidebar Manipulations 1474 A sidebar can be viewed as a separate Conference instance that only 1475 exists within the context of a parent conference instance. Although 1476 viewed as an independent conference instance, it can not exist 1477 without a parent. A sidebar is created using the same mechanisms 1478 employed for a standard conference as described in Section 7.1. 1480 A conference object representing a sidebar is created by cloning the 1481 parent associated with the existing conference and updating any 1482 information specific to the sidebar. A sidebar conference object is 1483 implicitly linked to the parent conference object (i.e. it is not an 1484 independent object) and is associated with the parent conference 1485 object identifier as as shown in Figure 11. A conferencing system 1486 manages and enforces the parent and appropriate localized 1487 restrictions on the sidebar conference object (e.g., no members from 1488 outside the parent conference instance can join, sidebar conference 1489 can not exist if parent conference is terminated, etc.). 1491 +--------------+ 1492 | Conference | 1493 | Object | 1494 | Identifier | 1495 +--------------+ 1496 | 1497 | 1498 | 1499 +---------------------+---------------------+ 1500 | | | 1501 +-------+-------+ +-------+-------+ +-------+-------+ 1502 | Sidebar | | Sidebar | | Sidebar | 1503 | Conference | | Conference | | Conference | 1504 | Object | | Object | | Object | 1505 | Identifier | | Identifier | | Identifier | 1506 +-------+-------+ +-------+-------+ +---------------+ 1508 Figure 11: Conference Object Mapping. 1510 Figure 11 illustrates the relationship between a conference object 1511 and associated Sidebar conference objects within a conferencing 1512 system. Each Sidebar conference object has a unique conference 1513 object Identifier as described in Section 6.2.1. The main conference 1514 object identifier acts as a top level identifier for associated 1515 sidebars. 1517 A sidebar conference object Identifier follows many of the concepts 1518 outlined in the cloning tree model described in Section 7.1. A 1519 Sidebar conference object contains a subset of members from the 1520 original Conference object. Properties of the sidebar conference 1521 object can be manipulated by a Conference Control Protocol 1522 (Section 8.3) using the unique conference object identifier for the 1523 sidebar. It is also possible for the top level conference object to 1524 enforce policy on the sidebar object (similar to parent enforceable 1525 as discussed in Section 7.1). 1527 Figure 12 provides an example of one client "Alice" involved in 1528 active conference with "Bob" and "Bud". "Alice" wants to create a 1529 sidebar to have a side discussion with "Bob" while still viewing the 1530 video associated with the main conference. "Alice" initiates the 1531 sidebar by sending a request to the conferencing system to create a 1532 conference reservation based upon the active conference object. 1534 +--------------------------------+ 1535 | Conferencing System | 1536 | +---------+--+| 1537 | |policies | || 1538 | +---------+ || 1539 | |Active || 1540 | |Conference || 1541 "Alice" | +-------+ || 1542 +--------+ | |"Alice"| || 1543 | |CCP Req |Conference | +-------+ || 1546 | | confUserID> | |Control |~~~>|"Bud" | || 1547 | |<--------------------------|Server | +-------+----+| 1548 | |CCP Response | | | | | 1549 +--------+ | | | V | 1551 | | | +---------+--+| 1552 | | | |policies | || 1553 | | |~~~>+---------+ || 1554 | | | | || 1555 | +-----------+ | || 1556 "Alice" | | Sidebar || 1557 +--------+ | | Reservation|| 1558 | |CCP Request | |~~~>| || 1561 | | confID,confUserID, | | | +------------+| 1562 | | video=parent, | | | | | 1563 | | audio=sidebar> | |Conference | | | 1564 | | | |Control | V | 1565 | | | |Server | +---------+--+| 1566 | |CCP Response | | | |policies | || 1567 | | | | | |Sidebar || 1570 | | | |Conference || 1571 | +-----------+ +-------+ || 1572 | |"Alice"| || 1573 "Bob" | | | || 1574 +--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ || 1575 | |<-------------------------|Notification|<~~~| | || 1576 | Client | ||Service | |"Bob" | || 1577 +--------+ || | +-------+----+| 1578 |+------------+ | 1579 +--------------------------------+ 1581 Figure 12: Client Creation of a Sidebar Conference 1583 Upon receipt of the Conference Control Protocol request to "reserve" 1584 a new sidebar conference, based upon the active conference received 1585 in the request, the conferencing system uses the received active 1586 conference to clone a conference reservation for the sidebar. As 1587 discussed previously, the sidebar reservation is NOT independent of 1588 the active conference (i.e., parent). The conferencing system also 1589 reserves or allocates a conference ID to be used for any subsequent 1590 protocol requests from any of the members of the conference. The 1591 conferencing system maintains the mapping between this conference ID 1592 and the conference object ID associated with the sidebar reservation 1593 through the conference instance. 1595 Upon receipt of the conference control protocol response to reserve 1596 the conference, "Alice" can now create an active conference using 1597 that reservation or create additional reservations based upon the 1598 existing reservations. In this example, "Alice" wants only "Bob" to 1599 be involved in the sidebar, thus she manipulates the membership. 1600 Alice also only wants the video from the original conference and 1601 wants the audio to be restricted to the participants in the sidebar. 1602 Alice sends a conference control protocol request to update the 1603 information in the reservation and to create an active conference. 1605 Upon receipt of the conference control protocol request to update the 1606 reservation and to create an active conference for the sidebar, as 1607 identified by the conference object ID, the conferencing system 1608 ensures that "Alice" has the appropriate authority based on the 1609 policies associated with that specific conference object to perform 1610 the operation. The conferencing system must also validate the 1611 updated information in the reservation, ensuring whether members like 1612 "Bob" are already a user of this conferencing system or whether he is 1613 a new user. If "Bob" is a new user for this conferencing system, a 1614 conference user identifier is created for Bob. Based upon the 1615 addressing information provided for "Bob" by "Alice", the call 1616 signaling to add "Bob" to the conference is instigated through the 1617 Focus. 1619 Depending upon the policies, the participants in the sidebar (i.e., 1620 "Bob") may be notified of his addition to the sidebar via the 1621 conference notification service. 1623 9.5. Whispering or Private Messages 1625 The case of private messages can be handled as a sidebar with just 1626 two participants, similar to the example in section Section 9.4, but 1627 rather than using audio within the sidebar, "Alice" could add an 1628 additional text based media stream to the sidebar. The other 1629 context, referred to as whisper, in this document refers to 1630 situations such as when a announcement server injects a message 1631 targetted to specific user(s). The details of this mechanism within 1632 the context of the framework are TBD. 1634 9.6. Conference Announcements and Recordings 1636 Each participant can require a different type of announcement and/or 1637 recording service from the system. For example, "Alice", the 1638 conference chair, could be listening to a roll call while "Bob" may 1639 be using a telephony user interface to create a sidebar. The 1640 conferencing system would also need to have the capability to monitor 1641 for DTMF from each individual participant. 1643 Further details of conference announcements and recordings, within 1644 the context of this framework, are TBD. 1646 10. Relationships between SIPPING and Centralized Conferencing 1647 Frameworks 1649 The SIPPING Conferencing Framework [9] provides an overview of a wide 1650 range of centralized conferencing solutions known today in the 1651 conferencing industry. The document introduces a terminology and 1652 logical entities in order to systemize the overview and to show the 1653 common core of many of these systems. The logical entities and the 1654 listed scenarios in the SIPPING Conferencing Framework are being used 1655 to illustrate how SIP [4] can be used as a signaling means in these 1656 conferencing systems. SIPPING Conferencing Framework does not define 1657 new conference control protocols to be used by the general 1658 conferencing system. It uses only basic SIP [4], the SIP 1659 Conferencing for User Agents [15], and the SIPPING Conference Package 1660 [9] for basic SIP conferencing realization. 1662 This centralized conferencing framework document defines a particular 1663 centralized conferencing system and the logical entities implementing 1664 it. It also defines a particular data model and refers to the set of 1665 protocols (beyond call signaling means) being defined by the XCON WG 1666 to be used among the logical entities for implementing advanced 1667 conferencing features. The purpose of the XCON working group and 1668 this framework is to achieve interoperability between the logical 1669 entities from different vendors for controlling different aspects of 1670 advanced conferencing applications. 1672 The logical entities defined in the two frameworks are not intended 1673 to be mapped one-to-one. The two frameworks differ in the 1674 interpretation of the internal conferencing system decomposition and 1675 the corresponding operations. Nevertheless, the basic SIP [4], the 1676 SIP Conferencing for User Agents [15], and the SIPPING Conference 1677 Package [9] are fully compatible with both Framework documents. 1679 11. Security Considerations 1681 There are a wide variety of potential attacks related to 1682 conferencing, due to the natural involvement of multiple endpoints 1683 and the many, often user-invoked, capabilities provided by the 1684 conferencing system. Examples of attacks include the following: an 1685 endpoint attempting to listen to conferences in which it is not 1686 authorized to participate, an endpoint attempting to disconnect or 1687 mute other users, and theft of service, by an endpoint, in attempting 1688 to create conferences it is not allowed to create. 1690 There are several issues surrounding security of this conferencing 1691 framework. One set of issues involves securing the actual protocols 1692 and the associated authorization mechanisms. This first set of 1693 issues should be addressed in the specifications specific to the 1694 protocols described in Section 8. The protocols used for 1695 manipulation and retrieval of confidential information MUST support a 1696 confidentiality and integrity mechanism. Similar requirements apply 1697 for the floor control protocols. Section 11.3 discusses an approach 1698 for client authentication of a floor control server. 1700 There are also security issues associated with the authorization to 1701 perform actions on the conferencing system to invoke specific 1702 capabilities. Section 5.3 discusses the policies associated with the 1703 conference object to ensure that only authorized entities are able to 1704 manipulate the data to access the capabilities. The final set of 1705 issues involves the privacy and security of the identity of a user in 1706 the conference, which is discussed in Section 11.2 1708 11.1. Authorization 1710 Many policy authorization decisions are based on the identity of the 1711 user or the role that a user may have. There are several ways that a 1712 user might authenticate its identity to the system. The conferencing 1713 system may know about specific users and assign passwords to the 1714 users. The users may also be authenticated by knowing a particular 1715 conference ID and a PIN for it. Sometimes, a PIN is not required and 1716 the conference ID is used as a shared secret. The call signaling 1717 means can provide a trusted form of the user identity or it might 1718 just provide a hint of the possible identity and the user still needs 1719 to provide some authentication to prove it has the identity that was 1720 provided as a hint in the call signaling. This may be in the form of 1721 an IVR system or other means. The goal for the conferencing system 1722 is to figure out a user identity and a role for any attempt to send a 1723 request to the conferencing system. 1725 When a conferencing system presents the identity of authorized users, 1726 it may choose to provide information about the way the identity was 1727 proven to or verified by the system. A user may also come as a 1728 completely unauthenticated user into the system - this fact needs 1729 also be communicated to interested parties. 1731 When guest users interact with the system, it is often in the context 1732 of a particular conference. In this case, the user may provide a PIN 1733 or a password that is specific to the conferences and authenticates 1734 the user to take on a certain role in that conference. The guest 1735 user can then perform actions that are allowed to any user with that 1736 role. 1738 The term password is used to mean the usual, that is to say a 1739 reasonable sized, in number of bits, hard to predict shared secret. 1740 Today users often have passwords with more than 30 bits of randomness 1741 in them. PIN is a special password case - a shared secret that is 1742 only numeric and often contains a fairly small number of bits (often 1743 as few as 10 bits). When conferencing systems are used for audio on 1744 the PSTN, there is often a need to authenticate using a PIN. 1745 Typically if the user fails to provide the correct PIN a few times in 1746 a row, the PSTN call is disconnected. The rate of making the calls 1747 and getting to the point to enter a PIN makes it fairly hard to do an 1748 exhaustive search of the PIN space even for 4 digit PINs. When using 1749 a high speed interface to connect to a conferencing system, it is 1750 often possible to do thousands of attempts per second and the PIN 1751 space could quickly be searched. Because of this, it is not 1752 appropriate to use PINs for authorization on any of the interfaces 1753 that provide fast queries or many simultaneous queries. 1755 11.2. Security and Privacy of Identity 1757 This conferencing system has an idea of the identity of a user but 1758 this does not mean it can reveal this identity to other users, due to 1759 privacy considerations. Users can set select various options for 1760 revealing their identity to other users. A user can be "hidden" such 1761 that other users can not see they are involved in the conference, or 1762 they can be "anonymous" such that users can see that another user is 1763 there, but not see the identity of the user, or they can be "public" 1764 where other users can see their identity. If there are multiple 1765 "anonymous" users, other parties will be able to see them as 1766 independent "anonymous" parties and will be able to tell how many 1767 "anonymous" parties are in the conference. Note, that the visibility 1768 to other participants is dependent on their roles. For example, 1769 users' visibility (including "anonymous" and "hidden") may be 1770 displayed to the moderator or administrator, subject to a 1771 conferencing system's local policies. "Hidden" status is often used 1772 by robot participants of a conference (e.g., call recording) and is 1773 also used in many call center situations. 1775 11.3. Floor Control Server Authentication 1777 Clients can authenticate a floor control server using the TLS 1778 certificates. Requests submitted on a successfully created 1779 connection between the client and floor control server may 1780 additionally require digest authentication within the BFCP protocol 1781 to authenticate the floor control client to the server. For this to 1782 take place, a shared secret needs to be exchanged between the floor 1783 control client/server entities. This can be achieved out of band 1784 using a mechanism such as the 'k=' SDP attribute. The shared secret 1785 can also be exchanged using un-specified 'out of band' mechanisms. 1786 When using Digest authentication of floor control client messages the 1787 exchange of an active 'Nonce' is also required. This can be achieved 1788 using a BFCP request response interaction as defined in BFCP (A 1789 request is submitted without a Nonce TLV and the server generates an 1790 error response with either an Error Code 7 (DIGEST TLV Required) or 6 1791 (Invalid Nonce) containing the valid nonce). The BFCP 'Nonce' value 1792 can also be obtained 'out of band' using information provided in the 1793 offer/answer exchange. As with the other SDP Floor attributes 1794 referenced in this section and defined in [23], the 'nonce' attribute 1795 can be inserted in the SIP response e.g., a=nonce:dhsa8hd0dwqj. 1797 [Editor's Note: May need more specifics on fetching from the 1798 conference object the credentials required for BFCP. This includes 1799 the conference id, user id, and password.] 1801 12. IANA Considerations 1803 This is an informational draft, with no IANA considerations required. 1805 13. Acknowledgements 1807 This document is a result of architectural discussions among IETF 1808 XCON working group participants. The authors would like to thank 1809 Henning Schulzrinne for the "Conference Object Tree" proposal and 1810 general feedback, Cullen Jennings for providing input for the 1811 "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar 1812 Novo, Roni Even, Umesh Chandra and Avshalom Houri for their reviews 1813 and constructive input. 1815 14. Changes since last Version 1817 Changes from WG 02 to 03: 1819 - Updated the definition of Blueprint (per DP 4/4.1 discussions) 1821 - Added definition for Sidebar. 1823 - Section 5.2 Added text indicating that adding new elements or 1824 modifying elements requires the definition of a new template. (per 1825 DP4.2 conclusion). 1827 - Section 7.3. Added text reiterating that the blueprint comprises 1828 both the common conference information and a template (per DP4/4.1 1829 discussions. 1831 - Section 7.3. Added text per resolution of DP 4.3 indicating that a 1832 blueprint is common conference information + one template and that 1833 multiple templates is FFS. 1835 - Section 8.3 - Updated Conference Control Protocol section to 1836 include the protocols on the table for WG discussion as of 31 Dec 1837 2005 deadline. 1839 - Section 9.4 - Sidebars - added Ascii art to show FW interactions 1841 - Section 9.5 - Whisper - Added some text, reflecting past WG 1842 discussions. Basic definition and further details/example still 1843 needed. 1845 - Section 9.6 - Conf Anncs and Recordings - Added some basic text. 1846 Further details/example still needed. 1848 Changes from WG 01 to 02: 1850 - Editorial nits -i.e. consistent terminology, capatilization, etc. 1852 - Revamped abstract and introduction 1854 - Global removal of XCON as a qualifier (we had previously done this 1855 in a previous version with all the identifiers). 1857 - Global change of "call control signalling" to "call signaling" 1859 - Moved the terminology section after the Overview section: 1861 - - Modified the definitions to be more concise and per some of 1862 Henning's recommendations. 1864 - - Added definitions for blueprint and conference reservation. 1866 - Clarified the definition of policy and added more explicit text as 1867 to how policy is accomplished via the data model and system 1868 realization (section 4.3 and 6.1) 1870 - Removed the Editor's note/text in section 4 about the options for 1871 the schema; added a reference to a TBD schema document. 1873 - Section 5: 1875 - - clarified the identifiers. Kept the logical definition as 1876 "identifiers", although most will be realized as URIs. 1878 - - deleted the section on conference instance. 1880 - - removed the term "umbrella" from sections conference User and 1881 conference object identifier sections 1883 - - moved alot of detail from Conference User Identifier and 1884 conference Object Identifier sections into appendices, and added 1885 additional detail, that will become the basis for separate documents. 1887 - In section 6: 1889 - - added a bit of explanation as to the intent of the cloning tree 1890 model - it's not implementation binding, but rather to illustrate the 1891 data model and context for the protocol interactions. 1893 - - removed the term copying altogether. Cloning is the model and 1894 the idea is that the cloned object contains data indentical to the 1895 parent when it was created (whether it gets "copied" or whatever from 1896 the parent is an implementation issue). 1898 - - introduce the blueprint concept in section 6.1 prior to its 1899 implied usage in 6.2 and 6.3. 1901 - - removed the usage of the term occurrence (which is just a child 1902 reservation). 1904 - Removed security related details from Floor Control section and 1905 moved those to the security section. As a result removed most of the 1906 editorial notes from the front of the Floor control section and 1907 integrated the remaining ones inline into that section, where the 1908 resolution should be documented. 1910 - Section 8: 1912 - - Added new example 8.1 - conference creation 1914 - - Added a placeholder for a more detailed example to the sidebar 1915 section to show a sidebar which has some media specifically 1916 associated with the sidebar (i.e. audio), yet still use the main 1917 conference for other media (visual presentation). 1919 - Section 11: As a result of adding additional information to the 1920 security section, divided this section into subsections for clarity. 1922 Changes from WG 00 to 01:: 1924 - Section 2 (Conventions and Terminology). Slight modifications to 1925 definitions of Call (control) signaling, Conference Identifer, 1926 Conference Instance, Conference Object. 1928 - Section 2 (Conventions and Terminology).Renaming of term 1929 "Registered Template Definition" to "Registered Conference Document" 1930 (per agreement at interim meeting). 1932 - Section 3 (Next to the last paragraph on the media model). 1933 Clarified the text such that it doesn't read that the focus performs 1934 media mixing. Changed "focus" to "media mixer controlled by the 1935 focus" in the 2nd sentence and "performed" to "controlled" in the 1936 4th. 1938 - Section 5. Rearranged the sub-sections a bit for better flow. 1939 First describe the Conference ID, then the Conference Instance, 1940 followed by the Conference Object, with the Conference Object 1941 Identifer described in a subsection of the Conference Object section. 1942 Added a diagram showing the relationship between Conference 1943 Identifer/Focus and Conference Object Identifier, within the context 1944 of a Conference Instance to the Conference Object section. 1946 - Section 6.1 (Cloning Tree). Rewording to clarify which operations 1947 apply to independent objects (and non-independent). 1949 - Section 6.3 (Advanced Example). Added additional text with regards 1950 to future conferences, introducing the concept of infinite series 1951 (which would be limited by calendaring interface). 1953 - Section 7.3 (Conference Control Protocol). Updated to include 1954 reference to SOAP option. 1956 - Section 8.3 (sidebars) - reworded 1st paragraph to be more explicit 1957 about the XCON FW constructs used. 1959 Changes from individual 02 to WG 00: 1961 - few minor editorial changes 1963 - Section 2. Removed second sentence of definition of Conference ID, 1964 as that's now included/described in context in new Identifier 1965 section. 1967 - Section 3. Clarified that TBD in Figure 1 is "Conference Control 1968 Protocol" (per Keith's comment to be more explicit). 1970 - Section 4.1. Identifiers. Moved this to a new section ( 1971 Section 6). 1973 - New section for Identifiers ( Section 6), thus all section 1974 references beyond 4 are incremented in the new version. 1976 - Section 4. Since section 4.1 was removed, section 4.2 became the 1977 body text for section 4. 1979 - Section 4.2. Added "Floor Information" to Figure 2 as part of 1980 Common Conference Information, also added "Floor Control" to 1981 Conference Template (per text and Cullen's draft). 1983 - Section 4.5. Conference policies. Reworded to not introduce new 1984 terms, but use the general terms identified in the 1st paragraph. 1986 - Section 5.2. Removed "Instance" from "Active Conference Instance" 1987 in Figure 4. 1989 - Section 5.3. Added text clarifying that templates are retrieved 1990 from server (not central repository) (per DP3 conclusion). 1992 - Section 5.4. Added text that there is a single time and that the 1993 times are all relative the one time (per DP1 conclusion). 1995 - Section 5.4. Added text clarifying that changes to a series impact 1996 "all future occurrences (per DP1 discussion/conclusion). 1998 - Section 6.3 - Added subsections for discussion of CSCP and NETCONF 1999 as the CCP. 2001 - Section 6.4 - Floor Control. Removed Editor's notes 2 and 3. 2002 Condensed the text only slightly, but added explicit references to 2003 new identifier section. 2005 - Section 6.4.1 Moved to new Identifier section ( Section 6) 2007 - Section 7.1 - moved example to 7.2. Included a new (more 2008 appropriate example) in 7.1, although this may be too basic. 2010 - Section 7.3 - added some proposed text for Sidebars. 2012 15. Appendix A - Conference Object Identifier 2014 [Editors Note: This appendix will be incorporated in a separate 2015 specification in the next release of this document and will include 2016 all relevant detail.] 2018 The conference object URI can be viewed as a key to accessing a 2019 specific conference object. It is used by the Conference Control 2020 Protocol as described in Section 8.3 to access, manipulate and delete 2021 a conference object associated with a specific conference instance. 2022 A conference object identifier is provided to the Conference Control 2023 Client to enable such functions to be carried out. This can either 2024 be returned through the Conference Control Protocol while creating a 2025 conference object, be provided by the conference notification service 2026 or through out-of-band mechanisms (e.g. E-Mail). 2028 [Editors Note: Previous section to be expanded and more detail 2029 included. It also needs to link up with other drafts and explicitly 2030 reference.] 2032 A centralized conferencing system, as defined in the Conference 2033 Framework [ref] has potential to expose a range of interfaces and 2034 protocols. It is also possible that future centralized conferencing 2035 enhancements might place requirements to provide further additional 2036 protocols and interfaces. A conference object can consist and be 2037 associated with many identifiers that are in some way related to a 2038 conference object. Good examples include the Binary Floor Control 2039 Protocol (BFCP)[23] and call signaling protocols, such as SIP. Each 2040 use unique identifiers to represent a protocol instance associated 2041 with a conference object. 2043 A conferencing system may maintain a relationship between the 2044 conference object URIs and the identifiers associated with each of 2045 the complementary centralized conferencing protocols (e.g., call 2046 signaling protocols, BFCP, etc.). To facilitate the maintenance of 2047 these relationships, the conference object URI acts as a top level 2048 identifier within the conferencing system for the purpose of 2049 identifying the interfaces for these other protocols. This implicit 2050 binding provides a structured mapping of the various protocols with 2051 the associated conference object identifier. Figure 13 illustrates 2052 the relationship between the identifiers used for the protocols 2053 within this framework and the general conference object identifier. 2055 +--------------+ 2056 | Conference | 2057 | Object | 2058 | Identifier | 2059 +------+-------+ 2060 | 2061 | 2062 | 2063 +-----------------+---------------+ 2064 | | 2065 +-------+---------+ +-------+-------+ 2066 |CSP Conference ID| | BFCP 'confid' | 2067 +-----------------+ +---------------+ 2069 Figure 13: Conference Object Mapping. 2071 In Figure 13, the conference object identifier acts as the top level 2072 key in the identification process. The call signaling protocols have 2073 an associated conference ID representation in the form of URIs. The 2074 binary floor control protocol, as defined in [23], defines the 2075 'conf-id' identifier which represents a conference instance within 2076 floor control. When created within the conferencing system, the 2077 'conf-id' has a 1:1 mapping to the unique conference object 2078 Identifier. Operations associated with the Conference Control 2079 Protocols are directly associated with the conference object, thus 2080 the primary identifier associated with these protocols is the 2081 conference object identifier. The mappings between additional 2082 protocols/interface is not strictly 1:1 and does allow for multiple 2083 occurrences. For example, multiple call signaling protocols will 2084 each have a representation that is implicitly linked to the top level 2085 conference object identifier, for example, H323 and SIP URIs that 2086 represent a conference instance. It should be noted that a 2087 conferencing system is free to structure such relationships as 2088 required and this information is just included as a guideline that 2089 can be used. 2091 The following example illustrates the representation and 2092 relationships that might occur in a typical conference instance. The 2093 table in Figure 14 lists a typical conference instance and related 2094 properties. 2096 +----------------------+------------------------+----------------------+ 2097 | Conf Obj URI | CSP URI | BFCP Conf-ID | 2098 +----------------------+------------------------+----------------------+ 2099 | xcon:Ji092i | sip:Ji092i@example.com | Ji092i | 2100 | | tel:+44(0)2920930033 | | 2101 | | h323:Ji092i@example.com| | 2102 +----------------------+------------------------+----------------------+ 2104 Figure 14: Conference Table Representation 2106 The information from Figure 14 can then be applied to the 2107 representation introduced in Figure 13. This results in Figure 15. 2109 +--------------+ 2110 | Conference | 2111 | Object | 2112 | Identifier | 2113 +--------------+ 2114 | xcon:Ji092i | 2115 +------+-------+ 2116 | 2117 | 2118 | 2119 +-----------------+---------------+ 2120 | | 2121 +-----------+-----------+ +-------+-------+ 2122 | CSP Conference IDs | | BFCP 'confid' | 2123 +-----------------------+ +---------------+ 2124 |h323:Ji092i@example.com| | Ji092i | 2125 |tel:+44(0)2920930033 | +-------+-------+ 2126 |sip:Ji092i@example.com | | 2127 +-----------------------+ +-------|-------+ 2128 | BFCP 'floorid | 2129 +---------------+ 2130 | UEK78d | 2131 | 09cnJk | 2132 +---------------+ 2134 Figure 15: Conference Tree Representation 2136 Further elements can be added to the tree representation in Figure 15 2137 to enable a complete representation of a conference instance within a 2138 conferencing system. 2140 This style of association can be applied to any supplementary 2141 protocols or conferencing mechanisms that are applied to the 2142 centralized conferencing model defined in this document as long as a 2143 unique reference per conference instance is available that can be 2144 mapped to a conference object. 2146 15.1. Conference Object URI Definition 2148 [Editors Note: When the appendix split from the Framework document, 2149 full URI definition will be included. 2151 16. Appendix B - Conference User Identifier 2153 [Editors Note: This appendix will be incorporated in a separate 2154 specification in the next release of this document and will include 2155 all relevant detail.] 2157 Each user within a conferencing system is allocated a unique 2158 conference user identifier. The user identifier is used in 2159 association with the conference object identifier defined in 2160 Section 15, and by the conference control protocol to uniquely 2161 identify a user within the scope of conferencing system. The 2162 conference control protocol uses the user identifier to uniquely 2163 determine who is issuing commands. Appropriate policies can then be 2164 applied to the requested command. 2166 As with the conference object identifier, a number of supplementary 2167 user identifiers defined in other protocols are used within a 2168 conference instance. Such user identifiers can be associated with 2169 this conference user identifier and enable the conferencing system to 2170 correlate and map these multiple authenticated user identities to the 2171 single user identifier. 2173 Figure 16 illustrates an example using the conference user identifier 2174 in association with the user identity defined for BFCP and SIP Digest 2175 user identity as defined in RFC3261[4], which would be used when SIP 2176 is the call signaling protocol. It should be noted that a 2177 conferencing system is free to structure such relationships as 2178 required and this information is just included as a guideline that 2179 can be used. 2181 +---------------+ 2182 | Conference | 2183 | User | 2184 | Identifier | 2185 +-------+-------+ 2186 | 2187 | 2188 | 2189 +---------------+---------------+ 2190 | | 2191 +-------+-------+ +-------+-------+ 2192 | BFCP | | SIP Digest | 2193 | 'UserID' | | Username | 2194 +---------------+ +-------+-------+ 2196 Figure 16: Conference User Identifier 2198 Within a conferencing system, a user is identified by a single 2199 conference user identifier. Any additional conferencing mechanisms 2200 that contain a protocol specific user ID can be associated with the 2201 conference user identifier, as illustrated in Figure 16. This 2202 mechanism allows conferencing systems to manage and relate system 2203 wide user identities in relation to specific conference objects and 2204 helps in the enforcement of system wide policies. 2206 The following example illustrates the representation and 2207 relationships that might occur in a typical conference instance. The 2208 table in Figure 17 lists a typical representation of user identifier 2209 hierarchy and associations. 2211 +----------------+----------------+---------------+----------------+ 2212 | Conf User ID | BFCP User ID | SIP User ID | H323 User ID | 2213 +----------------+----------------+---------------+----------------+ 2214 | John | HK37ihdaj | 123674 | 928373 | 2215 +----------------+----------------+---------------+----------------+ 2217 Figure 17: User Identitier Representation 2219 The information from Figure 17 can then be applied to the 2220 representation introduced in Figure 16. This results in Figure 18. 2222 +--------------+ 2223 | Conference | 2224 | User | 2225 | Identifier | 2226 +--------------+ 2227 | John | 2228 +------+-------+ 2229 | 2230 | 2231 | 2232 +---------------------+---------------------+ 2233 | | | 2234 +-------+--------+ +-------+-------+ +--------+-------+ 2235 | BFCP User ID | | SIP User ID | | H323 User ID | 2236 +----------------+ +---------------+ +----------------+ 2237 | HK37ihdaj | | 123674 | | 928373 | 2238 +----------------+ +-------+-------+ +----------------+ 2240 Figure 18: User ID Tree Representation 2242 Further elements can be added to the tree representation in Figure 15 2243 to enable a complete representation of a conference instance within a 2244 conferencing system. 2246 16.1. Conference User Definition 2248 [Editors Note: When the appendix is split from the Framework 2249 document, full definition will be included. 2251 17. References 2253 17.1. Normative References 2255 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2256 Levels", BCP 14, RFC 2119, March 1997. 2258 17.2. Informative References 2260 [2] Handley, M. and V. Jacobson, "SDP: Session Description 2261 Protocol", RFC 2327, April 1998. 2263 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2264 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2265 August 1998. 2267 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2268 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2269 Session Initiation Protocol", RFC 3261, June 2002. 2271 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2272 Session Description Protocol (SDP)", RFC 3264, June 2002. 2274 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2275 Notification", RFC 3265, June 2002. 2277 [7] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2278 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2279 RFC 3550, July 2003. 2281 [8] Dawson, F. and Stenerson, D., "Internet Calendaring and 2282 Scheduling Core Object Specification (iCalendar)", RFC 2445, 2283 November 1998. 2285 [9] Rosenberg, J., "A Framework for Conferencing with the Session 2286 Initiation Protocol", 2287 draft-ietf-sipping-conferencing-framework-05 (work in 2288 progress), May 2005. 2290 [10] Levin, O. and R. Even, "High Level Requirements for Tightly 2291 Coupled SIP Conferencing", 2292 draft-ietf-sipping-conferencing-requirements-01 (work in 2293 progress), October 2004. 2295 [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 2296 Package for Conference State", 2297 draft-ietf-sipping-conference-package-12 (work in progress), 2298 July 2005. 2300 [12] Schulzrinne, H., "Requirements for Floor Control Protocol", 2301 draft-ietf-xcon-floor-control-req-03 (work in progress), 2302 October 2005. 2304 [13] Koskelainen, P. and H. Khartabil, "Requirements for Conference 2305 Policy Control Protocol", draft-ietf-xcon-cpcp-reqs-04 (work in 2306 progress), August 2004. 2308 [14] Even, R. and N. Ismail, "Conferencing Scenarios", 2309 draft-ietf-xcon-conference-scenarios-05 (work in progress), 2310 September 2005. 2312 [15] Levin, O., "Session Initiation Protocol Call Control - 2313 Conferencing for User Agents", 2314 draft-ietf-sipping-cc-conferencing-07 (work in progress), 2315 June 2005. 2317 [16] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 2318 draft-ietf-xcon-bfcp-06 (work in progress), December 2005. 2320 [17] Schulzrinne, H., "COMP: Conference Object Manipulation 2321 Protocol", draft-schulzrinne-xcon-comp-00 (work in progress), 2322 January 2006. 2324 [18] Boulton, C. and M. Barnes, "Centralized Conferencing 2325 Manipulation Protocol", draft-barnes-xcon-ccmp-00 (work in 2326 progress), January 2006. 2328 [19] Levin, O., "Centralized Conference Control Protocol", 2329 draft-levin-xcon-cccp-04 (work in progress), January 2006. 2331 [20] Jennings, C. and B. Rosen, "Media Conference Server Control for 2332 XCON", draft-jennings-xcon-media-control-03 (work in progress), 2333 July 2005. 2335 [21] Rosen, B., "SIP Conferencing: Sub-conferences and Sidebars", 2336 draft-rosen-xcon-conf-sidebars-01 (work in progress), 2337 July 2004. 2339 [22] Levin, O. and G. Camarillo, "The SDP (Session Description 2340 Protocol) Label Attribute", 2341 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 2342 January 2005. 2344 [23] Camarillo, G., "Session Description Protocol (SDP) Format for 2345 Binary Floor Control Protocol (BFCP) Streams", 2346 draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), 2347 October 2004. 2349 [24] Campbell, B., "The Message Session Relay Protocol", 2350 draft-ietf-simple-message-sessions-14 (work in progress), 2351 February 2006. 2353 [25] Jennings, C., "Conference State Change Protocol (CSCP)", 2354 draft-jennings-xcon-cscp-02 (work in progress), December 2005. 2356 [26] Enns, R., "NETCONF Configuration Protocol", 2357 draft-ietf-netconf-prot-11 (work in progress), February 2006. 2359 Authors' Addresses 2361 Mary Barnes 2362 Nortel 2363 2201 Lakeside Blvd 2364 Richardson, TX 2366 Email: mary.barnes@nortel.com 2368 Chris Boulton 2369 Ubiquity Software Corporation 2370 Building 3 2371 Wern Fawr Lane 2372 St Mellons 2373 Cardiff, South Wales CF3 5EA 2375 Email: cboulton@ubiquitysoftware.com 2377 Orit Levin 2378 Microsoft Corporation 2379 One Microsoft Way 2380 Redmond, WA 98052 2382 Email: oritl@microsoft.com 2384 Intellectual Property Statement 2386 The IETF takes no position regarding the validity or scope of any 2387 Intellectual Property Rights or other rights that might be claimed to 2388 pertain to the implementation or use of the technology described in 2389 this document or the extent to which any license under such rights 2390 might or might not be available; nor does it represent that it has 2391 made any independent effort to identify any such rights. Information 2392 on the procedures with respect to rights in RFC documents can be 2393 found in BCP 78 and BCP 79. 2395 Copies of IPR disclosures made to the IETF Secretariat and any 2396 assurances of licenses to be made available, or the result of an 2397 attempt made to obtain a general license or permission for the use of 2398 such proprietary rights by implementers or users of this 2399 specification can be obtained from the IETF on-line IPR repository at 2400 http://www.ietf.org/ipr. 2402 The IETF invites any interested party to bring to its attention any 2403 copyrights, patents or patent applications, or other proprietary 2404 rights that may cover technology that may be required to implement 2405 this standard. Please address the information to the IETF at 2406 ietf-ipr@ietf.org. 2408 Disclaimer of Validity 2410 This document and the information contained herein are provided on an 2411 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2412 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2413 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2414 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2415 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2416 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2418 Copyright Statement 2420 Copyright (C) The Internet Society (2006). This document is subject 2421 to the rights, licenses and restrictions contained in BCP 78, and 2422 except as set forth therein, the authors retain all their rights. 2424 Acknowledgment 2426 Funding for the RFC Editor function is currently provided by the 2427 Internet Society.