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

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Apr 10 20:31:17 UTC 2003

"Peter Millard" <me at pgmillard.com> wrote on 10-4-2003 21:21:54:
>I completely disagree here. Why does every real world application have 
>to ack every packet? It seems more than sufficient in almost all cases 
>to say ack every 5th packet. This is especially true if we've 
>negotiated a packet size and or "# of packets per ack" parameters. 
>(Which would be a nice addition to this JEP IMO).
>I want less acks to get better throughput if desired. We should not 
>always be relegated to the worst case scenario (as Matt Miller already 
>pointed out). 

If you want less acks, make the packet bigger? Yes, if you want less 
latency (with smaller packets) in your stream you'll get more acks, so 
at the same time you'll know your latency is actually less. 

>> 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/>
>This is a moot point given #1 above. I don't want to ack every packet. 
>Which means we can't use <iq>. It's really _THAT_ simple.
>> 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).
>How so??? This seems like a cop-out to me.. I think it would be really 
>nice to be able to send a friend a small JPG and have it go offline. 
>As for disk-space/spool issues... This is just not reasonable. On 
>jabber. org (one of the busiest public jabberd14 implementations) 
>users receive huge email fwds, or RSS notifications which can be 
>upwards of 40-50Kb. It's not that big a deal to put a cap on this (it 
>becomes an xdb/offline implementation detail). My xdb instance may 
>decide to limit your total allowable spool for offline, etc.. This is 
>a nice feature that we should NOT overlook and just say "its out of 

The scope of this JEP is (at least that's what I thought IBB stood for) 
In Band Bytestream between two entities. I have my doubts it should be 
extended to this type of behaviour. 

I've never used the argument that servers will crash and burn, except 
when people started to suggest you don't need flow control at all, as 
in using <message/> as it is. I hope that, partially cause of that, 
people suggested now to put JEP-22 on the standards track. Wich will 
fix one of the problems with using <message/>, however still only the 
easyest one. 
>> - 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.
>XMPP core defines stream features. It would be easy to add in 
>additional features which that server supports. This would be a prime 
>candidate for this. 

I'm not sure what you're saying here, but if you mean that, rather then 
relying on informational JEPs we move this functionality XMPP Core I 
would welcome that, as I've suggested several times now. If you mean 
something else, oops :) 

>And yes, it takes time for standards to propogate through 
>existing implementations. This is not a "bad" thing, and should not be 
>a driver for protocol design. Saying something like: "we can't do that 
>because it would take too long for existing implementations to make it 
>work correctly" is a lame argument and an implementation issue. 

It's a lame argument when there is no decent alternative. In this case 
that is in my opinion cleary not so. IBB is meant to be a simple way of 
transporting some binary data inband. It's design goal is as far as I 
know, not to be as efficiant as possible. I think it was you yourself 
that said "we don't have to reinvent TCP here" yet you already made the 
suggestion that we negiotiate packetsize and # packets to ack. 

>designing protocols here, not software.

We're designing a simple protocol to transfer some binary data in band, 
we're not working on a cross ocean ATM link. 

>> - 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? 
>We're not complicating things, we're trying to do it the _right_ way. 
>Why rush things?? We've made enough mistakes with protocol in the 
>past, the whole point of the JSF is to not make the same mistakes over 
>again, and to standardize stuff.

You *are* complicating things. Call it good or bad but you're turning a 
very simple protocol design into something that will simply be 
troublesome to implement. Let's *please* not make that mistake. 

>> 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'm giving you my opinion right here, before it goes to vote, so we 
>don't waste time and the author's time & energy. Here are my bullet 
>1. I don't like using <iq> and the fact it forces me to ack every 
>packet. Using <message> and delivery events is a more robust and 
>flexible solution. <message> IS designed to be our generic data 
>envelope. PERIOD.

For a session based architecture between to resources? I'd like to 
argue NO. It is cleary NOT designed for this, else it wouldn't be so 
horrible flawed. Can we turn it into that? Yes... Does the rest of the 
community have to wait till that is completed while there are other 
sound alternatives? No... 

Ofcourse, as a council member you can disagree with me. 
I do ask you what the alternatives are for those that see IBB is 
possible today without any problems, that in 99% of the cases is 99% as 
effective as using the most "perfect message stanza"? 

>If this has not been clear in the paste, I'm doing so 
>now :) If it's broken, lets fix it. (xref #4 below). If we need to 
>standardize message events, lets do that too. (xref #4 below). 2. I 
>_REALLY_ don't like the precedant we'd be setting for other JEPs which 
>want to use <iq> as an envelope for other data. If we allow IBB to use 
><iq> for data, then we're implicitly saying that <message> is only 
>ever useful for text messages. Which is obviously not true. 

Right now it's usefull as a data-envelope for generic data, for single 
packets, not a session based string of packets. 

>3. I don't like 
>avoiding hard questions just to allow a JEP to proceed through the 
>process quickly. 

I'm not argueing we do so, in fact, if you read back if I've argues the 
exact opposite :) That is, for the JEPs and parts of Jabber that need 

