Either include status code 110 in the unavailable presence or use an error presence.
The XEP is a bit fuzzy on when to use what. But I won’t be able to parse an unavailable w/o 110 So in your case (a join attempt to the tombstone) I have a slight personal preference toward error; But I’m ok with both as long as the unavailable has a 110. 2018-07-11 4:02 GMT+02:00 Kim Alvefur <[email protected]>: > Hello list, > > I have implemented tombstones for destroyed MUC rooms. My reading of the > sacred texts did not give me enlightenment as how to inform someone > who's attempting to enter the remains of such a place. I've so far opted > to return an <presence type=unavailable> with the same <destroyed> child > that was in the inital announcement of the rooms destruction. > > Of the clients I’ve tested so far, only Gajim seems to understand this. > Swift says something unspecific about failure to enter the room, while > Pidgin and poezio say nothing. > > So basically, this is the reply one gets to a MUC join: > > ``` xml > <presence type="unavailable" id="" to="me@localhost/r" > from="[email protected]/n"> > <x xmlns="http://jabber.org/protocol/muc#user";> > <item affiliation="none" role="none"/> > <destroy>You see only a crater.</destroy> > </x> > </presence> > > ``` > > Does this make sense? > > -- > Kim "Zash" Alvefur > Destroyer of rooms > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
