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

Daniel Chote daniel at chote.net
Thu Apr 10 18:59:22 UTC 2003

Tijl has brought up a very good point... with all these additions to the 
message packet, ie stanza etc... The packets will be HUGE, and acking 
with iq starts looking like a leaner alternative once more.


Tijl Houtbeckers wrote:

> 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 
> <message/> 
> 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 
> again... 

Daniel Chote
Developer/Designer and typical drunk!
email/jabber: daniel at chote.net
blog: http://daniel.chote.com
website: http://www.chote.com

More information about the Standards mailing list