Instant Standard

Jabber is preparing to submit itself to the IETF as a standard for instant messaging and presence services.

"When people ask me what we're doing to drive standards, I tell them to go to hell", says James Barry, the new CTO for Jabber, Inc. But there's a twinkle in his voice as he adds the URL: "". That's where has posted Jabber-rfc, an informational "working document", also known in IETF lingo as an "Internet-draft". RFC more commonly means Request For Comment. IETF is the Internet Engineering Task Force. The latest draft of the document, which runs 80 pages in text format, is dated February 12. In customary open-source fashion, the Jabber folks are exposing the process and inviting participation.

James Barry says this is already a "historical" document, for the simple reason that it's a public source of information to which anybody can easily refer. He also thinks it may be historic in another respect. "Not many open-source projects have made the effort to form standards", he says. "They rely on the code itself to do that. So this is a different approach. It's a great way to legitimize an open-source project. It's a forced rigor. We're documenting what we do to a high degree of accuracy and completeness, to fit the conventions of the IETF."

Jabber's standards are also less a matter of code than of protocol. Here's the abstract:

Jabber is a set of open, XML-based protocols for which there exist multiple implementations. These implementations have been used mainly to provide instant messaging and presence services that are currently deployed on thousands of domains worldwide and are accessed by millions of users daily. Because a standard description of the Jabber protocols is needed to describe this new traffic growing over the Internet, the current document defines the Jabber protocols as they exist today. In addition, this document describes, but does not address, the known deficiencies of the Jabber protocols, since these are being addressed through a variety of standards efforts.

The document is unsparing in its description of deficiencies. For example, "At present the Jabber protocols comply only with a subset of the XML namespace specification and do not offer the full flexibility of XML namespaces. In addition it would be beneficial for the Jabber protocols to enable additional types of availability through a properly namespaced sub-element of the <presence/> data type."

As with all open-source efforts, what needs to be done matters more than what's been done already.

