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."
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.
or Google? :) I really hope they come out with a GIM.
-Steve
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.
Google makes a great search engine, I do appreciate their Usenet archives, but they do not have the Midas touch. If they made a GIM I am sure they would have a hardcore following, probably the same people using orkut and GMail, but I doubt they could market it to enough people.
Jabber is much more than a simple IM protocol, but that is where it needs to take root. I doubt even Google can see beyond IM here, but someone needs to (hence the IBM reference). A wise man (the Linux nerd who converted me) once told me (while drunk) that "Perl is the glue that holds Unix together." Jabber could be the glue that holds networks together at the application level (I am not drunk but I wish I was). Cross-platform, standards based (XML), extensible, versatile...
24 beers in a case, 24 hours in a day. Coincidence? I think not!
I don't think Jabber/XMPP will truly propogate until every ISP hands you out an IM address on their XMPP compliant server along with the email they hand out. Hopefully this standardisation process will go a long way to see this happening.
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 interesting to note that Apple will be supporting this protocol. Perhaps that will be the start of some big industry backing.
Jabber is that little jem in the back of everyone's minds, it's great, yet nobody notices it. Very much the Linux of instant messaging.
It's open, easy to understand (if you were so inclined you could type the raw XML yourself) simple yet scalable, and improved by JEPs (Jabber Enhancement Proposals) so even though there may be new features (such as vcards, buddy icons, user tunes), the underlying protocol remains the same.
I love Jabber, it's the greatest IM protocol out there. All it needs is users.
90 pages.
As excessively verbose as XML streams it describes.
Yuck.
Not quite.. jabber is multi-site too.. moreso than any of teh other IM clients which require a central server farm to work.
user@foo.com can message user@bar.com. you can set up your own jabber server and join the global jabber community.
it works like email.. DNS looks up the domain, finds the appropriate record for the server to use, and then delivers.
Ultimately, all the other IM systems (msn, aim, etc) are centralized... we rely on one provider. Jabber is completely internet-scale.. infinitely more scalable than the others.. that's one large long-term advantage.
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.
Hey, if you didn't want to use XML then don't and if you were going to compromise anyway, you should have built a hybrid protocol with proper framing. Like BEEP.
This is the sloppiest, ugliest, most naive piece of protocol design I have seen in many years. The protocol bears witness to the fact that the designers can't possibly have had much experience with building scalable IO-intensive systems.
And it really pains me to say so, because I badly want a proper, open IM protocol.
Guys, go back to the drawing board and don't come back until you've at least remedied the most obvious problem: lack of proper, non-XML-parser dependent framing. This is NOT good enough.
IM is even used in warfare.
A good example of this is the CTF-50 Case Study done by OFT. The types of capabilities they used to increase Mission Effectiveness (i.e. Instant Messenger, Web-logs, basic Portal) would be available directly from Core Information Services.
The study doesn't say which IM protocol/client was used. The value of IM over phone/radio was having a history of what was communicated.
I was thinking the exact same thing. My only guess is that SIP/SIMPLE doesn't have the same amount of 'corporate' backing to push it through the standards process? Although, from other, recent articles, I was lead to believe that SIP had made some inroads in VoIP and P2P... So it is a suprising development.
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.
In both cases, you are required to acknowledge inclusion of the software. Furthermore, in the case of the LGPL, you are required to offer redistribution of the library to your users (which means that they must know that you are using it).
In fact, if you want to behave decently, you should (1) acknowledge use of the library in the "About" box, in the game's credits, and in the printed documentation, (2) include the library source on the CD (no reason not to), and (3) let the developers know about your use of their code. This isn't strictly speaking legally required, but it shows that you are a good citizen, and it helps ensure that there will be improvements for you to include in the next game.
How do you solve the framing problem in XMPP? How would you go about designing a multiplexing implementation that can handle, say, 1000 connections on a 800Mhz P3 without burning a lot of CPU?
Erlang is an Open source developping environent that does properly support concurrent development thanks to its light threading model.
Jabber implementation in Erlang (called ejabberd) does this without any problem. -- Mickaël Rémond http://www.erlang-projects.org/
HP do that for us. Not only are they sponsoring various Jabber-related projects, but they also use Jabber for internal IM. I can reach any HP employee using the internal Jabber system (Yes, I work at HP).
As far as I understand it, both standards are attempting to map themselves to CPIM (RFC-3862). And I'm pretty sure there is already at least one working gateway from Jabber to SIMPLE, so the two can co-exist in practice anyway.
In the end I hope it's the developers who get the say over which one stays and which one goes. If they get intimidated by the ironic nature of SIMPLE (it's not simple!), and every developer decides to use Jabber/XMPP instead, then all the best apps should inevitably be based on Jabber. That would pull in the most users, and they would win.
About the worst thing that could happen would be for Microsoft to back SIMPLE, write some shitty apps for it, and force them down the throats of the users of their OS. Which... is probably what's going to happen, since Microsoft have been supporting SIP for some time now.
Karma: It's all a bunch of tree-huggin' hippy crap!
Sheesh..
It's what XMLRPC and SOAP are for. Look ma, RPC over XML via any medium (http, e-mail, ftp etc etc). And it's _widely_ supported.
Would you please enlighten me why XMPP is better than SOAP?
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
Also, I seem to remember something about NASA and FEMA choosing Jabber for their needs, and IBM's CapWIN law enforcement / first response flash network using Jabber.
You're absolutely right. Jabber could be the nervous system of future businesses. I've been putting inter application communication systems together using NNTP servers given the costs of traditional middlware systems, quite a lot of work and the data formats are simple, but it works fairly well but Jabber would be faster and could be more standardised, more ubiquitous.
a re/
e.g.
http://www.archeus.plus.com/colin/middlew
Deleted
How about this