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
fallback resource.
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
the user.
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
will happen.
If it needs fixing, though, it can be fixed in the IBB spec, and
*not* the E2E spec.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
