Slashdot Mirror
Jabber Could Get An IETF Working Group
21mhz writes: "There is a story on CNET news that provides an analysis of what is happening with
SIP/SIMPLE, AOL protocols and Jabber/XMPP in the IETF. It says that Jabber is close to securing a dedicated IETF working group, in spite of political struggle and corporate maneuvering."
For those of you who want to try out jabber, psi is a great crossplatform client, with support for windows, linux and mac OSX. I've been using it for some time, and with the msn, icq/aim, etc transports, there isn't really any reason to use anything else.
I really do hope the jabber folks are able to make jabber a standard.
Unlike propietary networks like icq or msn, jabber is a distributed network of multiple jabber servers pretty much like email. Users have a profile hosted by a server and are identified as user@jabberhost in a similar way to email. This is both its strength (anyone can set up a server) and its weakness (you need someone to host a server). Endusers without the ability to run servers themselves and without a provider offering a jabber server have to rely on one of the public jabber servers. Unlike with the big messaging networks, however, there are no central servers where you can permanently host your jabber profile. There are plenty of public testing servers but these may go offline at any time.
Because of this, many people download a jabber client, figure out that they need a server and are told by the jabber faq that they might try this or that server without any guarantees that it will still work next week. Not very convincing.
For people to adopt jabber as an alternative to current propietary messaging clients, a reliable, available server that will host profiles for free is needed. As long as servers are lacking, jabber will remain an interesting technology that is mostly used in corporate intranets.
If a good public server was available, I would have been running jabber years ago.
Jilles
I've used Jabber on and off from the beginning and I can safely agree that the user end is a bit rough.
...).
However, here are the reasons you want it:
XML: Now I'm sure by the time this is posted, there will be tons of "XML is the future, adopt it and DESPAIR" posts, but in this case, it is a clear benefit. Bascially, due to XML, the message format allows trivial extension of the protocol. Really, you can just make up an XML element, stick it in the right place and *poof*.
"Is it really this trivial?", you ask. Well, one of my pet projects was writing a Jabber bot for pen/paper RPGs (think Dungeons and Dragons). It took about six hours and I added a element (use the sides property to specify type of dice) that would message you back with a dice roll. I never completely finished the client, but it worked.
Keep in mind all I did to do this was hack two copies of the command-line client--no server changes whatsoever. The key here is that any Jabber server will pass custom XML--so protocol content changes *DO NOT* require server changes and are completely client implementable. Freedom for the masses, anyone?
The possibility of custom clients is huge. Unfortunately, the ability for large companies (AOL, MSFT) to control the state-of-the-art and to make sure that, despite interacting with all IM clients, theirs offers better proprietary functionality on their network (i.e. everyone can message, but AOL partnered with newgame.com so only AOL users can use IM to launch NewGame netgames).
Transparency: This is a big win. It is always possible to pull apart the protocol. Heck, the protocol is designed to be human-readable. This has the added benefit of making obfuscation really obvious (why is AOL using elements named option1, option2, and option3? What is the nsakey element for?
OpenSource: You read Slashdot, you know the pros and cons. The less obvious side of this is how it compares to the corporate offerings--specifically SIP. SIP is great, but try to find a free implementation. If you're using SIP for VoIP (which is pretty much the norm) you probably have had to drop a chunk of change on a nasty Cisco CallManager server.
Loosely Connected: Perhaps the most intelligent Jabber decision was to make it just like e-mail. There's no longer a global hostname, but rather a user@host naming scheme. If you're Internet savvy you can get your e-mail address and jabber address to be the same (exercise left to the reader, think about it).
Existing Gateways: Jabber's weirdest appeal is that it already has gateways to access existing services. The docs have the specifics, but the gateways servers can hit AOL and about everybody else.
Good Standards: Practically all of the corporate offerings are standards that were thrown together (Mirabilis ICQ grew like a Frankenstein's monster, see the procotol specs, they're scary http://www.d.kth.se/~d95-mih/icq/). A ground-up thoughtful implementation like Jabber is a Good Thing(TM) compared to some of the messes.
There are other reasons but I'm tired of typing. You get the idea--Jabber stays crunchy in milk. It's nummy. Get some.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
I was at the Jabber BOF and it was quite interesting.
One thing is that jabber was presented as a solution not for instant messaging (IM) or presence protocol (PP) but as a solution for asynchronous transfer of XML. Another BOF, XML Conf, was suggesting there was a requirement for this sort of stuff to provision routers and such.
Most people seemed to feel that Jabber had major issues from a security and privacy point of view for doing IMPP. Remember that the IETF did look at jabber a few years ago for doing IMPP and it was rejected. Since then, many protocols have been proposed. IM can send message in "page mode" where you are just sending a one time message or it can set up a whole session between the clients for cases where you are going to transfer many message back and forth. This second mode is called session mode. Right now the SIMPLE group more or less has a good proposal for page mode and setting up sessions but is debating how to transfer messages in session mode.
I believe that the following companies have said they will support SIMPLE: Microsoft, Yahoo, Lotus, etc. Unlike what the CNET article said, I was told that AOL filed documents with the FCC saying they would do SIMPLE.
If there is a IETF WG on jabber, which I believe might happen, the interesting thing will be to read what that groups chatter is to do - I bet it won't say that it is gong to developed a complete IMPP solution.
On a side note about how this effects open source development, I work with the vovida.org project which develops voice over IP and messaging open source software. We have talked to the jabber.org and jabber.com multiple times. It's always been difficult to figure out how this all fits together from an open source point of view. You see, jabber.com has patents on stuff you need to implement jabber. At the Jabber BOF at IETF I specifically asked them if they would make this IPR available in a way that worked for open source people. They answered that people had implements this stuff and they weren't suing them. This is like yah, DUH, of course when we are trying to get people addicted to the drug we don't sue them. They have NEVER made any commitment to allow this IPR to be used in open source products. They are a desperate company looking for a way to make a business model out of jabber. If you think jabber is the best for open source - give that some careful thought.
Cullen
The big problem with IETF process is that it is very easy to block a specification indefinitely and plenty of folk try to do so.
The problem is not so much the companies as individuals with their own private agenda. I think it very unlikely that a Jabber group would be derailed by AOL seeking to defend its IM turf. But one or two people with an agenda to push some other spec like BEEP could easily bring the group down.
The IETF also has a large number of procedural problems, like insisting that all the group development take place on the mailing list rather than through a mailing list and regular teleconferences as is standard in OASIS or W3C. Another problem is that the RFC format freezes the format of specs in the era of the teletype. Not only is the output ugly, it is damn hard to read.
Another problem with the IETF is that it really does not play well with other children. Most standards bodies have by now got used to interacting with other bodies, not the IETF which has a massive NIH complex. The PKIX group which has been profiling the X.509 standard developed by the ITU is a case in point rather than an exception, the ITU standard had to be profiled before it could be used in IETF standards.
A graphic example of this is BEEP. The Web Services vendors stated at the outset that all their infrastructure was being designed arround XML schema, they would not support BEEP if it was specified as a DTD. So the IETF rushes BEEP to draft standard in less than a year with a DTD based spec and now wonders why none of the major platform vendors intend to use it. The only 'justification' for this decision ever given has been Marshall Rose saying 'well there are some problems with XML Schema', but no details to substantiate the assertion which basically comes down to the whole 'trust us, we know what we are doing and if you disagree with us then you obviously do not'.
The inner circles of the IETF are largely closed to anyone who has not been arround the IETF for 15 years or more. The big problem is that the fine words about being open etc etc are simply not backed by any accounability process with the inevitable result that 'meritocracy' quickly degenereates to cronyism.
The part where things fall apart is at the IESG level. In theory the IESG is charged with maintaining some sort of consistency across IETF work. The problem is that maintaining consistency can easily be a cover for trying to propagate some piece of lossage that should probably be taken off to the woodshed and shot instead. So a lot of groups have been pressured into considering BEEP even though it is inappropriate to their application.
Finally the IETF has a whole rack of shiboleths that have passed their prime. For a long time the IETF was absolutely against NAT 'if you're NAT on the NET you're NOT on the net', to the extent that the IPSEC protocol was designed to be incompatible with NAT (I was there at the meeting). This might have been a defensible position if the IETF had not been responsible for the 32 bit address space allocation scheme that would already have been exhausted in several countries without NAT.
I was giving the keynote at a security track of a Web Services conference recently. A member of the IESG spoke on the IETF approach to standards and inevitably a question about firewalls came up. Not suprisingly the IETF mantra of 'end to end security' was repeated. The problem being that when Alice and Bob are both working for different enterprises the 'ends' of the communication are not identical to the 'ends' of the security context (the enterprise network) or the ends of the trust relationship (the enterprises as a logical construct).
From a design point of view no specification should rely upon security services provided by a firewall. However that is not the same as saying that firewalls provide no protection or add no value. Fifteen years ago, before the ubiquitous availability of crack answered the question a very large number of UNIX sysops argued against the use of shadow passwords as being an exemplar of 'security through obscurity'. The IESG argument on firewalls falls into the same category - although hopefully with Steve Bellovin now on the IESG as a security area director he will be able to do some clue insertion.
The IETF does some usefull work, but they really need to radically reasses what their future role is going to be and how they are going to fill it. They need to shed a lot of the dogma and look into ways that they can improve upon the way things have been done for twenty years rather than continuously praising themselves.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/