[Standards-JIG] RFC: NGMUC -- Problems of and suggestion on JEP-0045 (Multi User Conference)

[Olivier Goffart]

Le mercredi 9 août 2006 15:07, Peter Saint-Andre a écrit :

> tmarkmann at googlemail.com wrote:

> > > ==Resource Support==
> > > JEP-0045 doesn't support multiple resources for one participant. You
> > > have to log into the conferece again as another participant by using
> > > another nickname. Multiple participants who are one and the same
> > > individual can lead into confusion and missunderstanding. Of course
> > > there is not much confusing in room with just 13 participants but
> > > the
> > > jabber protocol is no hobby project and up to 100 users can join a
> > > conference.
>
> In fact you *can* join the same room many times, but each of your
> resources has a different roomnick.
>
> Some questions:
>
> 1. How common is this behavior? Do people really join the same room
> multiple times?

Hello,

There are several reason to do that. They are the same that for an user who 
connect simultaneously with two ressources.
 - You can stay idle on the channel at home,  and want to connect from work
 - You have two computer in two different room, and you move sometimes around 
room and want to stay connected
 - ... whatever others reasons ...

> Most IM users don't even use multiple resources, after all.

But resources still exists and may be used, I don't see why we should not 
support them in groupchats


> 2. Can this be solved at the client side by showing the user's bare JID
> (in non-anonymous rooms) or preferred nickname (JEP-0172)?

I don't think that solve the whole problem.

I have this problem with my implementation of JEP-0048  (bookmarks storage)
If an item have the 'autojoin' attribute, it will join the room with the 
nickname specified in the <nick/> element.
But if you connect simultaneously with two ressources, you always have a nick 
collision error message at login for each room

> 3. If you can have one roomnick (room at service/nick) for multiple
> resources, how do you propose to handle the message routing? Does the
> service send the message to all resources or only the most available?

That's a good question. I think that two solutions make sens.
I personally prefer the first one (send messages to each resources).[1]

Maybe the setting may be added in the <x/> element of the <presence/>

But i think at least one of theses two action should be taken.

The JEP-0045 § 7.1.10 already say :
|However, if the bare JID of the present occupant matches the bare JID of the
|user seeking to enter the room, then the service MAY allow entry to the new
|occupant instead of or (preferably) in addition to the existing occupant.

So there is probable no problems in the protocol, but in their implementation.
Maybe the 'MAY' should becomes 'SHOULD'

the JEP also say :
|it is up to the implementation to determine how to appropriately handle
|presence from the user's resources, route in-room messages to both resources,
|route private messages to both or only one resource as desired (based on
|presence priority or some other algorithm), etc.; all of these matters are
|implementation-specific and are not defined herein.        

Maybe the JEP should give a guideline in order to uniform the processus.
Or user will be confused if not all room behave the same.


[1] As user, I would even personally like to have each message send to each 
resources, even for normal chat. For now, the only solution to emulate that 
would be the JEP-0146. But maybe something could be done at server level ?

--
Olivier (aka Gof)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20060809/3345aaf4/attachment.pgp