[Standards] XEP-0045: Handling presence type='error' coming from s2s

Kevin Smith kevin.smith at isode.com
Tue Dec 19 16:11:31 UTC 2017

> On 15 Dec 2017, at 00:56, Maxime Buquet <pep at bouah.net> wrote:
> Hi Standards!
> I have been trying to find indications on how to handle the following
> kind of presence in MUC (and any other valid error):
> ```
> <presence type="error" to="muc at muc-server">
>  <error xmlns="jabber:client" type="cancel">
>    <undefined-condition xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" />
>  </error>
> </presence>
> ```

I think you’re missing some of the stanza headers to understand who’s receiving an error from where, here.

> This discussion started with a potential issue in prosody[0].  This is
> the answer that I get from it when the payload above happens:
> ```
> <presence type="unavailable" to="me at server/poezio" from="muc at muc-server/pep.">
>  <status>Kicked: undefined condition</status>
>  <x xmlns="http://jabber.org/protocol/muc#user">
>    <status code="307" />
>    <item jid="me at server/poezio" affiliation="owner" role="moderator" />
>    <status code="110" />
>  </x>
> </presence>
> ```
> This is displayed as a kick in clients I've tested with, like gajim or
> poezio.  Some display nothing (conversations, dino), I suppose it is
> handled like any presence, or bug? as this should be a kick if I'm
> correct?  Maybe the presence of `<status>` at the top-level and
> `<status code='307' />` is confusing?

This seems to be a bug, as it's simultaneously saying it’s a kick and that the user is still in the room (role moderator), so I’m not surprised some clients render one side of it, and some render the other.


More information about the Standards mailing list