Internet Engineering Task Force

Hell it must have been a great place to be in the good old days. In fact it still is exciting to meet so many very very bright minds all in one place. But most of them would agree that IETF has become a very political place, where politics often weigh heavier than the actual technological issues.

I wouldn't go as far as saying that money can buy you an RFC, but you could quite easily spot RFCs in the long list that never deserved to be published.

Running a standards institution must be a horrible job no matter how. And then you have to look at the results. The big innovations on the Internet almost always circumvent the IETF. HTTP didn't even ask IANA for a port number. Tim just started using 80, which was in fact assigned to something else.

Help me come up with big achievements of the IETF.

• The MIME extension to SMTP has become more of a platform for SPAM than actually being useful at file transfer (any messenger tool is a better idea, or FTP or HTTP or even IRC's DCC. base64-encoded file transfer consumes more bandwidth than any of those).
• IP Multicast is an impressive work of art, but in the end it didn't solve the scalability issue.
• SIP was just a minor item of the IP Multicast protocol suite, until a telecom person raised his hand in a SIP working group meeting and asked if SIP could be applied to telephony. He could have tried a proprietary solution instead, but thought going through IETF would be more strategic. Skype demonstrates that it's never too late for a proprietary solution, and IAX shows how an open source project can successfully establish an alternative to SIP on the fly.
• Was it really a good idea to grant RFCs to XMPP with all the bugs in it? See Jabber if you can take the details. Why did IRC only get to publish informational RFCs instead of sitting down to fix the protocol? After all it was the only applicative realtime multicast protocol at the time.

It was a wrong decision of the IESGs of all times to think the Internet does not need a universal messaging protocol beyond UDP and TCP. I don't mean chat. I mean the mess that we have today of messaging and RPC being done on top of HTTP, like OpenID, OAuth, RSS, SOAP, XML-RPC. HTTP is so very much not designed to be the functionality superhighway, yet it is the inefficient industry standard it is today. IESG always said every little application should have its own protocol, thus people turned to practical dirty hacks: Putting stuff on top of a protocol which does something vaguely similar, gets through firewalls, never mind the overheads.

Still, being at an IETF Meeting is a great experience. Absolutely try it out.

For more on the IETF, look out for Standards.