Looking Backwards: Eight Lessons from Twenty Years of MIME

Sharing the credit is remarkably useful in leading argumentative technology gurus to consensus. At the end of the MIME standard, there's a long list of acknowledgements of people who helped draft the standard. I found that adding someone to this list made them less argumentative. There's no downside to sharing credit generously.

After this week's celebration of MIME's 20th anniversary, I expected to feel sated enough leave it alone for another 20 years. But I think it might be worth writing just a bit more, summarizing the lessons MIME might teach about how to create a successful technology standard.

1.  Where you work matters. I devoted roughly 2 years of my life to defining MIME. Not that many employers would tolerate that, but I was a researcher at Bellcore, with a broad mandate to promote more bandwidth use in the future. Other companies support standards work, but few to the extent that Bellcore supported me. It would have been hard to create MIME while working for most technology companies.

2.  Address a real need. Most people didn't know it yet, but the world really needed an interoperable, open standard for multimedia data; almost everything on today's Internet reflects this reality. I realized it early because I had built a multimedia email system at Carnegie Mellon, and Steve Jobs had followed up with something similar at NeXT, but the two systems couldn't exchange multimedia data with each other. I knew that some day I wanted to get pictures of my grandchildren by email, but I didn't want my kids and I to have to use the same email software.

3.  Address another real need. Any standard will face barriers to adoption, at least from the inertia of the installed base; meeting two major needs can increase the number of people who care, and hence the pressure for adoption. In the case of MIME, multimedia junkies like me were able to make common cause with the deep desire of people around the world to send email in languages other than English. These problems could have been solved separately, but a standard that solved both surely hastened adoption, perhaps even making the difference between success and failure.

4.  Connect the dots and share the credit. Some successful teams self-assemble, but behind most successful teams is a visionary who figured out what parts needed to be brought together. In the case of MIME, the visionary was the late Einar Stefferud, who introduced me to Ned Freed and suggested that we collaborate on the work that became MIME.

5.  Keep your goals modest, realistic, and limited. I know, extending email to include all human languages and all media types doesn't sound like a limited goal, but the truth is that we achieved those goals via a very limited mechanism. We avoided trying to settle as many battles as we could, preferring instead to create a framework for the debate to continue. Thus, MIME doesn't declare  JPEG a better image format than GIF, or PDF superior to HTML and DOC; we just made it possible to unambiguously define labels for these types, such as image/gif and image/jpeg. (The wisdom of this approach is clearest when you consider applying it to the natural language problem: had we tried to specify that everyone should always speak English, or Chinese, we would never have found consensus.)

6.  Acknowledge that your vision is limited. Standards designers tend to overspecify; MIME was designed in the aftermath of X.400, a proposed email standard that failed in large part due to its complexity. Rather than try to imagine every future use of MIME, we created an initial set of media types, and a registry for defining new ones. The result is that the number of media types has grown from under 20 in the original standard to over 1,300 today.

7.  Worry about branding and marketing. This is the lesson I find hardest to convey to technically-oriented people, who tend to dismiss anything non-technical as fluff. The fact is, technologies are adopted (or not) by people, who are subject to a wide range of influences. Good publicity and catchy names really matter.

In fact, the best advice I've gotten in my entire career came from Dave Crocker, the author of the original Internet email standards, who convinced me to come up with a clever name or acronym. I laughed, but he was insistent, so after 15 minutes I came up with "Multipurpose Internet Mail Extensions" -- MIME which, because it is much catchier than, say, RFC 1341, is often used conversationally.

Essentially, because people have heard the name MIME and perhaps have a vague idea what it is, I have instant credibility with total strangers.

8.  Give it away. If you want to see a standard adopted, it helps to produce a solid implementation and release it as open source software. I built a software package called metamail, a standalone MIME implementation for UNIX that could be plugged into any mail reader, and released it to the world when the MIME spec was stable. Combine real need and free software, and things happen fast. Within a few days, I received patches that made it work on DOS, while Macintosh, Amiga, and others were not far behind. Again, credit is due Bellcore, for supporting building such software only to give it away.

There are other lessons, I'm sure, but most relate to technical details and are unlikely to be of wider value. So now, perhaps, I can stop writing about MIME for another ten or twenty years and see what it looks like then.

Photo CC via Len RadinDave GrayÞorgerður Olafsdottir on Flickr