[standards-jig] IBB: Making it all "go"

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Apr 10 16:57:25 UTC 2003

Peter Saint-Andre <stpeter at jabber.org> wrote on 10-4-2003 16:48:23:
>I apologize, my message was a little harsh.
>It seems to me that it may be a little early to consider IBB using
>message, since we don't have the appropriate message semantics and
>routing in place yet. So I see three possible courses of action:
>1. Defer IBB until we've defined the required messaging semantics

If we were to postpone IBB again I think we'd have to have a good 
reason for it. I hope the reason in this case is not "IBB should be 
done with the message stanza, because then we have to fix message." 

>2. Push through IBB using IQ (my sense is the Council may reject it)

If they will reject it, hopefully they'll have a better reason then 
that. So what is this reason then? From what I've heard from the others 
on the list those could be a few things: 

1. less overhead because you don't always have an "ack" packet.
2. the message stanza was meant for this, the iq stanza not.
3. offline delivery could be usefull.

As for 1: in almost every real world case you'll *want* to have an ack 
packet, for the various reasons mentioned (flowrate control, 
reliability). And as pointed out you won't save much bandwith with all 
the extensions, though in those (rare?) cases you don't want acks 
you'll get a few less packets. If you were in this because you want to 
save bandwith and packets you might want to look for a different 
protocol alltogether anyway. 

As for 2: I don't see any "philosofical" reasons why we couldn't use 
<iq/>. Sure, if <message/> would be fixed the same would go for 

As for 3: I think this is out of the scope of the JEP. The potential 
purposes can be solved through other means (for wich this JEP too could 
be used). 

Add to this:

- Even if there will be a JEP for proper delivery sematics etc. it will 
take very long before every server will support this. Even when most 
do, it's difficult for clients to find wich servers do and wich servers 
don't. Even if it *does* make it into XMPP Core rather quickly, this 
would still greatly hinder implementation and usage for this JEP. I'm 
not saying you can never do this with a new protocol, but here we have 
a perfect working alternative. 

- It's a simple JEP and with it you can do perfectly what it's designed 
for, both in theory and the real world. Why complicate things? 

Apart from this:
If the message stanza was meant for this kind of use the council should 
have rejected the JEP for it, cause as it is it's too flawed. Ofcourse 
there was no JEP  for it, or a council around when Jer thought of it. 
If we'd write one today describing what we have, and we'd send it to 
the council stating that (amongst other things) it's meant for the kind 
of usage we are talking about right now, it would have to get -1 all 
over the place. 

But in a way, with the XMPP Core docs we *are* writing that JEP. So I 
propose this JEP has it's final tweaks, and is then send to the council 
for voting. If it does get rejected then the council, like it should, 
can give it's opinion on the issues summerized here and all the things 
not mentioned in this post. 

I don't know what will happen if the council rejects an (otherwise?) 
perfectly good JEP on the basis of the <iq/> vs. <message/>, but 
whatever it is they do I hope that will move the discussion forward, 
and help clear the intended role of the message stanza. 

>3. Implement IBB with IQ in some clients and see how it works

I don't think that there are any horrible issues with <iq/> based IBB 
that people can't live with. Unlike <message/> in it's current form, 
wich would continue to be a problem for a long long while considering 
the equasion that contains the time it will take to standerdize fixes 
to <message/> and implement them, the number of servers deployed, and 
the speed in wich they upgrade. 

>Not everything in Jabber needs to go through the JEP process, and in
>this instance it might be valuable to pursue #3 and gain some
>experience with IBB before seeking ratification of the protocol.

I think it's best to push ahead with <iq/>. Even if the council rejects 
it for good or for bad reasons, it will put some presure on that 
council or others to fix the message stanza so it can be used the way 
they think it should be used. 

My advice to all client authors is, if you want IBB in your clients, go 
ahead and implement Justin's JEP, because waiting for a useable form of 
<message> is going to be a long, long wait. Wether it will be rejected 
or not, it's a good JEP that get's the job done, in theory and in the 
real world. 

BTW, I have an old version of TKabber in front of me here that does an 
early version of IBB<->Jidlink. Ofcourse my windoze TCL/TK is f*ck*d 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list