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

[Peter Saint-Andre]

Olivier Goffart wrote:
> 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 ...

Sure, but you can do that right now, just with different roomnicks. Is
there a special reason why people need to join with the same roomnick? I
guess you're saying that a roomnick needs to be a stable identity like a
JID is. Just like you can have one JID with many resources, you can "log
in" as one roomnick from many resources. I'm not convinced this is
necessary but I'm open to argument.

>> 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

See above.

>> 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

I think I added some text to JEP-0045 about nick collisions / discovery.

>> 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'

IMHO that text is a bit unclear, because it doesn't precisely specify
what we mean by "in addition to the existing occupant" (i.e., with the
same roomnick?).

> 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.

I don't think we have enough experience with this functionality to
specify best practices yet.

> [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 ?

Google Talk does this. It's not forbidden by RFCs 3920 and 3921 but it
is not the custumary behavior.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20060809/ab929b64/smime.bin