idnits 2.17.1 draft-ietf-xcon-common-data-model-12.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4307. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 (October 28, 2008) is 5657 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: 5 errors (**), 0 flaws (~~), 1 warning (==), 9 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: May 1, 2009 D. Morgan 6 Fidelity Investments 7 R. Even 8 Polycom 9 J. Urpalainen 10 Nokia 11 October 28, 2008 13 Conference Information Data Model for Centralized Conferencing (XCON) 14 draft-ietf-xcon-common-data-model-12.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 1, 2009. 41 Abstract 43 This document defines an Extensible Markup Language (XML)-based 44 conference information data model for centralized conferencing 45 (XCON). A conference information data model is designed to convey 46 information about the conference and about participation in the 47 conference. The conference information data model defined in this 48 document constitutes an extension of the data format specified in the 49 Session Initiation Protocol (SIP) Event Package for Conference State. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 6 57 3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 6 58 3.3. The Conference Object Identifier . . . . . . . . . . . . . 7 59 3.3.1. Conference Object URI Definition . . . . . . . . . . . 9 60 3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 9 61 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 10 62 4.1. . . . . . . . . . . . . . . . . . . . . 13 63 4.2. . . . . . . . . . . . . . . . . . 14 64 4.2.1. . . . . . . . . . . . . . . . . . . . . . . 14 65 4.2.2. . . . . . . . . . . . . . . . . . . . . 14 66 4.2.3. . . . . . . . . . . . . . . . . . . . . . . 14 67 4.2.4. . . . . . . . . . . . . . . . . . . . . . 14 68 4.2.5. . . . . . . . . . . . . . . . . . . . . . . 15 69 4.2.6. . . . . . . . . . . . . . . . . . . . 15 70 4.2.7. . . . . . . . . . . . . . . . . . . 15 71 4.2.8. . . . . . . . . . . . . . . . . . . . . . 16 72 4.2.9. . . . . . . . . . . . . . . . . . . . . 16 73 4.2.10. . . . . . . . . . . . . . . . . . 16 74 4.2.11. . . . . . . . . . . . . . . . . . . 17 75 4.3. . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.4. . . . . . . . . . . . . . . . . . . . . 19 77 4.4.1. . . . . . . . . 19 78 4.4.2. . . . . . . . . . . . . . . . . . . . . . 19 79 4.4.3. . . . . . . . . . . . . . . . . . . . . . . . 19 80 4.4.4. . . . . . . . . . . . . . . . . . . . . . . . 20 81 4.5. . . . . . . . . . . . . . . . . . . . 20 82 4.5.1. . . . . . . . . . . . . . . . . . . . 20 83 4.5.2. . . . . . . . . . . . . . . . . . 20 84 4.5.3. . . . . . . . . . . . . . . . 20 85 4.5.4. . . . . . . . . . . . . . . 21 86 4.6. . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 4.6.1. . . . . . . . . . . . . . . . . . . . 22 88 4.6.2. . . . . . . . . . . . . . . . 22 89 4.6.3. . . . . . . . . . . . . . . . . . 23 90 4.6.4. . . . . . . . . . . . . . . . . . . 24 91 4.6.5. and Its Sub-elements . . . . . . . . . . 24 92 4.6.5.1. . . . . . . . . . . . . . . . . . . 25 93 4.6.5.2. . . . . . . . . . . . . . . . . 25 94 4.6.5.3. . . . . . . . . . . . . . . . 25 95 4.6.5.4. . . . . . . . . . . . . . . . . . . . . . 26 96 4.6.5.5. . . . . . . . . . . . . . . . . . . . 26 97 4.6.5.6. . . . . . . . . . . . . . . . . . 26 98 4.6.5.7. . . . . . . . . . 26 99 4.6.5.8. . . . . . . . . . 26 100 4.6.5.9. . . . . . . . . . 27 101 4.6.5.10. . . . . . . . . . . . . . . . . . . . . 27 102 4.7. . . . . . . . . . . . . . . . . . . . . 28 103 4.8. . . . . . . . . . . . . . . . . . . . . 28 104 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 28 105 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 39 106 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 39 107 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 108 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 49 109 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 49 110 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 50 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 112 9.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 50 113 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 50 114 9.3. Conference Object Identifier Registration . . . . . . . . 51 115 9.4. Conference User Identifier Registration . . . . . . . . . 52 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 53 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 53 120 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 54 121 Appendix B. Non-Normative W3C XML Schema . . . . . . . . . . . . 81 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 123 Intellectual Property and Copyright Statements . . . . . . . . . . 92 125 1. Introduction 127 There is a core data set of conference information that is utilized 128 in any conference, independent of the specific conference media. 129 This core data set called the 'conference information data model' is 130 defined in this document using an Extensible Markup Language (XML)- 131 based. The conference information data model defined in this 132 document is logically represented by the conference object. 134 Conference objects are a fundamental concept in Centralized 135 Conferencing, as described in the Centralized Conferencing Framework 136 [RFC5239]. A conference object contains data that represents a 137 conference during each of its various stages (e.g., created/creation, 138 reserved/reservation, active/activation, completed/completion). A 139 conference object can be manipulated using a conference control 140 protocol at a conference server. The conference object represents a 141 particular instantiation of a conference information data model. 142 Consequently, conference objects follow the XML format defined in 143 this document. 145 A conference object contains the core information of a conference 146 (i.e., capabilities, membership, call control signaling, media, etc.) 147 and specifies who, and in which way that information can be 148 manipulated. 150 Figure 1 shows the logical functional elements of a conference server 151 as defined by the Centralized Conferencing Framework [RFC5239]. They 152 are a Conference Control Server, a Floor Control Server, a number of 153 Foci, and a Notification Service. A conference control protocol 154 provides the interface between a conference control client and the 155 conference control server. A floor control protocol (e.g., BFCP 156 [RFC4582]) provides the interface between a floor control client and 157 the floor control server. A call signaling protocol (e.g., SIP, 158 H.323, Q.931, ISUP, etc.) provides the interface between a call 159 signaling client and a Focus. A notification protocol (e.g., SIP- 160 based event notifications [RFC3265]) provides the interface between 161 the conferencing client and the Notification Service. Within a 162 conference, the conference control server, floor control server, and 163 focus can modify the information in the conference object. 165 ............................................................... 166 . Conferencing Server . 167 . +---------------------------------------------------+ . 168 . | C o n f e r e n c e o b j e c t | . 169 . +-+--------------------------------------------------+| . 170 . | C o n f e r e n c e o b j e c t || . 171 . +-+---------------------------------------------------+|| . 172 . | C o n f e r e n c e o b j e c t ||| . 173 . | +--------------------------------------------------+||| . 174 . | | Conference Information Data Model |||| . 175 . | | +----------------------------------------------+ |||| . 176 . | | | Conference description (times, duration) | |||| . 177 . | | +----------------------------------------------+ |||| . 178 . | | +----------------------------------------------+ |||| . 179 . | | | Host information | |||| . 180 . | | +----------------------------------------------+ |||| . 181 . | | +----------------------------------------------+ |||| . 182 . | | | Conference state | |||| . 183 . | | +----------------------------------------------+ |||| . 184 . | | +----------------------------------------------+ |||| . 185 . | | | Floor information | |||| . 186 . | | +----------------------------------------------+ |||| . 187 . | | +----------------------------------------------+ |||| . 188 . | | | Membership (users, capacity) | |||| . 189 . | | +----------------------------------------------+ |||| . 190 . | | +----------------------------------------------+ |||| . 191 . | | | Sidebars, Etc. | |||| . 192 . | | +----------------------------------------------+ |||| . 193 . | | +----------------------------------------------+ |||| . 194 . | | | Etc. | |||| . 195 . | | +----------------------------------------------+ |||+ . 196 . | +--------------------------------------------------+|+ . 197 . +----^------------------^-------------^--------|------+ . 198 . | | | | . 199 . +------v-------+ +--------v-----+ +-----v-+ +----v-------+ . 200 . | Conference | | Floor | | | | | . 201 . | Control | | Control | |Foci | |Notification| . 202 . | Server | | Server | | | |Service | . 203 . +-----^--------+ +---^----------+ +-^-----+ +------------+ . 204 ........|..............|..............|..........|............. 205 |Conference |Floor |Call |Notification 206 |Control |Control |Signaling |Protocol 207 |Protocol |Protocol |Protocol | 208 ........v..............v..............v..........v............. 209 . C o n f e r e n c i n g C l i e n t . 210 ............................................................... 212 Figure 1: Conference Server Architecture 214 The Session Initiation Protocol (SIP) Event Package for Conference 215 State, specified in [RFC4575], already defines a data format for 216 conferences. However, that model is SIP specific and lacks elements 217 related to some of the functionality defined by the Centralized 218 Conferencing Framework [RFC5239] (e.g., floor control). The data 219 model defined in this document constitutes a superset of the data 220 format defined in [RFC4575]. The result is a data format that 221 supports more call signaling protocols besides SIP and that covers 222 all the functionality defined in the Centralized Conferencing 223 Framework [RFC5239]. 225 2. Terminology 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC 2119 [RFC2119]. 231 This document uses the terminology defined in the Centralized 232 Conferencing Framework [RFC5239], the SIPPING conferencing framework 233 [RFC4353] and the BFCP (Binary Floor Control Protocol) specification 234 [RFC4582]. Readers of this document should be familiar with the 235 terminology used in those documents. 237 3. Overview 239 The data model specified in this document is the result of extending 240 the data format defined in [RFC4575] with new elements. Examples of 241 such extensions include scheduling elements, media control elements, 242 floor control elements, non-SIP URIs, and addition of localization 243 extensions to text elements. This data model can be used by 244 conference servers providing different types of basic conferences. 245 It is expected that this data model can be further extended with new 246 elements in the future in order to implement additional advanced 247 features. 249 3.1. Data Model Format 251 A conference object document is an XML [W3C.REC-xml-20001006] 252 document that MUST be well formed and SHOULD be valid. Conference 253 object documents MUST be based on XML 1.0 and SHOULD be encoded using 254 UTF-8. 256 3.2. Data Model Namespace 258 This specification defines a new namespace specification for 259 identifying the elements defined in the data model. This namespace 260 is as follows: 262 urn:ietf:params:xml:ns:xcon-conference-info 264 3.3. The Conference Object Identifier 266 The conference object identifier (XCON-URI) can be viewed as a key to 267 accessing a specific conference object. It can be used, for 268 instance, by the conference control protocol to access, manipulate 269 and delete a conference object. A conference object identifier is 270 provided to the conferencing client by the conference notification 271 service or through out-of-band mechanisms (e.g. E-Mail). 273 A conferencing system may maintain a relationship between the 274 conference object identifiers and the identifiers associated with 275 each of the complementary centralized conferencing protocols (e.g., 276 call signaling protocols, BFCP, etc.). To facilitate the maintenance 277 of these relationships, the conference object identifier acts as a 278 top level identifier within the conferencing system for the purpose 279 of identifying the interfaces for these other protocols. This 280 implicit binding provides a structured mapping of the various 281 protocols with the associated conference object Identifier. Figure 2 282 illustrates the relationship between the identifiers used for the 283 protocols and the general conference object identifier (XCON-URI). 285 +--------------------------+ 286 | Conference | 287 | Object | 288 | Identifier | 289 +--------------------------+ 290 | xcon:Ji092i@example.com | 291 +------+-------------------+ 292 | 293 | 294 | 295 +-----------------+---------------+ 296 | | 297 +-----------+-----------+ +----------+---------+ 298 | CSP Conference IDs | |BFCP 'Conference ID'| 299 +-----------------------+ +--------------------+ 300 | h323:i092@example.com | | i092 | 301 | tel:+44(0)2920930033 | +----------+---------+ 302 | sip:i092@example.com | | 303 +-----------------------+ +-------+--------+ 304 | BFCP 'Floor ID'| 305 +----------------+ 306 | 543 | 307 | 236 | 308 +----------------+ 310 Figure 2: Conference Object Mapping 312 In Figure 2, the conference object identifier acts as the top level 313 key in the identification process. The call signaling protocols have 314 an associated conference user identifier, often represented in the 315 form of URIs. The binary floor control protocol, as defined in 316 [RFC4582], defines the 'conference ID' identifier which represents a 317 conference instance within floor control. When created within the 318 conferencing system, the 'conference ID' has a 1:1 mapping to the 319 unique conference object Identifier(XCON-URI). Operations associated 320 with the conference control protocols are directly associated with 321 the conference object, thus the primary identifier associated with 322 these protocols is the conference object identifier(XCON-URI). The 323 mappings between additional protocols/interface is not strictly 1:1 324 and does allow for multiple occurrences. For example, multiple call 325 signaling protocols will each have a representation that is 326 implicitly linked to the top level conference object identifier e.g. 327 H323 and SIP URIs that represent a conference instance. It should be 328 noted that a conferencing system is free to structure such 329 relationships as required and this information is just included as a 330 guideline that can be used. 332 Further elements can be added to the tree representation in Figure 2 333 to enable a complete representation of a conference instance within a 334 conferencing system. 336 3.3.1. Conference Object URI Definition 338 XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ] 340 conf-object-id = 1*( unreserved / "+" / "=" / "/" ) 342 host, port, and unreserved are defined in RFC3986[RFC3986] 344 3.4. Data Model Structure 346 The information in this data model is structured in the following 347 manner. All the information related to a conference is contained in 348 a element. The element contains 349 the following child elements: 351 o The element describes the conference as a 352 whole. It has, for instance, information about the URI of the 353 conference, maximum users allowed in the conference, media 354 available in the conference, or the time the conference will 355 start. 356 o The element contains information about the entity 357 hosting the conference (e.g., its URI). 358 o The element informs the subscribers about the 359 changes in the overall conference information. 360 o The element contains information about the 361 status of the different floors in the conference. 362 o The element describes the membership information as a 363 whole. The element contains a set of child 364 elements, each describing a single participant in the conference. 365 o If a participant in the main conference joins a sidebar, a new 366 element is created in the conference referenced from the 367 element or under one of the 368 elements. 370 Note that some of the elements described above such , , , or are not defined in the data model but are defined in the data 373 format of [RFC4575]. We describe them here because they are part of 374 the basic structure of the data model. 376 4. Data Model Definition 378 The following non-normative diagram shows the structure of conference 379 object documents. The operator "!" preceding an element indicates 380 that the element is mandatory in the data model. The operator "*" 381 following an element indicates that the element is introduced and 382 defined in this document. That is, elements without a "*" have 383 already been defined in [RFC4575]. 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 | | | |-- 510 | | | |-- 511 | | | |-- 512 | | | |-- 513 | | | | |-- 514 | | | | |-- 515 | | | | |--