iChat Clarifications
Some people in the Jabber community seem to be confused about my criticisms of iChat’s Jabber support. I’d like to reiterate why I criticized iChat in the first place.
Regardless of what iChat does in the future, at this very moment we have a client which is quickly becoming popular which has some broken protocol. Client authors will be tempted to implement things the iChat way (some already have—Trillian supports iChat’s HTML as well as proper XHTML-IM). Even if iChat changes in the future, it will probably continue to support the older broken ways of sending things. Therefore, the de facto standard which everyone can support is iChat’s current method. This is the problem I am trying to warn everyone of, and this is what I would like client authors to avoid. It’s like having Internet Explorer stuck at essentially the same version for five years, except I think we can bet we’ll see newer versions of iChat in much less time than that. :)
I’m trying to point out the flaws in iChat’s protocol so that those of you attempting Jabber compatibility will not be confused and will know that for at least some of these things there are proper ways to do things. Today, as I say this, XMPP support is a must for any new client—ejabberd and jabberd2 are by far the most common internal free server installations, especially for universities. XHTML-IM is also quite popular. I would like client authors to be aware of the proper ways to implement those and to follow up with them, rather than implementing things based on what iChat does.
iChat’s protocol issues mostly do not affect end users. Obviously those who use XMPP-compliant servers (especially with SASL) will not be able to use iChat. Registration and gateway support are not an absolute necessity of an everyday client—users that need those can do them without iChat and use iChat later.
it is me or does it seem like the jabber client world is going to end up looking a lot like the web browser world, i.e., with a core group trying to control the standards (w3c, jsf) but with large influential companies creating apps that have non-standardersied ways of doing things or lack some of the more nifty albeit more obscure features of the standard.
i wonder what kind of animal the mozilla foundation will rename jabberzilla to when they take it onboard… ;)
FWIW, Julian, I only wrote support for iChat’s mutant HTML variant on input. I generate strict XHTML-IM on output, no matter what’s on the other end. I tend to think this is the ‘right’ way to do things in terms of client design: be liberal in what you accept as input across the wire, but strict in what you generate as output in return.
That said, I probably shouldn’t speak too loudly about strict standards, given the Trillian-specific file transfer extensions and whatnot I wrote. (But at least I namespace’d ‘em in a Trillian-specific xmlns…!) :)