XCON WG A. B. Roach Internet-Draft Estacado Systems Expires: February 17, 2008 August 16, 2007 An Analysis of Feature Parity Between XCON/SIMPLE-Based Chatrooms and Other Chatrooms draft-roach-xcon-chatroom-analysis-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides an overview of the features available in currently deployed text chatroom software, and analyzes which of these features can be acheived using IETF-defined protocols. In the case of features that have no clear IETF-defined mechanism, this document provides high-level recommendations for work to implement such features. Roach Expires February 17, 2008 [Page 1]
Internet-Draft Chatroom Gap Analysis August 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Feature Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Fully Supported Features . . . . . . . . . . . . . . . . . 4 2.1.1. Discovery of Support for Chatrooms . . . . . . . . . . 4 2.1.2. Automatic Creation of New Chatroom . . . . . . . . . . 5 2.1.3. Joining a Chatroom . . . . . . . . . . . . . . . . . . 6 2.1.4. Leaving a Chatroom . . . . . . . . . . . . . . . . . . 6 2.1.5. Inviting Other Users to a Chatroom . . . . . . . . . . 6 2.1.6. Removing Other Users from a Chatroom . . . . . . . . . 6 2.1.7. Transition from One-to-One Chat to Chatroom . . . . . 7 2.1.8. Chatroom Roster . . . . . . . . . . . . . . . . . . . 7 2.1.9. Sending Files and Images to a Chatroom . . . . . . . . 8 2.2. Partially Supported Features . . . . . . . . . . . . . . . 8 2.2.1. Determining of Chatroom Attributes . . . . . . . . . . 8 2.2.2. Determining of Chatroom User Attributes . . . . . . . 9 2.3. Features to be Supported by XCON Protocols . . . . . . . . 9 2.3.1. Explicit Creation of New Chatroom . . . . . . . . . . 9 2.3.2. Manipulation of Existing Chatrooms . . . . . . . . . . 9 2.3.3. Setting Chatroom Topic . . . . . . . . . . . . . . . . 10 2.3.4. Assignment of Roles and Permissions . . . . . . . . . 10 2.3.5. Explicit Destruction of Existing Chatrooms . . . . . . 10 2.3.6. Discovery of Existing Chatrooms . . . . . . . . . . . 10 2.3.7. Determining of Chatroom Attributes . . . . . . . . . . 10 2.3.8. Members-Only Chatrooms . . . . . . . . . . . . . . . . 11 2.3.9. Maximum User Count . . . . . . . . . . . . . . . . . . 11 2.3.10. Chatroom Locking . . . . . . . . . . . . . . . . . . . 11 2.3.11. Inviting Other Users to a Chatroom . . . . . . . . . . 11 2.3.12. Removing Other Users from a Chatroom . . . . . . . . . 11 2.3.13. Private Messages . . . . . . . . . . . . . . . . . . . 11 2.4. Features Requiring Additional Specification . . . . . . . 12 2.4.1. Discovery of Factory URIs . . . . . . . . . . . . . . 12 2.4.2. Discovery of Client Chatroom Support . . . . . . . . . 12 2.4.3. Password-Protected Chatrooms . . . . . . . . . . . . . 12 2.4.4. Private and Semi-Private Chatrooms . . . . . . . . . . 13 2.4.5. Banned Users . . . . . . . . . . . . . . . . . . . . . 13 2.4.6. Nicknames . . . . . . . . . . . . . . . . . . . . . . 13 2.4.7. Reasons Associated with Operations . . . . . . . . . . 13 2.4.8. Alternate Venues for Terminated Chatrooms . . . . . . 14 2.4.9. Discussion History . . . . . . . . . . . . . . . . . . 14 2.4.10. Chatroom Logging . . . . . . . . . . . . . . . . . . . 15 2.4.11. Private Messages . . . . . . . . . . . . . . . . . . . 16 2.4.12. Detailed User Registration . . . . . . . . . . . . . . 16 2.4.13. Chatroom Directories . . . . . . . . . . . . . . . . . 16 2.4.14. Subscribing to Phrases and Events . . . . . . . . . . 17 2.4.15. Notification of Unread Messages . . . . . . . . . . . 17 2.4.16. Designation of Chatroom Language . . . . . . . . . . . 17 Roach Expires February 17, 2008 [Page 2]
Internet-Draft Chatroom Gap Analysis August 2007 2.4.17. User Role Change Requests . . . . . . . . . . . . . . 18 2.4.18. Per-User Approval to Join by Moderator . . . . . . . . 18 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Roach Expires February 17, 2008 [Page 3]
Internet-Draft Chatroom Gap Analysis August 2007 1. Introduction This document attempts to collect a complete list of features supported by various chatroom systems in use, and determine which ones can be supported by using the protocols defined by and under definition within the IETF. Note that related work has been undertaken in draft-niemi-simple-chat and draft-boulton-xcon-msrp-conferencing. This work is intended to complement such ongoing work. In particular, this document does not seek to define protocol extensions (although it does make some recommendations about how protocols might be extended to implement certain features). This document also attempts to exhaustively list features of currently deployed chatroom servers, and analyze where any gaps may lie between such features and what can be achieved using IETF protocols. It is not the author's expectation that this document will be adopted by any working group, nor that it will be published as an RFC. Its goal is to identify where additional work may be required in the IETF to define a complete chatroom system based on protocols defined in the SIP, SIMPLE and XCON working groups, while living up to user expectations in terms of features offered. 2. Feature Analysis The following sections contain descriptions of features available in currently deployed chatroom solutions. They are split according to the level of support available via IETF protocols. 2.1. Fully Supported Features The following features are supported using existing mechanisms defined in published RFCs. In some cases, the mechanism is explicitly supported; in others, the mechanisms already exist, but may not have been specifically described in relation to chat rooms. 2.1.1. Discovery of Support for Chatrooms Discovering whether a server supports chatroom functionality for a particular URI can be achieved by sending an OPTIONS request to the URI. The combination of an "isfocus" feature tag on the "Contact" header field and at least one "m=" line containing a protocol of "TCP/MSRP" is sufficient to indicate that a URI supports chatroom functionality. The "isfocus" feature tag is defined in RFC 3840. The "TCP/MSRP" Roach Expires February 17, 2008 [Page 4]
Internet-Draft Chatroom Gap Analysis August 2007 protocol is defined in RFC 4975. An example OPTIONS response that indicates support for chatroom functionality follows. SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: <sip:cr@chicago.com>;tag=93810874 From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:cr@chicago.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Content-Type: application/sdp Content-Length: 274 v=0 o=- 2890844526 2890844527 IN IP4 alice.example.com s=- c=IN IP4 alice.example.com t=0 0 m=message 7394 TCP/MSRP * a=accept-types: message/cpim a=accept-wrapped-types: text/plain text/html text/* * 2.1.2. Automatic Creation of New Chatroom RFC 4353 and RFC 4579 describe the use of factory URIs for automatic creation of new chatrooms using normal SIP requests. Using such a mechanism, users can create new chatrooms using unique names chosen by the server. These names will typically be random strings of characters. Although not explicitly described, it would also be valid to develop a chatroom server that automatically created a new chatroom whenever an INVITE (or similar) request arrives with a username that doesn't yet correspond to an existing chatroom. Doing so would allow users to choose meaningful chatroom names for automatic creation, albeit at the risk of joining an existing chatroom when the intention was to create a new chatroom. In both cases, the chatroom server may have policy that restricts the ability to automatically create chatrooms to a certain set of users. Currently, there is no standardized mechanism for provisioning such users. Roach Expires February 17, 2008 [Page 5]
Internet-Draft Chatroom Gap Analysis August 2007 See also Section 2.3.1. 2.1.3. Joining a Chatroom Joining a chatroom is achieved by an interested user sending an INVITE request to the focus URI with a body that indicates at least one MSRP stream with an "accept-types" that includes "message/cpim". 2.1.4. Leaving a Chatroom A user leaves a chatroom by sending a BYE within the dialog that established the chatroom session. 2.1.5. Inviting Other Users to a Chatroom Inviting other users to a chatroom can be acheived using REFER requests. This can be done in two ways. One approach to effect an invitation to a chatroom is to send a REFER to the focus URI, which then causes the focus to send an INVITE to the invited user. The invited user can infer that the INVITE request is an invitation to join a chatroom by observing the combination of the presence of "isfocus" on the Contact header field and SDP that includes at least one MSRP stream. This approach has the drawback that the invited user recieves no indication which user invited them to the conference. Alternately one may send a REFER to the invited user that requests that his user agent send an INVITE to the focus URI. This approach has the disadvantage that there the invited party cannot immediately distinguish between such a condition and a request to initiate another type of session, such as a phone call. However, if such distinction is important, the client can employ the OPTIONS approach described in Section 2.1.1 to determine whether the target is a chatroom. See also Section 2.3.11. 2.1.6. Removing Other Users from a Chatroom Semantically, a REFER request sent to a focus URI that requests that it send a BYE request to a chatroom user should be interpreted to mean that the focus is to remove the indicated user from the conference. To prevent abuse of such a feature, servers will need to implement policy regarding which users are allowed to perform such an operation. Currently, there is no standardized mechanism for Roach Expires February 17, 2008 [Page 6]
Internet-Draft Chatroom Gap Analysis August 2007 provisioning such users. However, XCON is addressing such issues; see Section 2.3.12. 2.1.7. Transition from One-to-One Chat to Chatroom When users are in a one-to-one text chat session, and wish to invite another user into the discussion, it becomes necessary to transition from the discussion into a chatroom. To effect such a transition, one user selects a chatroom (possibly creating a new one, if necessary), enters the selected chatroom, and then sends a REFER to the other user. This REFER request contains a "Replaces" header field, indicating that the chatroom session is replacing the one-to-one text chat session. After such a transition, both users can begin to invite additional users into the chatroom using the mechanisms described in Section 2.1.5 and Section 2.3.11. 2.1.8. Chatroom Roster A key aspect of chatrooms is the ability to determine which other users are present, and discover various levels of information regarding such users. Two mechanisms exist that allow such information to be gathered. 2.1.8.1. Basic List of Chatroom Users RFC 4575 provides a mechanism for users in a chatroom to learn which users are in the conference. Information available via such a channel include user's AORs, display name, preferred language, and various other attributes. This provides a basic user roster. 2.1.8.2. Presence Information In addition to the basic infomation available through RFC 4575, users in a chatroom may wish to discover more detailed presence information about a user. If the information learned through the conference event package includes a user's AOR, then other users may choose to subscribe to that user's presence information by sending SUBSCRIBE requests to the AOR for the "presence" event package. Such an approach has a couple of drawbacks. First, in chatrooms that don't publish users' AORs, such an approach is impossible. Secondly, when users' AORs are made available by the chatroom, any such SUBSCRIBE requests will need to be authorized by the user whose presence is being subscribed to. In large chatrooms, such authorization can become unwieldy. Finally, such grants of permission are likely to be relevant only for the duration of the chatroom, at which point users Roach Expires February 17, 2008 [Page 7]
Internet-Draft Chatroom Gap Analysis August 2007 will need to manually deauthorize subscribers who they do not wish to grant long-term presence authorization to. SIP actually provides all the tools necessary to avoid this situation, although their use in combination with each other has not yet been documented in an RFC. Through a combination of PUBLISH (RFC 3903), SUBSCRIBE/NOTIFY (RFC 3265), the presence event package (RFC 3856), and list subscriptions (RFC 4662), the chatroom can act as a aggregator and distributor of presence information for users within the context of a chatroom. Under such a system, users would publish the presence information they wish to have presented within a chatroom by sending PUBLISH requests to the chatroom focus URI; these PUBLISH requests would indicate an event package of "presence". Implicit in such publications would be permission to distribute such presence information to any users of the chatroom. Chatrooms can correlate the presence information to the proper user using the "entity" attribute of the <presence> tag. Users in a chatroom would then be able to subscribe to the presence event package at the chatroom focus URI, indicating support for the event list extension. The chatroom would then send the presence information it had received from other users via PUBLISH requests in an event list format. This approach allows publication of very rich presence information (and related data) using, for example, RPID (RFC 4480) and PIDF-LO (RFC 4119). 2.1.9. Sending Files and Images to a Chatroom MSRP inherently supports sending of arbitrary content in a chat session. The only additional requirements this places on the system is that chatrooms must include '*' in the 'accept-wrapped-types' list, and the they need to be prepared to dispatch large content to all the partcipants in a chatroom. 2.2. Partially Supported Features The following features are supported to varying degrees using existing mechanisms defined in published RFCs. 2.2.1. Determining of Chatroom Attributes RFC 4575 provides substantial information regarding the attributes of a chatroom. However, some attributes that are available to currently deployed systems -- such as whether a chatroom is moderated, members- Roach Expires February 17, 2008 [Page 8]
Internet-Draft Chatroom Gap Analysis August 2007 only, persistent, or anonymous -- isn't included in the information available via RFC 4575. Note that the information made available via the RFC 4575 mechanism includes continuous updates of changes to chatroom attributes. Users who wish to retrive the information only once and not receive updates when it changes may do so by using the polling mechanism described in RFC 3265. See also Section 2.3.7. 2.2.2. Determining of Chatroom User Attributes If the chatroom exposes the AORs of its users, then other users may discover the attributes of such users by sending an OPTIONS request to the user's AOR. This approach does have a couple of drawbacks: the AOR will not always be available through the chatroom; and, even when it is, the OPTIONS request is not guaranteed to reach the same user agent that is currently being used in the chatroom. The ability to learn about user agent capbilities in a chatroom environment is of somewhat limited utility in any case, so the inability to reliably query for this information seems to be unimportant. 2.3. Features to be Supported by XCON Protocols The following features are supported or planned to be supported in the model and protocols being defined by the XCON working group. The preponderence of the concepts in this section are covered by draft-ietf-xcon-framework. 2.3.1. Explicit Creation of New Chatroom The XCON conference control protocol will include the ability to create new conference rooms via cloning of a system blueprint conference and via cloning of existing conferences (whether active or not). See also Section 2.1.2. 2.3.2. Manipulation of Existing Chatrooms The XCON conference control protocol is used to modify conferences, both active and inactive. Roach Expires February 17, 2008 [Page 9]
Internet-Draft Chatroom Gap Analysis August 2007 2.3.3. Setting Chatroom Topic The XCON conference control protocol is used to modify conferences, including the subject (topic), room description, and keywords. 2.3.4. Assignment of Roles and Permissions The XCON data model includes five roles (administrator, creator, moderator, participant, and observer). These five roles generally map to the various roles provided by existing chatroom systems in a straightforward fashion. The XCON conference control protocol is used to assign roles to specific users. Additionally, XCON will be defining a configurable permissions model that defines which XCON conference control protocol operations each role is allowed to perform (and, where applicable, to which roles they are allowed to perform them). 2.3.5. Explicit Destruction of Existing Chatrooms There are a number of mechanisms that can be used to destroy a conference room. Some rooms are defined to have a specified end time, at which point the chatroom will disappear. Additionally, chatrooms may (as a matter of policy) disappear once they are vacant; this will often be the case for automatically created conference rooms (see Section 2.1.2). Additionally, the XCON conference control protocol will contain operations that can explicitly destroy a conference room. 2.3.6. Discovery of Existing Chatrooms The XCON conference control protocol is planned to include the ability to query for blueprints, inactive conferences, and active conferences. Such a mechanism can be used to find all conferences available on a server. It is not clear whether the current mechanisms are planned to include the ability to filter such results to conferences that support MSRP as a media type. 2.3.7. Determining of Chatroom Attributes The event package chartered within the XCON working group, based on RFC 4575, provides comprehensive conference information, including that information discussed in Section 2.2.1 as being missing from RFC 4575. Roach Expires February 17, 2008 [Page 10]
Internet-Draft Chatroom Gap Analysis August 2007 2.3.8. Members-Only Chatrooms Members-only chatrooms are acheived by using the XCON conference control protocol to set the <user-admission-policy> to "closedAuthenticated", and indicating allowed members in the <allowed-users-list>. 2.3.9. Maximum User Count Limiting the number of users is effected using the XCON conference control protocol to set the <maximum-user-count> to the desired value. 2.3.10. Chatroom Locking Locking a chatroom (that is, preventing any additional members from joining) can be performed by using the XCON conference control protocol to set the <locked> element to "true". 2.3.11. Inviting Other Users to a Chatroom The XCON conference control protocol will include the ability to add desired users to a dial-out or "refer to" list. Unfortunately, such approaches do not currently allow the invitee to know which user has invited them to the conference. For this reason, the second approach described in Section 2.1.5 may be preferable. 2.3.12. Removing Other Users from a Chatroom The XCON conference control protocol will include operations to remove users from a conference. See also Section 2.1.6. 2.3.13. Private Messages It is occasionally desirable to send a private message to one or more chatroom users without broadcasting them to all the users in a chatroom. Private messages can be effected using XCON mechanisms by creating a sidebar that includes the desired target(s) of the private message and sending the private message to that sidebar. After one or more such private messages, the sidebar is then destroyed. This approach is described in more detail in draft-boulton-xcon-msrp-conferencing. See also Section 2.4.11. Roach Expires February 17, 2008 [Page 11]
Internet-Draft Chatroom Gap Analysis August 2007 2.4. Features Requiring Additional Specification The following features are not clearly covered by existing RFCs or by work chartered within the XCON working group. 2.4.1. Discovery of Factory URIs The current system does not include the ability to discover factory URIs. Ideally, this information could be made available on a per- domain or per-host basis. One approach that provides this level of flexibility would be the specification of a DNS mechanism that allows lookup of the chatroom focus URI via NAPTR records. Other approaches are possible as well. 2.4.2. Discovery of Client Chatroom Support Although discovering that a URI is a chatroom focus is a fairly straightforward excercise, it is difficult to ascertain that another user has reasonable support for the features required to participate in a chatroom in any useful way (e.g., MSRP and CPIM). Consequently, it is difficult for one user to determine whether another user can be invited to a chatroom and expected to be able to join in any meaningful way. Probably the most flexible approach to solve this problem would be the definition of new feature tags for MSRP and CPIM support. Support could then be detected via OPTIONS responses; further, users (and focuses) could make use of the "caller prefs" mechanism to preferentially route chatroom-related requests to an appropriate user agent. 2.4.3. Password-Protected Chatrooms The current framework described in XCON uses user authentication for admissions control. However, some deployed systems instead use a single, chatroom-wide password that can be used to enter a chatroom. This allows users to disseminate the password as a kind of invitation token without explicitly provisioning the allowed users into the chatroom system. In many ways, it is similar to the PIN already defined within XCON for authorizing PSTN users. The SIP authentication mechanism provides a mechanism via which users can be asked for a password; however, there is no mechanism currently under discussion that allows a standardized way to provision such a password. If we decide to add this feature, it will require a new field in the XCON data model ("conference password"), and accompanying operations to set and modify this password. Roach Expires February 17, 2008 [Page 12]
Internet-Draft Chatroom Gap Analysis August 2007 2.4.4. Private and Semi-Private Chatrooms Currently, the XCON model allows users to be marked individually as anonymous or not via their corresponding <provide-anonymity> tag. Some systems, however, include a chatroom-wide setting that can be used to specify that all users in a chatroom are either completely anonymous (private), or anonymous to all users with equal or lesser permissions (semi-private). If we agree to emulate this functionality, we will need to add another element to the XCON data model, at the conference data model, that specifies these modes of operation. We will also need to define how these conference-wide anonymity specifications interact with per- user anonymity settings. 2.4.5. Banned Users In addition to removing specific users from a conference ("kicking" a user out), most deployed systems permit the specification of "banned" users. Such banned users are prevented from re-joining the chatroom until they have been un-banned. This functionality is not possible within the current XCON data model. Currently, the XCON data model allows three modes of operation: (1) authenticated users on an "allowed users" list, (2) all authenticated users, and (3) all users. Banned users obviously make no sense in the third case -- without authentication, banning a user is a no-op. In the first case, banning of a user can be accomplished by merely removing them from the "allowed users" list. The second case is the one that requres additional work if we are to support the concept of banning users. If we wish to support banning of users from a chatroom, one approach would be to modify the semantics of the <user-admission-policy> of "openAuthenticated" to take into consideration the users included in a (not yet defined) <denied-users-list>, rejecting any users in the list. 2.4.6. Nicknames The topic of nicknames in chatrooms is currently the focus of furious discussion in the SIMPLE working group. Interested readers are referred to the SIMPLE working group mailing list archives at http://www1.ietf.org/mail-archive/web/simple/current/index.html 2.4.7. Reasons Associated with Operations Several existing systems allow the inclusion of reason phrases in Roach Expires February 17, 2008 [Page 13]
Internet-Draft Chatroom Gap Analysis August 2007 certain operations (kicking people out of chatrooms, banning people from chatrooms, leaving chatrooms, destroying chatrooms, etc). When the associated operation is performed, these reason phrases are delivered to the chatroom users. If emulation of this ability is desired, two channels are needed: one to deliver the reason from the user taking the action to the chatroom (e.g., in the XCON conference control protocol), and another channel to deliver the reason to the various chatroom users. The addition of a human-readable "reason" field to appropriate XCON conference control protocol requests is straightforward. Delivery of such information to the chatroom users is less so. One potential approach would involve the chatroom sending out instant messages to all the chatroom users, with a CPIM "From" header indicating the chatroom identity itself; the body of the message would include the action taken, the name of the user taking the action, and the reason for the action. Other approaches for delivering this information are also possible, including the definition of a new MIME type to deliver the information semantically. 2.4.8. Alternate Venues for Terminated Chatrooms One mechanism that exists in some current chatroom systems is the ability to specify an alternate venue for a chatroom that has been closed. This alternate venue is communicated to chatroom users at the end of the conference (generally in a way that allows clients to automatically join the new chatroom), and can also be used to redirect users who attempt to join the chatroom after it has ceased to exist. 2.4.9. Discussion History When users join a chatroom, most chatroom systems will deliver the last several messages to the user, to provide them context for the ongoing conversation. Although chatroom systems can do this unilaterally by simply replaying the messages as if they were just sent, such a solution misses two minor attributes provided by some current systems. 2.4.9.1. Marking of Messages as History Currently, neither MSRP nor CPIM provide a means to mark a message as being part of a history replay as opposed to a "live" message that was just received from its author. Some currently deployed systems do include such an indiation in the protocol, allowing clients to render such historical messages in a way that allows their users to distinguish between the history and the live conversation. Roach Expires February 17, 2008 [Page 14]
Internet-Draft Chatroom Gap Analysis August 2007 If we wish to replicate such functionality, we will need to add an indication to either MSRP or CPIM that indicates that a message is part of a history replay. The use of the "Date" field in CPIM might be sufficient to indicate which messages are historic, as long as the client that is joining has some other mechanism for determination of what time the chatroom beleives it to be (e.g., using the "Date" header field in SIP messages received from the chatroom). 2.4.9.2. Client Control of History Replay Size Some currently deployed systems allow client control over how much history is to be replayed upon joining the conference. Because this information must be exchanged while a user is joining a chatroom (that is, it is not a parameter that can be set after joining), adding this feature will likely require adding support in the call control protocol (i.e., SIP and/or SDP). One fairly obvious way to add such support would be the addition of a new SDP attribute for MSRP media lines; something like; "a=chatroom-history:2048". 2.4.10. Chatroom Logging Although the logging of messages exchanged in a chatroom is something that chatroom servers can perform unilaterally, the current XCON/ SIMPLE solutions do not include the ability to control or indicate information about such logging. 2.4.10.1. Control Over Chatroom Logging Ideally, certain roles in a chatroom should have the ability to indicate whether the contents of a chatroom should be logged. Support for such an ability would likely include the addition of a new, boolean tag to the XCON data model, along with operations for modifying the value of the tag in the XCON conference control protocol. 2.4.10.2. Indication of Chatroom Logging Additionally, some current systems allow the ability to indicate whether a given chatroom is being logged. The addition of the boolean tag discussed above would provide chatroom users with the ability to discern whether a chatroom was being logged to a persistant archive. 2.4.10.3. Indication of Chatroom Log Archive Location Finally, some systems include the ablity for clients to access the on-line archive of a chatroom log from within the context of their Roach Expires February 17, 2008 [Page 15]
Internet-Draft Chatroom Gap Analysis August 2007 chatroom client. (e.g., a menu selection or button that brings up a the chatroom log). One approach that would provide such functionality would be the addition to the XCON data model of an element that indicates a URL that the client can dereference to find the chatroom log archive. This would potentially be an HTTP URL, although other types (IMAP?) might be appropriate as well. 2.4.11. Private Messages Because all chatroom messages are wrapped in CPIM, it is potentially possible to define a mechanism that uses the CPIM "To" header to indicate that a message sent to the chatroom is intended for one or more specified users, instead of being broadcast to the entire chatroom. This mechanism is described in detail in draft-niemi-simple-chat. See also Section 2.3.13. 2.4.12. Detailed User Registration Some chatroom systems allow -- and some require -- registration of detailed information about a user before they are allowed to join a chatroom. Currently, the XCON data model does not include a way to store persistent information (name, nickname, email address, etc.) about users who are not actively part of an ongoing chatroom sesssion. One potential approach that would allow this kind of mechanism would be (1) adding elements to the <allowed-users-list>/<target> element in the XCON data model that store information about users who are associated with the chatroom, but not presently particpating in it (these elements would contain the aforementioned information); (2) setting permissions on the operations for adding users to the <allowed-users-list> so that anyone can add such elements (as long as they can authenticate themselves as owning the URI present in the entry); and (3) setting the chatroom to "closedAuthenticated". This would then require users to "register" with a chatroom before joining. An interesting side-effect of such an approach is that is would allow persistent reservation of a specified nickname within a chatroom. It would also allow for system assignment of specific nicknames to users. 2.4.13. Chatroom Directories Most or all current chatroom systems allow users to list and search chatrooms currently available on a server. This can be supported by Roach Expires February 17, 2008 [Page 16]
Internet-Draft Chatroom Gap Analysis August 2007 the XCON conference control protocol; however, such operations aren't clearly part of the XCON data model (nor do the need to be). Additionally, some systems allow chatrooms listed in a directory to be stored in a heirarchical tree of chatrooms and folders. This is very important for systems that may have an unmanageably large number of chatrooms on a single server. 2.4.14. Subscribing to Phrases and Events Some chatroom servers include the ablity to subscribe to certain words and phrases -- either on a chatroom level, or on a server level -- and receive notification when such words or phrases are used in a chatroom. Additionally, some chatroom servers include the ability to be notified when certain events occur (chatroom reserved, new chatroom created, chatroom destroyed, etc). These events generally occur at a server level (instead of at the conference level addressed by the conference event package). Support of such features will almost ceratinly take the form of defining one or more RFC 3265 event packages. 2.4.15. Notification of Unread Messages Some chatroom servers support the ability of users to monitor chatrooms for messages that they have not yet read -- typically because the user was not present in the chatroom when the message was sent. Users then receive notification of such unread messages, either immediately, or the next time that they log into the system. This is similar to the problem addressed by the "message waiting indicator" event package; however, the notion of "unread messages" in this case is not uniquely identified by a single URI -- User A may well have unread messages in the chatroom "sip:nerf@example.com", while User B may not. Consequently, support for this type of functionality will require either a new RFC 3265 event package, or addition of refining information to the existing "message waiting indication" event package. 2.4.16. Designation of Chatroom Language The XCON data model does not currently provide a mechanism for indicating the predominant language that is expected to be employed within a conference. This is likely a useful addition to the data model. Roach Expires February 17, 2008 [Page 17]
Internet-Draft Chatroom Gap Analysis August 2007 2.4.17. User Role Change Requests The XCON conference control protocol will contain commands that allow assignment of specific roles to specific users. Some existing systems additionally include the ability for users to request a role with permissions higher than their current role. The moderator (or owner or administrator) is then notified of such a request, which can be granted or denied. So far, models surrounding the XCON conference control protocol have generally modeled it as a client/server protocol, in which User Agents send requests to the focus, and receive results from those requests in response. Such a model does not support notification of the moderator that a user wishes to change their role in the conference. One approach that can be used to effect such a system would be the inclusion of an element in the XCON conference event package that indicates a desired role for every user in the conference. So, for example, a participant who wishes to be a moderator would appear in the roster as: <user entity="john2840" state="partial"> <display-text>John Smith</display-text> <associated-aors state="full"> ... </associated-aors> <provide-anonymity>false</provide-anonymity> <roles> <entry>participant</entry> </roles> <desired-roles> <entry>moderator</entry> </desired-roles> ... </user> User agents for moderators (and owners and administrators) can then monior the "<desired-roles>" lists, and interactively query their users when such lists exist and vary from the corresponding "<roles>" list. In addition to granting such permissions, the XCON conference control protocol would ideally also include the ability to explicitly reject such requests, thereby clearing the "<desired-roles>" entry. 2.4.18. Per-User Approval to Join by Moderator Similar to the ability to request elevated privledges, it may be useful to have chatrooms with closed membership lists, but allow new users not on the membership list to be approved by the moderator prior to joining. This has the same problem as requesting elevated Roach Expires February 17, 2008 [Page 18]
Internet-Draft Chatroom Gap Analysis August 2007 permissions, but with a twist: since users cannot manipulate conference state (e.g., to set their desired role) until after they have been granted access to the conference, the solution employed for permissions cannot be applied directly to this problem. Fundamentally, this problem is very similar to the permissions required to watch a user's permission information. The IETF elected to solve that problem via the "watcher information" template event package defined by RFC 3857. If we decide to solve this problem, the solution will likely be similar. In fact, one potential approach that provides the ability to perform such screening involves the moderator subscribing to the winfo information for the conference event package. If the moderator sees someone attempting to subscribe to the event package who is not authorized to be in the chatroom, then he can add that user to the allowed user list at an appropriate level of permissions (e.g., observer). The user can then use the mechanism described in the preceding section to request the desired level of participation. 3. Security Considerations This analysis does not inherently have security implications; however, many of the suggested mechanisms do. If such mechanisms are specified, their security considerations will be addressed as part of such specification. 4. IANA Considerations This document has no IANA implications. 5. References Roach Expires February 17, 2008 [Page 19]
Internet-Draft Chatroom Gap Analysis August 2007 Author's Address Adam Roach Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US Phone: sip:adam@estacado.net Email: adam@estacado.net Roach Expires February 17, 2008 [Page 20]
Internet-Draft Chatroom Gap Analysis August 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Roach Expires February 17, 2008 [Page 21]