Peter Responds
In response to my list of Jabber protocol inadequecies in iChat, Peter Saint-Andre comes to iChat’s defense. Peter, I never said there weren’t reasons for the ways iChat does things. I certainly offer some explanations when I know them—in fact, several of the topics I list I flat out say I didn’t expect iChat to implement. That doesn’t mean everything is a-ok and perfect, however. If things don’t get publicly criticized for incompatibilities, nothing will ever get fixed.
I do not think protocol issues will go with the next version without anyone saying something—I suspect Apple is going to favor backwards-compatibility with iChat, especially when it comes to things like XHTML-IM. I’d be glad to be proven wrong, though, and that’s why I air my criticisms. I only take the time to criticize so deeply things which I really like—I’d love to see them become even better.
That still doesn’t make it OK that the Jabber client I now use on a daily basis is spamming every single person I ever talk to with XHTML-IM packets—non-compliant ones which no other client (except Trillian, which knew iChat would have these packets and thus reverse-engineered them) can actually render as intended. It’s not like it was only the <font> element which slipped through—iChat is basically using HTML, not XHTML+CSS as defined in the XHTML-IM JEP. You’re a standards person, Peter, and you make excuses for iChat when compliance slips this much? I certainly wouldn’t have gotten away with this much in Gabber without criticism.
I also believe that many Jabber clients are going to implement things The iChat Way, so even if a future version of iChat were to attempt to change, many Jabber clients are going to be supporting the old way. That’s why we shouldn’t be happy with a client that doesn’t implement protocol properly—these choices will be around for a long while.
As I’ve alluded to in my Jabber FAQ and my original criticisms, I really like iChat. I recommend that all Mac OS X users use it, and I’m really excited about the fact that Mac OS X now has a great client with Jabber support. I understand that my past two posts have been highly critical of it—but that’s just me focusing on obscure protocol issues to make client developers aware of them. From a user’s point of view, things are quite different. I’ll certainly have more to say on that topic within the next week.
“[iChat] is spamming every single person I ever talk to with XHTML-IM packets”
“Spamming” seems like too strong a word. Unless I’m missing something, there’s no user-visible effect to this, since clients that don’t support XHTML-IM will just ignore that tag and use the regular plain-text body. The only ill effect is that the message packet is a couple hundred bytes longer than it needs to be. Which seems somewhat inconsistent to complain about, since the Jabber protocol is already extremely verbose (compared to, say, OSCAR) due to its use of XML with namespaces.
>“Spamming” seems like too strong a word. Unless I’m missing something,
>there’s no user-visible effect to this, since clients that don’t
>support XHTML-IM will just ignore that tag and use the regular plain-
>text body.
It’s not a tag, it’s an element. This is XML, not HTML.
XHTML 1.0 is an XML standard. It is invalid to add a tag, and a validating parser will flag it as an error. A validating parser will discard the entire fragment or document.
It just so happens that my Jabber server and Jabber client both use validating parsers for security reasons, and as a result if you declare that you’re using XHTML-IM and then send a tag that isn’t included in the XHTML-IM schema, I will discard the entire fragment.
I will also log this as an invalid request, and after several invalid requests (again for security reasons), I will temporarily blacklist the IP. If it continues to be a problem over a 24 hour period of time (a specific threshold is breached), I will permanently blacklist the IP.
I’m not altering this process to deal with Apple’s inability to conform to the XML or XHTML standards, and I’d hope that others who are writing and maintaining Jabber servers and clients would also refuse to use non-validating parsers for the same reason.
If Apple wants to send a proprietary flag that is not valid XHTML and is not valid XML, they can introduce it in an XML Namespace. That allows a validating parser to deal with it, and is required by both the XML and the XHTML standards for adding a new tag.
And yes, I used tag all over the place, but again, it’s not a tag it’s an element.
A font element does not exist in the XHTML namespace. It is an error to use it, an error that will cause any validating client to fail when processing the message.
“If things don’t get publicly criticized for incompatibilities, nothing will ever get fixed.”
That’s a pretty lame statement, and you come off as a rabid freak when you say shit like that.
His response was gentle, pointing out things he thought could use some clarification. Why get all hurt over that and post this inflammatory piece here?
He recognizes the work you’re doing “he’s also posted a helpful FAQ for iChatters who are new to Jabber” and obviously approves.
Why the hell would you whine about it? Email him, it’s supposed to be discussion, don’t be such a child.
Well, I was wrong. But I still feel I was right to make the statements I made here and elsewhere.
My fundamental assumption about iChat Jabber development was completely wrong. I very much believed it to be true, and if it were, statements like the above blog entry would have been necessary.
I still feel that the person who is now regarded as the “head” of the Jabber Software Foundation should not be defending clients. Soon after Google Talk was released, the Google Talk developers came out of hiding and responded to complaints. That is exactly how things should happen. I hope that in the future, as they need more protocols, the Google Talk developers will continue to, well, talk.
The person representing Jabber should be fighting for protocol compliance. It is the job of the people developing software to defend their software’s compliance. Things seem very messy to me when you have one person who is telling developers “you MUST make Blah compliant!” and then turning around and saying, “oh, since Blah2’s developers don’t feel like talking, well, it’s OK that they’re not compliant.”
If there are issues with the protocol itself, software developers need to tell the people in charge of the protocol. If software developers don’t, and then don’t make compliant software, why should the protocol developer defend the software developer?
And this is a discussion. It’s a discussion that happened on blogs and in IM and on mailing lists. Just because you don’t see it doesn’t mean it didn’t happen. It’s also a discussion that’s basically over since my largest gripe was fixed. The smaller ones, well, they’re protocol issues that protocol developers need to fix and know that they need to fix.