[Standards] XEP-0045 MUC: am I still there?

Georg Lukas georg at op-co.de
Wed Apr 11 19:46:11 UTC 2018

* Florian Schmaus <flo at geekplace.eu> [2018-04-11 19:07]:
> > If Juliet is not joined, the MUC will respond with
> > <not-acceptable/>.
> I feel like this is missing "or if the ping request does not originate
> from Juliet". Or is this intentional?

Responding with <not-acceptable/> is the correct behavior for messages
sent to a participant while not being joined, as of

There is no spec in 0045 for how to handle IQs to participants, but I'd
consider it fair to do the same.

If you are joined and ping a different participant, the obvious thing is
to apply whatever IQ routing rules you have in place that are not
required or mandated for by 0045, but folklore claims that the IQ will
be routed to the "most active" client of that participant.

> > - clients don't need two different code paths depending on a
> >  'self-ping-supported' feature

I've written in-depth about it in the first mail of this thread
under "3. A silent intermittent network failure that eats some stanzas"

The self-ping dance right now, implemented correctly and required to
stay in a MUC is as follows:

1. set a (short, like maybe 15mins) timeout after the last stanza
   received from a MUC

2. on timeout: send a ping IQ to your own participant JID

3. (maybe) respond to the reflected ping IQ, depending whether you are
    the "most active" MSN and on the phase of the moon

4. if the ping IQ is responded to with iq-result, service-unavailable
   (official RFC response for a feature not implemented) or
   feature-not-implemented (incorrect but found in the wild response
   for feature not implemented): phew, we are still joined, we are done

5. if the ping IQ is responded to with anything else: we lost the
   connection to the MUC, send presence-unavailable, rejoin

6. if the ping IQ times out, one of your clients probably lost the
   connection to the MUC, just to be sure we need to send
   presence-unavailable, rejoin

You could do things with presence updates and silent messages to the
MUC, but those end up O(N²) with N clients, and not all MUCs allow

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180411/9356611c/attachment.sig>

More information about the Standards mailing list