[standards-jig] IBB: The options

Richard Dobson richard at dobson-i.net
Thu Apr 10 16:16:40 UTC 2003

> The fix defines semantics for controlling message delivery.  This can
> and would be used for more than just IBB, because they would exist as
> siblings to each other:  a binary data transport within the <message/>
> envelope, and delivery guidelines for how this particular <message/>
> should be treated.  When message delivery is finalized, IBB
> implementations can move to it as immediately or cautiously as they
> wish.

IMO it is very bad to finalize IBB before the delivery control fixes, this
is rushing out an effectively broken protocol IMO.

> Until this message delivery JEP is ready, JEP-0047 (or whatever JEP
> becomes inband data transport) can include a non-normative section on
> using the existing Informational JEP for "jabber:x:expire", and a
> section on how to act in the case of offline resources.

But just using x:expire doesnt stop messages going to other resources
instead of offline storage, which is something which IMO needs to be solved

> Simply having message delivery standardized before IBB does not
> necessarily fix the problem:  it will need to be implemented.  If people
> have a problem with IBB without message delivery, the motivation to
> incorporate it will be there.  If they don't, then all this really
> becomes a small blurb in the history books on Jabber.

Sure it needs to be implemented before things are fix but you still need it
to be standardised before IBB, also this is yet another good thing about IQ,
no changes need to be made to it to get it working, but IMO major changes
need to be made to the way message works before it can really be used.

> Using "implementation latency" as an excuse for using <iq/> in a manner
> it was not designed or intended *will* manifest in yet another Pandora's
> Box, this being one that cannot be fixed (IMO).

See below for the question "How is it not designed for it?"

> The uses for which <iq/> (such as browse, disco, "jabber:iq:last", etc)
> do not carry the risk that IBB does, because they do not have the two
> characteristics that IBB possesses:
> 1)  Generate a possibly large amount of data within each stanza, AND
> 2)  Generate a possibly large count of such stanzas in a possibly minute
> amount of time.
> That behavior is not what <iq/> is designed for, but <message/> is (or
> at least more so than <iq/)).

How is it not designed for it?, it has the same limitations as message as
far as I can see. To transmit the data you have to add a namespaced
extension to the message, and virtually the same sort of this is done in iq,
am I missing something here?

> If <iq/> is used, at best it will double network traffic (which could
> easily lead to congestion and DOS in its own right), and at worst double
> the bandwidth usage (if each IBB packet carries a single byte or two of
> data, and/or the sending end-point attempts to send a number of
> datagrams that all fail).
> The biggest benefit gotten from <message/> is a reduction, quite
> literally in half, of this network traffic.  That is, unless you'd
> prefer risking a DOS on the server (ruining everyone's experience)
> instead of risking a DOS on an end-point (ruining that one end-point's
> experience).

Ah well im not sure this is entirely true, when adding all the extra
extensions to message IMO that will create lots of extra bandwidth use, ill

Using IQ

<iq to="user1/res" from="user2/res" type="set" id="1">
    <ibb xmlns="http://jabber.org/protocol/ibb" session="565565">

<iq to="user2/res" from="user1/res" type="result" id="1"/>

Using message

<message to="user1/res" from="user2/res" id="msg1">
    <body>this is a data transfer packet</body>
    <x xmlns="http://jabber.org/protocol/ibb" session="565565">
    <x xmlns="jabber:x:event">
    <x xmlns="jabber:x:expire" seconds="60"/>
    <x xmlns="http://jabber.org/protocol/delivery">

<message from="user2/res" to="user1/res">
      <x xmlns='jabber:x:event'>

Now ive added an extra example protocol in for delivery control as an
example of the extra bandwidth that is being taken up by all these
extensions just to make message perform in a way iq does already, now this
demonstrates that actually more bandwidth is used up by the message sending
mechanism than iq is using up. I still think IQ is a much more elegant


More information about the Standards mailing list