Fifteen years earlier saw the publication of RFC 733, Standard for the format of ARPA network text messages. (The “ARPA network” was the forerunner of today’s Internet.) This established the rules that allowed computers to exchange e-mail, but the phrase “text messages” in the title of that RFC is telling. According to that standard, e-mail consisted solely of plain text, specifically text arranged in relatively short lines. Furthermore, the text could only be expressed with ASCII characters, that is, the fifty-two upper- and lowercase letters of the English alphabet, the ten digits, and thirty-odd typographical characters, and no others.
In those bad old days, you could not attach a picture or a spreadsheet and mail it to someone; you had to settle for letting your correspondent know from which directory on which FTP server they could download your file. You could not emphasize text with boldface or italics, you had to settle for emphasis that looked *like this*. And if you wanted to say something in Russian or Greek or Hebrew or Chinese or Thai, you had to transliterate it using English letters (“na zdorovia”). You couldn’t even include the accent in “Buenos días.”
By the early 1990’s, the need for these expanded abilities was starting to be felt, in part due to the burgeoning of the Internet, in part due to the ever-increasing storage and display capabilities of the computers attached thereto, and in part due to experiments such as the Andrew project, which I worked on with Nathaniel Borenstein and others. In the Andrew project, users running the appropriate software within a closed community (such as the Carnegie Mellon campus) could exchange rich e-mail with fancy text styles and a wide assortment of attachment types (or “insets” in Andrew parlance), including pictures, sound, and an inline “hyperlink” object (due to my friend Michael McInerny) that prefigured the invention of the World Wide Web.
As I say, users within a closed community could use Andrew and other systems like it, but they could not exchange “rich” mail with the Internet at large. There was no widely accepted standard for the format of such messages. The only widely accepted Internet mail format was RFC 822, which by this time had superseded but not meaningfully expanded upon RFC 733. Like its predecessor, it too insisted on treating e-mail as short lines of plain ASCII text, and across the Internet there was a huge installed base of RFC 822 e-mail systems. There was no possibility of replacing all those e-mail systems with anything that could handle other kinds of content. To complicate matters, the conformance of most e-mail systems to the rules in RFC 822 (and its companion, RFC 821, which dealt with the details of transporting RFC-822 data between computers) was only approximate in many cases. Cobbled together as they were by amateurs and academics, the mail systems of the early Internet often got things wrong.
All of which I mention in order to highlight the genius of Borenstein and Freed. With MIME they invented a collection of mechanisms for expressing and transporting all conceivable kinds of e-mail content, including text using foreign alphabets, that worked entirely within the rules of RFC 821 and RFC 822. By variously encoding, labeling, and encapsulating the many data objects in a rich e-mail message, they were able to make it look like a standards-compliant text message, consisting of short ASCII lines. They even managed to work around the many different ways in which most mail systems failed to obey the standards.
In this way, MIME messages could be exchanged across the Internet without the need for any of the existing mail software even to be aware that the messages were special. Of course, if you happened to have one of the handful of MIME-aware mail systems that existed at first, it would decode the message and display it richly, giving you the full benefit of MIME. But if your mail system was not MIME-aware, that was OK; your mail program would simply show you the un-decoded MIME content, which, thanks to more ingenious MIME mechanisms such as “the preamble,” “quoted-printable,” and “multipart/alternative,” was usually somewhat legible anyway.
Thus did MIME take over the e-mail infrastructure of the Internet in viral fashion. Immediately upon its introduction, it worked at least bearably for everyone, and terrifically for some. Of course everyone wanted it to work terrifically, so bit by bit, users across the Net upgraded their mail systems to be MIME-aware.
After I left Carnegie Mellon I went to work for Z-Code, which made e-mail software called Z-Mail. No sooner did I start there, trying to convey the wonders of the Andrew system to my new coworkers, than the MIME standard appeared, and Z-Code went to work making Z-Mail MIME-aware. Thus by Nathaniel’s efforts was my career not only begun but perpetuated. I write e-mail software professionally to this day.
Nowadays users think nothing of sending e-mail with pictures, spreadsheets, and even movies attached, and being unable to receive and view them properly is now the rare exception and not the rule. But the infrastructure is largely the same as it was in 1992. At bottom, e-mail messages are still arranged as short lines of ASCII text. Only MIME makes possible such wonders as Asian Viagra image spam.
The rate-of-climb indicator, also called the vertical-speed indicator or VSI, is one of six instruments in the standard instrument cluster familiar to airplane pilots. It reports the rate at which the airplane’s altitude is changing, in hundreds of feet per minute. (Interesting fact: in an unpressurized airplane cabin, a comfortable rate of descent is five hundred feet per minute. Much more than that and passengers will begin to feel ear pain from the pressure changes. So a pilot flying 5,000 feet above the elevation of his or her destination should begin descending while still ten minutes away from the airfield.)
The altimeter, another standard instrument, is much easier to understand. It registers the airplane’s height above sea level by measuring the ambient air pressure. (Interesting fact: the ambient air pressure runs to the altimeter through a tube originating at a tiny hole in the skin of the plane called the “static port.” An airplane in flight affects the pressure of the air all around it; the static port is strategically placed where the effect on the surrounding air pressure is neutral.) Air pressure decreases at a pretty constant rate the higher you go, so if you know the pressure at sea level (a setting that changes from place to place and from hour to hour — pilots periodically get the setting from a radio broadcast and adjust a knob on the altimeter), and you know the air pressure, then you know your altitude. The altimeter is nothing but a funny-looking barometer calibrated in feet above sea level.
Even the airspeed indicator, which is a bit cleverer, is easy to understand. It uses two sources of air pressure: the “static” air pressure (from the aforementioned static port), and the “ram” air pressure, which is the pressure of the oncoming air as measured by a tube (the “pitot” tube, rhymes with Frito) pointing forward. Via some simple plumbing, the static pressure is subtracted from the ram pressure and the result is shown on the airspeed dial, calibrated in knots or in miles per hour.
Yesterday I finally got around to resetting the clock on my answering machine at home after 
One of Goldstein’s friends-and-clients, in turn, was a photographer named 
As I toiled at the computer on a wide variety of projects — now programming, now data entry, now educating myself further in CP/M and later 
He was among the best in the business and lots of big-name clients came through the studio. Very often they purchased excessive amounts of food for the shoot and left it behind after the shoot was done. Many were the times I lugged a dozen steaks, a few hundred slices of American cheese, or a crate of Ronzoni spaghetti home on the subway.