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."
The next version of iChat will include Jabber support.
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)
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
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.
In a nutshell, it's pretty similar to e-mail, only without indirect routing between servers, and (partly therefore) less store-and-forward, and definitely less latency. It also includes presence information. See also http://www.jabber.org/oscon/2004/jabber-bootcamp.p pt
and http://en.wikipedia.org/wiki/Jabber
And with links:p pt
http://www.jabber.org/oscon/2004/jabber-bootcamp.
http://en.wikipedia.org/wiki/Jabber
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.
The glossed over version:
jabber is multi-site, like mail. You don't need a server with like-minded people... all jabber users globally can chat with each other (unless, you know, you set up a private jabber server, etc.. same with email)
The protocol is open and extensible, and supports the idea of extended transports.. so the jabber server can act as a gateway for msn/icq/aol/foo/bar/baz. My jabber server deals with all of this... my yahoo/aim/icq/msn contacts are all stored on my jabber server.. I just sign in with whatever jabber client I want, and it all just works.
I should note that I used Jabber as the network layer of my honors thesis project, a general-purpose distributed computing architecture. If my web server weren't dead this week, I'd share a link with you, but rest assured that Jabber makes things simple that would otherwise not be.
One problem I had when using Jabber for my honors thesis project was that it doesn't make fully-standard use of XML. The way the protocol assumes namespaces work is incorrect, and a fully-compliant XML parser will not work with Jabber, in my experience.
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.
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.
It's Google. Sure they could.
And the cool thing is that with IE, Mozilla, _and_ Opera (in the upcoming 7.60 release) supporting XMLHTTPRequest, they could make a web-based IM, without using such nasty stuff as Java or Flash.
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?
Already been done without Java or Flash. (demo).
Disclaimer: I'm one of the developers for this product.
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.
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".
That's a false statement. You have to shut off any kind of even minimal validation for it to parse. The assumptions XMPP makes about namespaces are false.
The Jabber protocol isn't bad. It's got its quirks, but overall it's okay. The problem is that it relies on a broken version of XML to be useful. Anyone who's written a validating XML parser with the intent of using it to speak Jabber (as I did 3 years ago) can tell you just how bad it is. Things like treating "xmlns" as a regular attribute instead of a namespace declaration, not including subnodes in the correct namespace, barfing if you send a subnode with the correct namespace specified, etc.
It's for that reason that my relationship with Jabber is love-hate. I love the "presence-aware XML router" nature of it, but I hate that it operates on bad assumptions about XML.
First of all, a long stream of Jabber messages is irrelevant - you won't be handling more than the greater of your IO buffer (and don't try to tell me 100MB would be a sensible size) or one XML stanza and parts of another at most - so unless you're leaking memory the length of the stream have absolutely no bearing. The IO buffer size is a tradeoff between performance and memory usage, but can be fairly large since in a multiplexed environment it will be shared between all the connections when you are parsing the message as you go.
If you want to parse the message at the end, however, you'd need to retain a copy of the message.
Second, a SAX parser needs to maintain only very limited state between calls - it needs the XML namespace declarations and a list of open tags, and enough space to hold a single incomplete token. I'm sure you can find implementations that keep all kinds of extra around, but I've both used and written parsers that have made do with just the above.
The general approach then is to maintain a fixed size IO buffer, fill it as much as possible with a single non blocking read (which btw. is another reason to consider interspersing processing with the reads, as you for some workloads otherwise end up context switching to fill up only small parts of the buffer at a time), feed it to the SAX parser. If any events are fired, your code looks at the data and throw away any parts it doesn't need, or stores it in whatever more compact form is convenient for you. If the message is complete, process whatever stored data you have gathered from it, and throw away afterwards. Repeat as long as the connection remains active.
Since XML usually is extremely redundant, it is normally trivial to come up with an internal representation that is more space efficient than raw XML, but many applications (including XMPP) don't even need all the data from many messages - often you only need to store parts of the data you are receiving. If space is really important for you, and you're dealing with limited XML vocabularies, this is particularly true, as "compressing" the XML can be very efficient.
Applying this to multiplexed IO is exactly the same as for the single connection case. You maintain the state required per socket. Each time the socket becomes readable, you fill the buffer as much as possible, and feed the SAX parser.
No, it's not guaranteed to always save space - if you NEED to do processing on the raw XML for whatever reason, or NEED all the data before you can do processing that allow you to throw some of it away (after passing it on to another client or server for instance), you could apply compression techniques to your IO buffer without parsing the XML and might end up doing better, but I've yet to come across a single real life application where that would have been a useful approach.
That said, I'd not usually spend time doing any of this except as a side effect of the convenience of storing the data in a more useful form than raw XML, as memory is cheap and developer time isn't. Given relative component costs it's almost always IO performance that is the most cost effective to optimize in the kind of systems I've dealt with.
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?
I'm trying to recreate the entire web through XMPP:
nuWeb.org
Yeah, using a IM standard and some P2P apps. Unlikely, but solves polling and distribution problems.
I may be out of my mind, but HTTP sucks.
http://pixelcort.com/