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."
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
Jabber Inc. does not have "patents on stuff you need to implement Jabber" (check the USPTO for the facts). The company does own a trademark on "JABBER" but that will be transitioned to the non-profit Jabber Software Foundation. The Jabber protocol is as free as air, and there are multiple open and free implementations of it (server, libraries, clients).
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/
I doubt that either FTP or SMTP would be passed in their current form today.
SMTP was introduced as a quick and dirty 'Gordian knot' solution to email transport. The good part is that it was introduced as a far simpler solution than the competing UUCP, MTP etc specs...
The bad part is that SMTP has plenty of features that are poorly thought out and still more that are not well specified. For example most of the problems with mailing lists could have been avoided if the design of SMTP had considered mailing lists more thoroughly.
Now as it happens none of the alternatives to SMTP address the real problems of email any better than SMTP. However the real failing of the IETF process is that once something like SMTP becomes a standard changing the spec is far harder than the initial design. Only a small part of that difficulty is the problem of compatibility with the legacy base.
In the early days of IETF specifications were published as 'Request For Comments' - the original concept was that they were nothing more than a lengthy email. Today there is layer upon layer of protocol.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/