[Standards] [E2E] Why we need a <body> element
dave at cridland.net
Tue Sep 30 15:06:22 UTC 2008
On Tue Sep 30 15:53:14 2008, Remko Tronçon wrote:
> 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.
I disagree - I think using <iq/> is probably the wrong thing to do a
lot of the time. But this is almost besides the point.
JS does have a point, but it's not really related to E2E security,
it's related to IBB, and it's not a particular worry.
The trick is this:
1) If an IBB message-stanza channel is used *and* the original
resource goes away, IBB message stanzas may be diverted to another
non-negative priority resource. I'll call this other resource the
2) In this instance, the receiving user - who presumably sees both -
may not be aware that they've lost messages until they receive a
subsequent one at the original resource, because the fallback
resource might throw away the unknown IBB stanzas without notifying
3) Actually, the fallback resource could easily spot that it's a part
of an IBB session they weren't expecting, and warn the user.
4) Adding a <body/> element solves the case where the client doesn't.
Of course, the sender will see an unavailable presence for the
original resource, and will stop sending very quickly, so this is a
rare case (which in turn is why JS hasn't seen it before), but it
If it needs fixing, though, it can be fixed in the IBB spec, and
*not* the E2E spec.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards