idnits 2.17.1 draft-ietf-xcon-common-data-model-04.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 3268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3292. 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 (March 3, 2007) is 6235 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-xcon-framework-07 ** Obsolete normative reference: RFC 2445 (ref. '6') (Obsoleted by RFC 5545) -- Obsolete informational reference (is this intentional?): RFC 4582 (ref. '7') (Obsoleted by RFC 8855) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '8') (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: Informational Ericsson 4 Expires: September 4, 2007 D. Morgan 5 Fidelity Investments 6 R. Even 7 Polycom 8 March 3, 2007 10 Conference Information Data Model for Centralized Conferencing (XCON) 11 draft-ietf-xcon-common-data-model-04.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 September 4, 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. Conference Policies . . . . . . . . . . . . . . . . . . . 7 60 3.2.1. Role Definitions . . . . . . . . . . . . . . . . . . . 8 61 3.2.1.1. Role in a Floor . . . . . . . . . . . . . . . . . 8 62 3.2.1.2. Changing Roles . . . . . . . . . . . . . . . . . . 9 63 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 9 64 4.1. . . . . . . . . . . . . . . . . . 13 65 4.1.1. . . . . . . . . . . . . . . . . . . 14 66 4.1.2. . . . . . . . . . . . . . . . . . . . . . 15 67 4.1.3. . . . . . . . . . . . . . . . . . . . . 16 68 4.1.4. . . . . . . . . . . . . . . . . . 16 69 4.1.5. . . . . . . . . . . . . . . . . . . 16 70 4.1.5.1. . . . . . . . . . . . . . . . . . . . . 17 71 4.1.5.1.1. mute . . . . . . . . . . . . . . . . . . . . . 17 72 4.1.5.1.2. pause-video . . . . . . . . . . . . . . . . . 17 73 4.1.5.1.3. gain . . . . . . . . . . . . . . . . . . . . . 18 74 4.1.5.1.4. video-layout . . . . . . . . . . . . . . . . . 18 75 4.2. . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.3. . . . . . . . . . . . . . . . . . . . . 19 77 4.4. . . . . . . . . . . . . . . . . . . . 19 78 4.5. . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 4.5.1. . . . . . . . . . . . . . . . . . 22 80 4.5.2. . . . . . . . . . . . . . . . . . . . . . . . . 22 81 4.5.2.1. , . . . . . . . . . . . . . 23 82 4.5.2.1.1. . . . . . . . . . . . . . . . . . . . 23 83 4.5.3. . . . . . . . . . . . . . . . . . . 24 84 4.5.4. . . . . . . . . . . . . . . . . . . 24 85 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 24 86 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 33 87 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 90 9.1. Conference Relax NG Schema Registration . . . . . . . . . 42 91 9.2. Conference Namespace Registration . . . . . . . . . . . . 43 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 43 96 Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML 97 Syntax . . . . . . . . . . . . . . . . . . . . . . . 44 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 99 Intellectual Property and Copyright Statements . . . . . . . . . . 71 101 1. Introduction 103 Conference objects are a fundamental concept in Centralized 104 conferencing, as described in the XCON Conferencing Framework [1]. A 105 conference object contains data that represents a conference during 106 each of its various stages (e.g., reserved, started, running, ended, 107 etc.). Conference Objects are instantiations of the conference 108 information data model defined in this document. Consequently, 109 conference objects follow the XML format defined in this document. 111 A conference object contains the core information of a conference 112 (i.e., capabilities, membership, roles, call control signaling, 113 media, etc.) and specifies who, and in which way, can manipulate that 114 information. 116 Figure 1 shows logical functional elements of a conference server as 117 defined by the XCON Conferencing Framework [1]. They are a 118 Conference Control Server, a Floor Control Server, a number of Foci, 119 and a Notification Service. A conference control protocol provides 120 the interface between a conference and media control client, and the 121 conference control server. A floor control protocol (e.g., BFCP [7]) 122 provides the interface between a floor control client and the floor 123 control server. A call signaling protocol (e.g., SIP, H.323, PSTN, 124 etc.) provides the interface between a call signaling client and a 125 Focus. A notification protocol (e.g., SIP-based event notifications 126 [8]) provides the interface between the conferencing client and the 127 Notification Service. Within a conference, the conference control 128 server, floor control server, and focus can modify the information in 129 the conference object. 131 ............................................................... 132 . Conferencing Server . 133 . +---------------------------------------------------+ . 134 . | C o n f e r e n c e o b j e c t | . 135 . +-+--------------------------------------------------+| . 136 . | C o n f e r e n c e o b j e c t || . 137 . +-+---------------------------------------------------+|| . 138 . | C o n f e r e n c e o b j e c t ||| . 139 . | +--------------------------------------------------+||| . 140 . | | Conference Information Data Model |||| . 141 . | | +----------------------------------------------+ |||| . 142 . | | | Conference description (times, duration) | |||| . 143 . | | +----------------------------------------------+ |||| . 144 . | | +----------------------------------------------+ |||| . 145 . | | | Host information | |||| . 146 . | | +----------------------------------------------+ |||| . 147 . | | +----------------------------------------------+ |||| . 148 . | | | Conference state | |||| . 149 . | | +----------------------------------------------+ |||| . 150 . | | +----------------------------------------------+ |||| . 151 . | | | Floor information | |||| . 152 . | | +----------------------------------------------+ |||| . 153 . | | +----------------------------------------------+ |||| . 154 . | | | Membership (users, roles, capacity) | |||| . 155 . | | +----------------------------------------------+ |||| . 156 . | | +----------------------------------------------+ |||| . 157 . | | | Sidebars, Etc. | |||| . 158 . | | +----------------------------------------------+ |||| . 159 . | | +----------------------------------------------+ |||| . 160 . | | | Etc. | |||| . 161 . | | +----------------------------------------------+ |||+ . 162 . | +--------------------------------------------------+|+ . 163 . +----^------------------^-------------^--------|------+ . 164 . | | | | . 165 . +------v-------+ +--------v-----+ +-----v-+ +----v-------+ . 166 . | Conference | | Floor | | | | | . 167 . | Control | | Control | |Foci | |Notification| . 168 . | Server | | Server | | | |Service | . 169 . +-----^--------+ +---^----------+ +-^-----+ +------------+ . 170 ........|..............|..............|..........|............. 171 |Conference |Binary Floor |Call |Notification 172 |Control |Control |Signaling |Protocol 173 |Protocol |Protocol |Protocol | 174 ........v..............v..............v..........v............. 175 . C o n f e r e n c i n g C l i e n t . 176 ............................................................... 178 Figure 1: Conference Server Architecture 180 The Session Initiation Protocol (SIP) Event Package for Conference 181 State, specified in RFC 4575 [2], already defines a data model for 182 conferences. However, that model is SIP specific and lacks elements 183 related to some of the functionality defined by the XCON conferencing 184 framework [1] (e.g., floor control). The data model defined in this 185 document extends the one defined in RFC 4575 [2]. The result is a 186 data model that supports more call signaling protocols besides SIP 187 and that covers all the functionality defined in the XCON 188 conferencing framework [1]. 190 2. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [3]. 196 This document uses the terminology defined in the XCON Conferencing 197 Framework [1], the SIP conferencing framework [4] and the BFCP 198 (Binary Floor Control Protocol) specification [7]. Readers of this 199 document are supposed to be familiar with the terminology used in 200 those documents. 202 3. Overview 204 The data model defined in this document is the result of extending 205 the data model defined in RFC 4575 [2] with new elements, which carry 206 information such as non-SIP URIs or floor-control-related parameters. 207 This data model can be used by conference servers providing different 208 types of basic conferences. It is expected that this data model can 209 be further extended with new elements in the future in order to 210 implement advanced features. 212 3.1. Data Model Structure 214 The information in this data model is structured in the following 215 manner. All the information related to a conference is contained in 216 a element. The element contains 217 the following child elements: 218 o The element describes the conference as a 219 whole. It has, for instance, information about the URI of the 220 conference, maximum users allowed in the conference, media 221 available in the conference, or the time the conference will 222 start. 223 o The element contains information about the entity 224 hosting the conference (e.g., its URI). 226 o The element informs the subscribers about the 227 changes in the overall conference information. 228 o The element contains information about the 229 status of the different floors in the conference. 230 o The element describes the membership information as a 231 whole. The element contains a set of child 232 elements, each describing a single participant in the conference. 233 o If a participant in the main conference joins a sidebar, a new 234 element is created in the conference referenced from the 235 element or under one of the 236 elements. 238 3.2. Conference Policies 240 Conference policies specify who, and in which way, information in a 241 conference object can be manipulate. This data model has no strict 242 separation between conference membership and media information, and 243 its related policies. Policy-related elements and attributes appear 244 with the element they apply to. 246 [Editor's Note: The Policies section is still under discussion. For 247 more details refer to the XCON mailing list. ] 249 The set of rights describes the read/write access privileges for the 250 conference object data model as a whole. Every element of the data 251 model SHOULD define two attributes: the attribute 'read-only', and 252 the attribute 'read-write'. These attributes describes the read/ 253 write access privileges for accessing the Conference Object as a 254 whole. This is partially described in [1]. When the conferencing 255 server receives a request to access privacy-sensitive data it needs 256 to match it against the 'read-only' and the 'read-write' attributes. 257 Each attribute of each individual element is evaluated and as a 258 result it is determined if the requestor can access that element. 259 The attributes specify the minimum requestor's role that can access 260 or modify the element of the conference. Requestors with a role with 261 lower privileges as defined in Section 3.2.1 cannot access or modify 262 the element. 264 If an attribute is not defined in some element, the 'read-only' 265 attribute MUST be interpreted as a "participant" role and the 'read- 266 write' attribute MUST be interpreted as an "administrator" role by 267 default. It is possible to defined only one of the attributes of the 268 element, the other attribute SHOULD be interpreted by default. The 269 next section defines conferencing roles that are used to represent 270 participants within a Conference Object. Additional roles may be 271 defined in the future, as necessary, with their corresponding schema 272 extensions, as appropriate. 274 However, it can also be the case that conflicts can occur given a 275 hierarchy of elements. In that case, the lower-level element 276 privileges predominate over the upper-level privileges element. 278 The policies and rights are an integral part of the data model, with 279 elements containing the allowed ranges for other elements (e.g., 280 maximum number of participants) and lists of end-points allowed to 281 perform certain operations on a conference object. 283 3.2.1. Role Definitions 285 This section defines five logical roles for a Conference System to 286 represent participants within a Conference Object. In hierarchical 287 order they are: "administrator", "creator", "moderator", 288 "participant", and "observer". A set of semantics associated with 289 each role is out of the scope of this document. A Conference System 290 MAY choose not to support a particular role. As well, additional 291 roles may be defined in the future, as necessary, with their 292 corresponding schema extensions. 294 These five roles have an intrinsic hierarchical order within a 295 specific conference. By hierarchical order, it is implied that the 296 "administrator" by default SHOULD have higher privileges than a 297 "creator", which by default SHOULD have higher privileges than a 298 "moderator" and so on. For example, the "administrator" SHOULD have 299 the ability to make changes to all conference variables during 300 instantiation and full lifecycle of the Conference Object. The 301 "creator" is the 'owner' of the conference and has various privileges 302 which SHOULD allow them to modify the conference variables up to the 303 time the conference is instantiated. The "moderator" is a logical 304 entity that will manage the conference. The "participant" is a 305 logical entity with generic privileges that will be attending a 306 conference. The "observer" is a logical entity which can only 307 receive media streams from the conference. All Conference Systems 308 MUST have a role defined as "participant". 310 Each user participating in a conference instance is an entity that 311 can assume one or more roles. Any entity can be allocated to an 312 appropriate logical role. A role can also be assumed in conjunction 313 with the users identity within the Conference System as a result of 314 an identity assertion transaction on the Conference System. If no 315 roles are defined for an entity, they SHOULD by default be a 316 "participant" but local policy MAY define an alternative. 318 3.2.1.1. Role in a Floor 320 Floor control in centralized conferencing is described in the Binary 321 Floor Control Protocol (BFCP) [7]. Floors can be specified in the 322 Conference System or created dynamically. Users can be added or 323 deleted from a floor when the conference is active. 325 A floor chair is a logical entity that manages a floor (grants, 326 denies, or revokes a floor). The floor chair is usually in an 327 "administrator", "moderator", or "creator" role. A floor participant 328 is a logical entity that requests floors, and possibly information 329 about them from a floor control server. They are usually in a 330 "participant" or even a "moderator" role [7]. 332 Users in a conference MAY assume different roles in different floors. 333 They MAY also assume different roles in the same floor, as floor 334 transactions are processed. 336 3.2.1.2. Changing Roles 338 Users can change roles during a conference. This can be done in two 339 ways: First, the user can join a new floor in a different role. 340 Second, an "administrator" or "creator" can dynamically change that 341 user's role. This can be accomplished before the conference is 342 instantiated, or during the conference, using an appropriate 343 conference control protocol. A logical entity whose role has been 344 changed will typically have access to the media streams associated 345 with that role. 347 4. Data Model Definition 349 A conference object document is an XML [5] document that MUST be well 350 formed and SHOULD be valid. Conference object data model documents 351 MUST be based on XML 1.0 and SHOULD be encoded using UTF-8. 353 A conference object document begins with the root element tag 354 , which is defined in [2]. The 355 element has an 'entity' attribute that contains a conference object 356 identifier (ID) that identifies the conference being described in the 357 document. 359 The element contains the , 360 , , , , 361 , child elements. All these 362 elements, except , are defined in [2]. A 363 conference document MUST at least include the , , , and child 365 elements. 367 The following non-normative diagram shows the structure of conference 368 object documents. The operator "!" preceding an element indicates 369 that the element is mandatory in the data model. The operator "*" 370 following an element indicates that the element is introduced and 371 defined in this document. That is, elements without a "*" have 372 already been defined in RFC 4575 [2]. 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 | | ... 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 | | | |--! 510 | | | | |-- 511 | | | | |-- 512 | | | | |--