[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/