[Standards-JIG] Dead participants in MU-conf, JEP-0045

Heiner Wolf wolf at bluehands.de
Wed Dec 15 09:35:34 UTC 2004


>Well, I'm a MUC implementer (both client and server side) 


>and I believe
>we do need to rely on XMPP servers performing the role they are
>to perform.  They are supposed to be sending stanza errors when there
>are delivery problems.  This is a must in the spec.  

Yes, they are supposed to.

>The MUC service
>needs to handle stanza errors (I'm not sure if the OSS one does) and
>clean up occupants accordingly.
>IMHO the servers/services in question should just be fixed instead of
>throwing a workaround into MUC. 

I understand what you mean, but I don't see it as a workaround. It's a
protection mechanism in MUCs interest. It is a general rule of protocol
development to not rely entirely on correct behaviour. Makes the system
too vulnerable.  

>If you're going to the trouble of
>working around the problem anyway, why not fix it?

Yes, I will, but all I can do is to fix MUC. I can not fix many servers
worldwide. They are not my servers. In some cases its not even the
server software, but the network or network configuration. I don't think
we can blame amessage.info for running buggy jabber servers. The
operator actively maintains jabberd 1.x. But sometimes the server can
not connect to somehost.jabber.org, for whatever reason. So I get
zombies without a broken jabber component. jabbernuke.com is also
running jabberd 1.4.3. But since one week I have dead participants in a
room who are registered @jabbernuke.com. 

If you are installing conference components and jabber servers for your
customers on intranets, then you may be out of trouble. But people
operating public MUCs with hundreds of rooms will run into the same

Dr. Klaus H. Wolf
bluehands GmbH & Co.mmunication KG
+49 (0721) 16108 75
Jabber enabled Virtual Presence on the Web: http://www.lluna.de/
Open Source Future History: http://www.galactic-developments.com/

More information about the Standards mailing list