IMUnified: Playing Red Rover With AOL

Griz writes: "Looks like the bigger names in the IM business have come together to support a uniform protocol, and to rally behind IETF. AOL is noticeably absent. Check out IMUnified for more information." And practically speaking, it looks like a tough sell even for giant AOL to balk at implementing the same standards that will be available to customers of Excite@home, MSN, Prodigy, Yahoo!, AT&T and others.

Re:Just say NO to monolithic messaging

XML is a bad choice for protocol messages. The use of XML carries far too much baggage for a lightweight/automated implementation.

Not necessarily. XML parsers have now been implemented that are as small as 1.5K of code. And Jabber doesn't use full-blown XML with DTDs, automatic validation, and all that; it uses it for the sole purpose of creating a structured data stream.

I've been thinking for some time about how a good Internet-wide IM system could be used not just to send silly chat messages back and forth, but also to be a method for client-server interaction.

The Jabber protocol would be excellent for this purpose. We are exploring such possibilities as embedding XML-RPC or SOAP messages in Jabber to promote client-server interaction over the same stream you might use for two-way human-to-human communication. The existing Info/Query mechanism in Jabber already does this, to a certain extent.

The XML message format requires each piece of software to contain an XML parser and also (from what I've seen) limits the kinds of data you can send back and forth. Why not do what HTTP does -- not care about the content, just specify a header format and let arbitrarily formatted data be attached?

XML parsers are readily available, and, as I mentioned above, can be quite small. As for percveived "limitations" on data types, any text-format data can be expressed as XML and sent through a message extension. For binary data, we use the jabber:x:oob (out-of-band data) extension to pass HTTP URIs for data retrieval, which keeps the data from having to be sent if the receiving client does not support binary attachments.

In addition, Jabber makes the unfortunate choice of not wanting anything to do with crypto on the protocol level; instead, it wants client folk to slap OpenPGP on top of it.

First of all, Jabber already supports SSL connections (via the OpenSSL [openssl.org] library) for transparent transport-layer encryption. The only drawback here is that not many Jabber clients support SSL.

That being said, I would like to see Jabber support crypto at a level in between the transport layer (SSL) and the end-user level (OpenPGP). But it's not going to be supported until it can be done right, as it's my belief that poorly-done crypto support is worse than no crypto at all. And I might also point out that competing protocols either use no encryption, or use something that's a total joke in terms of real security (e.g., ICQ). Then, too, there are US export regulations to consider (and we have very few non-US developers at this point that could mount any sort of Jabber crypto effort).

Eric

The preceding was my opinion only, and not the official opinions of Jabber.com Inc. [jabber.com] or The Jabber Project [jabber.org].
--

Re:Except it (WinJab) won't compile.

Excuse the existing CVS mess. I'm 100% to blame for it's current state :( WinJab has really grown and I'm still learning a lot about being in charge of an Open-Source project.. Its a steep learning curve, especially since I'm still trying to do my "real job" (tm).

I added a readme.txt yesterday (July 25) to the winjab CVS module that should hopefully resolve the component issues. If you have other issues, please contact me directly via email (check the sourceforge site for the addy).

I could _REALLY_ use the help and want to be as accomodating as possible.

Except it (WinJab) won't compile.

I downloaded the CVS version of WinJab a couple of days after it's release (About 16-July-2000). It wouldn't compile.

You do expect a little bit of that with Delphi programs - missing components, etc, but this was crazy. I downloaded everthing I could find, and still it wouldn't compile. There was a whole set of XML stuff missing from CVS. God knows where to find that... (And yes, I registered the type library)

I code Delphi for a living, so I'd hate to think how much trouble other people would be having.

I left a message on SourceForge about it... now there are a whole lot complaining about that same thing [sourceforge.net], but no answers.

I'm a little annoyed about this, because I had a look at the code, and I saw a lot of things I could have fixed for very little effort. (Eg, they are auto-creating all the forms in the project at application start-up. That's a bad thing to do, but pretty easy to fix.) I wanted to help, but I couldn't.

Open IM Standard + Encryption = Useful Tool?

So let's see if my math here is good:

IMUnified comes up with an open standard for instant messaging. Assuming a large enough user base recognizes this as a good thing (and they likely will as the next "upgrade" of Yahoo! IM will be both standards and backwards compatible) then the worry about getting messages to my cohorts (each of whom use different services) dissapears... but what else happens?

Well, if there is a single (or, almost single) standard for IM then writing a client that's useful becomes a much easier task. Having, say, a client which knows how to do MIME would be useful in a nubmer of ways, not the least of which is that PGPMIME is a handy way (and one of many) to move around encrypted dated with arbitrary encapsulation (in this case the IM standard protocol). Suddenly a secure IM platform is available with only a few days coding time, and if the poor sod on the other end of my message doesn't know how to interpret PGPMIME (or whatever else I use) all he gets is a nice ASCII block which is conviently labeled, oh, I don't know, "PGP Encrypted Message"...

hmmmm, I think I like where this is going.
--

Re:Just say NO to monolithic messaging

Thanks for the response, Eric. I was beginning to wonder if I'd gotten swallowed up in the flood of crap that's been posted to all the stories lately. One of these days I'm going to relocate to Advogato [advogato.org] and stay there. :-/

XML parsers are readily available, and, as I mentioned above, can be quite small. As for percveived "limitations" on data types, any text-format data can be expressed as XML and sent through a message extension. For binary data, we use the jabber:x:oob (out-of-band data) extension to pass HTTP URIs for data retrieval, which keeps the data from having to be sent if the receiving client does not support binary attachments.

I'm not so sure that I'm comfortable with that. I know that with XML's namespace support, you can easily push XML-based formats inside of one another, but that strategy requires (AFAICT) anything that's not expressible in XML to be sent OOB. The OOB mechanism also would therefore require additional protocol support within the client, beefing its code up just a little more. If I'm understanding it correctly, it also offers a security risk where a sniffer could grab his own copy of the OOB file.

I would instead implement an inband message send/ack/reject strategy for short messages; and for larger messages or files, an offer/accept/reject message strategy that could transfer content either on the same channel (blocking further messages) or another channel, but without the overhead of additional transfer protocols.

First of all, Jabber already supports SSL connections (via the OpenSSL library) for transparent transport-layer encryption. The only drawback here is that not many Jabber clients support SSL.

This is cool, but it is not the be-all and end-all. I've been over the protocol on a few occasions in the past and I just recently looked at the whitepaper. I don't believe this addresses the issue of how a client attached to one server can authenticate itself to another server to the point of being able to subscribe to presence changes of a user of the latter server. If you had even a simple DSA implementation, you could have the user of the latter server say "I'll accept requests from this public key, this public key, etc." and authenticate based on that.

But it's not going to be supported until it can be done right, as it's my belief that poorly-done crypto support is worse than no crypto at all.

I admire you for taking this stand.

And I might also point out that competing protocols either use no encryption, or use something that's a total joke in terms of real security (e.g., ICQ).

This is a fault of those protocols, and something that needs to be corrected by competing proposals. I respectfully submit that it is not an excuse to not implement cryptographic security and authentication. US policy is a pretty darned good excuse, on the other hand. :-/

A Waste of time without AOL.

According to ICQ's homepage [icq.com] they currently have over 72 million users. Last month C| Net claimed thatt AIM has 91 million users [cnet.com] which may have changed since ICQ had 62 million at the time. All AOL has to do is make ICQ and AIM interoperate and any move by the remaining companies whose combined userbase dwarfs AIM's or ICQ's will be a waste of time.

Frankly I don't understand why people still hassle AOL, didn't they submit their Open IM Architecture Design [aol.com] to the IETF?

The Important Questions to Ask

I don't see any IM software (or protocol) surviving unless it can give me the following, which AIM does:

• Smiley face bitmaps
• News, stock, weather, sports, gardening, internet, and entertainment tickers which are, by, default, all turned on, increasing the space of the GUI to 50% of the screen.
• Everytime I open the program, I should be able to receive an offer to try AOL. The length of the time trial should increase exponentially, so that in 2001 all time trials are written in scientific notation.

Otherwise, ladies and gentlemen, this will fail.

This has potential

But you can bed AOL will never join. AOL controlls the biggest names in IM: ICQ and AIM (which is really only so big because it is forced on all AOL users). But ICQ and AIM can't even communicate with eachother!

Also, I really do hope that this new network supports what Licq (the most used Linux ICQ client) has supported for a while: encrypted messages. If one person using Licq sends a message to another, the message is encrypted (if you turn the feature on). This functionality is ESSENTIAL to the growth of IM if it is ever to be used for business use (as their site suggests it will be).

The MSN Coalition

I have a strong feeling that MS is the main player in this coalition. Take a look at the press release. #1, its from Waggener Edstrom, MS' PR firm. #2, scroll down to the bottom and read the disclaimer.

After all, they were going against AOL head to head for a while by making MSN Messenger compatible with AIM and then they just gave up. How un-Microsoft like, it seemed back then.

So now they engineer this coalition(with the proper IETF backing of course) and they've got a real battle plan again. Obviously they haven't given up.

I wonder if messaging clients are something that could be complex enough that you'd get that software rivalry like there was between Netscape and IE. Does anyone care about the quality of their messaging client?

Re:This won't fly!

they deserve to be as big as they are for helping the masses

Tell that to the (ex-)Compuserve users. AOL took over a great service, removed all the interesting technical forums which made it what it was, and foisted their stupid mass oriented childishness on the few diehards remaining.

Yep.

And less than a year after they bring AOL in line we'll see our first story about Micorsoft kerebosing up the new protocol.

You've read about these things in history class, kids. Now you can see it as it happens.

--

Why should I care? Lets see some real improvement

AIM and ICQ work fine... I'm not getting charged for them... there are clients for lots of platforms... so who cares about making a standard to interoperate with them? Only people that see a "market" and wish they were part of it.

I really can't bring myself to care until the technology improves. When someone invents the fully distributed datagram-only version with automatic encryption and message signing and no central point of failure, I will be the first to sign up. (I've been muttering about doing that to IRC for years, I suppose I should sit down and code something--except I hate writing GUIs, and that is the part most people would notice.) Until then, unless AOL is doing something weird with my messages, or tries to extract a fee from me, what difference does it make that Micros~1 and whoever else can't join the party?

