[Standards] Security consideration for XEP-0198

Georg Lukas georg at op-co.de
Mon May 12 07:05:21 UTC 2014

* 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 xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <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

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.

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).

|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140512/7c64d900/attachment.sig>

More information about the Standards mailing list