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."

Comments

Re:Well..

[KagatoLNX]

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.

Re:Fantastic

[FattMattP]

A little off-topic, but did anyone else notice this item on the PSI page?

We recently learned that a commercial entity has taken Psi's source code and made a closed source product from it. They have chosen not to release the source to their derivative work, thus violating the terms of the Psi licence, the GPL.

We are currently in talks with both the FSF and this commercial entity, and we'll be sure to let you all know if and when it's resolved. To protect the aforementioned company from hordes of angry Psi users and GPL advocates, we choose not to disclose their name. Don't even ask us, we won't tell... unless, of course, they decide to continue using the Psi code without releasing the source to their product, then you can have them.

Re:Great.......?

[Zeinfeld]

The organisation seems to be very slow moving, full of politics - and also, full of clever minds. It is ofcourse good to get official recognition and other good things that can come out of it, but one of the obvious minuses I see is: it s ..l ...o ...w .e..s. d...o...w...n . . .t..h..e d..e...v...e..l..o..p...m..e...n.....?

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.