Loading
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: " Hades.jabber.org/ietf". That's where Jabber.org 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
Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- RSS Feeds
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- Readers' Choice Awards
- The Secret Password Is...
- Reply to comment | Linux Journal
5 min 31 sec ago - All the articles you talked
2 hours 29 min ago - All the articles you talked
2 hours 32 min ago - All the articles you talked
2 hours 33 min ago - myip
6 hours 58 min ago - Keeping track of IP address
8 hours 49 min ago - Roll your own dynamic dns
14 hours 2 min ago - Please correct the URL for Salt Stack's web site
17 hours 14 min ago - Android is Linux -- why no better inter-operation
19 hours 29 min ago - Connecting Android device to desktop Linux via USB
19 hours 58 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
Developer Poll
Comments
Re: single-IM protocol vs interop protocol? status
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...
--BillSeitz, http://webseitz.fluxent.com/wiki
Re: single-IM protocol vs interop protocol? status
Yes, it has been submitted -- I just sent the submission email to the RFC Editor. --stpeter
Re: single-IM protocol vs interop protocol? status
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
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
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
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
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
Well, go.com'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
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.