[standards-jig] IBB: The options

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Thu Apr 10 15:10:59 UTC 2003

First, I'd like to state  that I have a real interest in authoring a
"message delivery semantics" JEP.  Any and all ideas on this are
welcome, and I'll work to provide my collections of thoughts (in the
form of a JEP) this weekend (-:

Please try to give this a subject of "Message Delivery Semantics", kay
thanks (-:

On Thu, 2003-04-10 at 06:41, Richard Dobson wrote:
> > Obviously, I don't agree that the message delivery fix MUST be done
> > before IBB is fixed -- this isn't a problem of mutual exclusivity. The
> > Right Thing (tm) to do is proceed with IBB using <message> and start a
> > new JEP in parallel to address <message> problems. Creating multiple
> > JEPs (one w/  and one w/o IQs) creates even MORE backwards
> > compatibility issues.
> Well im sorry but I dont see how IBB can proceed to draft without the
> delivery fix having been standardised and finalised beforehand.

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

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.

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.

> > With all due respect, I would reiterate that this isn't just about the
> > "name" of the stanza/packet. There IS a problem with <message> -- we
> > can't use it as it was originally meant to be used. This means there is
> > a bug in the protocol that should be fixed. Making the right choices
> > for protocol clarity and uniformity is a critical part of the JSF's
> > function. If we are serious about wanting to build a long-lived
> > protocol we MUST be concerned with making changes that match the
> > original intent and goals of the protocol.
> Well im sorry but with all due respect, I still dont logically see the need
> for using message, IQ just seems a much simpler more logical and more
> elegant solution, and doesn't need all the hacking of message with lots of
> extensions which would not be required with IQ.
> Im happy to be convinced otherwise but that hasnt happened so far as using
> philosophical reasons over technical reasons seems silly to me, but oh
> well...

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

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

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

> Richard
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)

More information about the Standards mailing list