Hi, 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@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@server/poezio" > from="muc@muc-server/pep."> <status>Kicked: undefined condition</status> > <x xmlns="http://jabber.org/protocol/muc#user";> > <status code="307" /> > <item jid="me@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
code='307').
> 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:
```
<presence
from='[email protected]/pistol'
to='[email protected]/harfleur'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='none'>
<actor nick='Fluellen'/>
<reason>Avaunt, you cullion!</reason>
</item>
<status code='110'/>
<status code='307'/>
</x>
</presence>
```
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,
Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