>If you need something like IBB in a project soon then 
>use your own namespace, and just do it. Your proprietary extensions do 
>NOT need to be standardized. 

I could benifit from a standardized approach. As would most of the 
clients out there if they want to interoperate. Are you suggesting, 
cause whoever in the community thought <message> should be used for 
session based resource-to-resource data exchanges neglected to mention 
this (it's been a while now that IBB first came up too!) and neglected 
to fix it, everyone should start developing proprietary extensions? 

Dare I say it, if there are those in the council, that (the council) is 
supposed to give "technology leadership" to the community, that have 
had this opionion on a subject that touches the *core* of how 
Jabber/XMPP is and will used and not voiced it, have in this respect 
failed! I mean, we're in the middle of making Jabber an IETF standard, 
and this crucial issue (not in the last place crucial because it 
heavily depends on SERVER implementation) comes up 80% through the 
design of am IBB JEP (wich in it's own right, is not flawed at all!). 

But I'm not pointing fingers here because I do not seriously believe 
<message/> has always been viewed like this. And I do think/hope it's 
not too late to turn the message stanza into a tool suitable for this 
kind of behaviour, and I do think that once we have done it we can do 
great things with it too. But that's no reason to hold back another 
desperatly needed protocol will work just as well, both in theory and 
especially in practise without this. 

>4. I think we need to address the delivery 
>semantics around <message>. IBB is just the tip of the ice-berg in 
>uses of sending data inside the message envelope. We're going to have 
>the same problem with lots of other applications if we don't do this 
>now. </council_member>

Maybe the difference is (besides the "philosopical" difference) you see 
big implementation issues with using <iq/>. I don't see any that big. A 
few extra "acks" will not be what makes using IBB inefficient. 

>[some stuff snipped]
>> 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.
>Matt Miller has already volunteered to write this JEP. I surely don't 
>have the bandwidth to do this (I'm currently trying to finish the pub-
>sub JEP). I agree, this is a good discussion that we need to have as 
>protocol developers. 

What surprises me the most is that, apperently most(?) people in the 
council have the opinion that <message/> should be used for this type 
of protocol. This comes as a surprise to me because the flaws in it are 
so obvious. Let's not bother Jer with it, but I think at one time 
<message/> was designed to make sure in many different cases a text 
message from one person got to another person. This is a very different 
requirment from what IBB needs. I'm not all up to par with ealry jabber 
history, but I think think the basic design hasn't changed much since 
then, with the additions of offline storage, and the 2 infamous 
informational JEPs 22 and 23. 

>> 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.
>You know, I'm sick of hearing this crap. There is NO reason that IBB 
>can't be changed to use the <message> element and work with the author 
>of the delivery-semantics JEP to finalize a protocol. Both JEPs can be 
>voted on at the same time.

I'll give you a reason. It *doesn't* work. The only *technical* reason 
you seem to dislike using IQ is because you get an "ack" every now and 

Ok, so what's the alterative we ask? Well use message for it, that's 
what it's meant for! Oh really? Then why has it been so horrible flawed 
for it since.. well.. forever? Ah, ok, give me a few months/years to 
rewrite the book on <message/>, write some JEPs down, rewrite some 
servers and do a few 1000 upgrades, I garuantuee you, it will run like..
 2% faster then what you suggest we use! 

Maybe I should file a JEP that that the council buys the domain j.org, 
think of all the performance we'll gain by smaller stringlenght for our 

>Why does it take so long to get stuff pushed through the process?? I 
>can tell you: It's because people don't drive their JEPs through the 
>process. Look at how many experimental JEP's we have in the JEP list. 
>Most of these JEPs have never been discussed or proposed for a last 
>call. I have received only 1 request to sponser a JEP so far, and that 
>was verbally. If you want to push something through quickly, then 
>write the JEP, and drive discussion, find consensus, do a last call, 
>and have it voted. It's not really that hard. </rant>

Is ranting obligated in the bylaws of the council? ;)

Honestly, I don't know where it comes from in this discussion. The JEP 
is written, and we surthenly are discussing it!? And I say (not that 
everyone will listen), put it up for vote, implement it everywhere IBB 
is needed, and let the council try and find a better reason then a few 
acks to vote it down. 


Indeed you are one and I'm not, but I'm still looking forward to see 
what the rest of the community and council has to say, because I don't 
think one council member will hold us back. That being said, ofcourse I 
don't think you are the only one that has this view either. We will see.

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list