[standards-jig] NEW JEP: Multi-User Chat

Iain Shigeoka iain.shigeoka at messaginglogic.com
Mon Sep 16 17:03:55 UTC 2002

On 9/14/02 9:37 AM, "Dave Smith" <dizzyd at jabber.org> wrote:

> On Saturday, Sep 14, 2002, at 08:21 America/Denver, Ryan Eatmon wrote:
>> One good reason is that to setup the conversation to negotiate things
>> like nicks is complicated.  And just doing it based off of
>> type='error' is a really bad way of doing it.
> Why is using an error code a bad way to deal with an error? :)

I can't speak for Ryan, but IMO, the trouble with error is that, to date, no
one has very clearly defined what errors (code) are sent in response to what
error conditions.  So "getting an error" currently tells you something went
wrong but leaves it to you to guess what exactly happened (unless you are an
english speaking human that can read and understand the error message...
Hard for computer programs, and very difficult for people who don't
understand english).

I would not have a problem with error IF the protocol defined all valid
error codes for each action. We have been talking about similar efforts for
general protocol works (using flow diagrams or something similar).

>> Another reason is that overloading the presence tag to do more and
>> more is also a bad hack.
> Overloading? I personally think that sending presence to a JID to
> indicate that you are "joining" the room makes a lot of sense and maps
> nicely to a presence-based communications system like Jabber.  Why have
> a whole seperate IQ series to "join" a room? What does it mean to join
> a room without having any presence in that room?

I find it confusing at times too.  From an implementation standpoint,
overloading <presence> makes it hard to determine what a particular packet
is doing without providing access to the entire state of both the user's
session and the server's resources. This can hurt modularity.

It also makes it hard to point to any particular packet or group of packets
and say, "that's groupchat".  Kind of silly but it really helps when trying
to explain things to others.

On the other hand, reusing the packets does have a certain elegance...  Sort
of the same argument as RISC vs CISC I suppose.  On this debate though, I
think I am more on the side of separating protocols by using a separate
packet type or namespace.

>> It would be nicer to have a cleanly designed protocol to do everything
>> all contained within one namespace.
> I think the point of this work is to maintain as much simplicity (and
> backwards compatbility) as possible (i.e. GC 1.0) while providing a
> clean and modular extension for doing advanced multi-user chat
> functions.

Agreed.  It's great for that. I think in the future, it would be nice to
break groupchat out from normal packet traffic (by namespace, by new root
packet type, or something).  For that, we'd need a new "protocol".

>> Yes, the initial groupchat protocol was nice and simple.  So leverage
>> that and use the simple parts in the new protocol, but don't juse hack
>> up the existing one.  DW's groupchat protocol was looking to try and
>> bring full groupchat capability to Jabber, which is something we
>> greatly need.
> The bigger question is, how does this new proposal _not_ bring "full
> groupchat capability" to Jabber?

1) hacks on a simple, new (and "yet another"), insecure
security/authorization system rather than using or integrating with any
existing Jabber security/authorization system. Aha, yes, there isn't a
standard jabber security/authorization system... However when there is one,
its not likely this proposal will work with it... :)

2) does not address one-to-many style groupchats (pub-sub/online
"events"/moderated chats).

3) does not address interoperability issues with other IM systems.

4) does not address quality of service issues... Er unless we say, there
aren't any QoS and leave it at that.

5) does not provide management/administration protocols.  Probably something
that could be combined with a security/authorization effort.

6) does not provide for secure chats (this may or may not be redundant with
#1).  Identity and repudiation guarantees are particularly interesting.  The
current protocol can be implemented to guarantee no identity and 100%
repudiation (anonymous), but the opposite is not easily possible.   We've
run into this problem ourselves when trying to use a chatbot for "binding"

7) does not address search/browse.

8) Probably more if we sat down and brain stormed on it for a bit.


More information about the Standards mailing list