One document matched: draft-roach-xcon-chatroom-analysis-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 05:26:00 |