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

Jonas Wielicki jonas at wielicki.name
Fri Dec 15 08:19:00 UTC 2017


On Freitag, 15. Dezember 2017 00:56:36 CET Maxime Buquet wrote:
> 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>
> ```
> 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.

Which is, based on the status code, correct.

> Some display nothing (conversations, dino)

This is at least weird.

> , I suppose it is
> handled like any presence, or bug? as this should be a kick if I'm
> correct?

You are indeed correct, this is definitely a kick (indicated by the 

> Maybe the presence of `<status>` at the top-level and
> `<status code='307' />` is confusing?

It is, but for different reasons than you might think. Example 90 in XEP-0045 
shows this syntax for a kick + kick message:

    from='harfleur at chat.shakespeare.lit/pistol'
    to='pistol at shakespeare.lit/harfleur'
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'>
      <actor nick='Fluellen'/>
      <reason>Avaunt, you cullion!</reason>
    <status code='110'/>
    <status code='307'/>

As you can see, the reason should be nested into the <{…muc#user}item/> 
element, not part of the <{jabber:client}status/>.

What is even more confusing is that the <{…muc#user}item/> you have shown 
indicates a role="moderator" which in fact means that the user is still in the 
MUC (having a non-"none" role <=> being present in the MUC, this is described 
in 5.1.3 Changing Roles). This may be why clients get confused by it.

As for the more general problem of how to handle s2s failure induced kicks, I 
think that a new status code which is used in addition to the 307 code (for 
compat) would be useful. This new code would indicate that the kick was caused 
by a technical error and not by a moderator removing a user (this would be 
reinforced by the absence of an <{…muc#user}actor/> element). New/updated 
clients could then adapt the view accordingly (and showing "$user got 
disconnected" instead of "$user got kicked" or "$user left"), while old 
clients retain the existing behaviour.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171215/8b71cc56/attachment.sig>

More information about the Standards mailing list