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 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
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."
Does anyone here actually use the official AIM?
It gets significantly more bloated and less usable with each version. I have stopped upgrading it and only continue to use it because coupled with Dead AIM it is bareable and neccessary as everyone I know uses AIM for IMs. I understand GAIM or Trillian will also connect with AIM, but my point is that AOL is butchering what was once a simple and elequent program.
http://brandonbloom.name
It's interesting to note that Apple will be supporting this protocol. Perhaps that will be the start of some big industry backing.
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.
Real Time Ads! Next time I cyber I will get distracted by hardcore pr0n text ads!
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.
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.
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.
Don't worry. Audio/Video chat is currently being implemented in the Psi jabber client using Jabber/Helix. It shouldn't take too long before it's finished.
And you could be saving hundreds of dollars on car insurance by switching to voip! I mean! FUCK!
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.
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.
I had a look at Jabber years ago, but what put me off what is now known as XMPP was that it didn't solve the problem of framing stanzas. The only way to determine the borders of a stanza, and thus when you have read enough to successfully parse it, was by parsing the content.
When you write a high-performance multiplexing server (for any protocol) you wish to minimize the state associated with each session or connection. I am not sure this is necessarily easy for Jabber. Its lack of proper framing dictates that you need to do some serious thinking about how to end up not wasting a lot of memory and CPU. Not really important if your server has ~100 clients, but when you want to accomodate millions of clients (as must be the goal for any large ISP when choosing an IM architecture), these things translate into dollars.
As someone else pointed out: BEEP solves the framing problem, as does HTTP.
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?
(The figure was chosen because I've observed a hub IRC server handle 7-800 client connections and 4 servers on IRCNet while only consuming about 10% CPU in steady state)
Was really excited seing RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol. I only thought the jabber people were making rfc's for the basic protocol.
Sadly I don't think there is any clients supporting it yet?
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.
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!
Yeah, IRC has some nice features, and it was the way to do IM before there was such a thing as IM (talk and write be damned). All the cool kids were using it.
Unfortunately, its adoption as a standard ran into some issues:
- RFC 1459, the Internet Relay Chat Protocol RFC was placed into the "Experimental" category.
- Many programs implemented special improvements that were eventually collectively released as RFCs 2810 through 2813. These RFCs, though, were marked as "Informational".
- The IRC Client-To-Client Protocol (CTCP) for sending structured data between clients was released as an Internet Draft, but was never made an RFC.
I think the real killer of IRC as a standard, was the release of RFC 2779, "Instant Messaging / Presence Protocol Requirements". IRC just wouldn't fit this model without a major overhaul, and at that point, you have to question whether it would be worth trying to do that without sacrificing compatibility. It was probably easier to just write a new standard.How does it compare to Jabber? Well, IRC is much simpler (try to write IRC with netcat, then try XMPP).
At it's base level, yes, it's definitely easier. You can do most of what you need for IRC with just a Telnet client. This is kind of fun actually.
Show me on the doll where his noodly appendage touched you.
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
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".
Full stop, end of story. XML is nothing more or less than a structured way to store data. What would they get by not using XML, other than having to write their own container format, their own parser, their own editors, their own portable libraries to deal with it, and their their own inevitable screwups that happen every single time someone decides to reinvent the wheel?
Since it's pretty clear that writing ad-hoc parses for structured data is an obsolete practice, what else could they have used? EDI?
No, they chose to use the established standard that can take advantage of the optimized and field-tested libraries that are already in widespread use. Frankly, inventing their own representational language would've been the naive alternative that would have resulted in Yet Another Unused Instant Messaging Protocol. They were fortunately more far-sighted than yourself and we now have something useful to show for it.
Dewey, what part of this looks like authorities should be involved?
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.