[Standards] [E2E] Why we need a <body> element

Jonathan Schleifer js-xmpp-standards at webkeks.org
Tue Sep 30 15:02:39 UTC 2008

Am 30.09.2008 um 16:53 schrieb Remko Tronçon:

> As Dirk said, an <iq> cannot be delivered to the wrong resource,
> unless there is a bug in the server (which is not a case you should be
> trying to solve anyway).

Wrong. It can. You have client A and client B installed. Both have the  
same resource configured. Client A can handle it, client B can't.  
Client B connectes and kicks client A. Tada, you got the problem.

> A client shouldn't have sent an encrypted packet in the first place to
> a client that is not supporting it. That's a bug in the sending
> client.

See the situation above. It is perfectly fine for the client to send.

> The routing rules are different for <message> than for <iq>. Messages
> can still be routed to other resources, iq's can't.

Which doesn't help in the above example.

> As noted before, your client has to detect this (using Entity
> Capabilities for example).

The client did that before, but it changed while sending. We got a  
race condition here.

> It does, and in more than just the routing. I think IBB using
> <messages> is a bad thing, both for routing and for control. I'm not
> sure why this approach is still described in the IBB spec.

It helps the sender to know that something went wrong, but not the  
receiver. The the race condition I mentioned above.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080930/cb1cac90/attachment.sig>

More information about the Standards mailing list