idnits 2.17.1 draft-ietf-xcon-common-data-model-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2010) is 5091 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 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (Obsoleted by RFC 8856) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON O. Novo 3 Internet-Draft G. Camarillo 4 Intended status: Standards Track Ericsson 5 Expires: November 20, 2010 D. Morgan 6 Fidelity Investments 7 J. Urpalainen 8 Nokia 9 May 19, 2010 11 Conference Information Data Model for Centralized Conferencing (XCON) 12 draft-ietf-xcon-common-data-model-19.txt 14 Abstract 16 This document defines an Extensible Markup Language (XML)-based 17 conference information data model for centralized conferencing 18 (XCON). A conference information data model is designed to convey 19 information about the conference and about participation in the 20 conference. The conference information data model defined in this 21 document constitutes an extension of the data format specified in the 22 Session Initiation Protocol (SIP) Event Package for Conference State. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 20, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 7 75 3.3. The Conference Object Identifier . . . . . . . . . . . . . 8 76 3.3.1. Conference Object URI Definition . . . . . . . . . . . 10 77 3.3.2. Normalization and Conference Object URI Comparison . . 10 78 3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 10 79 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 11 80 4.1. . . . . . . . . . . . . . . . . . . . . 15 81 4.2. . . . . . . . . . . . . . . . . . 15 82 4.2.1. . . . . . . . . . . . . . . . . . . . . . . 15 83 4.2.2. . . . . . . . . . . . . . . . . . . . . 15 84 4.2.3. . . . . . . . . . . . . . . . . . . . . . . 16 85 4.2.4. . . . . . . . . . . . . . . . . . . . . . 16 86 4.2.5. . . . . . . . . . . . . . . . . . . . . . . 16 87 4.2.6. . . . . . . . . . . . . . . . . . . . 16 88 4.2.7. . . . . . . . . . . . . . . . . . . . 16 89 4.2.8. . . . . . . . . . . . . . . . . . . . 16 90 4.2.9. . . . . . . . . . . . . . . . . . . 16 91 4.2.10. . . . . . . . . . . . . . . . . . . . . . 18 92 4.2.11. . . . . . . . . . . . . . . . . . . . . 18 93 4.2.12. . . . . . . . . . . . . . . . . . 18 94 4.2.13. . . . . . . . . . . . . . . . . . . 18 95 4.3. . . . . . . . . . . . . . . . . . . . . . . . 21 96 4.4. . . . . . . . . . . . . . . . . . . . . 21 97 4.4.1. . . . . . . . . 21 98 4.4.2. . . . . . . . . . . . . . . . . . . . . . 21 99 4.4.3. . . . . . . . . . . . . . . . . . . . . . . . 21 100 4.4.4. . . . . . . . . . . . . . . . . . . . . . . . 21 101 4.5. . . . . . . . . . . . . . . . . . . . 21 102 4.5.1. . . . . . . . . . . . . . . . . . . . 22 103 4.5.2. . . . . . . . . . . . . . . . . . 22 104 4.5.3. . . . . . . . . . . . . . . . 22 105 4.5.4. . . . . . . . . . . . . . . 23 106 4.6. . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 4.6.1. . . . . . . . . . . . . . . . . . . . 24 108 4.6.2. . . . . . . . . . . . . . . . 24 109 4.6.3. . . . . . . . . . . . . . . . . . 25 110 4.6.4. . . . . . . . . . . . . . . . . . . 26 111 4.6.5. and Its Sub-elements . . . . . . . . . . 26 112 4.6.5.1. . . . . . . . . . . . . . . . . . . 27 113 4.6.5.2. . . . . . . . . . . . . . . . . 27 114 4.6.5.3. . . . . . . . . . . . . . . . 27 115 4.6.5.4. . . . . . . . . . . . . . . . . . . . . . 28 116 4.6.5.5. . . . . . . . . . . . . . . . . . . . 28 117 4.6.5.6. . . . . . . . . . . . . . . . . . 28 118 4.6.5.7. . . . . . . . . . 28 119 4.6.5.8. . . . . . . . . . 28 120 4.6.5.9. . . . . . . . . . 29 121 4.6.5.10. . . . . . . . . . . . . . . . . . . . . 29 122 4.7. . . . . . . . . . . . . . . . . . . . . 30 123 4.8. . . . . . . . . . . . . . . . . . . . . 30 124 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30 125 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 41 126 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 41 127 8. Security Considerations . . . . . . . . . . . . . . . . . . . 51 128 8.1. Authentication, Access Control, and Integrity . . . . . . 51 129 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 52 130 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 131 9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 52 132 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 52 133 9.3. Conference Object Identifier Registration . . . . . . . . 53 134 9.4. Conference User Identifier Registration . . . . . . . . . 54 135 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 136 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 137 11.1. Normative References . . . . . . . . . . . . . . . . . . . 55 138 11.2. Informative References . . . . . . . . . . . . . . . . . . 55 139 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56 140 Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 84 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 143 1. Introduction 145 There is a core data set of conference information that is utilized 146 in any conference, independent of the specific conference media. 147 This core data set called the 'conference information data model' is 148 defined in this document using an Extensible Markup Language (XML)- 149 based. The conference information data model defined in this 150 document is logically represented by the conference object. 152 Conference objects are a fundamental concept in Centralized 153 Conferencing, as described in the Centralized Conferencing Framework 154 [RFC5239]. A conference object contains data that represents a 155 conference during each of its various stages (e.g., created/creation, 156 reserved/reservation, active/activation, completed/completion). A 157 conference object can be manipulated using a conference control 158 protocol at a conference server. The conference object represents a 159 particular instantiation of a conference information data model. 160 Consequently, conference objects follow the XML format defined in 161 this document. 163 A conference object contains the core information of a conference 164 (i.e., capabilities, membership, call control signaling, media, etc.) 165 and specifies by whom, and in which way that information can be 166 manipulated. 168 Figure 1 shows the logical functional elements of a conference server 169 as defined by the Centralized Conferencing Framework [RFC5239]. They 170 are a Conference Control Server, a Floor Control Server, a number of 171 Foci, and a Notification Service. A conference control protocol 172 provides the interface between a conference control client and the 173 conference control server. A floor control protocol (e.g., BFCP 174 [RFC4582]) provides the interface between a floor control client and 175 the floor control server. A call signaling protocol (e.g., SIP, 176 H.323, Q.931, ISUP, etc.) provides the interface between a call 177 signaling client and a Focus. A notification protocol (e.g., SIP- 178 based event notifications [RFC3265]) provides the interface between 179 the conferencing client and the Notification Service. Within a 180 conference, the conference control server, floor control server, and 181 focus can modify the information in the conference object. 183 ............................................................... 184 . Conferencing Server . 185 . +---------------------------------------------------+ . 186 . | C o n f e r e n c e o b j e c t | . 187 . +-+--------------------------------------------------+| . 188 . | C o n f e r e n c e o b j e c t || . 189 . +-+---------------------------------------------------+|| . 190 . | C o n f e r e n c e o b j e c t ||| . 191 . | +--------------------------------------------------+||| . 192 . | | Conference Information Data Model |||| . 193 . | | +----------------------------------------------+ |||| . 194 . | | | Conference description (times, duration) | |||| . 195 . | | +----------------------------------------------+ |||| . 196 . | | +----------------------------------------------+ |||| . 197 . | | | Host information | |||| . 198 . | | +----------------------------------------------+ |||| . 199 . | | +----------------------------------------------+ |||| . 200 . | | | Conference state | |||| . 201 . | | +----------------------------------------------+ |||| . 202 . | | +----------------------------------------------+ |||| . 203 . | | | Floor information | |||| . 204 . | | +----------------------------------------------+ |||| . 205 . | | +----------------------------------------------+ |||| . 206 . | | | Membership (users, capacity) | |||| . 207 . | | +----------------------------------------------+ |||| . 208 . | | +----------------------------------------------+ |||| . 209 . | | | Sidebars, Etc. | |||| . 210 . | | +----------------------------------------------+ |||| . 211 . | | +----------------------------------------------+ |||| . 212 . | | | Etc. | |||| . 213 . | | +----------------------------------------------+ |||+ . 214 . | +--------------------------------------------------+|+ . 215 . +----^------------------^-------------^--------|------+ . 216 . | | | | . 217 . +------v-------+ +--------v-----+ +-----v-+ +----v-------+ . 218 . | Conference | | Floor | | | | | . 219 . | Control | | Control | |Foci | |Notification| . 220 . | Server | | Server | | | |Service | . 221 . +-----^--------+ +---^----------+ +-^-----+ +------------+ . 222 ........|..............|..............|..........|............. 223 |Conference |Floor |Call |Notification 224 |Control |Control |Signaling |Protocol 225 |Protocol |Protocol |Protocol | 226 ........v..............v..............v..........v............. 227 . C o n f e r e n c i n g C l i e n t . 228 ............................................................... 230 Figure 1: Conference Server Architecture 232 The Session Initiation Protocol (SIP) Event Package for Conference 233 State, specified in [RFC4575], already defines a data format for 234 conferences. However, that model is SIP specific and lacks elements 235 related to some of the functionality defined by the Centralized 236 Conferencing Framework [RFC5239] (e.g., floor control). The data 237 model defined in this document constitutes a superset of the data 238 format defined in [RFC4575]. The result is a data format that 239 supports more call signaling protocols besides SIP and that covers 240 all the functionality defined in the Centralized Conferencing 241 Framework [RFC5239]. 243 2. Terminology 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in RFC 2119 [RFC2119]. 249 This document uses the terminology defined in the Centralized 250 Conferencing Framework [RFC5239], the SIPPING conferencing framework 251 [RFC4353] and the BFCP (Binary Floor Control Protocol) specification 252 [RFC4582]. Readers of this document should be familiar with the 253 terminology used in those documents. 255 3. Overview 257 The data model specified in this document is the result of extending 258 the data format defined in [RFC4575] with new elements. Examples of 259 such extensions include scheduling elements, media control elements, 260 floor control elements, non-SIP URIs, and addition of localization 261 extensions to text elements. This data model can be used by 262 conference servers providing different types of basic conferences. 263 It is expected that this data model can be further extended with new 264 elements in the future in order to implement additional advanced 265 features. 267 3.1. Data Model Format 269 A conference object document is an XML [W3C.REC-xml-20001006] 270 document that MUST be well formed and SHOULD be valid. Conference 271 object documents MUST be based on XML 1.0 and SHOULD be encoded using 272 UTF-8. 274 3.2. Data Model Namespace 276 This specification defines a new namespace specification for 277 identifying the elements defined in the data model. This namespace 278 is as follows: 280 urn:ietf:params:xml:ns:xcon-conference-info 282 3.3. The Conference Object Identifier 284 The conference object identifier (XCON-URI) can be viewed as a key to 285 accessing a specific conference object. It can be used, for 286 instance, by the conference control protocol to access, manipulate 287 and delete a conference object. A conference object identifier is 288 provided to the conferencing client by the conference notification 289 service or through out-of-band mechanisms (e.g. E-Mail). 291 A conferencing system may maintain a relationship between the 292 conference object identifiers and the identifiers associated with 293 each of the complementary centralized conferencing protocols (e.g., 294 call signaling protocols, BFCP, etc.). To facilitate the maintenance 295 of these relationships, the conference object identifier acts as a 296 top level identifier within the conferencing system for the purpose 297 of identifying the interfaces for these other protocols. This 298 implicit binding provides a structured mapping of the various 299 protocols with the associated conference object Identifier. Figure 2 300 illustrates the relationship between the identifiers used for the 301 protocols and the general conference object identifier (XCON-URI). 303 +--------------------------+ 304 | Conference | 305 | Object | 306 | Identifier | 307 +--------------------------+ 308 | xcon:Ji092i@example.com | 309 +------+-------------------+ 310 | 311 | 312 | 313 +-----------------+---------------+ 314 | | 315 +-----------+-----------+ +----------+---------+ 316 | CSP Conference IDs | |BFCP 'Conference ID'| 317 +-----------------------+ +--------------------+ 318 | h323:i092@example.com | | i092 | 319 | tel:+44(0)2920930033 | +----------+---------+ 320 | sip:i092@example.com | | 321 +-----------------------+ +-------+--------+ 322 | BFCP 'Floor ID'| 323 +----------------+ 324 | 543 | 325 | 236 | 326 +----------------+ 328 Figure 2: Conference Object Mapping 330 In Figure 2, the conference object identifier acts as the top level 331 key in the identification process. The call signaling protocols have 332 an associated conference user identifier, often represented in the 333 form of URIs. The binary floor control protocol, as defined in 334 [RFC4582], defines the 'conference ID' identifier which represents a 335 conference instance within floor control. When created within the 336 conferencing system, the 'conference ID' has a 1:1 mapping to the 337 unique conference object Identifier(XCON-URI). Operations associated 338 with the conference control protocols are directly associated with 339 the conference object, thus the primary identifier associated with 340 these protocols is the conference object identifier(XCON-URI). The 341 mappings between additional protocols/interface is not strictly 1:1 342 and does allow for multiple occurrences. For example, multiple call 343 signaling protocols will each have a representation that is 344 implicitly linked to the top level conference object identifier e.g. 345 H323 and SIP URIs that represent a conference instance. It should be 346 noted that a conferencing system is free to structure such 347 relationships as required and this information is just included as a 348 guideline that can be used. 350 Further elements can be added to the tree representation in Figure 2 351 to enable a complete representation of a conference instance within a 352 conferencing system. 354 3.3.1. Conference Object URI Definition 356 XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] 358 conf-object-id = 1*( unreserved / "+" / "=" / "/" ) 360 host, port, and unreserved are defined in RFC3986[RFC3986] 362 3.3.2. Normalization and Conference Object URI Comparison 364 In order to facilitate the comparison of the XCON-URI identifiers, 365 all the components of the identifiers SHOULD be converted to 366 lowercase. After normalizing the URI strings, the URIs comparison 367 SHOULD applied a character-by-character basis as prescribed by 368 RFC3986, Section 6.2.1. 370 3.4. Data Model Structure 372 The information in this data model is structured in the following 373 manner. All the information related to a conference is contained in 374 a element. The element contains 375 the following child elements: 377 o The element describes the conference as a 378 whole. It has, for instance, information about the URI of the 379 conference, maximum users allowed in the conference, media 380 available in the conference, or the time the conference will 381 start. 382 o The element contains information about the entity 383 hosting the conference (e.g., its URI). 384 o The element informs the subscribers about the 385 changes in the overall conference information. 386 o The element contains information about the 387 status of the different floors in the conference. 388 o The element describes the membership information as a 389 whole. The element contains a set of child 390 elements, each describing a single participant in the conference. 391 o If a participant in the main conference joins a sidebar, a new 392 element is created in the conference referenced from the 393 element or under one of the 394 elements. 396 Note that some of the elements described above such , , , or are not defined in the data model but are defined in the data 399 format of [RFC4575]. We describe them here because they are part of 400 the basic structure of the data model. 402 4. Data Model Definition 404 The following non-normative diagram shows the structure of conference 405 object documents. The operator "!" preceding an element indicates 406 that the element is mandatory in the data model. The operator "*" 407 following an element indicates that the element is introduced and 408 defined in this document. That is, elements without a "*" have 409 already been defined in [RFC4575]. 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 | |--* 510 | |--* 511 | |--* 512 | | |--* 513 | | | 514 | | |--* 515 | | | |--* 516 | | | | |-- * 517 | | 518 | |--* 519 | | 520 | |-- 521 | | |-- 522 | | |-- 523 | | |--* 524 | | |-- 525 | | | | 526 | | | ... 527 | | |-- 528 | | |-- 529 | | |--* 530 | | |--* 531 | | |--* 532 | | |--! 533 | | | |-- 534 | | | |-- 535 | | | |-- 536 | | | |-- 537 | | | |-- 538 | | | |-- 539 | | | |-- 540 | | | |-- 541 | | | | |-- 542 | | | | |-- 543 | | | | |--