[standards-jig] IBB: Making it all "go"
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,
>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
>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
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
>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
Software Engineer @ Splendo
More information about the Standards