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

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Apr 10 22:22:13 UTC 2003

Rachel Blackman <rcb at ceruleanstudios.com> wrote on 10-4-2003 21:41:34:
>> 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). 
>I disagree; in a real-world case, I could very definitely want the 
>ability to turn ack on or off.  What if I want to do the equivalent of 
>a UDP connection over IBB, where I don't really care all that much if 
>I lose packets or not?  I can think of a few situations where this 
>would be ideal (such as streaming media, though admittedly whoever 
>does streaming media with IBB should probably be shot by server 
>Assuming IBB has to mirror TCP's behavior in terms of guaranteed 
>delivery seems like a fundamental oversight to me, especially when 
>it's possible to add control over the ACK and thus emulate either UDP 
>or TCP, whichever is more appropriate for the stream in question. :)

In the past on this list I have argueed for a generic connection 
framework (for both IBB and OOB connection), wich would allow to 
differitiate between reliable and non-reliable connections (again, both 
IBB and OOB). Both this, and the closest thing to it (JidLink) have 
been rejected by the community. 

I think there's a place for unreliable/fast UDP like sending of IBB 
packets, and when someone will need this they can propose a JEP for it. 
Hopefully by then they'll have decent message stanza delivery sematics 
to work with, both on paper and in reality. So it's not that I don't 
see a future need for this, I've advocated it before. Heck, they even 
wanted to call JEP-65 (SOCKS5 stuff) "generic bytestreams" for a while 
:). I don't see anything wrong with choice however, I don't feel they 
necisarly have to be possible in the same JEP. 

Imagine the IETF saying: "Sorry guys, SIP/SIMPLE can do everything XMPP 
can. Well ok, maybe not *now* yet, and maybe it lacks usage and 
implementation. But we're working on that you know! We wouldn't want to 
standerdize some other protocol, it'll set a bad example! One protocol, 
one way! Real Soon Now(tm)!!!" 

>> 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/> 
>No; there's no real /technical/ reason (other than losing the ability 
>to emulate UDP, which is actually a concern for some things I'd like 
>to see later).  There /are/ definitely philosophical ones.  

PGM seems to feel though that "acks" make the protocol so seriously 
flawed it can't be used at all. I'd like to know the opinion of the 
rest of the community and council on this. 

>There's no technical reason (other than sheer 'eeew?  WHY?!' factor and
>BASE64 encoding bloat) that I can't encode a webpage entirely in the
>headers of an HTTP result as BASE64 strings either, and eliminate the 
>HTTP stream.  But it's not what HTTP headers are designed for so (as 
>well as being architecturally repulsive) it's not philosophically 
>correct, and this doesn't seem like what IQ was designed for either. :)

Neither <iq/> nor <message/> was meant for this. Let's face it, 
<message/> is designed with delivering textmessages between *persons* 
in mind. HTTP = Hyper Text Transport Protocol if I'm not mistaken. 
Don't tell me you never used it to open a bytestream before. The points 
"<iq/>, it's kinda like HTTP, we could do IBB with it" is just as much 
correct as "<message/>, it's kind of like information pushing, we could 
do IBB with it". Right now, <iq/> is the best tool for the job. It 
might be a little bit more unefficient, but <message/> is not even safe 
for use. That's why the JEP uses <iq/>, and that's why IMHO, it should 
be accepted. 

Maybe a name change to "reliable IBB"?

>> - 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? 
>Because taking the path of least resistance doesn't seem like the best 
>way to ensure a solid protocol? 

If anyone can point out something that is not solid about the JEP as it 
is, please do so. Perhaps giving in to a questionable philosophical 
argument and saying: "allright, if you want to use the message stanza 
we'll wait another few months/years" is a path of even less resitance 

>Have a Canadian nickel; I'm out of pennies to give my $0.02. :)

With all that cash, I wonder how much I'll need to bribe PGM into 
supporting the deprecation of the message stanza :P 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list