Insanity and the standards process

Microsoft's OOXML may have stumbled on the standards fast track, but the format is already implemented in Office 2007.

[The opinions expressed here are mine alone, and not those of Google, Inc. my employer.]

Jeremy AllisonCommentary: Until recently I didn't think much about International Standards Organization (ISO) standards. I guess most people are the same. ISO standards cover a range of different things such as pipe threads (ISO standard number 7) to shoe sizes (ISO 9407) to photographic film speeds (ISO 5800). Although they're invisible to the lay person, much of modern life is made easier by their international adoption; think how difficult it would be to buy shoes from China without standard sizes.

In the computing world, ISO standards have a mixed record. Back in the early days of computer networking, starting around 1977, ISO developed a networking protocol standard which ended up being completely sidelined when it ran into the working TCP/IP protocol standard that became the Internet. I still remember going to presentations that confidently predicted the transition of all networks to the ISO seven layer networking stack. However, ISO did standardize the UNIX commands and application programming interface POSIX, which brought some sanity to the fractured worlds of proprietary UNIX implementations. It seems that computing ISO standards work better when they standardize something that already exists.

But standards don't rule the computing world. Today, 92 percent of desktops and now 70 percent of servers run the completely proprietary and non-standardized Microsoft Windows operating system. Even though POSIX was an ISO standard the weight of the market got behind the de-facto standard of Windows. Network effects matter. The definition of Microsoft Windows is completely under the control of its creator, and "Windows" is defined as what Microsoft says it is, nothing more or less. (Steve Ballmer famously claimed Microsoft could bundle a "ham sandwich" into Windows if they so desired.)

Microsoft has historically had an ambivalent view of standards. An example from my own background of file serving protocols serves as an illustration here. In the days when Novell Netware dominated the file serving world Microsoft was a great supporter of standards. They published the specifications of their own protocols (then called Server Message Block, or SMB) and supported implementations on other platforms than Windows. They even paid the expenses for my colleague Andrew Tridgell to fly business class from Australia to Redmond, Washington to attend the first conference on the subject (I had to fund myself, but was only flying up from California so I'm not too jealous). They even proposed the SMB protocol (now renamed the "Common Internet File System", CIFS) as an Internet (IETF) standard.

Once Netware was defeated by Windows NT, their attitudes changed, and the flow of information stopped. Proprietary modifications to core protocols like the Kerberos authentication protocol followed, and these changes were treated as trade secrets, patented if possible, and only released under restrictive non-disclosure agreements, if released at all. (Many of them weren't until the US government mandated Microsoft Communications Protocol Licensing Program (MCPP) as part of the anti-trust settlement.)

This historical record makes the recent global activities over the "Office Open XML" (OOXML) document format so interesting. In this case a competitor manged to place a stake in the ground first. The Open Source project OpenOffice.org (managed by Sun, a fierce Microsoft competitor) spawned an ISO standard for office document storage called "Open Document Format" (ODF), which was adopted by several other office automation software packages, none of them with a fraction of the size of the market share of the leader, Microsoft Office, of course. The danger in this for Microsoft was that once an official ISO standard for office documents existed, governments could potentially be lobbied to adopt it as their official document standard. ODF is a format that Microsoft Office does not currently support and Microsoft does not control.

Microsoft countered by creating the OOXML office document format, which was made the standard in Microsoft Office 2007 and donated it to the European Computer Manufacturers Association (ECMA) to shepherd it through the ISO standardization process. ECMA was so confident of the adoption of OOXML that they put it into a "fasttrack" process, which would have allowed the document to become a standard with no further modification.

As part of my job I had to read the OOXML standard document. At over six-thousand pages (compared with the eight hundred and sixty seven pages for the ODF standard) it wasn't a trivial task. There are already enough web sites and blogs (http://www.noooxml.org for example) detailing the technical deficiencies already found within OOXML that I won't bother to repeat them here. Suffice it to say there were enough problems that if the ISO procedures were followed to the letter it should not have gone into the fast-track procedure, but should have gone into a process designed to fix technical problems with the standard instead.

But ISO standards have a much more political dimension to them than Internet (IETF) or World Wide Web Consortium (W3C) standards. Every country can vote, although not all chose to do so. So we saw over the past few weeks some strange and rather irregular national positions coming to light. My own favorites were Cuba voting "yes" to the fast- tracking of OOXML, even though Microsoft is prohibited by the US Government from selling any software on the island that might even be able to read and write the new format, and Azerbaijan's "yes" vote, even though OOXML as defined isn't able to express a Web URL address in Azeri, their official language.

As has been widely reported, the "fast-track" vote failed, although it was voted down only by a one percent margin (in other words it was a very close thing). So the next step in the complex ISO rules is a comment resolution meeting, at which all standards bodies with a stake in the process will meet and go though all of the technical comments and try and move the process forward in good faith.

At the meeting ECMA (and presumably Microsoft as an ECMA member) will have to promise to make changes to a format that is already implemented in Microsoft Office 2007, and is already shipping in the volume only the market leader can deliver.

This reminds me of an exchange of email during the efforts by Microsoft to standardize the file sharing protocol that Samba implements (CIFS). After a white paper was published demonstrating a man-in-the-middle security attack against the current protocol Microsoft responded by publishing a specification for cryptographically signing the packet exchange. This change fixed the security hole and was a good first response to the attack. Unfortunately, after analysis by some of the experts on the list we discovered that there were some theoretical holes to the new signing protocol, which needed a few trivial changes in order to fix and improve the security. After these proposals were submitted, the response came back from Microsoft that although the fixes were valid, unfortunately the code was already written and was going to be shipped in the next service pack. End of discussion. It wasn't even in a shipping product yet, but the specification was determined to be unchangeable as they didn't want to change their existing code.

I hope the comment resolution meeting for OOXML goes better than the CIFS one did. Still, I have hopes that things might be different this time. After all, I wouldn't be developing Free Software/Open Source code if I didn't think things could ever be changed, like a 92 percent desktop market share, or a 70 percent server market share. Or maybe that just makes Free Software developers as certifiable as the proprietary software vendors say we are :-).

After all, as Albert Einstein is reported to have said: "The definition of insanity is doing the same thing over and over and expecting different results."


Jeremy Allison is one of the lead developers on the Samba Team, a group of programmers developing an Open Source Windows compatible file and print server product for UNIX systems. Developed over the Internet in a distributed manner similar to the Linux system, Samba is used by all Linux distributions as well as many thousands of corporations worldwide. Jeremy handles the co-ordination of Samba development efforts and acts as a corporate liason to companies using the Samba code commercially. He works for Google, Inc. who fund him to work full-time on improving Samba and solving the problems of Windows and Linux interoperability.

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All