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

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Apr 10 06:47:12 UTC 2003


Rachel Blackman <rcb at ceruleanstudios.com> wrote on 10-4-2003 8:42:56:
>
>> However, considering that would problably take a while, I *do* think 
>> there is a need for IBB in the time inbetween, using what we have 
>> now today: <iq/>. If not a standards track JEP then an informational 
>> one. 
>
>That seems like a dangerous road to walk down; 'interim' solutions 
>have a tendency to become entrenched by simple fact of people 
>implementing them and then not changing.  Look at how much non-
>standard gunk has attached itself to general-usage HTML like some kind 
>of mutant barnacle, or alien parasite.  I can point to some really 
>scary tags WebTV came up with, some stuff Netscape should be shot for 
>(remember 'layer', anyone?), etc.  Some die, but some linger on, never 
>fully expunged. 

That's sort of why I suggested to release at least an informational JEP 
for it, to prevent everyone from coming up with their own solution. We 
can be like W3C and tell everyone to wait a few years till we come up 
with that brilliant standard, but don't be surprised if they don't wait.
 (I, for one won't because my project will need IBB within weeks rather 
 then months). I think informal open standards agreed upon by all 
 parties such as Netscape and Microsoft while W3C were slowly getting 
 their act together would have made it a lot eayser to write a decent 
 browser today. 

>We already have stuff where XMPP clients are going to have to support 
>two methods for things in order to be backwards compatible with older 
>'Jabber 0.9' stuff.  SASL and iq:auth, error classes and error codes, 
>etc.  Do we really need yet one /more/ situation where we'll need a 0.
>9 implementation and a 1.0 implementation for client authors to deal 
>with? 
>  (Speaking as a client author, I'm personally hoping the answer is 
>  'no'...) 

It's better to put up with 1 new and one old standard as having to put 
up with 1 new and more then 1 badly standerdized protocols. OK, maybe 
I'm wrong here and will I be the only one that will use IBB without 
waiting till we fix the message stanza, but what if I'm not ;) 

>If fixing the behavior of the message stanzas is the right path to 
>take, then doesn't it make more sense to make this JEP push it forward 
>rather than push it aside?  Make it use <message/>;

Yes! Let's give our customers and users a protocol we know is flawed 
when we have a better alternative. Then (after their clients are 
flooded and their server swapfile has grown to 100 gigabyte) when they 
ask us: "Why did you do this?", we'll answer: "It's so you'll upgrade 
next year!". Admitted, this is a buisness strategy for some companies 
but I'd rather not ;) 

>if IBB is widely adopted, 
>the very problems sparking this whole debate will be impetus for 
>people to adopt XMPP in order to improve it...in the meantime, clients 
>made to use it now will still use it properly when we've moved on from 
>Jabber 0. 9 to XMPP. 
>
>And if IBB is not widely adopted, the problem isn't all that much of a
>problem anyway, right? ;)

I think the worst of our fears should be that we'll see for 99% of the 
cases an <iq> based IBB will be fine and our new and improved message 
stanza won't have any significant advantages. Still, we'd have a decent 
IBB implementation and if will hopefully have sparked of some thing 
that should have been for a while (standards track message events, 
proper delivery semetics for messages, etc.) 

>
>Hrm.  I've tossed in a lot of pairs of pennies today; this can be my 
>$0. 05, for variety. :)

I'll add my 2 eurocents to that then. With all the cents and pennies 
going around here we could probably fund the JSF without any sponsors...
 :) 

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list