As long as we are going to make a "standard", lets redo the protocol from the ground up and fix all the flaws... and yes, I've seen the IETF draft standard, I think its fugly. Publishing standards for the existing tools would be nice, but what right has anyone to force AOL to open their protocols? Personally I don't see anything sinister in AOL acquiring Mirabilis and Nullsoft and Netscape... they just want to make sure those tools continue to exist, if only so that the value of the Internet experience of their own customers is improved.

Or does someone have evidence to the contrary?

Just say NO to monolithic messaging

What these companies want is to wrest the eyes and clicks of the countless AIM users into using their advertising supported clients. The "open" here is a misnomer that only means "interoperable" which is far from the same thing. It doesn't matter that the huge, dominating overlord is made up of a number of seperate organizations, it's still a huge, dominating overlord. The word for this type of union is "cartel." If you want a real open standard for messaging, you want Jabber [jabber.org]. Jabber is an open standard, it's open source, and most importantly, it just makes sense. There are many reasons why it's better than the current adware messengers, but the best reason is that Jabber is a decentralized network. There's no single, monolithic entity that you must rely on to supply your connectivity. In other words, Jabber is built on the same model of the internet itself.

So download Jabber, but don't sign up at jabber.(org|com). No, instead you should start your own server (if you're able), or encourage your ISP to set up a local server. I mean, what would you rather be known as, "[e-mail]", or "[e-mail]".

