Slashdot Mirror
IETF Publishes Jabber/XMPP RFCs
stpeter writes "The Internet Engineering Task Force has published the XMPP specifications as RFCs. These documents formalize the core protocols developed within the Jabber open-source community, and publication as RFCs represents a major milestone in acceptance of Jabber technologies. Read on for details."
Good, now hopefully someone with some market clout will pick this up and market an IM program using these protocols to the masses. Jabber may be cool, but it is no MSN or AIM. Both of those have immense market penetration. I have high hopes for this protocol, hopefully someone like IBM will make this happen.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
What chance one of the big four (aim/icq/msn/yahoo) adopting these standards? Sorry, I did say standards, so you can discount msn. But if any of the other three did, and there was a greater level of interchangability between those, and jabber because of it, the takeup would be much higher.
But that's the thing about standards - unfortunately it's always the big players that seem to set the ones that have any major sway.
~
~
~
-- INSERT --
I remember when IETF drafts took less than six years to make it through to RFC status.
"What chance one of the big four (aim/icq/msn/yahoo) adopting these standards?"
Immediately? Very slim.
However, like almost all of the other standardised protocols they will eventually have to be able to interoperate to survive. In the long term they will adopt a standard protocol or they will vanish.
Deleted
To all my former colleagues: this is an historic day for Jabber, for instant messaging, and for the Internet. Congratulations!
Erbo - Former employee, Jabber Inc., Denver, CO
Be who you are...and be it in style!
Would be a great business proposition for google or novell or redhat to follow up on.... A novell branded IM client ... businesses would like that.
What Jabber struggles with is a high quality open source reference server implementation that can serve as the center of gravity for server side jabber development.
Whether it is hgiher level C# / Java or lowerlevel C++ / C there isn't (yet) a body of software with a lot of developer momentum behind it.
Jive just released some of their stuff, will be interesting to see how that unwinds.
If Jabber could get to that gravity producing mass on an open source implementation, I think you'd start to see Jabber expand into reliable messaging, higher volume messaging, presense, communication, BPM and lots of others apps.
Actually, Apple has been supporting this protocol, in their iChat software. It uses Rendezvous to get two nodes connected, but the message traffic between them is XMPP.
Be who you are...and be it in style!
To elaborate a bit further...
The reason why XML is so darned handy is that is captures the essence of what makes a computer useful: data structures. XML standardizes parsing (never write a text parser again), leaving only the task of grok'ing data structures to the programmer.
XMPP takes that a step further: a standardized way two programs may exchange data structures.
To me, this has all sorts of useful implications, particularly in enterprise installations. Now engineers can stop rolling their own TCP protocols just to get two custom applications to communicate with each other; they can now use XMPP, and exchange data structures.
Jabber is a presence-aware XML router. Beyond that, it's imagination-bound.
AIM/ICQ, Yahoo and MSN have no need to adopt open standards, and never will. Yahoo does so much stuff that Jabber doesn't do - Imvironments, Audibles, etc., and more importantly, they want to be proprietary so they can decide whether or not to allow third party clients to connect to their service. Twice in the past year I've been locked out of Trillian because of Yahoo, and once they even caused Trillian to crash completely. I had to wait for an update to Trillian, which was available within 24 hours. Supporting open standards wouldn't let them do that. Remember, running a massive IM server and developing a client doesn't make you money, but showing ads does, and Yahoo brilliantly works these in as Imvironments.
Imvironments and Audibles, proprietary smilies, etc. are also strong arguments for using Yahoo's client rather than Gaim or Trillian. I don't get any of those things, and someone with Yahoo will inevitibly complain that I'm not in Yahoo, so I have to launch it. Very clever and "viral" of them.
Jabber will probably never reach the same market penetration as the other IM clients, but that's ok, it's not really competition for them. You use AOL if you want to talk to your friends no matter where they are. You ues Jabber because you want complete control over your chat network - who can connect, whether or not you log chats centrally on the server, and who can eavesdrop.
Jabber can work entirely behind a firewall, so your employees can talk to each other and not worry about revealing trade secrets to someone else sniffing their conversation, or talking to their friends and wasting company time. Or you use Jabber because you're conducting business you don't want someone else to find out about. For example, Google might want to use Jabber to communicate because MSN, Yahoo and AOL are their direct competitors and could listen in to their conversations.
You also use Jabber because you deal with clients and need an audit trail. By logging conversations centrally on a server, you can produce an audit trail superior to even email. Being centrally located, if you trust that nobody's tampered with it, you get chat logs that prove what was said when to who, and what the response was. This is similar to centralied web-based trouble ticket systems.
So, while Jabber may have many mechanical similarities to the other IM clients, the actual uses and needs it fulfils are somewhat different.
unlike say the http 1.1 RFC http://www.ietf.org/rfc/rfc2616.txt which weighs in a trim 176 pages?
I'm suprised everyone thinks Jabber is DOA. It's no MSN, AIM, or Yahoo. However, it's not supposed to be.
Currently, Jabber is an open IM standard with tools available now. It has been receiving large rollouts for corporate use, and plenty of people use it exclusively for IM. (Myself, recently, included.)
It the future, instant messaging will become more important. Be it text, audio, video, or something new Jabber (with its XML base) can theoretically support it nicely.
And the worry about numbers isn't something I have. It's fairly simple scalability math. For example, if every cellphone/mobile device comes online and even a quarter of them use instant messaging, the AIM/MSN/Yahoo userspace will be completely swamped.
Ok. What have they done to prevent spam here. email/smtp had some design
flaws when it comes to identifying senders. Does Jabber "solve" this.
In the real world, XML is a very verbose protocol, and in most cases it is trivial to store the incoming data in a less space consuming format. Using a SAX parser that is reasonably efficient, the only state you will need to keep track of is namespace declarations and open tags - that is highly unlikely to be much data, and certainly unlikely to get anywhere close to closing the gap between the maximum size of a well parsed data set and the maximum allowed size of a message. As a consequence, a well written server should REDUCE state by parsing as you go, not increase it, and only a complete moron would keep trying to parse the message over and over again from the beginning each time.
Even if this wasn't the case, a well written system would run into bandwidth limitations and IO limitations of the server long before memory limitations in any sane configuration - memory and CPU is cheap, good IO subsystems aren't.
As a benefit of this approach, by the time all the data has arrived from the client, you have the message in a much more efficient representation. In fact, in many cases you might have enough information even before you have received the complete message that you may not even need to store the rest of the message as it comes in.
The idea that you need the complete message before you start doing work on it is flawed - it implies that during sudden bursts of activity, your system will sit mostly idle until complete messages have been received, and then suddenly be swamped with processing, instead of spreading the processing cost over the whole time it takes to receive a message, which could potentially be a "long time" for many clients on slow connections.
Fortunately, you don't have to. I provided you with a brief list later in my reply.
Thats a bit like saying you can make a go-kart go really fast if you try. Yeah great , but why not just buy a car in the first place then?
You've got your comparison backward. Your whole argument was that a car (XML), which is larger but is more versatile, wasn't as small as a go-kart (compact, binary format). My point was that if you want, you can negate the size difference while retaining the versatility of the car, so your argument is moot.
So what , its still just a shell! So you can download some parser to parse it. Oh well great, that saves a weeks development time. And slows down the whole product whenever its run. Hmm , great tradeoff. Not.
It's again clear that you've never actually developed with XML. If you really care about speed (or need to reduce memory use), you work with SAX streams instead of DOM or other object models. You might take a speed hit compared to working with byte-delimited chunks of binary data, but it will be of a scale you're certainly not going to care about in message-passing, which tends to be a sparsely executed operation anyway.
I'm also beginning to wonder whether you've actually got a job, as saving a week's development time is often the difference between whether the project gets done or not. In the context of XMPP, this could be a major factor in adoption of the protocol-- bear in mind that's a week's development time saved for every implementation of the protocol.
No , theres nothing special about "messages" that means they all have to use a standard format. Why shoehorn everything into the same dumb standard? Horses for courses...
Bear in mind that I'm talking about the messaging protocol (carrier format), not the payload. If your protocol requires changes, isn't it good to be able to add information without necessarily breaking older implementations of the protocol? Wouldn't it be good if they could simply ignore information relating to features they don't support? You can't do that in a byte-delimited binary format without careful and specific pre-planning, the effort of which may be wasted if you're not sufficiently prescient.
Absolute fastest speed and optimum compactness are not everything, and are usually pretty far down on the list of requirements even for an application-level network protocol. They are almost always trumped by minimizing development effort, maximizing extensibility and maintainability, and standards compliance (yes, even of "shells"). If this weren't the case, we'd all be writing everything in C and doing pointer math on arrays of gobbledygook all the time.