[Standards] Security consideration for XEP-0198
dave at cridland.net
Wed May 14 09:54:11 UTC 2014
On 12 May 2014 08:05, Georg Lukas <georg at op-co.de> wrote:
> * Kevin Smith <kevin at kismith.co.uk> [2014-05-08 12:34]:
> > Consider the case of a paused client in a MUC. The MUC sends a
> > message, and gets a bounce because the buffer's full. The client
> > resumes the session, but now its out of sync - it thinks its in the
> > MUC and the MUC has removed it due to bounces.
> I can see the point, however I encountered a very similar situation
> yesterday - even though in the opposite direction: I sent two messages
> from my client to a MUC, and only the second one arrived. Digging into
> client and server logs revealed that the first one bounced with the
> following error:
> <message id='Tx26a-19' type='error' to='jid at op-co.de' from='
> yaxim at chat.yax.im'>
> <error type='cancel'><remote-server-not-found
> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
> Server-to-server connection failed: DNS resolution failed
> There was apparently a short network outage between the two servers,
> causing one of the messages to be bounced, bringing client and MUC out
> of sync. If the MUC side of this connection had encountered the error,
> the client probably would have been kicked, leading to what you
I'm not sure we discuss what clients should do if they receive an error
"from" the MUC. We should probably give some advice there. I suspect we
should assume the client is no longer in the MUC, but that assumption is
only really safe if the MUC is handling joins properly.
> Furthermore, I am regulary experiencing a MUC-out-of-sync situation when
> a MUC server is restarted, leading my client to believe it is still in
> a room where everybody is silent.
Then the server isn't M-Link, because I fixed that case. Usually, though,
that's when you join a room that thinks you're in it already, rather than
the other way around - I used to get this a lot when restarting my personal
(and often development) server, which is why I spent a silly amount of time
The problem then is that some servers treat the join (marked specifically
as a join) as updated room presence, and don't hand back the list of
If the MUC thinks you're not in the room, and your client thinks it is,
then the MUC treats an updated presence as a groupchat (ie, pre-XEP-0045)
join, and your client just has to notice the presence and history. This is
slightly unpleasant, but the user experience is a lot less confusing.
> My point is: we already have a world where things get out of sync
> because of misbehaving clients, servers, components and networks. Maybe
> it is better to make this problem explicitly acknowledged instead of
> feigning an ideal world (this also somehow reminds me of the "TCP is
> reliable" argument, one layer up).
The point of 198 is to reduce the scope of this.
TCP *is* reliable, within bounds. 198 makes XMPP reliable within a larger
On a grander scale, we can look for cases where state is held in common by
multiple entities, and see how to avoid mismatch - the MUC joined state
example above is one case, but there are others (pubsub and presence
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards