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

Florian Schmaus flo at geekplace.eu
Thu Apr 12 07:26:31 UTC 2018

On 11.04.2018 21:46, Georg Lukas wrote:
> * 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
> https://xmpp.org/extensions/xep-0045.html#privatemessage
> 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
> <https://mail.jabber.org/pipermail/standards/2017-October/033501.html>

I see.

A different approach would be to define an am-I-still-here IQ send to
the bare MUC address:

<iq type='get' to='room at muc.example.org' …>
  <am-i-still-here xmlns='…'/>

upon which the MUC either returns a result response containing the
nickname if you are still joined

<iq to='user at example.com' type='result'…>
  <joined xmlns='…' nickname='.'/>

or a result response indicating that you are not longer joined

<iq to='user at example.com' type='result'…>
  <not-joined xmlns='…'/>

or an error response, for example if the IQ is unknown..

Advantages I see here is

- The MUC does not intercept IQs
  - Hence it is not so easy to produce an implementation which would
    leak MUC nicknames
- We sidestep the "IQ to MUC participant" problematic
- We do not add  additional semantic to xep199 pings

I think I would slightly favour this approach.

- Florian

More information about the Standards mailing list