[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.

/K


More information about the Standards mailing list