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."
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 --
Does someone wanna give a quick HOWTO and/or a pointer to a suitably high-level explanation? Thanks.
I find your ideas intriguing and I wish to subscribe to your newsletter.
The next version of iChat will include Jabber support.
Actually, Jabber has found a very good niche doing behind the scenes work in lots of commercial software. For example, we were using it in my last job writing console video games. We're also looking to use it in a current voip product at my new company. The thing is, most of this work uses LGPL/BSD licensed libraries like iksemel so you'd never know that the underlying protocol driving that video game chat lobby is jabber unless you ran tcpdump on it.
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!
Well, nobody in this thread seems to care so far, but the question is indeed valid: does this mean that Jabber just beat SIMPLE? How will the IETF accommodate these two competing standards?
"In our tactical decisions, we are operating contrary to our strategic interest."
It's worth pointing out that XMPP is not just for instant messaging.
XMPP standardizes a method for exchanging structured information streams between autonomous entities -- by they human or automated agent.
Thus, when you (as an engineer) need to set up a network of programs that all communicate with each other, you don't have to roll your own protocol, XMPP can do it for you.
Although IRC "botnets" have existed for quite some time, they are typically very primitive and exist mostly in the realm of script kiddies. Further, IRC is unformatted, unstructured, un-standardized text, making it very difficult to parse reliably.
XMPP allows networks programs to communicate with each other in a "native" language -- data structures -- rather than attempting to glean information from a line of IRC ASCII.
I'm currently using XMPP for several local applications: backup agents communicating with each other, sending and receiving mon monitors and alerts, an improved (RSS-like) syndication system, and more.
This ain't your grandfather's IM protocol.
It's not a IM client, it's a protocol that can be easily extended to do just about anything. I'm pretty sure there's something out there that can use video/audio conferencing, if not, then one will soon appear if there's enough demand.
Actually, the ease of use and portability is what will eventually make Jabber the new thing. Don't get me wrong, Yahoo, AIM, and Microsoft's alternative have a lot more functionality, but that same functionality can be easily integrated into Jabber. In fact, many have done so already.
I'll give an example:
Imagine the HTTP protocol for persistent connections. Let's imagine for a moment that all HTML instances are well formed and that the only other file type to be transferred is JPEG images. Now imagine that responses came without HTTP headers describing the nature of the response as well as the size. Content-length is really important. It dictates the amount of processing the software needs to do to determine when it has read a whole element of the protocol. This is an _IO_ operation and you snould NOT have to parse during pure IO.
You might say "well, if it is HTML, then just parse it and see where it ends, and if it is a JPEG, heck you just parse that and see where it ends".
No proper framing.
Now imagine you are writing an HTTP Cache server which needs to do this for tens of thousands of connections simultaneously. Hard? Of course it is. Hard to do right at least. (We leave the kindergarten solutions to freshman students).
The problem hinges on the fact that in most scalable implementations, you do not follow the one-thread-per-connection paradigm, hence you need to be able to process input in chunks. Given that you are processing many connections at the same time, you want to minimize context for each connection; ie. the amount of state you have to keep around to make sense of the data.
The only way to securely know that the data you've read so far contains a valid element is to try and parse it. If you were able to consume an element, fine, if not, you have to read more data and try to parse the entire thing all over again. (Also, now you need to figure out how much you consumed, and thus, how much of the input buffer you can throw away).
Of course, you could make your own primitive XML parser which can infer stanza boundaries, but everyone who has written an XML parser that is reasonably standards compliant knows that this is not easy. In fact, it is a significant project unto itself.
It is not like this is a new problem. Just look at BEEP (or whatever it is called now). The designers of BEEP quickly realized just how incredibly clumsy a protocol that does not do proper framing is, so they added framing to an XML protocol, and hey presto, you have a protocol that is a lot easier to implement correctly AND efficiently. Or HTTP for that sake.
I feel that the Jabber team didn't do their homework, and I am incredibly disappointed that IETF didn't have someone flag these problems. The fact that it has been so many years since they started working on this, and that they have not stumbled across this themselves does not bode well for the Jabber team.
Let's hope they do the right thing now and add proper framing to their protocol. This way it becomes much easier to implement correct and really scalable servers, and we might be able to get a usable standard that can be used for large-scale IM.