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

Heiner Wolf wolf at bluehands.de
Tue Jan 18 19:18:49 UTC 2005

>> What I mean is: "A MUC service SHOULD remove a user if the service
>> receives a delivery-related error"
>Section 15.1 of JEP-0045 currently says:
>  A MUC service SHOULD remove a user if the service receives a   
>  delivery-related error in relation to a stanza it has previously 
>  sent to the user (remote server unreachable, user not found, etc.).
>That seems to address the issue, no?

Well :-) of course does this address the issue. I cited it from there.
But my lengthy explanation tries to explain that it does not solve the

>It seems that we all agree on the wording of JEP-0045 and RFC 3920/3921

>regarding error generation and handling. It's just that some server and

>component implementations may not be doing the right thing. So let's 
>submit some bug reports and patches. :-)

We don't know if it is a matter of bug reports. Only the MUC
implementors can tell. If MUC implementors correctly handle
"delivery-related errors" by "removing the user" then it is a bug report
to whatever server was involved on the client side. If they do not
handle the case then it goes to them. I am trying to find out who will
get the bug report. 

I do not agree completely that the Jabber should rely on properly
implemented components. I think that compoments should protect themself
from other badly implemented components. Therefore it is not only a
matter of bug reports. Imagine David Sutton would reply "Yes,
MU-Conference already handles delivery-related errors correctly". Then
we have one correct cmoponent and another incorrect, but unknown one.
How would I be able to convince the unknown administrator of the buggy
component to change it? I don't. I would have to live with users of
buggy servers. 

Only, in this case I doubt that the server is buggy, because it is
jabber 1.4 operated by Matthias Wimmer. We are talking about a system
where Matthias Wimmer's code talks to David Sutton's code. Both know
what they do. Still there seems to be an instability. 

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