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