[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
wish.

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

> 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