| Network Working Group | A. B. Roach |
| INTERNET DRAFT | Estacado Systems |
| <draft-roach-xcon-chatroom-analysis> | August 2007 |
| Category: Informational | |
| Expires: February 2008 |
An Analysis of Feature Parity Between XCON/SIMPLE-Based Chatrooms and Other Chatrooms
draft-roach-xcon-chatroom-analysis
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 in February 2008.
Copyright © The Internet Society (2007). All Rights Reserved.
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.
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.
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.
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.
See also Section 2.3.1.
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.
See also Section 2.3.11.
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 Section 2.3.12.
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.
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.
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.
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).
The following features are supported to varying degrees using existing mechanisms defined in published RFCs.
See also Section 2.3.7.
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 Section 2.1.2.
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.
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.
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 Section 2.2.1 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".
See also Section 2.1.6.
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.
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.
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 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.
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.
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
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.
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.
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).
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.
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.
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.
Support of such features will almost ceratinly take the form of defining one or more RFC 3265 event packages.
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.
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.
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.
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.
This document has no IANA implications.
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.
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 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 © The Internet Society (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.
Funding for the RFC Editor function is currently provided by the Internet Society.