Why Unify?

Is it such a huge problem that clients generally aren't interoperable? Now, as much of a proponent of interoperability as I am (check my bio :)) I am not convinced that this is an area where it's a worthy goal to strive for.

AOL, essentially, owns the instant communication market. Instant Messenger has some 70 million users (or so they say) and I think we're seeing ICQ #'s in about the same range. I can't really blame them for being absent here. (Before you start blaming them for embracing and extending protocols, or closing out markets, please consider the evidence. Although AOL-Time-Warner is a frightening market giant, they have not done anything to illegally or unethically corner the instant messenging market.) Anyway, my point is, the odds are very, very good that anyone you might want to reach will use one of those two services. (And with ICQ's excellent cross-platform support, there's no excuse for them not to).

Additionally, AOL and ICQ (both owned, though not created, by the same company) use radically different, fundamentally dissimilar naming conventions. When you start introducing others into the fray, a unified protocol or client could easily become a hindrance or lead to complications.

AOL has more-or-less earned (or acquired) the instant messenging market. When something better comes out, I have no doubt that it will take the place of AIM or ICQ. Until then, though, incompatible standards shouldn't be foisted upon them.

yours,
john

Jabber

The protocol that we have implemented in the Jabber system, is designed just for this task, to bridge the current, and future IM services. We currently bridge to AIM, ICQ, Yahoo!, MSN, IRC, and others are in the works, along with other networks working on bridging into ours. What's even better is we are already completely open and free.

I would highly encourage you to visit our site Jabber.org [jabber.org] for all your development needs, and Jabbercentral [jabbercentral.com] for your end user related needs. Even more so we encourage you to download our server and seutp your own system, because we are similar in idea to how email works, anyone can run a server and talk with all the currently existing Jabber servers.

With ~20,000 users between just the public jabber.org and jabber.com servers we're growing extremely fast, and we hope that others will take part in our growth.

--Temas
Jabber ROCKS!

Nonsense -- Network effect

IM clients benefit from a huge network effect. The value of them increases as you get more users. (This throws a lot of economic paradigms out the window, but IM is "free" so it's hard to apply them).

AOL owns the two largest IM networks, AIM/AOL and ICQ. This system is an obvious one. Why, the rest of the players are tiny. If they merge and can grow, they can become significant. They need to count on users switching to the "standard" so that they can force AOL to play (after which, Microsoft takes over the non-AOL user market).

However, AOL still hasn't (to my knowledge, I mostly use AIM as my friends have all switched from ICQ) gotten ICQ and AIM to play nicely.

Now, if AOL feels any threat, then they merge the top two messaging clients and get even bigger network effects. Right now, AOL doesn't find it critical... they just don't put effort into ICQ and let everyone drift to AIM. If they needed two, they'd merge the databases.

AOL will never join one of these groups. These groups won't make a dent, as Instant Messenger/ICQ dominate the market. It would be suicide to work with this group. Who would download the AOL client if the Microsoft one shipped with Windows and was equivalent (good enough)...

Remember Netscape? AOL is too smart for this.

Alex