idnits 2.17.1 draft-roach-xcon-chatroom-analysis-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 884. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (August 16, 2007) is 6095 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON WG A. B. Roach 3 Internet-Draft Estacado Systems 4 Expires: February 17, 2008 August 16, 2007 6 An Analysis of Feature Parity Between XCON/SIMPLE-Based Chatrooms and 7 Other Chatrooms 8 draft-roach-xcon-chatroom-analysis-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 17, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document provides an overview of the features available in 42 currently deployed text chatroom software, and analyzes which of 43 these features can be acheived using IETF-defined protocols. In the 44 case of features that have no clear IETF-defined mechanism, this 45 document provides high-level recommendations for work to implement 46 such features. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Feature Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Fully Supported Features . . . . . . . . . . . . . . . . . 4 53 2.1.1. Discovery of Support for Chatrooms . . . . . . . . . . 4 54 2.1.2. Automatic Creation of New Chatroom . . . . . . . . . . 5 55 2.1.3. Joining a Chatroom . . . . . . . . . . . . . . . . . . 6 56 2.1.4. Leaving a Chatroom . . . . . . . . . . . . . . . . . . 6 57 2.1.5. Inviting Other Users to a Chatroom . . . . . . . . . . 6 58 2.1.6. Removing Other Users from a Chatroom . . . . . . . . . 6 59 2.1.7. Transition from One-to-One Chat to Chatroom . . . . . 7 60 2.1.8. Chatroom Roster . . . . . . . . . . . . . . . . . . . 7 61 2.1.9. Sending Files and Images to a Chatroom . . . . . . . . 8 62 2.2. Partially Supported Features . . . . . . . . . . . . . . . 8 63 2.2.1. Determining of Chatroom Attributes . . . . . . . . . . 8 64 2.2.2. Determining of Chatroom User Attributes . . . . . . . 9 65 2.3. Features to be Supported by XCON Protocols . . . . . . . . 9 66 2.3.1. Explicit Creation of New Chatroom . . . . . . . . . . 9 67 2.3.2. Manipulation of Existing Chatrooms . . . . . . . . . . 9 68 2.3.3. Setting Chatroom Topic . . . . . . . . . . . . . . . . 10 69 2.3.4. Assignment of Roles and Permissions . . . . . . . . . 10 70 2.3.5. Explicit Destruction of Existing Chatrooms . . . . . . 10 71 2.3.6. Discovery of Existing Chatrooms . . . . . . . . . . . 10 72 2.3.7. Determining of Chatroom Attributes . . . . . . . . . . 10 73 2.3.8. Members-Only Chatrooms . . . . . . . . . . . . . . . . 11 74 2.3.9. Maximum User Count . . . . . . . . . . . . . . . . . . 11 75 2.3.10. Chatroom Locking . . . . . . . . . . . . . . . . . . . 11 76 2.3.11. Inviting Other Users to a Chatroom . . . . . . . . . . 11 77 2.3.12. Removing Other Users from a Chatroom . . . . . . . . . 11 78 2.3.13. Private Messages . . . . . . . . . . . . . . . . . . . 11 79 2.4. Features Requiring Additional Specification . . . . . . . 12 80 2.4.1. Discovery of Factory URIs . . . . . . . . . . . . . . 12 81 2.4.2. Discovery of Client Chatroom Support . . . . . . . . . 12 82 2.4.3. Password-Protected Chatrooms . . . . . . . . . . . . . 12 83 2.4.4. Private and Semi-Private Chatrooms . . . . . . . . . . 13 84 2.4.5. Banned Users . . . . . . . . . . . . . . . . . . . . . 13 85 2.4.6. Nicknames . . . . . . . . . . . . . . . . . . . . . . 13 86 2.4.7. Reasons Associated with Operations . . . . . . . . . . 13 87 2.4.8. Alternate Venues for Terminated Chatrooms . . . . . . 14 88 2.4.9. Discussion History . . . . . . . . . . . . . . . . . . 14 89 2.4.10. Chatroom Logging . . . . . . . . . . . . . . . . . . . 15 90 2.4.11. Private Messages . . . . . . . . . . . . . . . . . . . 16 91 2.4.12. Detailed User Registration . . . . . . . . . . . . . . 16 92 2.4.13. Chatroom Directories . . . . . . . . . . . . . . . . . 16 93 2.4.14. Subscribing to Phrases and Events . . . . . . . . . . 17 94 2.4.15. Notification of Unread Messages . . . . . . . . . . . 17 95 2.4.16. Designation of Chatroom Language . . . . . . . . . . . 17 96 2.4.17. User Role Change Requests . . . . . . . . . . . . . . 18 97 2.4.18. Per-User Approval to Join by Moderator . . . . . . . . 18 98 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 99 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 Intellectual Property and Copyright Statements . . . . . . . . . . 21 104 1. Introduction 106 This document attempts to collect a complete list of features 107 supported by various chatroom systems in use, and determine which 108 ones can be supported by using the protocols defined by and under 109 definition within the IETF. Note that related work has been 110 undertaken in draft-niemi-simple-chat and 111 draft-boulton-xcon-msrp-conferencing. 113 This work is intended to complement such ongoing work. In 114 particular, this document does not seek to define protocol extensions 115 (although it does make some recommendations about how protocols might 116 be extended to implement certain features). This document also 117 attempts to exhaustively list features of currently deployed chatroom 118 servers, and analyze where any gaps may lie between such features and 119 what can be achieved using IETF protocols. 121 It is not the author's expectation that this document will be adopted 122 by any working group, nor that it will be published as an RFC. Its 123 goal is to identify where additional work may be required in the IETF 124 to define a complete chatroom system based on protocols defined in 125 the SIP, SIMPLE and XCON working groups, while living up to user 126 expectations in terms of features offered. 128 2. Feature Analysis 130 The following sections contain descriptions of features available in 131 currently deployed chatroom solutions. They are split according to 132 the level of support available via IETF protocols. 134 2.1. Fully Supported Features 136 The following features are supported using existing mechanisms 137 defined in published RFCs. In some cases, the mechanism is 138 explicitly supported; in others, the mechanisms already exist, but 139 may not have been specifically described in relation to chat rooms. 141 2.1.1. Discovery of Support for Chatrooms 143 Discovering whether a server supports chatroom functionality for a 144 particular URI can be achieved by sending an OPTIONS request to the 145 URI. The combination of an "isfocus" feature tag on the "Contact" 146 header field and at least one "m=" line containing a protocol of 147 "TCP/MSRP" is sufficient to indicate that a URI supports chatroom 148 functionality. 150 The "isfocus" feature tag is defined in RFC 3840. The "TCP/MSRP" 151 protocol is defined in RFC 4975. 153 An example OPTIONS response that indicates support for chatroom 154 functionality follows. 156 SIP/2.0 200 OK 157 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 158 ;received=192.0.2.4 159 To: ;tag=93810874 160 From: Alice ;tag=1928301774 161 Call-ID: a84b4c76e66710 162 CSeq: 63104 OPTIONS 163 Contact: ;isfocus 164 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE 165 Accept: application/sdp 166 Content-Type: application/sdp 167 Content-Length: 274 169 v=0 170 o=- 2890844526 2890844527 IN IP4 alice.example.com 171 s=- 172 c=IN IP4 alice.example.com 173 t=0 0 174 m=message 7394 TCP/MSRP * 175 a=accept-types: message/cpim 176 a=accept-wrapped-types: text/plain text/html text/* * 178 2.1.2. Automatic Creation of New Chatroom 180 RFC 4353 and RFC 4579 describe the use of factory URIs for automatic 181 creation of new chatrooms using normal SIP requests. Using such a 182 mechanism, users can create new chatrooms using unique names chosen 183 by the server. These names will typically be random strings of 184 characters. 186 Although not explicitly described, it would also be valid to develop 187 a chatroom server that automatically created a new chatroom whenever 188 an INVITE (or similar) request arrives with a username that doesn't 189 yet correspond to an existing chatroom. Doing so would allow users 190 to choose meaningful chatroom names for automatic creation, albeit at 191 the risk of joining an existing chatroom when the intention was to 192 create a new chatroom. 194 In both cases, the chatroom server may have policy that restricts the 195 ability to automatically create chatrooms to a certain set of users. 196 Currently, there is no standardized mechanism for provisioning such 197 users. 199 See also Section 2.3.1. 201 2.1.3. Joining a Chatroom 203 Joining a chatroom is achieved by an interested user sending an 204 INVITE request to the focus URI with a body that indicates at least 205 one MSRP stream with an "accept-types" that includes "message/cpim". 207 2.1.4. Leaving a Chatroom 209 A user leaves a chatroom by sending a BYE within the dialog that 210 established the chatroom session. 212 2.1.5. Inviting Other Users to a Chatroom 214 Inviting other users to a chatroom can be acheived using REFER 215 requests. This can be done in two ways. 217 One approach to effect an invitation to a chatroom is to send a REFER 218 to the focus URI, which then causes the focus to send an INVITE to 219 the invited user. The invited user can infer that the INVITE request 220 is an invitation to join a chatroom by observing the combination of 221 the presence of "isfocus" on the Contact header field and SDP that 222 includes at least one MSRP stream. This approach has the drawback 223 that the invited user recieves no indication which user invited them 224 to the conference. 226 Alternately one may send a REFER to the invited user that requests 227 that his user agent send an INVITE to the focus URI. This approach 228 has the disadvantage that there the invited party cannot immediately 229 distinguish between such a condition and a request to initiate 230 another type of session, such as a phone call. However, if such 231 distinction is important, the client can employ the OPTIONS approach 232 described in Section 2.1.1 to determine whether the target is a 233 chatroom. 235 See also Section 2.3.11. 237 2.1.6. Removing Other Users from a Chatroom 239 Semantically, a REFER request sent to a focus URI that requests that 240 it send a BYE request to a chatroom user should be interpreted to 241 mean that the focus is to remove the indicated user from the 242 conference. 244 To prevent abuse of such a feature, servers will need to implement 245 policy regarding which users are allowed to perform such an 246 operation. Currently, there is no standardized mechanism for 247 provisioning such users. However, XCON is addressing such issues; 248 see Section 2.3.12. 250 2.1.7. Transition from One-to-One Chat to Chatroom 252 When users are in a one-to-one text chat session, and wish to invite 253 another user into the discussion, it becomes necessary to transition 254 from the discussion into a chatroom. 256 To effect such a transition, one user selects a chatroom (possibly 257 creating a new one, if necessary), enters the selected chatroom, and 258 then sends a REFER to the other user. This REFER request contains a 259 "Replaces" header field, indicating that the chatroom session is 260 replacing the one-to-one text chat session. 262 After such a transition, both users can begin to invite additional 263 users into the chatroom using the mechanisms described in 264 Section 2.1.5 and Section 2.3.11. 266 2.1.8. Chatroom Roster 268 A key aspect of chatrooms is the ability to determine which other 269 users are present, and discover various levels of information 270 regarding such users. Two mechanisms exist that allow such 271 information to be gathered. 273 2.1.8.1. Basic List of Chatroom Users 275 RFC 4575 provides a mechanism for users in a chatroom to learn which 276 users are in the conference. Information available via such a 277 channel include user's AORs, display name, preferred language, and 278 various other attributes. This provides a basic user roster. 280 2.1.8.2. Presence Information 282 In addition to the basic infomation available through RFC 4575, users 283 in a chatroom may wish to discover more detailed presence information 284 about a user. If the information learned through the conference 285 event package includes a user's AOR, then other users may choose to 286 subscribe to that user's presence information by sending SUBSCRIBE 287 requests to the AOR for the "presence" event package. Such an 288 approach has a couple of drawbacks. First, in chatrooms that don't 289 publish users' AORs, such an approach is impossible. Secondly, when 290 users' AORs are made available by the chatroom, any such SUBSCRIBE 291 requests will need to be authorized by the user whose presence is 292 being subscribed to. In large chatrooms, such authorization can 293 become unwieldy. Finally, such grants of permission are likely to be 294 relevant only for the duration of the chatroom, at which point users 295 will need to manually deauthorize subscribers who they do not wish to 296 grant long-term presence authorization to. 298 SIP actually provides all the tools necessary to avoid this 299 situation, although their use in combination with each other has not 300 yet been documented in an RFC. Through a combination of PUBLISH (RFC 301 3903), SUBSCRIBE/NOTIFY (RFC 3265), the presence event package (RFC 302 3856), and list subscriptions (RFC 4662), the chatroom can act as a 303 aggregator and distributor of presence information for users within 304 the context of a chatroom. 306 Under such a system, users would publish the presence information 307 they wish to have presented within a chatroom by sending PUBLISH 308 requests to the chatroom focus URI; these PUBLISH requests would 309 indicate an event package of "presence". Implicit in such 310 publications would be permission to distribute such presence 311 information to any users of the chatroom. Chatrooms can correlate 312 the presence information to the proper user using the "entity" 313 attribute of the tag. 315 Users in a chatroom would then be able to subscribe to the presence 316 event package at the chatroom focus URI, indicating support for the 317 event list extension. The chatroom would then send the presence 318 information it had received from other users via PUBLISH requests in 319 an event list format. 321 This approach allows publication of very rich presence information 322 (and related data) using, for example, RPID (RFC 4480) and PIDF-LO 323 (RFC 4119). 325 2.1.9. Sending Files and Images to a Chatroom 327 MSRP inherently supports sending of arbitrary content in a chat 328 session. The only additional requirements this places on the system 329 is that chatrooms must include '*' in the 'accept-wrapped-types' 330 list, and the they need to be prepared to dispatch large content to 331 all the partcipants in a chatroom. 333 2.2. Partially Supported Features 335 The following features are supported to varying degrees using 336 existing mechanisms defined in published RFCs. 338 2.2.1. Determining of Chatroom Attributes 340 RFC 4575 provides substantial information regarding the attributes of 341 a chatroom. However, some attributes that are available to currently 342 deployed systems -- such as whether a chatroom is moderated, members- 343 only, persistent, or anonymous -- isn't included in the information 344 available via RFC 4575. 346 Note that the information made available via the RFC 4575 mechanism 347 includes continuous updates of changes to chatroom attributes. Users 348 who wish to retrive the information only once and not receive updates 349 when it changes may do so by using the polling mechanism described in 350 RFC 3265. 352 See also Section 2.3.7. 354 2.2.2. Determining of Chatroom User Attributes 356 If the chatroom exposes the AORs of its users, then other users may 357 discover the attributes of such users by sending an OPTIONS request 358 to the user's AOR. This approach does have a couple of drawbacks: 359 the AOR will not always be available through the chatroom; and, even 360 when it is, the OPTIONS request is not guaranteed to reach the same 361 user agent that is currently being used in the chatroom. 363 The ability to learn about user agent capbilities in a chatroom 364 environment is of somewhat limited utility in any case, so the 365 inability to reliably query for this information seems to be 366 unimportant. 368 2.3. Features to be Supported by XCON Protocols 370 The following features are supported or planned to be supported in 371 the model and protocols being defined by the XCON working group. The 372 preponderence of the concepts in this section are covered by 373 draft-ietf-xcon-framework. 375 2.3.1. Explicit Creation of New Chatroom 377 The XCON conference control protocol will include the ability to 378 create new conference rooms via cloning of a system blueprint 379 conference and via cloning of existing conferences (whether active or 380 not). 382 See also Section 2.1.2. 384 2.3.2. Manipulation of Existing Chatrooms 386 The XCON conference control protocol is used to modify conferences, 387 both active and inactive. 389 2.3.3. Setting Chatroom Topic 391 The XCON conference control protocol is used to modify conferences, 392 including the subject (topic), room description, and keywords. 394 2.3.4. Assignment of Roles and Permissions 396 The XCON data model includes five roles (administrator, creator, 397 moderator, participant, and observer). These five roles generally 398 map to the various roles provided by existing chatroom systems in a 399 straightforward fashion. The XCON conference control protocol is 400 used to assign roles to specific users. 402 Additionally, XCON will be defining a configurable permissions model 403 that defines which XCON conference control protocol operations each 404 role is allowed to perform (and, where applicable, to which roles 405 they are allowed to perform them). 407 2.3.5. Explicit Destruction of Existing Chatrooms 409 There are a number of mechanisms that can be used to destroy a 410 conference room. Some rooms are defined to have a specified end 411 time, at which point the chatroom will disappear. Additionally, 412 chatrooms may (as a matter of policy) disappear once they are vacant; 413 this will often be the case for automatically created conference 414 rooms (see Section 2.1.2). 416 Additionally, the XCON conference control protocol will contain 417 operations that can explicitly destroy a conference room. 419 2.3.6. Discovery of Existing Chatrooms 421 The XCON conference control protocol is planned to include the 422 ability to query for blueprints, inactive conferences, and active 423 conferences. Such a mechanism can be used to find all conferences 424 available on a server. It is not clear whether the current 425 mechanisms are planned to include the ability to filter such results 426 to conferences that support MSRP as a media type. 428 2.3.7. Determining of Chatroom Attributes 430 The event package chartered within the XCON working group, based on 431 RFC 4575, provides comprehensive conference information, including 432 that information discussed in Section 2.2.1 as being missing from RFC 433 4575. 435 2.3.8. Members-Only Chatrooms 437 Members-only chatrooms are acheived by using the XCON conference 438 control protocol to set the to 439 "closedAuthenticated", and indicating allowed members in the 440 . 442 2.3.9. Maximum User Count 444 Limiting the number of users is effected using the XCON conference 445 control protocol to set the to the desired 446 value. 448 2.3.10. Chatroom Locking 450 Locking a chatroom (that is, preventing any additional members from 451 joining) can be performed by using the XCON conference control 452 protocol to set the element to "true". 454 2.3.11. Inviting Other Users to a Chatroom 456 The XCON conference control protocol will include the ability to add 457 desired users to a dial-out or "refer to" list. Unfortunately, such 458 approaches do not currently allow the invitee to know which user has 459 invited them to the conference. For this reason, the second approach 460 described in Section 2.1.5 may be preferable. 462 2.3.12. Removing Other Users from a Chatroom 464 The XCON conference control protocol will include operations to 465 remove users from a conference. 467 See also Section 2.1.6. 469 2.3.13. Private Messages 471 It is occasionally desirable to send a private message to one or more 472 chatroom users without broadcasting them to all the users in a 473 chatroom. 475 Private messages can be effected using XCON mechanisms by creating a 476 sidebar that includes the desired target(s) of the private message 477 and sending the private message to that sidebar. After one or more 478 such private messages, the sidebar is then destroyed. This approach 479 is described in more detail in draft-boulton-xcon-msrp-conferencing. 481 See also Section 2.4.11. 483 2.4. Features Requiring Additional Specification 485 The following features are not clearly covered by existing RFCs or by 486 work chartered within the XCON working group. 488 2.4.1. Discovery of Factory URIs 490 The current system does not include the ability to discover factory 491 URIs. Ideally, this information could be made available on a per- 492 domain or per-host basis. One approach that provides this level of 493 flexibility would be the specification of a DNS mechanism that allows 494 lookup of the chatroom focus URI via NAPTR records. Other approaches 495 are possible as well. 497 2.4.2. Discovery of Client Chatroom Support 499 Although discovering that a URI is a chatroom focus is a fairly 500 straightforward excercise, it is difficult to ascertain that another 501 user has reasonable support for the features required to participate 502 in a chatroom in any useful way (e.g., MSRP and CPIM). Consequently, 503 it is difficult for one user to determine whether another user can be 504 invited to a chatroom and expected to be able to join in any 505 meaningful way. 507 Probably the most flexible approach to solve this problem would be 508 the definition of new feature tags for MSRP and CPIM support. 509 Support could then be detected via OPTIONS responses; further, users 510 (and focuses) could make use of the "caller prefs" mechanism to 511 preferentially route chatroom-related requests to an appropriate user 512 agent. 514 2.4.3. Password-Protected Chatrooms 516 The current framework described in XCON uses user authentication for 517 admissions control. However, some deployed systems instead use a 518 single, chatroom-wide password that can be used to enter a chatroom. 519 This allows users to disseminate the password as a kind of invitation 520 token without explicitly provisioning the allowed users into the 521 chatroom system. In many ways, it is similar to the PIN already 522 defined within XCON for authorizing PSTN users. 524 The SIP authentication mechanism provides a mechanism via which users 525 can be asked for a password; however, there is no mechanism currently 526 under discussion that allows a standardized way to provision such a 527 password. If we decide to add this feature, it will require a new 528 field in the XCON data model ("conference password"), and 529 accompanying operations to set and modify this password. 531 2.4.4. Private and Semi-Private Chatrooms 533 Currently, the XCON model allows users to be marked individually as 534 anonymous or not via their corresponding tag. 535 Some systems, however, include a chatroom-wide setting that can be 536 used to specify that all users in a chatroom are either completely 537 anonymous (private), or anonymous to all users with equal or lesser 538 permissions (semi-private). 540 If we agree to emulate this functionality, we will need to add 541 another element to the XCON data model, at the conference data model, 542 that specifies these modes of operation. We will also need to define 543 how these conference-wide anonymity specifications interact with per- 544 user anonymity settings. 546 2.4.5. Banned Users 548 In addition to removing specific users from a conference ("kicking" a 549 user out), most deployed systems permit the specification of "banned" 550 users. Such banned users are prevented from re-joining the chatroom 551 until they have been un-banned. This functionality is not possible 552 within the current XCON data model. 554 Currently, the XCON data model allows three modes of operation: (1) 555 authenticated users on an "allowed users" list, (2) all authenticated 556 users, and (3) all users. Banned users obviously make no sense in 557 the third case -- without authentication, banning a user is a no-op. 558 In the first case, banning of a user can be accomplished by merely 559 removing them from the "allowed users" list. The second case is the 560 one that requres additional work if we are to support the concept of 561 banning users. 563 If we wish to support banning of users from a chatroom, one approach 564 would be to modify the semantics of the of 565 "openAuthenticated" to take into consideration the users included in 566 a (not yet defined) , rejecting any users in the 567 list. 569 2.4.6. Nicknames 571 The topic of nicknames in chatrooms is currently the focus of furious 572 discussion in the SIMPLE working group. Interested readers are 573 referred to the SIMPLE working group mailing list archives at 574 http://www1.ietf.org/mail-archive/web/simple/current/index.html 576 2.4.7. Reasons Associated with Operations 578 Several existing systems allow the inclusion of reason phrases in 579 certain operations (kicking people out of chatrooms, banning people 580 from chatrooms, leaving chatrooms, destroying chatrooms, etc). When 581 the associated operation is performed, these reason phrases are 582 delivered to the chatroom users. 584 If emulation of this ability is desired, two channels are needed: one 585 to deliver the reason from the user taking the action to the chatroom 586 (e.g., in the XCON conference control protocol), and another channel 587 to deliver the reason to the various chatroom users. The addition of 588 a human-readable "reason" field to appropriate XCON conference 589 control protocol requests is straightforward. Delivery of such 590 information to the chatroom users is less so. One potential approach 591 would involve the chatroom sending out instant messages to all the 592 chatroom users, with a CPIM "From" header indicating the chatroom 593 identity itself; the body of the message would include the action 594 taken, the name of the user taking the action, and the reason for the 595 action. Other approaches for delivering this information are also 596 possible, including the definition of a new MIME type to deliver the 597 information semantically. 599 2.4.8. Alternate Venues for Terminated Chatrooms 601 One mechanism that exists in some current chatroom systems is the 602 ability to specify an alternate venue for a chatroom that has been 603 closed. This alternate venue is communicated to chatroom users at 604 the end of the conference (generally in a way that allows clients to 605 automatically join the new chatroom), and can also be used to 606 redirect users who attempt to join the chatroom after it has ceased 607 to exist. 609 2.4.9. Discussion History 611 When users join a chatroom, most chatroom systems will deliver the 612 last several messages to the user, to provide them context for the 613 ongoing conversation. Although chatroom systems can do this 614 unilaterally by simply replaying the messages as if they were just 615 sent, such a solution misses two minor attributes provided by some 616 current systems. 618 2.4.9.1. Marking of Messages as History 620 Currently, neither MSRP nor CPIM provide a means to mark a message as 621 being part of a history replay as opposed to a "live" message that 622 was just received from its author. Some currently deployed systems 623 do include such an indiation in the protocol, allowing clients to 624 render such historical messages in a way that allows their users to 625 distinguish between the history and the live conversation. 627 If we wish to replicate such functionality, we will need to add an 628 indication to either MSRP or CPIM that indicates that a message is 629 part of a history replay. The use of the "Date" field in CPIM might 630 be sufficient to indicate which messages are historic, as long as the 631 client that is joining has some other mechanism for determination of 632 what time the chatroom beleives it to be (e.g., using the "Date" 633 header field in SIP messages received from the chatroom). 635 2.4.9.2. Client Control of History Replay Size 637 Some currently deployed systems allow client control over how much 638 history is to be replayed upon joining the conference. 640 Because this information must be exchanged while a user is joining a 641 chatroom (that is, it is not a parameter that can be set after 642 joining), adding this feature will likely require adding support in 643 the call control protocol (i.e., SIP and/or SDP). One fairly obvious 644 way to add such support would be the addition of a new SDP attribute 645 for MSRP media lines; something like; "a=chatroom-history:2048". 647 2.4.10. Chatroom Logging 649 Although the logging of messages exchanged in a chatroom is something 650 that chatroom servers can perform unilaterally, the current XCON/ 651 SIMPLE solutions do not include the ability to control or indicate 652 information about such logging. 654 2.4.10.1. Control Over Chatroom Logging 656 Ideally, certain roles in a chatroom should have the ability to 657 indicate whether the contents of a chatroom should be logged. 658 Support for such an ability would likely include the addition of a 659 new, boolean tag to the XCON data model, along with operations for 660 modifying the value of the tag in the XCON conference control 661 protocol. 663 2.4.10.2. Indication of Chatroom Logging 665 Additionally, some current systems allow the ability to indicate 666 whether a given chatroom is being logged. The addition of the 667 boolean tag discussed above would provide chatroom users with the 668 ability to discern whether a chatroom was being logged to a 669 persistant archive. 671 2.4.10.3. Indication of Chatroom Log Archive Location 673 Finally, some systems include the ablity for clients to access the 674 on-line archive of a chatroom log from within the context of their 675 chatroom client. (e.g., a menu selection or button that brings up a 676 the chatroom log). One approach that would provide such 677 functionality would be the addition to the XCON data model of an 678 element that indicates a URL that the client can dereference to find 679 the chatroom log archive. This would potentially be an HTTP URL, 680 although other types (IMAP?) might be appropriate as well. 682 2.4.11. Private Messages 684 Because all chatroom messages are wrapped in CPIM, it is potentially 685 possible to define a mechanism that uses the CPIM "To" header to 686 indicate that a message sent to the chatroom is intended for one or 687 more specified users, instead of being broadcast to the entire 688 chatroom. This mechanism is described in detail in 689 draft-niemi-simple-chat. 691 See also Section 2.3.13. 693 2.4.12. Detailed User Registration 695 Some chatroom systems allow -- and some require -- registration of 696 detailed information about a user before they are allowed to join a 697 chatroom. Currently, the XCON data model does not include a way to 698 store persistent information (name, nickname, email address, etc.) 699 about users who are not actively part of an ongoing chatroom 700 sesssion. 702 One potential approach that would allow this kind of mechanism would 703 be (1) adding elements to the / element 704 in the XCON data model that store information about users who are 705 associated with the chatroom, but not presently particpating in it 706 (these elements would contain the aforementioned information); (2) 707 setting permissions on the operations for adding users to the 708 so that anyone can add such elements (as long as 709 they can authenticate themselves as owning the URI present in the 710 entry); and (3) setting the chatroom to "closedAuthenticated". This 711 would then require users to "register" with a chatroom before 712 joining. 714 An interesting side-effect of such an approach is that is would allow 715 persistent reservation of a specified nickname within a chatroom. It 716 would also allow for system assignment of specific nicknames to 717 users. 719 2.4.13. Chatroom Directories 721 Most or all current chatroom systems allow users to list and search 722 chatrooms currently available on a server. This can be supported by 723 the XCON conference control protocol; however, such operations aren't 724 clearly part of the XCON data model (nor do the need to be). 726 Additionally, some systems allow chatrooms listed in a directory to 727 be stored in a heirarchical tree of chatrooms and folders. This is 728 very important for systems that may have an unmanageably large number 729 of chatrooms on a single server. 731 2.4.14. Subscribing to Phrases and Events 733 Some chatroom servers include the ablity to subscribe to certain 734 words and phrases -- either on a chatroom level, or on a server level 735 -- and receive notification when such words or phrases are used in a 736 chatroom. 738 Additionally, some chatroom servers include the ability to be 739 notified when certain events occur (chatroom reserved, new chatroom 740 created, chatroom destroyed, etc). These events generally occur at a 741 server level (instead of at the conference level addressed by the 742 conference event package). 744 Support of such features will almost ceratinly take the form of 745 defining one or more RFC 3265 event packages. 747 2.4.15. Notification of Unread Messages 749 Some chatroom servers support the ability of users to monitor 750 chatrooms for messages that they have not yet read -- typically 751 because the user was not present in the chatroom when the message was 752 sent. Users then receive notification of such unread messages, 753 either immediately, or the next time that they log into the system. 755 This is similar to the problem addressed by the "message waiting 756 indicator" event package; however, the notion of "unread messages" in 757 this case is not uniquely identified by a single URI -- User A may 758 well have unread messages in the chatroom "sip:nerf@example.com", 759 while User B may not. Consequently, support for this type of 760 functionality will require either a new RFC 3265 event package, or 761 addition of refining information to the existing "message waiting 762 indication" event package. 764 2.4.16. Designation of Chatroom Language 766 The XCON data model does not currently provide a mechanism for 767 indicating the predominant language that is expected to be employed 768 within a conference. This is likely a useful addition to the data 769 model. 771 2.4.17. User Role Change Requests 773 The XCON conference control protocol will contain commands that allow 774 assignment of specific roles to specific users. Some existing 775 systems additionally include the ability for users to request a role 776 with permissions higher than their current role. The moderator (or 777 owner or administrator) is then notified of such a request, which can 778 be granted or denied. So far, models surrounding the XCON conference 779 control protocol have generally modeled it as a client/server 780 protocol, in which User Agents send requests to the focus, and 781 receive results from those requests in response. Such a model does 782 not support notification of the moderator that a user wishes to 783 change their role in the conference. 785 One approach that can be used to effect such a system would be the 786 inclusion of an element in the XCON conference event package that 787 indicates a desired role for every user in the conference. So, for 788 example, a participant who wishes to be a moderator would appear in 789 the roster as: 791 792 John Smith 793 794 ... 795 796 false 797 798 participant 799 800 801 moderator 802 803 ... 804 806 User agents for moderators (and owners and administrators) can then 807 monior the "" lists, and interactively query their 808 users when such lists exist and vary from the corresponding "" 809 list. In addition to granting such permissions, the XCON conference 810 control protocol would ideally also include the ability to explicitly 811 reject such requests, thereby clearing the "" entry. 813 2.4.18. Per-User Approval to Join by Moderator 815 Similar to the ability to request elevated privledges, it may be 816 useful to have chatrooms with closed membership lists, but allow new 817 users not on the membership list to be approved by the moderator 818 prior to joining. This has the same problem as requesting elevated 819 permissions, but with a twist: since users cannot manipulate 820 conference state (e.g., to set their desired role) until after they 821 have been granted access to the conference, the solution employed for 822 permissions cannot be applied directly to this problem. 824 Fundamentally, this problem is very similar to the permissions 825 required to watch a user's permission information. The IETF elected 826 to solve that problem via the "watcher information" template event 827 package defined by RFC 3857. If we decide to solve this problem, the 828 solution will likely be similar. In fact, one potential approach 829 that provides the ability to perform such screening involves the 830 moderator subscribing to the winfo information for the conference 831 event package. If the moderator sees someone attempting to subscribe 832 to the event package who is not authorized to be in the chatroom, 833 then he can add that user to the allowed user list at an appropriate 834 level of permissions (e.g., observer). The user can then use the 835 mechanism described in the preceding section to request the desired 836 level of participation. 838 3. Security Considerations 840 This analysis does not inherently have security implications; 841 however, many of the suggested mechanisms do. If such mechanisms are 842 specified, their security considerations will be addressed as part of 843 such specification. 845 4. IANA Considerations 847 This document has no IANA implications. 849 5. References 850 Author's Address 852 Adam Roach 853 Estacado Systems 854 17210 Campbell Rd. 855 Suite 250 856 Dallas, TX 75252 857 US 859 Phone: sip:adam@estacado.net 860 Email: adam@estacado.net 862 Intellectual Property Statement 864 The IETF takes no position regarding the validity or scope of any 865 Intellectual Property Rights or other rights that might be claimed to 866 pertain to the implementation or use of the technology described in 867 this document or the extent to which any license under such rights 868 might or might not be available; nor does it represent that it has 869 made any independent effort to identify any such rights. Information 870 on the procedures with respect to rights in RFC documents can be 871 found in BCP 78 and BCP 79. 873 Copies of IPR disclosures made to the IETF Secretariat and any 874 assurances of licenses to be made available, or the result of an 875 attempt made to obtain a general license or permission for the use of 876 such proprietary rights by implementers or users of this 877 specification can be obtained from the IETF on-line IPR repository at 878 http://www.ietf.org/ipr. 880 The IETF invites any interested party to bring to its attention any 881 copyrights, patents or patent applications, or other proprietary 882 rights that may cover technology that may be required to implement 883 this standard. Please address the information to the IETF at 884 ietf-ipr@ietf.org. 886 Disclaimer of Validity 888 This document and the information contained herein are provided on an 889 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 890 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 891 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 892 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 893 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 894 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 896 Copyright Statement 898 Copyright (C) The IETF Trust (2007). This document is subject to the 899 rights, licenses and restrictions contained in BCP 78, and except as 900 set forth therein, the authors retain all their rights. 902 Acknowledgment 904 Funding for the RFC Editor function is currently provided by the 905 Internet Society.