idnits 2.17.1 draft-ietf-xcon-common-data-model-05.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, updated by RFC 4748 on line 3109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3120. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3133. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 17, 2007) is 6218 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2445 (ref. '3') (Obsoleted by RFC 5545) == Outdated reference: A later version (-11) exists of draft-ietf-xcon-framework-07 -- Obsolete informational reference (is this intentional?): RFC 4582 (ref. '5') (Obsoleted by RFC 8855) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '6') (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON O. Novo 2 Internet-Draft G. Camarillo 3 Intended status: Standards Track Ericsson 4 Expires: October 19, 2007 D. Morgan 5 Fidelity Investments 6 R. Even 7 Polycom 8 April 17, 2007 10 Conference Information Data Model for Centralized Conferencing (XCON) 11 draft-ietf-xcon-common-data-model-05.txt 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 October 19, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document defines an Extensible Markup Language (XML)-based 45 conference information data model for centralized conferencing 46 (XCON). A conference object, which can be manipulated using a 47 conference control protocol, at a conference server represents a 48 particular instantiation of this data model. The conference 49 information data model defined in this document is an extension of 50 (and thus, compatible with) the model specified in the Session 51 Initiation Protocol (SIP) Event Package for Conference State. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Data Model Structure . . . . . . . . . . . . . . . . . . . 6 59 3.2. Role Definitions . . . . . . . . . . . . . . . . . . . . . 7 60 3.2.1. Role in a Floor . . . . . . . . . . . . . . . . . . . 8 61 3.2.2. Changing Roles . . . . . . . . . . . . . . . . . . . . 8 62 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 8 63 4.1. . . . . . . . . . . . . . . . . . 13 64 4.1.1. . . . . . . . . . . . . . . . . . . 14 65 4.1.2. . . . . . . . . . . . . . . . . . . . . . 15 66 4.1.3. . . . . . . . . . . . . . . . . . . . . 16 67 4.1.4. . . . . . . . . . . . . . . . . . 16 68 4.1.5. . . . . . . . . . . . . . . . . . . 16 69 4.1.5.1. . . . . . . . . . . . . . . . . . . . . 17 70 4.1.5.1.1. mute . . . . . . . . . . . . . . . . . . . . . 17 71 4.1.5.1.2. pause-video . . . . . . . . . . . . . . . . . 17 72 4.1.5.1.3. gain . . . . . . . . . . . . . . . . . . . . . 18 73 4.1.5.1.4. video-layout . . . . . . . . . . . . . . . . . 18 74 4.2. . . . . . . . . . . . . . . . . . . . . . . . 19 75 4.3. . . . . . . . . . . . . . . . . . . . . 19 76 4.4. . . . . . . . . . . . . . . . . . . . 19 77 4.5. . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 4.5.1. . . . . . . . . . . . . . . . . . 22 79 4.5.2. . . . . . . . . . . . . . . . . . . . . . . . . 22 80 4.5.2.1. , . . . . . . . . . . . . . 24 81 4.5.2.1.1. . . . . . . . . . . . . . . . . . . . 24 82 4.5.3. . . . . . . . . . . . . . . . . . . 24 83 4.5.4. . . . . . . . . . . . . . . . . . . 24 84 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 25 85 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 32 86 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 89 9.1. Conference Relax NG Schema Registration . . . . . . . . . 41 90 9.2. Conference Namespace Registration . . . . . . . . . . . . 41 91 9.3. Conference Object Identifier Registration . . . . . . . . 41 92 9.4. Conference User Identifier Registration . . . . . . . . . 42 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 42 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 42 97 Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML 98 Syntax . . . . . . . . . . . . . . . . . . . . . . . 43 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 100 Intellectual Property and Copyright Statements . . . . . . . . . . 68 102 1. Introduction 104 Conference objects are a fundamental concept in Centralized 105 conferencing, as described in the XCON Conferencing Framework [4]. A 106 conference object contains data that represents a conference during 107 each of its various stages (e.g., reserved, started, running, ended, 108 etc.). Conference Objects are instantiations of the conference 109 information data model defined in this document. Consequently, 110 conference objects follow the XML format defined in this document. 112 A conference object contains the core information of a conference 113 (i.e., capabilities, membership, roles, call control signaling, 114 media, etc.) and specifies who, and in which way, can manipulate that 115 information. 117 Figure 1 shows logical functional elements of a conference server as 118 defined by the XCON Conferencing Framework [4]. They are a 119 Conference Control Server, a Floor Control Server, a number of Foci, 120 and a Notification Service. A conference control protocol provides 121 the interface between a conference and media control client, and the 122 conference control server. A floor control protocol (e.g., BFCP [5]) 123 provides the interface between a floor control client and the floor 124 control server. A call signaling protocol (e.g., SIP, H.323, PSTN, 125 etc.) provides the interface between a call signaling client and a 126 Focus. A notification protocol (e.g., SIP-based event notifications 127 [6]) provides the interface between the conferencing client and the 128 Notification Service. Within a conference, the conference control 129 server, floor control server, and focus can modify the information in 130 the conference object. 132 ............................................................... 133 . Conferencing Server . 134 . +---------------------------------------------------+ . 135 . | C o n f e r e n c e o b j e c t | . 136 . +-+--------------------------------------------------+| . 137 . | C o n f e r e n c e o b j e c t || . 138 . +-+---------------------------------------------------+|| . 139 . | C o n f e r e n c e o b j e c t ||| . 140 . | +--------------------------------------------------+||| . 141 . | | Conference Information Data Model |||| . 142 . | | +----------------------------------------------+ |||| . 143 . | | | Conference description (times, duration) | |||| . 144 . | | +----------------------------------------------+ |||| . 145 . | | +----------------------------------------------+ |||| . 146 . | | | Host information | |||| . 147 . | | +----------------------------------------------+ |||| . 148 . | | +----------------------------------------------+ |||| . 149 . | | | Conference state | |||| . 150 . | | +----------------------------------------------+ |||| . 151 . | | +----------------------------------------------+ |||| . 152 . | | | Floor information | |||| . 153 . | | +----------------------------------------------+ |||| . 154 . | | +----------------------------------------------+ |||| . 155 . | | | Membership (users, roles, capacity) | |||| . 156 . | | +----------------------------------------------+ |||| . 157 . | | +----------------------------------------------+ |||| . 158 . | | | Sidebars, Etc. | |||| . 159 . | | +----------------------------------------------+ |||| . 160 . | | +----------------------------------------------+ |||| . 161 . | | | Etc. | |||| . 162 . | | +----------------------------------------------+ |||+ . 163 . | +--------------------------------------------------+|+ . 164 . +----^------------------^-------------^--------|------+ . 165 . | | | | . 166 . +------v-------+ +--------v-----+ +-----v-+ +----v-------+ . 167 . | Conference | | Floor | | | | | . 168 . | Control | | Control | |Foci | |Notification| . 169 . | Server | | Server | | | |Service | . 170 . +-----^--------+ +---^----------+ +-^-----+ +------------+ . 171 ........|..............|..............|..........|............. 172 |Conference |Binary Floor |Call |Notification 173 |Control |Control |Signaling |Protocol 174 |Protocol |Protocol |Protocol | 175 ........v..............v..............v..........v............. 176 . C o n f e r e n c i n g C l i e n t . 177 ............................................................... 179 Figure 1: Conference Server Architecture 181 The Session Initiation Protocol (SIP) Event Package for Conference 182 State, specified in RFC 4575 [1], already defines a data model for 183 conferences. However, that model is SIP specific and lacks elements 184 related to some of the functionality defined by the XCON conferencing 185 framework [4] (e.g., floor control). The data model defined in this 186 document extends the one defined in RFC 4575 [1]. The result is a 187 data model that supports more call signaling protocols besides SIP 188 and that covers all the functionality defined in the XCON 189 conferencing framework [4]. 191 2. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [2]. 197 This document uses the terminology defined in the XCON Conferencing 198 Framework [4], the SIP conferencing framework [7] and the BFCP 199 (Binary Floor Control Protocol) specification [5]. Readers of this 200 document are supposed to be familiar with the terminology used in 201 those documents. 203 3. Overview 205 The data model defined in this document is the result of extending 206 the data model defined in RFC 4575 [1] with new elements, which carry 207 information such as non-SIP URIs or floor-control-related parameters. 208 This data model can be used by conference servers providing different 209 types of basic conferences. It is expected that this data model can 210 be further extended with new elements in the future in order to 211 implement advanced features. 213 3.1. Data Model Structure 215 The information in this data model is structured in the following 216 manner. All the information related to a conference is contained in 217 a element. The element contains 218 the following child elements: 219 o The element describes the conference as a 220 whole. It has, for instance, information about the URI of the 221 conference, maximum users allowed in the conference, media 222 available in the conference, or the time the conference will 223 start. 224 o The element contains information about the entity 225 hosting the conference (e.g., its URI). 227 o The element informs the subscribers about the 228 changes in the overall conference information. 229 o The element contains information about the 230 status of the different floors in the conference. 231 o The element describes the membership information as a 232 whole. The element contains a set of child 233 elements, each describing a single participant in the conference. 234 o If a participant in the main conference joins a sidebar, a new 235 element is created in the conference referenced from the 236 element or under one of the 237 elements. 239 3.2. Role Definitions 241 This section defines five logical roles for a Conference System to 242 represent participants within a Conference Object. In hierarchical 243 order they are: "administrator", "creator", "moderator", 244 "participant", and "observer". A set of semantics associated with 245 each role is out of the scope of this document. A Conference System 246 MAY choose not to support a particular role. As well, additional 247 roles may be defined in the future, as necessary, with their 248 corresponding schema extensions. 250 These five roles have an intrinsic hierarchical order within a 251 specific conference. By hierarchical order, it is implied that the 252 "administrator" by default SHOULD have higher privileges than a 253 "creator", which by default SHOULD have higher privileges than a 254 "moderator" and so on. For example, the "administrator" SHOULD have 255 the ability to make changes to all conference variables during 256 instantiation and full lifecycle of the Conference Object. The 257 "creator" is the 'owner' of the conference and has various privileges 258 which SHOULD allow them to modify the conference variables up to the 259 time the conference is instantiated. The "moderator" is a logical 260 entity that will manage the conference. The "participant" is a 261 logical entity with generic privileges that will be attending a 262 conference. The "observer" is a logical entity which can only 263 receive media streams from the conference. All Conference Systems 264 MUST have a role defined as "participant". 266 Each user participating in a conference instance is an entity that 267 can assume one or more roles. Any entity can be allocated to an 268 appropriate logical role. A role can also be assumed in conjunction 269 with the users identity within the Conference System as a result of 270 an identity assertion transaction on the Conference System. If no 271 roles are defined for an entity, they SHOULD by default be a 272 "participant" but local policy MAY define an alternative. 274 3.2.1. Role in a Floor 276 Floor control in centralized conferencing is described in the Binary 277 Floor Control Protocol (BFCP) [5]. Floors can be specified in the 278 Conference System or created dynamically. Users can be added or 279 deleted from a floor when the conference is active. 281 A floor chair is a logical entity that manages a floor (grants, 282 denies, or revokes a floor). The floor chair is usually in an 283 "administrator", "moderator", or "creator" role. A floor participant 284 is a logical entity that requests floors, and possibly information 285 about them from a floor control server. They are usually in a 286 "participant" or even a "moderator" role [5]. 288 Users in a conference MAY assume different roles in different floors. 289 They MAY also assume different roles in the same floor, as floor 290 transactions are processed. 292 3.2.2. Changing Roles 294 Users can change roles during a conference. This can be done in two 295 ways: First, the user can join a new floor in a different role. 296 Second, an "administrator" or "creator" can dynamically change that 297 user's role. This can be accomplished before the conference is 298 instantiated, or during the conference, using an appropriate 299 conference control protocol. A logical entity whose role has been 300 changed will typically have access to the media streams associated 301 with that role. 303 4. Data Model Definition 305 A conference object document is an XML [8] document that MUST be well 306 formed and SHOULD be valid. Conference object data model documents 307 MUST be based on XML 1.0 and SHOULD be encoded using UTF-8. 309 A conference object document begins with the root element tag 310 , which is defined in [1]. The 311 element has an 'entity' attribute that contains a conference object 312 identifier (XCON-URI) that identifies the conference being described 313 in the document. 315 A conferencing system may maintain a relationship between the 316 conference object identifiers and the identifiers associated with 317 each of the complimentary centralized conferencing protocols (e.g., 318 call signaling protocols, BFCP, etc.). 320 This implicit binding provides a structured mapping of the various 321 protocols with the associated conference object Identifier. Figure 2 322 illustrates the relationship between the identifiers used for the 323 protocols within the framework [4] and the general XCON-URI. 325 +--------------------------+ 326 | Conference | 327 | Object | 328 | Identifier | 329 +--------------------------+ 330 | xcon:Ji092i@example.com | 331 +------+-------------------+ 332 | 333 | 334 | 335 +-----------------+---------------+ 336 | | 337 +-----------+-----------+ +-------+-------+ 338 | CSP Conference IDs | | BFCP 'confid' | 339 +-----------------------+ +---------------+ 340 |h323:Ji092i@example.com| | Ji092i | 341 |tel:+44(0)2920930033 | +-------+-------+ 342 |sip:Ji092i@example.com | | 343 +-----------------------+ +-------|-------+ 344 | BFCP 'floorid | 345 +---------------+ 346 | UEK78d | 347 | 09cnJk | 348 +---------------+ 350 Figure 2: Conference Object Mapping 352 Further elements can be added to the tree representation in Figure 2 353 to enable a complete representation of a conference instance within a 354 conferencing system. 356 The element contains the , 357 , , , , 358 , child elements. All these 359 elements, except , are defined in [1]. A 360 conference document MUST at least include the , , , and child 362 elements. 364 The following non-normative diagram shows the structure of conference 365 object documents. The operator "!" preceding an element indicates 366 that the element is mandatory in the data model. The operator "*" 367 following an element indicates that the element is introduced and 368 defined in this document. That is, elements without a "*" have 369 already been defined in RFC 4575 [1]. 371 ! 372 | 373 |--! 374 | |-- 375 | |-- 376 | |--* 377 | |-- 378 | |--* 379 | |--* 380 | | |--* 381 | | | |--* 382 | | | |--* 383 | | | |--* 384 | | | |--* 385 | | | |--* 386 | | | |--* 387 | | | |--* 388 | | | |--* 389 | | ... 390 | |-- 391 | | |--* 392 | | | |-- 393 | | | |-- 394 | | | |-- 395 | | |--* 396 | | | |--* 397 | | | |--* 398 | | |--* 399 | | | |--* 400 | | ... 401 | |-- 402 | | |--* 403 | | | |-- 404 | | | |-- 405 | | | |-- 406 | | |--* 407 | | | |--* 408 | | | |--* 409 | | |--* 410 | | | |--* 411 | | ... 412 | |-- 413 | | ... 414 | |--! 415 | | |--! 416 | | | |-- 417 | | | |-- 418 | | | |-- 419 | | | |--* 420 | | | |--* 421 | | | |--* 422 | | | | |--* 423 | | | | |--* 424 | | | | ... 425 | | | |--* 426 | | | | |--* 427 | | | | |--* 428 | | | | ... 429 | | |-- 430 | | | |-- 431 | | | |-- 432 | | | |-- 433 | | | |--* 434 | | | |--* 435 | | | |--* 436 | | | | |--* 437 | | | | |--* 438 | | | | ... 439 | | | |--* 440 | | | | |--* 441 | | | | |--* 442 | | | | ... 443 | | ... 444 | 445 |-- 446 | |-- 447 | |-- 448 | |--! 449 | | |--! 450 | | | |--! 451 | | | |-- 452 | | |--* 453 | | | |--* 454 | | | |--* 455 | | |--* 456 | | | |--* 457 | ... 458 |-- 459 | |--* 460 | |-- 461 | |--! 462 | |-- 463 | 464 |--* 465 | |--* 466 | |--* 467 | |--* 468 | |--* 469 | | |--* 470 | | | |--* 471 | | | |--* 472 | | | |--* 473 | | | |--* 474 | | | |--* 475 | | | ... 476 | | ... 477 | 478 |--! 479 | |--* 480 | |--* 481 | |--* 482 | | |--* 483 | | |-- ... 484 | | 485 | | 486 | |--! 487 | | |-- 488 | | |-- 489 | | |--* 490 | | |-- 491 | | | | 492 | | | ... 493 | | |-- 494 | | |-- 495 | | |--* 496 | | |--* 497 | | |--* 498 | | |--! 499 | | | |-- 500 | | | |-- 501 | | | |-- 502 | | | |-- 503 | | | |-- 504 | | | |-- 505 | | | |-- 506 | | | |--! 507 | | | | |-- 508 | | | | |-- 509 | | | | |--