An Analysis of Feature Parity Between XCON/SIMPLE-Based Chatrooms and Other Chatrooms

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.

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.

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" 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/* *

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. See also .

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".

A user leaves a chatroom by sending a BYE within the dialog that established the chatroom session.

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 to determine whether the target is a chatroom. See also .

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 provisioning such users. However, XCON is addressing such issues; see .

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 and .

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.

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.

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 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).

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.

The following features are supported to varying degrees using existing mechanisms defined in published RFCs.

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-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 .

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.

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.

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 .

The XCON conference control protocol is used to modify conferences, both active and inactive.

The XCON conference control protocol is used to modify conferences, including the subject (topic), room description, and keywords.

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).

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 ). Additionally, the XCON conference control protocol will contain operations that can explicitly destroy a conference room.

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.

The event package chartered within the XCON working group, based on RFC 4575, provides comprehensive conference information, including that information discussed in as being missing from RFC 4575.

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>.

Limiting the number of users is effected using the XCON conference control protocol to set the <maximum-user-count> to the desired value.

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".

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 may be preferable.

The XCON conference control protocol will include operations to remove users from a conference. See also .

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 .

The following features are not clearly covered by existing RFCs or by work chartered within the XCON working group.

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.

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.

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.

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.

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.

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

Several existing systems allow the inclusion of reason phrases in 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.

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.

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.

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. 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).

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".

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.

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.

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.

Finally, some systems include the ablity for clients to access the on-line archive of a chatroom log from within the context of their 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.

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 .

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.

Most or all current chatroom systems allow users to list and search chatrooms currently available on a server. This can be supported by 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.

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.

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.

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.

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:

John Smith

...

false

participant moderator ... ]]> 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.

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 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.