[Standards-JIG] Re: Dead participants in MU-conf, JEP-0045
stpeter at jabber.org
Wed Jan 19 23:28:26 UTC 2005
In article <77018BDE-69BA-11D9-95A2-000A958F753E at ceruleanstudios.com>,
Rachel Blackman <rcb at ceruleanstudios.com> wrote:
> >> If a bare jid tries to join a room with the same nick name they
> >> already
> >> have, the service should kick out the older occupant with a resource
> >> conflict error and allow in the new one.
> > What if I want to be in the same room with 2 different nicks? (and
> > think not just people chatting, but m2m applications as well). I'd say
> > what you suggest is implementation specific at most.
> Then you're not a bare JID trying to join a room with the *SAME* nick
> name they already have, as was the original proposal. ;)
> If sparks at jabber.org attempts to join jdev with nick 'Sparks' and then
> sparks at jabber.org attempts to join jdev with nick 'CeruleanSparks'
> those are two different nicks and should be allowed. If
> sparks at jabber.org attempts to join jdev with nick 'Sparks' and then
> later sparks at jabber.org attempts to join jdev /again/ with nick
> 'Sparks' then it should be treated like a resource conflict and the
> older one should be booted off.
Well, you can't join jdev from sparks at jabber.org because your server
will add in the resource, naturally.
So let's say you want to do this:
1. sparks at jabber.org/foo joins jdev as "Sparks"
2. That connection dies ungracefully for some reason, you don't have
access to that resource from your current location (you were logged in
back at the office or whatever), so you want to join the room as
"Sparks" again to kill off the old resource
3. So: sparks at jabber.org/bar tries to join jdev as "Sparks"
Intended result: sparks at jabber.org/foo is booted from the room.
Current result: sparks at jabber.org/bar receives a conflict error.
Well, there are lots of ways to handle this without special-casing room
entry in the MUC service. Here are some possibilities:
1. Log off before you leave location "foo"
2. Join as "CeruleanSparks" and ask a room admin to kick "Sparks"
3. Drive back to the office and log off the "foo" resource
This seems to me like more of a minor annoyance than a critically
important feature, but we can add something about it to the
implementation notes if people care enough to write up some proposed
More information about the Standards