Needless to say, James Barry and other members of the Jabber development community want the document to recruit development help. And since there's a lot of overlap between Jabber and Linux development, we're eager to hear more about the subject from Linux Journal readers as well. Here are three questions that quickly come to mind:

  • Should innovative open-source projects even bother with the standards process? (Others, such as Apache, don't.)

  • Does open source in some ways replace the standards process or render it irrelevant?

  • If not, are there better ways to participate?

Doc Searls is Senior Editor of Linux Journal. He is also a member of the Jabber Inc. Open Source Advisory Board.



Doc Searls is Senior Editor of Linux Journal


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: single-IM protocol vs interop protocol? status

Anonymous's picture

1. Has this RFC actually been submitted to the IETF? If not, does that make it less "real"?

2. I've only glanced at the RFC, but it seems like a specification for a specific rich IM protocol. Meaning that another system like AIM couldn't conform without changing its internal architecture. Wouldn't a better approach be to define an IM interop protocol? Which might imply a more reasonable expectation of conformance by existing vendors?

Right now this smells like a red herring to me. But I could certainly be wrong, I'm not well informed on the processes here...


Re: single-IM protocol vs interop protocol? status

stpeter's picture

Yes, it has been submitted -- I just sent the submission email to the RFC Editor. --stpeter

Re: single-IM protocol vs interop protocol? status

jmbarry's picture

It will be submitted as an informational document this week ( We hope!) subject to the comments of the Jabber mail list contributors. We have wanted the Open Source community to finish it's comments and submit as an informational document so that it will be published with minimum comment. Then we intend to take the pieces and submit them into the various efforts in the IETF around standardization. There are many protocols IMPP, cPIM, SIMPLE, Presence for SIP, IM for SIP aand those are just the IETF submissions. The IEE, ITU, WAP Forum, IM Unified, Parlay Group, 3GPP, Wireless Village, PAM forum are others that are also working on "standards" . We like the IETF because you submit as individuals and comments are taken rather free flowing like the Open Source effort. And standards are adopted by consensus.

Because many of the IM protocols are closed, an interop standard might be a real kludge without intimate help from the proprietary players. Based purely on XML, we hope that interop will come naturally, even though we know there will be issues.

Re: Instant Standard

Anonymous's picture

Like you wrote, alot of open-source projects "rely" on becoming a defacto standard.

Look at Apache. It's becoming more and more a standard because of it's versatile use and of course the open-source nature of the product. To me it is more valuable then a standard imposed by some sort of comittee. Why? It (Apache) has proven itself to be versatile and powerfull enough for people who would otherwise have chosen another product.

As opposed to a standard enforced upon me where the product itself has not proven itself to be "worthy" enough. I hear alot of talk about Jabber but haven't seen any serious real world application of it. At the very least i should have noticed by now that a product was "powered by" Jabber.

I'm not saying Jabber is a bad product but if Jabber becomes a standard while not being used much it has no value.

A standard should be widespread and widely used before it even becomes a standard. This way, it has a track record worthy of a standard. Or at least that's my humble opinion....

Re: Instant Standard

Anonymous's picture

Look at Apache. It's becoming more and more a standard because of it's versatile use and of course the open-source nature of the product. To me it is more valuable then a standard imposed by some sort of comittee. Why? It (Apache) has proven itself to be versatile and powerfull enough for people who would otherwise have chosen another product.

You're making somehting of an apples-to-oranges comparison here. If Apache is a standard, it's only "an industry standard" in the respect that a lot of people use it, and it was originally built upon the NCSA reference codebase. But that's a very different phenomenon than what we see with Jabber.

Apache relies on a real, honest to god, IETF standard already: RFC 2616. Jabber, on the other hand, seeks to actually become an IETF standard.

Don't confuse standards of the "we all agree that it should work like this type," with the "we all use this because it works well" type.

Re: Instant Standard

jmbarry's picture

Jabber, the Open Source project, came along because several proprietary players atarted the market and did not allow interoperability. Apache came out of the need to advance a government sponsored project (NCSA) in lieu of commercial alternatives at the time. Brian, Randy and the others needed better features for their commercial sites they were building and operating, and their were no commercial alternatives for their commecial sites. Thus Apache took off before the commercial guys were ready with their goods. (I know - I was at one of the commercial alternatives at the time) Jabber started after the commercial companies had locked up the market. Like Linux it is battling well entrenched players, yet making headway. It is widely used with thousands of servers, millions of users and dozens of servers based on the Jabber codebase. But because of the high value put on messaging by a large companies an interoperable standard has not yet emerged. If Jabber had appeared before the commercial versions it would be the defacto standard. So the Jabber community is in the position of trying to united the commercial software and content players with a standards push. There are over 20 standards efforts in the Instant Messaging and Presence area, yet none seem to have taken off. And to date there is no real interoperability between services. Jabber's XML play is an attempt to offer one up.

I think that Apache has become the defacto standard by being "good enough" that there is no reason to go to another product for Web servicng needs. The Apache core has not made an effort to get the http standard updated. The question is would working with the standards community to work with the http standard make the Net better?

Jabber is another case of being good enough. But because it started after the commercial player got market share, I think by going the standards route, it might still become the defacto standard.

I think this is a first by an Open Source effort. So we hope to lead the way in opening up the market.

Are you aware of another Open Source project that has gone the standards route?

Re: Instant Standard

Anonymous's picture

The main reason you don't see "powered by jabber" out there is because Jabber (the company) is targeting larger installations and companies which use jabber as a standard internally. You are not going to see it on mom and pop shops and smaller companies. It is out there though, go read they press releases.

Re: Instant Standard

Anonymous's picture

Well,'s messenger is a Jabber system. Plus there are over 20,000 domains with Jabber servers. Seems to be getting some use. ;-) It's my primary messaging system, although I do rely on the transports some.

Re: Instant Standard

Doc's picture

I negelected to say that this effort is in addition to widespread code adoption. If Jabber were not already in use all over the place -- and growing rapidly -- there would be little point to this kind of effort.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot