Chapter Introduction (Introduction to MIME)
[previous]
[next]
[table of contents] [index]
Someday, it'll be taken for granted that you can send email
containing "multimedia" information:
characters from non-English languages,
motion pictures, sound bites, spreadsheets, hypertext links,
interactive order forms, and other interesting stuff.
Until 1992, "standard" email was mostly restricted to
plain English text.
Multimedia email messages are a recent innovation,
and not everyone in the world can deal with them.
However, with the new MIME (Multipurpose Internet Mail Extensions) functions in MH, you can read and send multimedia
messages now.
Several popular MUAs have fairly complete MIME support; more will support
it soon.
To appreciate the changes MIME brought and why it works the way
it does, here's some email history.
Email on UNIX started in the days when a tty was actually a teletype.
(A teletype resembles a typewriter.
It prints electrically-transmitted text onto paper.
I used to run a teletype for Western Union, the telegraph company in the
USA, back when people used to send telegrams.
Now I do feel old. :-))
Digital pictures and sound, and the high-speed networks needed to carry them,
were research curiosities.
Back then,
email messages (at least in the United States, where a lot of the UNIX
development happened) were ASCII text -- and there was more than one
version of ASCII.
(Strictly speaking, the version of ASCII used in "standard" email
is named US-ASCII or ANSI X3.4-1986.
But the acronym most people seem to use for "printable English text"
is just "ASCII."
At the risk of being inaccurate, I'll use "ASCII" in this book.)
"Networks," for most people, were UUCP links over dialup modems;
in many cases, email was transmitted with 7-bit-wide data paths that couldn't
carry binary (8-bit, non-ASCII) text.
When you needed to email binary text, such as an executable program or a
compressed archive file,
you preprocessed the binary file through the ASCII converter program
uuencode(1).
The recipient used
uudecode(1)
to restore the binary file.
This worked pretty well -- as long as you were
computer-literate enough to know what to do with the binary text once
you'd uudecoded it, and as long as your version of uuencode
was compatible with the other person's.
The sidebar ASCII, bits, etc. has more information.
As networks and computing evolved, uuencode wasn't enough.
Users wanted easier and more reliable ways to handle binary text
automatically.
Internet mail transfer still used a 7-bit-wide path.
Worse, uuencoded text was munged (changed) by some non-UUCP
networks and gateways between networks.
Users and vendors found solutions, but these different
solutions wouldn't always work with each other.
The answer is MIME.
This chapter introduces it.
More and more email user agents support MIME.
Under UNIX, Pine, Elm, Z-Mail and MH do.
In personal computer environments, Eudora and Z-Mail
handle MIME; major vendors like Lotus and Microsoft
are rumored to have support coming.
To "support" MIME, a system does not have to handle every function
that's in
the RFC 1521 specification -- but, as more people use MIME, you can
expect to see better support.
(The MH support is fairly complete.)
As mail programs evolve, MIME and related standards are evolving, too:
supporting more types of data, clarifying problem areas, and so on.
If your MH system is set up correctly, you can probably read incoming mail
without reading this chapter:
MH will "do the right thing."
If you need to send messages that contain anything except ASCII text,
though, you'll need to know a little about MIME and how MH handles it.
(You'll also need to read the chapters that explain how to read and send
mail with MH.
This chapter gives background information about MIME that isn't in
those chapters.)
And if you want to understand what's in the messages you read, or you want to
be able to change the way MH treats MIME messages, let's get started!
[Table of Contents] [Index]
[Previous: Caution About MH Files and Newline Characters]
[Next: Overview of MIME Messages]
|
