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.

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.

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.

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.

“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.