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

David Sutton jabber at dsutton.legend.uk.com
Tue Jan 18 21:04:03 UTC 2005

Hello all

  There is already code in place that should remove a user in the case of an error. I am, however, currently auditing the code to find errors. I am also contemplating an idle timeout option, so people can be automatically removed if they have not made any input in a set period of time. This will work around the case where no error is returned.



On Tue, Jan 18, 2005 at 08:18:49PM +0100, Heiner Wolf wrote:
> >> 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
> issue. 
> >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. 
> hw
> --
> Dr. Klaus H. Wolf
> bluehands GmbH & Co.mmunication KG
> http://www.bluehands.de/people/hw
> +49 (0721) 16108 75
> --
> Jabber enabled Virtual Presence on the Web: http://www.lluna.de/
> Open Source Future History: http://www.galactic-developments.com/
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig

David Sutton
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk

More information about the Standards mailing list