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

Daniel Gultsch daniel at gultsch.de
Tue Dec 19 16:24:23 UTC 2017


2017-12-19 17:11 GMT+01:00 Kevin Smith <kevin.smith at isode.com>:
>
>
>> 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.

Who is the stanza supposed to look like? The same but without the item
element? Or a role of none in the item?

cheers
Daniel


More information about the Standards mailing list