idnits 2.17.1 draft-ietf-xcon-common-data-model-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (April 7, 2009) is 5498 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 (Obsoleted by RFC 5545) ** 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: 4 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: October 9, 2009 D. Morgan 6 Fidelity Investments 7 J. Urpalainen 8 Nokia 9 April 7, 2009 11 Conference Information Data Model for Centralized Conferencing (XCON) 12 draft-ietf-xcon-common-data-model-13.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on October 9, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document defines an Extensible Markup Language (XML)-based 60 conference information data model for centralized conferencing 61 (XCON). A conference information data model is designed to convey 62 information about the conference and about participation in the 63 conference. The conference information data model defined in this 64 document constitutes an extension of the data format specified in the 65 Session Initiation Protocol (SIP) Event Package for Conference State. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 7 73 3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 7 74 3.3. The Conference Object Identifier . . . . . . . . . . . . . 8 75 3.3.1. Conference Object URI Definition . . . . . . . . . . . 10 76 3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 10 77 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 11 78 4.1. . . . . . . . . . . . . . . . . . . . . 14 79 4.2. . . . . . . . . . . . . . . . . . 15 80 4.2.1. . . . . . . . . . . . . . . . . . . . . . . 15 81 4.2.2. . . . . . . . . . . . . . . . . . . . . 15 82 4.2.3. . . . . . . . . . . . . . . . . . . . . . . 15 83 4.2.4. . . . . . . . . . . . . . . . . . . . . . 15 84 4.2.5. . . . . . . . . . . . . . . . . . . . . . . 16 85 4.2.6. . . . . . . . . . . . . . . . . . . . 16 86 4.2.7. . . . . . . . . . . . . . . . . . . . 16 87 4.2.8. . . . . . . . . . . . . . . . . . . . 16 88 4.2.9. . . . . . . . . . . . . . . . . . . 16 89 4.2.10. . . . . . . . . . . . . . . . . . . . . . 17 90 4.2.11. . . . . . . . . . . . . . . . . . . . . 18 91 4.2.12. . . . . . . . . . . . . . . . . . 18 92 4.2.13. . . . . . . . . . . . . . . . . . . 18 93 4.3. . . . . . . . . . . . . . . . . . . . . . . . 20 94 4.4. . . . . . . . . . . . . . . . . . . . . 20 95 4.4.1. . . . . . . . . 20 96 4.4.2. . . . . . . . . . . . . . . . . . . . . . 21 97 4.4.3. . . . . . . . . . . . . . . . . . . . . . . . 21 98 4.4.4. . . . . . . . . . . . . . . . . . . . . . . . 21 99 4.5. . . . . . . . . . . . . . . . . . . . 21 100 4.5.1. . . . . . . . . . . . . . . . . . . . 21 101 4.5.2. . . . . . . . . . . . . . . . . . 21 102 4.5.3. . . . . . . . . . . . . . . . 22 103 4.5.4. . . . . . . . . . . . . . . 22 104 4.6. . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 4.6.1. . . . . . . . . . . . . . . . . . . . 23 106 4.6.2. . . . . . . . . . . . . . . . 24 107 4.6.3. . . . . . . . . . . . . . . . . . 24 108 4.6.4. . . . . . . . . . . . . . . . . . . 25 109 4.6.5. and Its Sub-elements . . . . . . . . . . 25 110 4.6.5.1. . . . . . . . . . . . . . . . . . . 26 111 4.6.5.2. . . . . . . . . . . . . . . . . 27 112 4.6.5.3. . . . . . . . . . . . . . . . 27 113 4.6.5.4. . . . . . . . . . . . . . . . . . . . . . 27 114 4.6.5.5. . . . . . . . . . . . . . . . . . . . 27 115 4.6.5.6. . . . . . . . . . . . . . . . . . 27 116 4.6.5.7. . . . . . . . . . 27 117 4.6.5.8. . . . . . . . . . 28 118 4.6.5.9. . . . . . . . . . 28 119 4.6.5.10. . . . . . . . . . . . . . . . . . . . . 28 120 4.7. . . . . . . . . . . . . . . . . . . . . 29 121 4.8. . . . . . . . . . . . . . . . . . . . . 29 122 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30 123 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 40 124 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 41 125 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 126 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 50 127 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 51 128 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 51 129 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 130 9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 51 131 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 52 132 9.3. Conference Object Identifier Registration . . . . . . . . 53 133 9.4. Conference User Identifier Registration . . . . . . . . . 54 134 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 135 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 136 11.1. Normative References . . . . . . . . . . . . . . . . . . . 55 137 11.2. Informative References . . . . . . . . . . . . . . . . . . 55 138 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56 139 Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 83 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 142 1. Introduction 144 There is a core data set of conference information that is utilized 145 in any conference, independent of the specific conference media. 146 This core data set called the 'conference information data model' is 147 defined in this document using an Extensible Markup Language (XML)- 148 based. The conference information data model defined in this 149 document is logically represented by the conference object. 151 Conference objects are a fundamental concept in Centralized 152 Conferencing, as described in the Centralized Conferencing Framework 153 [RFC5239]. A conference object contains data that represents a 154 conference during each of its various stages (e.g., created/creation, 155 reserved/reservation, active/activation, completed/completion). A 156 conference object can be manipulated using a conference control 157 protocol at a conference server. The conference object represents a 158 particular instantiation of a conference information data model. 159 Consequently, conference objects follow the XML format defined in 160 this document. 162 A conference object contains the core information of a conference 163 (i.e., capabilities, membership, call control signaling, media, etc.) 164 and specifies who, and in which way that information can be 165 manipulated. 167 Figure 1 shows the logical functional elements of a conference server 168 as defined by the Centralized Conferencing Framework [RFC5239]. They 169 are a Conference Control Server, a Floor Control Server, a number of 170 Foci, and a Notification Service. A conference control protocol 171 provides the interface between a conference control client and the 172 conference control server. A floor control protocol (e.g., BFCP 173 [RFC4582]) provides the interface between a floor control client and 174 the floor control server. A call signaling protocol (e.g., SIP, 175 H.323, Q.931, ISUP, etc.) provides the interface between a call 176 signaling client and a Focus. A notification protocol (e.g., SIP- 177 based event notifications [RFC3265]) provides the interface between 178 the conferencing client and the Notification Service. Within a 179 conference, the conference control server, floor control server, and 180 focus can modify the information in the conference object. 182 ............................................................... 183 . Conferencing Server . 184 . +---------------------------------------------------+ . 185 . | C o n f e r e n c e o b j e c t | . 186 . +-+--------------------------------------------------+| . 187 . | C o n f e r e n c e o b j e c t || . 188 . +-+---------------------------------------------------+|| . 189 . | C o n f e r e n c e o b j e c t ||| . 190 . | +--------------------------------------------------+||| . 191 . | | Conference Information Data Model |||| . 192 . | | +----------------------------------------------+ |||| . 193 . | | | Conference description (times, duration) | |||| . 194 . | | +----------------------------------------------+ |||| . 195 . | | +----------------------------------------------+ |||| . 196 . | | | Host information | |||| . 197 . | | +----------------------------------------------+ |||| . 198 . | | +----------------------------------------------+ |||| . 199 . | | | Conference state | |||| . 200 . | | +----------------------------------------------+ |||| . 201 . | | +----------------------------------------------+ |||| . 202 . | | | Floor information | |||| . 203 . | | +----------------------------------------------+ |||| . 204 . | | +----------------------------------------------+ |||| . 205 . | | | Membership (users, capacity) | |||| . 206 . | | +----------------------------------------------+ |||| . 207 . | | +----------------------------------------------+ |||| . 208 . | | | Sidebars, Etc. | |||| . 209 . | | +----------------------------------------------+ |||| . 210 . | | +----------------------------------------------+ |||| . 211 . | | | Etc. | |||| . 212 . | | +----------------------------------------------+ |||+ . 213 . | +--------------------------------------------------+|+ . 214 . +----^------------------^-------------^--------|------+ . 215 . | | | | . 216 . +------v-------+ +--------v-----+ +-----v-+ +----v-------+ . 217 . | Conference | | Floor | | | | | . 218 . | Control | | Control | |Foci | |Notification| . 219 . | Server | | Server | | | |Service | . 220 . +-----^--------+ +---^----------+ +-^-----+ +------------+ . 221 ........|..............|..............|..........|............. 222 |Conference |Floor |Call |Notification 223 |Control |Control |Signaling |Protocol 224 |Protocol |Protocol |Protocol | 225 ........v..............v..............v..........v............. 226 . C o n f e r e n c i n g C l i e n t . 227 ............................................................... 229 Figure 1: Conference Server Architecture 231 The Session Initiation Protocol (SIP) Event Package for Conference 232 State, specified in [RFC4575], already defines a data format for 233 conferences. However, that model is SIP specific and lacks elements 234 related to some of the functionality defined by the Centralized 235 Conferencing Framework [RFC5239] (e.g., floor control). The data 236 model defined in this document constitutes a superset of the data 237 format defined in [RFC4575]. The result is a data format that 238 supports more call signaling protocols besides SIP and that covers 239 all the functionality defined in the Centralized Conferencing 240 Framework [RFC5239]. 242 2. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in RFC 2119 [RFC2119]. 248 This document uses the terminology defined in the Centralized 249 Conferencing Framework [RFC5239], the SIPPING conferencing framework 250 [RFC4353] and the BFCP (Binary Floor Control Protocol) specification 251 [RFC4582]. Readers of this document should be familiar with the 252 terminology used in those documents. 254 3. Overview 256 The data model specified in this document is the result of extending 257 the data format defined in [RFC4575] with new elements. Examples of 258 such extensions include scheduling elements, media control elements, 259 floor control elements, non-SIP URIs, and addition of localization 260 extensions to text elements. This data model can be used by 261 conference servers providing different types of basic conferences. 262 It is expected that this data model can be further extended with new 263 elements in the future in order to implement additional advanced 264 features. 266 3.1. Data Model Format 268 A conference object document is an XML [W3C.REC-xml-20001006] 269 document that MUST be well formed and SHOULD be valid. Conference 270 object documents MUST be based on XML 1.0 and SHOULD be encoded using 271 UTF-8. 273 3.2. Data Model Namespace 275 This specification defines a new namespace specification for 276 identifying the elements defined in the data model. This namespace 277 is as follows: 279 urn:ietf:params:xml:ns:xcon-conference-info 281 3.3. The Conference Object Identifier 283 The conference object identifier (XCON-URI) can be viewed as a key to 284 accessing a specific conference object. It can be used, for 285 instance, by the conference control protocol to access, manipulate 286 and delete a conference object. A conference object identifier is 287 provided to the conferencing client by the conference notification 288 service or through out-of-band mechanisms (e.g. E-Mail). 290 A conferencing system may maintain a relationship between the 291 conference object identifiers and the identifiers associated with 292 each of the complementary centralized conferencing protocols (e.g., 293 call signaling protocols, BFCP, etc.). To facilitate the maintenance 294 of these relationships, the conference object identifier acts as a 295 top level identifier within the conferencing system for the purpose 296 of identifying the interfaces for these other protocols. This 297 implicit binding provides a structured mapping of the various 298 protocols with the associated conference object Identifier. Figure 2 299 illustrates the relationship between the identifiers used for the 300 protocols and the general conference object identifier (XCON-URI). 302 +--------------------------+ 303 | Conference | 304 | Object | 305 | Identifier | 306 +--------------------------+ 307 | xcon:Ji092i@example.com | 308 +------+-------------------+ 309 | 310 | 311 | 312 +-----------------+---------------+ 313 | | 314 +-----------+-----------+ +----------+---------+ 315 | CSP Conference IDs | |BFCP 'Conference ID'| 316 +-----------------------+ +--------------------+ 317 | h323:i092@example.com | | i092 | 318 | tel:+44(0)2920930033 | +----------+---------+ 319 | sip:i092@example.com | | 320 +-----------------------+ +-------+--------+ 321 | BFCP 'Floor ID'| 322 +----------------+ 323 | 543 | 324 | 236 | 325 +----------------+ 327 Figure 2: Conference Object Mapping 329 In Figure 2, the conference object identifier acts as the top level 330 key in the identification process. The call signaling protocols have 331 an associated conference user identifier, often represented in the 332 form of URIs. The binary floor control protocol, as defined in 333 [RFC4582], defines the 'conference ID' identifier which represents a 334 conference instance within floor control. When created within the 335 conferencing system, the 'conference ID' has a 1:1 mapping to the 336 unique conference object Identifier(XCON-URI). Operations associated 337 with the conference control protocols are directly associated with 338 the conference object, thus the primary identifier associated with 339 these protocols is the conference object identifier(XCON-URI). The 340 mappings between additional protocols/interface is not strictly 1:1 341 and does allow for multiple occurrences. For example, multiple call 342 signaling protocols will each have a representation that is 343 implicitly linked to the top level conference object identifier e.g. 344 H323 and SIP URIs that represent a conference instance. It should be 345 noted that a conferencing system is free to structure such 346 relationships as required and this information is just included as a 347 guideline that can be used. 349 Further elements can be added to the tree representation in Figure 2 350 to enable a complete representation of a conference instance within a 351 conferencing system. 353 3.3.1. Conference Object URI Definition 355 XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] 357 conf-object-id = 1*( unreserved / "+" / "=" / "/" ) 359 host, port, and unreserved are defined in RFC3986[RFC3986] 361 3.4. Data Model Structure 363 The information in this data model is structured in the following 364 manner. All the information related to a conference is contained in 365 a element. The element contains 366 the following child elements: 368 o The element describes the conference as a 369 whole. It has, for instance, information about the URI of the 370 conference, maximum users allowed in the conference, media 371 available in the conference, or the time the conference will 372 start. 373 o The element contains information about the entity 374 hosting the conference (e.g., its URI). 375 o The element informs the subscribers about the 376 changes in the overall conference information. 377 o The element contains information about the 378 status of the different floors in the conference. 379 o The element describes the membership information as a 380 whole. The element contains a set of child 381 elements, each describing a single participant in the conference. 382 o If a participant in the main conference joins a sidebar, a new 383 element is created in the conference referenced from the 384 element or under one of the 385 elements. 387 Note that some of the elements described above such , , , or are not defined in the data model but are defined in the data 390 format of [RFC4575]. We describe them here because they are part of 391 the basic structure of the data model. 393 4. Data Model Definition 395 The following non-normative diagram shows the structure of conference 396 object documents. The operator "!" preceding an element indicates 397 that the element is mandatory in the data model. The operator "*" 398 following an element indicates that the element is introduced and 399 defined in this document. That is, elements without a "*" have 400 already been defined in [RFC4575]. 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 | |--* 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 | | | | |--