idnits 2.17.1 draft-boulton-xcon-session-chat-04.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.ii 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 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 (July 10, 2009) is 5404 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.roach-xcon-chatroom-analysis' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC2664' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC4579' is defined on line 634, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-13 == Outdated reference: A later version (-15) exists of draft-ietf-xcon-ccmp-02 == Outdated reference: A later version (-10) exists of draft-ietf-xcon-examples-00 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) == Outdated reference: A later version (-18) exists of draft-ietf-simple-chat-04 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group M. Barnes 3 Internet-Draft Nortel 4 Intended status: Standards Track C. Boulton 5 Expires: January 11, 2010 NS-Technologies 6 S. Loreto 7 Ericsson 8 July 10, 2009 10 Chatrooms within a Centralized Conferencing (XCON) System 11 draft-boulton-xcon-session-chat-04 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 11, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The document "A Framework for Centralized Conferencing" defines a 50 centralized conference as both signaling and protocol agnostic. The 51 primary examples within this framework focus on audio and video as 52 the media types for the session. This document provides an overview 53 of the mechanisms defined in the centralized conferencing framework 54 that can be used to support multi-user chat. In addition, the 55 document describes additional functionality and requirements 56 necessary to provide feature rich functionality. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Basic Protocol Operations . . . . . . . . . . . . . . . . 5 64 3.2. Chat Session and Conferencing Identifiers . . . . . . . . 7 65 4. Advanced Operations . . . . . . . . . . . . . . . . . . . . . 9 66 5. Additional Operations . . . . . . . . . . . . . . . . . . . . 9 67 5.1. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.3. History . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.4. Indicating Alternate Venue . . . . . . . . . . . . . . . . 11 71 5.5. File Transfer . . . . . . . . . . . . . . . . . . . . . . 12 72 5.6. Real Time Collaboration . . . . . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 A Centralized Conference as defined by the "A Framework for 84 Centralized Conferencing" (XCON Framework) [RFC5239] is both 85 signaling and protocol agnostic. The primary examples within the 86 framework focus on audio and video as the media types for the 87 session. This document provides an overview of the mechanisms and 88 associated framework elements involved when text is the media for the 89 conference. This functionality is often referred to as a "multi-user 90 chat" as it enables a participant to join a chatroom (e.g. hosted by 91 the conference server) for the exchange of messages between multiple 92 participants. The message can be plain text or can contain different 93 format for more advanced functionality. 95 Several existing protocols support this multi-user chat 96 functionality, such as Extensible Messaging and Presence Protocol 97 (XMPP) [RFC3920],[RFC3921] and Internet Relay Chat (IRC) defined in 98 [RFC1459] and its successors: [RFC2810],[RFC2811],[RFC2812], 99 [RFC2813]. In addition, [I-D.ietf-simple-chat] provides multi-user 100 chat functionality for a purely SIP signaling based solution option 101 using Message Session Relay Protocol (MSRP) [RFC4975]. 103 The focus of this document is to describe the interface and provide 104 guidelines for the the support of existing multi-user chat 105 functionality on a conferencing system based on the XCON framework 106 using the Conference Control Manipulation Protocol (CCMP) independent 107 of the specific media type used by the chat client. 109 The functionality described in this document is not intended to 110 replace any of the existing chat protocols, nor is it specifying a 111 new chat protocol. The motivation for this document is to allow 112 clients that use the conferencing framework model for other media 113 types (e.g. voice/video) to utilize the same conference control 114 mechanisms and conferencing system to establish, update and delete a 115 chatroom associated with a conference instance, independent of the 116 chat protocol. This approach also allows the conferencing system to 117 provide a natural interworking point for various chat protocols - the 118 details of the interworking are outside the scope of this document. 120 2. Conventions and Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 This document reuses the terminology defined in the Centralized 127 Conferencing Framework [RFC5239] and related protocol document 129 [I-D.ietf-xcon-ccmp]. 131 Additional terminology used in this document: 132 Chat Client: a Conferencing Client as defined in [RFC5239] that 133 participates in a "chatroom". 134 Chatroom: A virtual space that users figuratively enter in order to 135 participate in real-time, text-based conferencing with other 136 users. 137 Multi-user chat: The functionality that allows multiple users to 138 exchange messages in the context of a room or channel, similar to 139 Internet Relay Chat (IRC). 140 Private message: A message sent from one participant directly to 141 another participant - i.e., not to the chatroom itself to all 142 participants. 144 3. Overview 146 Figure 1 provides a general illustration of chat clients having a 147 direct, 1:1 connection to the conferencing system. Participants can 148 use the chat clients to join a room associated with a conference 149 instance and send messages. The conferencing system receives the 150 messages sent from a client participating in a conference instance 151 and then distributes them to the other clients associated with the 152 conference instance, that are also present in the chatroom. 154 +--------+ 155 | Chat | 156 | Client | 157 +--------+ 158 | 159 | 160 | 161 v 162 +--------+ +------------+ +--------+ 163 | Chat | |Conferencing| | Chat | 164 | Client |----------->| System |<-----------| Client | 165 +--------+ +------------+ +--------+ 166 ^ 167 | 168 | 169 | 170 +--------+ 171 | Chat | 172 | Client | 173 +--------+ 175 Figure 1: Client Connection 177 The approach in this document is to have no impact on the existing 178 chat protocols, while taking full advantage of the functionality 179 provided by the centralized conferencing framework. 181 A basic solution for MSRP based IM chat sessions is documented in 182 [I-D.ietf-simple-chat]. It uses the concept of an "MSRP switch" as 183 the centralized component, whose role is very similar to the MSRP 184 Conferencing Server in this document. The solution in 185 [I-D.ietf-simple-chat] doesn't explicitly take advantage of the 186 centralized conferencing framework model, as it primarily intends to 187 make use of the basic SIP conferencing framework to provide the basic 188 chat functionality. The MSRP based IM chat solution is compatible 189 with the solution components described in this document, with no 190 impact on that basic solution proposal. One of the advantages of 191 applying the two solutions in concert would be to take advantage of 192 the centralized conferencing framework model for advanced features, 193 such as sidebars and private conferences, and manipulation of the 194 conference data. 196 XMPP assumes a decentralized client-server architecture similar to 197 the one showed in Figure 1, wherein a client utilizing XMPP accesses 198 a server and servers can also communicate with each other over TCP 199 connections, like in the email network. The XMPP server can provide 200 as additional functionality the multi-user conferencing services 201 [XEP-0045]. The XMPP multi-user conferencing service is also 202 compatible with the solution components described in this document, 203 with no impact on the basic solution proposal. Indeed the 204 centralized conferencing framework model is perfectly able to manage 205 the XMPP strong room control model, including the ability to kick and 206 ban users, to name room moderators and administrators, to require 207 membership or passwords in order to join the room. However it is 208 worth to note that the centralized conferencing framework does not 209 encompass the communication between servers, as XMPP does. Then when 210 used together the access to a XMPP chatroom SHOULD be only limited to 211 client having a direct connection with the server hosting the 212 chatroom instance, and the federation between servers SHOULD NOT be 213 allowed. 215 3.1. Basic Protocol Operations 217 The multi-user chat protocol operations, such as create, join and 218 delete a chat MAY be performed using both non-signaling specific 219 mechanisms or protocol specific mechanism if defined. Non-signaling 220 specific mechanisms are defined in the Centralized Conferencing 221 Framework [RFC5239] and related Conference Control Manipulation 222 Protocol (CCMP) document [I-D.ietf-xcon-ccmp]. This document 223 provides the details for the non-signaling specific mechanisms using 224 CCMP with detailed examples provided in [I-D.ietf-xcon-examples]. 225 Protocol specific mechanisms are defined in other documents such as 226 for SIP in the SIPPING Conference Framework [RFC4353] and for XMPP in 227 Multi-User Chat [XEP-0045]. 229 The privilege to create a chatroom associated with a conference 230 instance MAY be restricted to certain users or MAY be reserved to an 231 administrator of the conference. The room creation MAY be performed 232 using non-signaling mechanism or protocol specific mechanism if 233 defined. In the case of CCMP, a confRequest message with a "create" 234 operation is sent by the chat client. 236 A participant MAY query the conferencing system to discover the list 237 of the chat rooms associated to a hosted conference instance. In the 238 case of CCMP, a blueprintsRequest message for the chatrooms supported 239 by a conferencing system or a confsRequest message for the active 240 chatrooms can be sent by the chat client. 242 In order to participate in the discussions held in a multi-user chat 243 room, a participant MUST first enter the room. A chat client wishing 244 to enter a chatroom associated to a conference instance MAY use a 245 non-signaling or protocol specific mechanism if defined. In the case 246 of CCMP, a participant can join a conference instance using several 247 mechanisms which are described in [I-D.ietf-xcon-ccmp] - e.g., 248 userRequest message with a "create" operation to be added to a 249 conference instance. 251 The request to send a message is specific to the chat protocol (e.g., 252 MSRP SEND). Upon receipt of a request to send a message, the 253 conferencing system replicate and forwards the message to all other 254 chat clients that are participants of the chat room. Depending upon 255 policy, a conferencing system MAY ignore or reject messages, in which 256 case they are not distributed to the other chat room participants. 258 A participant MAY send a "private message" to a selected participant 259 or a group of participant. This privilege SHOULD be allowed for all 260 participants unless local policy dictates otherwise. 262 A chat client wishing to exit a chat room MAY uses non-signaling 263 mechanism or protocol specific mechanism if defined. If the chat 264 client is the last to exit, the conferencing system MAY be 265 responsible for deleting the room or the originator/owner/moderator 266 The privilege to delete a chatroom associated with a conference 267 instance MAY be restricted to certain users or MAY be reserved to an 268 administrator of the conference. The room deletion MAY be performed 269 using non-signaling mechanism or protocol specific mechanism if 270 defined. In the case of CCMP, the client SHOULD send a CCMP 271 confRequest message with an operation of "delete". 273 3.2. Chat Session and Conferencing Identifiers 275 As highlighted in the overview section, a chat client connecting to a 276 conferencing system has a 1:1 relationship with the chat signaling 277 entity, each having a unique protocol specific Chat Session 278 identifier (ID). When referring to Chat Session IDs the document is 279 making reference to the locally (at conferencing system) generated 280 Chat Session ID used for session signaling identification. In the 281 case of MSRP, this Chat Session ID is inserted into the local path 282 SDP attribute. An important concept in this proposal is the creation 283 and management of Group Chats. It is important that each chat 284 session created, as identified by a unique chat session ID, is 285 explicitly tied to an associated conference, represented by the 286 conference identifier (as defined in the Centralized Conferencing 287 Framework [RFC5239]). This provides the relevant association between 288 a chat session and a centralized conference. A generic example 289 representation is illustrated by the rows contained in Figure 2. 291 +-----------------------------------------+ 292 | Conference Identifier | 293 +-----------------------------------------+ 294 | Chat Session ID=8asjdhk | 295 | Chat Session ID=38iuhds | 296 | Chat Session ID=djiowid | 297 | Chat Session ID=389hewu | 298 +-----------------------------------------+ 300 Figure 2: Simple Session Association 302 The Centralized Conferencing Framework[RFC5239] introduces the 303 concept of a conference user identifier defined in 304 [I-D.ietf-xcon-common-data-model]. When a user joins a conference 305 instance through the signaling protocol, it is allocated an 306 appropriate conference user identifier either through authentication 307 or system allocation. The conference user identifier MUST be used in 308 conjunction with a chat session identifier to internally represent a 309 participant in a conference instance. Figure 2 is then expanded to 310 look like Figure 3. Again a row in the table representing a single 311 entry. 313 +--------------------------------------------------------------+ 314 | Conference Identifier | 315 +--------------------------------+-----------------------------+ 316 | Chat Session ID=8asjdhk | Conf User ID=839ULjj | 317 | Chat Session ID=38iuhds | Conf User ID=0283hHu | 318 | Chat Session ID=djiowid | Conf User ID=ncH37H | 319 | Chat Session ID=389hewu | Conf User ID=pakdjjH | 320 +--------------------------------+-----------------------------+ 322 Figure 3: Advanced Session Association 324 A more complex session association is necessary due to potential for 325 a user to have multiple group chats in a single conference instance, 326 such as multi-lingual conference support. In an example with SIP and 327 MSRP, the conference representation in Figure 3 allows for such 328 functionality when separate SIP dialogs represent MSRP sessions. 329 This process becomes complex in the case that multiple SDP MSRP media 330 sessions (m=) are defined in a single payload. This internal 331 representation needs expanding to enable a conferencing system to 332 explicitly associate a media session (m=). This involves including 333 the media label, as defined in [RFC4574], to maintain the internal 334 conference association. An example is illustrated in Figure 4. 336 +-----------------------------------------------------------------+ 337 | Conference Identifier | 338 +-----------------------------------------------------------------+ 339 | Chat Session ID=8asjdhk | Conf User ID=839ULjj | Label=iede3 | 340 | Chat Session ID=38iuhds | Conf User ID=0283hHu | Label=8heus | 341 | Chat Session ID=838unaH | Conf User ID=0283hHu | Label=3cnu7 | 342 | Chat Session ID=djiowid | Conf User ID=ncH37Hs | Label=jd38J | 343 | Chat Session ID=389hewu | Conf User ID=pakdj7H | Label=U83hd | 344 | Chat Session ID=Ko03jdk | Conf User ID=pakdj7H | Label=ehy3h | 345 +-----------------------------------------------------------------+ 347 Figure 4: Advanced Session Association + Media Label 349 In Figure 4, conference user identifiers '0283hHu' and 'pakdj7H' 350 appear twice. The combination of multiple conference user 351 identifiers and a unique Group Chat session ID enables the conference 352 system to clearly identify a specific Group Chat instance. Even in 353 the simplest conferencing system, where users are allowed to enter 354 anonymously, the internal representation described in this section 355 should be observed. In this case, the conferencing system would 356 still internally create a conference user identifier for participant 357 reference purposes. 359 4. Advanced Operations 361 Advanced chat features, such as sidebars and private messages can 362 also be supported within the context of the centralized conferencing 363 framework using CCMP. Additional protocol details for these advanced 364 features are provided in [I-D.ietf-xcon-examples]. 366 5. Additional Operations 368 This section discusses additional operations or features required to 369 provide chat room functionality. Most of the operations are not 370 explicitly defined in the centralized conferencing framework. While 371 most of the features and operations are achievable using the XCON 372 data model [I-D.ietf-xcon-common-data-model] and data maintained by a 373 conferencing system per the XCON framework, some advanced features 374 require extensions to the XCON data model and may be optimized with 375 more discrete CCMP messages. 377 5.1. Nicknames 379 Nicknames allow a user to define a text string that uniquely 380 identifies the user within a particular chatroom without necessarily 381 reflecting any protocol specific identity (e.g., SIP URI, Conference 382 User Identifier, etc.). It is also important to note that the 383 functionality to provide nicknames is not limited to users involved 384 in chatrooms, thus it should be a general feature of the conferencing 385 system. 387 Within a conferencing system, all nicknames should map to a 388 conference user identifier. The nicknames are unique only to the 389 specific conferencing system. There may be multiple nicknames 390 associated with a single conference user identifier (e.g., a user 391 that has different nicknames for different chat rooms and/or voice/ 392 video conferences). In order to support nicknames, a 'nickname' 393 attribute is defined in the XCON data model within the 'user' 394 element. A nickname can be assigned to the conference user when an 395 XCON-USERID is assigned to the user. The conferencing client MAY 396 include a preferred nickname in the CCMP userRequest with a "create" 397 operation. 399 The conferencing system allocates a conference user identifier and a 400 nickname using system specific mechanisms, which may also include 401 authentication. The conferencing system associates the assigned 402 nickname with the specific conference user identifier that has been 403 allocated. Another option would be to define a new CCMP message to 404 just manipulate the nickname element. 406 As described Section 3.2, the conference user identifier MUST be used 407 in conjunction with a chat session identifier to internally represent 408 a participant in a conference instance. This association is created 409 when a conferencing client requests to create or join a specific 410 chatroom. The nickname allocated for the specific conferencing user 411 identifier MUST also be associated with the chat session ID. 412 Figure 5 provides an example of the association between the chat 413 session identifier, the conference user identifier and conference 414 nickname for a specific Group Chat represented by the conference 415 identifier. 417 +-----------------------------------------------------------------+ 418 | Conference Identifier | 419 +-----------------------------------------------------------------+ 420 | Chat Session ID=8asjdhk | Conf User ID=839ULjj | Nick=Alice | 421 | Chat Session ID=38iuhds | Conf User ID=0283hHu | Nick=Bob | 422 | Chat Session ID=838unaH | Conf User ID=0283hHu | Nick=Cliff | 423 | Chat Session ID=djiowid | Conf User ID=ncH37Hs | Nick=Dude | 424 | Chat Session ID=389hewu | Conf User ID=pakdj7H | Nick=Elliott | 425 | Chat Session ID=Ko03jdk | Conf User ID=pakdj7H | Nick=Fluffy | 426 +-----------------------------------------------------------------+ 428 Figure 5: Nickname Associations for a Group Chat 430 Depending upon the conferencing system, the conference system may 431 allocate the preferred nickname for that user or return a different 432 nickname in the CCMP userResponse message. 434 In the future, if a more generic nickname mechanism is available, 435 rather than provide nicknames that are specific to the conferencing 436 system, a conferencing system may interface with a nickname registry, 437 for example, in order to allocate a new nickname for a specific 438 conferencing client. This change in how a conferencing system 439 allocates nicknames should not impact the CCMP protocol interface to 440 support nicknames. 442 5.2. Logging 444 A common chat feature involves logging the history of a chat room. 445 This provides a record of a chat room that can be used when a user 446 first joins a chat room as discussed in Section 5.3. It can also be 447 used to provide a complete capture of a specific chat room session. 448 When a participant enters a room in which the discussions are logged, 449 the conferencing system MUST warn the participant that the 450 discussions are logged. 452 The centralized conferencing framework does not fully describe the 453 role of recording or logging of active conferences. However, this 454 functionality can be realized with the manipulation of the 455 appropriate elements in the data model using the general conference 456 control protocol operations. One approach for implementing this 457 function would be to have it be based on specific manipulation of the 458 conference by a user with the appropriate permissions (i.e., 459 confRequest messaage with an "update" operation to start and stop 460 recording). Another mechanism for implementing this function would 461 be to have a specific user as part of the conference to perform this 462 function, by defining a specific role such as "observer" and having 463 the media proxied to a logging device. 465 5.3. History 467 A common chat feature allows users to view the past history of chat 468 rooms. This operation is common when a user first joins a chat room 469 that is underway. A user is often offered the option to review a 470 specific number of past messages. 472 Conferencing systems that maintain the history associated with 473 specific chat rooms through logging, as described in Section 5.2, 474 should provide a mechanism, using the conference identifier, to 475 access the specific information requested by a user based on a 476 specific timestamp. The user request for the information and the 477 rendering of the information is specific to the user's session based 478 messaging protocol and may not be supported by all the messaging 479 protocols. 481 5.4. Indicating Alternate Venue 483 Another chat room feature provides the details of an alternate chat 484 room venue for previously active chat rooms that have been closed, 485 with a related topic. While not detailed in the centralized 486 conferencing framework, this functionality can be accomplished by 487 creating the new chat room as a child or sibling of the previous chat 488 room and providing the Active chat conference object identifier to 489 any valid users that attempt to join a previous chat room. The 490 information about the new chat room can also be provided at the end 491 of a chat room that is being de-activated at the end of the session. 493 5.5. File Transfer 495 The ability to send files to a selected participant or group of 496 participants is another common functionality, supported by messaging 497 protocols. This functionality also enables the exchange of 498 information (e.g. name, size, and date) about the file to be 499 transferred and usually provide a mechanism to show an image 500 thumbnail for files such as photos. This capability could be 501 reflected in the conference data (in the conference instance) and 502 requires at least an extension to the "available-media" element. The 503 thumbnail rendering of the image is outside the scope of the data 504 model and is specific to the client application. Additional 505 functionality to support this capability requires further study. 507 5.6. Real Time Collaboration 509 The messaging protocols can be used, and are being used, in 510 applications quite different from a simple exchange of text messages 511 between two participants in the context of a chatroom. Real-time 512 collaboration tools (e.g. Whiteboarding, screen-share, co-browse or 513 document-share) are some of these applications. 515 The Conferencing Systems are usually bound to Real-time collaboration 516 tools to increase the productivity of distributed teams. In terms of 517 correlating this functionality with CCMP, the mechanisms for 518 manipulating the conference are the same in terms of updating the 519 data associated with the conference with the additional attributes to 520 reflect the multiple sources of media for the chatroom. This 521 capability could be reflected in the conference data (in the 522 conference instance) with an extension to the "available-media" 523 element. Some current systems using SIP embed the attributes in the 524 media stream. Overall, supporting this functionality requires 525 further study. 527 6. Security Considerations 529 As discussed in the Centralized Conferencing Framework, there are a 530 wide variety of potential attacks related to conferencing, due to the 531 natural involvement of multiple endpoints and the many, often user- 532 invoked, capabilities provided by the conferencing system. Examples 533 of attacks associated with chatrooms includes the following: an 534 endpoint attempting to receive the messages for conferences in which 535 it is not authorized to participate, an endpoint attempting to 536 disconnect other users, and theft of service, by an endpoint, in 537 attempting to create conferences it is not allowed to create. 539 Since this document describes the use of existing protocols (e.g. 540 MSRP/SIP, CCMP, XMPP, etc.), it depends on the security solutions for 541 those protocols and the associated authorization mechanisms. This 542 solution is based on the Centralized Conferencing framework and makes 543 use of the policy associated with the conference object to ensure 544 that only authorized entities are able to manipulate the data to 545 access the capabilities. This solution also makes use of the privacy 546 and security of the identity of a user in the conference, as 547 discussed in the Centralized Conferencing Framework. 549 7. IANA Considerations 551 This document requires no IANA registrations. 553 8. Acknowledgments 555 The authors appreciate the input and comments from Miguel Garcia- 556 Martin and Dave Morgan. 558 9. References 560 9.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 566 Centralized Conferencing", RFC 5239, June 2008. 568 [I-D.ietf-xcon-common-data-model] 569 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 570 "Conference Information Data Model for Centralized 571 Conferencing (XCON)", draft-ietf-xcon-common-data-model-13 572 (work in progress), April 2009. 574 [I-D.ietf-xcon-ccmp] 575 Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 576 "Centralized Conferencing Manipulation Protocol", 577 draft-ietf-xcon-ccmp-02 (work in progress), March 2009. 579 9.2. Informative References 581 [I-D.roach-xcon-chatroom-analysis] 582 Roach, A., "An Analysis of Feature Parity Between XCON/ 583 SIMPLE-Based Chatrooms and Other Chatrooms", 584 draft-roach-xcon-chatroom-analysis-00 (work in progress), 585 August 2007. 587 [I-D.ietf-xcon-examples] 588 Barnes, M., Boulton, C., Miniero, L., and S. Romano, 589 "Centralized Conferencing Manipulation Protocol (CCMP) 590 Call Flow Examples", draft-ietf-xcon-examples-00 (work in 591 progress), July 2009. 593 [RFC2664] Plzak, R., Wells, A., and E. Krol, "FYI on Questions and 594 Answers - Answers to Commonly Asked "New Internet User" 595 Questions", RFC 2664, August 1999. 597 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 598 RFC 1459, May 1993. 600 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 601 April 2000. 603 [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", 604 RFC 2811, April 2000. 606 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", 607 RFC 2812, April 2000. 609 [RFC2813] Kalt, C., "Internet Relay Chat: Server Protocol", 610 RFC 2813, April 2000. 612 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 613 Protocol (XMPP): Core", RFC 3920, October 2004. 615 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 616 Protocol (XMPP): Instant Messaging and Presence", 617 RFC 3921, October 2004. 619 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 620 Session Initiation Protocol (SIP)", RFC 4353, 621 February 2006. 623 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 624 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 626 [I-D.ietf-simple-chat] 627 Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party 628 Chat Using the Message Session Relay Protocol (MSRP)", 629 draft-ietf-simple-chat-04 (work in progress), March 2009. 631 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 632 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 634 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 635 (SIP) Call Control - Conferencing for User Agents", 636 BCP 119, RFC 4579, August 2006. 638 [XEP-0045] 639 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 640 July 2007. 642 Authors' Addresses 644 Mary Barnes 645 Nortel 647 Email: mary.barnes@nortel.com 649 Chris Boulton 650 NS-Technologies 652 Email: chris@ns-technologies.com 654 Salvatore Loreto 655 Ericsson 656 Hirsalantie 11 657 Jorvas 02420, Finland 659 Email: salvatore.loreto@ericsson.com