[standards-jig] IBB: Making it all "go"
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
> 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
Developer/Designer and typical drunk!
email/jabber: daniel at chote.net
More information about the Standards