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 --
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.
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.
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!
RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
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."
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.
Right from the Google corporate philosophy: "Google does search. Google does not do horoscopes, financial advice or chat."
While it'd be wonderful for Google to come along in its shining armour and rescue us from the oppression of closed IM protocols, I think the fact that not doing chat is right in their official philosophy is worth noting. Of course Apple's iChat will have support for it, in OS X 10.4, and others may well follow... just maybe not Google.
- Allen Pike
Altering time, one time at a time.
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.
Since XMPP has been in development for a while, hopefully it shouldn't take too much time for it to climb the Standards Track to full Internet Standard. Right now, XMPP is in the Proposed Standard category, which is the first step (look at the bottom of the list).
The next level up is Draft Standard. To become a Draft Standard, the RFC has to be a Proposed Standard for at least six months, have two independently developed interoperable implementations, and have had "sufficient" successful use. I think that Jabber is pretty much a shoe-in for this category. Several servers been in operation for years from which a large amount of experience with the protocol has been gained, so there shouldn't be any contention about XMPP not being mature. There are many independent implementations, so that shouldn't be an issue either. I don't think there will be any problems getting to Draft Standard in six months.
The final step in the Standards Process is Internet Standard, where the RFC retains its RFC number, and gets the all important STD series number. A standard needs to be in the Draft Standard category at least four months (or until at least one IETF meeting has occurred, whichever comes later). On the technical side, there needs to be a significant implementation of the protocol and much more experience using it needs to be gained. The level of maturity for Standards is such that the protocol is believed to be beneficial to the community. Again, since XMPP has been in the works for over two years now and there are now commercial implementations, I don't think there is a problem with the usage requirements. Furthermore, as the only open messaging protocol, it has a large value to the Internet. Thus, I think getting Jabber to full standard easily is not out of the question.
In about a year, we'll have an Internet Standard for IM and prescence (and an open one, at that)!
Show me on the doll where his noodly appendage touched you.
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.
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.
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.
No, it's not. If you'd ever developed with XML, you'd know human-readability is not a major reason to use it.
Not only is XML bloated and so sucks up bandwidth (important if you're still on dial up) but its slow to parse and generally ugly.
XML compresses amazingly well. I have an OpenOffice spreadsheet that's 25MB in uncompressed XML. Zipped up, as OpenOffice files are, it's about 150k. That's an extreme example, but grab any xhtml web page and gzip it.
"But its for developers!" someone shouts. I'm sorry? Just how dumb a developer do you have to be to not be able to grok some efficient binary protocol? "But its a standard" someone else shouts. No it isn't. XML is a shell , you can fill it with any old shit and just because something else is "XML based" doesn't mean it will understand it.
Yes, but XML is a standard shell. Data encoded in XML can be parsed, looked up, accessed, transformed, and represented in code using off-the-shelf toolkits which are extremely good at doing all of those things. You don't have to fuck about writing a parser and a lexer, you can just grab some stuff off Jakarta and go to work on your application instead of its IO format. Furthermore, XML is extensible (that's what the X is for)... if your format requires additional information in the future, or needs to act as a carrier for another format's info, that's already taken care of. Probably a good thing for a message-passing protocol, don't you think?
Using XML for IM is a clear case of jumping on the bandwagon for no reason other than the sheep mentality coming to the fore.
Funny, my first thought when I saw your post was "oh look, another cynical-but-wise wrong-tool-for-the-job anti-XML post".