Previous: 11. Acknowledgements
Next: Appendix B -- General Guidelines For Sending Email Data
The mechanisms described in this document are open-ended. It is
definitely not expected that all implementations will support all of
the Content-Types described, nor that they will all share the same
extensions. In order to promote interoperability, however, it is
useful to define the concept of "MIME-conformance" to define a
certain level of implementation that allows the useful interworking
of messages with content that differs from US ASCII text. In this
section, we specify the requirements for such conformance.
A mail user agent that is MIME-conformant MUST:
- Always generate a "MIME-Version: 1.0" header field.
- Recognize the Content-Transfer-Encoding header field, and
decode all received data encoded with either the quoted-printable
or base64 implementations. Encode any data sent that is not in
seven-bit mail-ready representation using one of these
transformations and include the appropriate Content-Transfer-
Encoding header field, unless the underlying transport mechanism
supports non-seven-bit data, as SMTP does not.
- Recognize and interpret the Content-Type header field, and
avoid showing users raw data with a Content-Type field other than
text. Be able to send at least text/plain messages, with the
character set specified as a parameter if it is not US-ASCII.
- Explicitly handle the following Content-Type values, to at
least the following extents:
- Text:
- Recognize and display "text" mail
with the character set "US-ASCII."
- Recognize other character sets at
least to the extent of being able
to inform the user about what
character set the message uses.
- Recognize the "ISO-8859-*" character
sets to the extent of being able to
display those characters that are
common to ISO-8859-* and US-ASCII,
namely all characters represented
by octet values 0-127.
- For unrecognized subtypes, show or
offer to show the user the "raw"
version of the data after
conversion of the content from
canonical form to local form.
- Message:
- Recognize and display at least the
primary (822) encapsulation.
- Multipart:
- Recognize the primary (mixed)
subtype. Display all relevant
information on the message level
and the body part header level and
then display or offer to display
each of the body parts individually.
- Recognize the "alternative" subtype,
and avoid showing the user
redundant parts of
multipart/alternative mail.
- Treat any unrecognized subtypes as if
they were "mixed".
- Application:
- Offer the ability to remove either of
the two types of Content-Transfer-
Encoding defined in this document
and put the resulting information
in a user file.
- Upon encountering any unrecognized Content- Type, an
implementation must treat it as if it had a Content-Type of
"application/octet-stream" with no parameter sub-arguments. How
such data are handled is up to an implementation, but likely
options for handling such unrecognized data include offering the
user to write it into a file (decoded from its mail transport
format) or offering the user to name a program to which the
decoded data should be passed as input. Unrecognized predefined
types, which in a MIME-conformant mailer might still include
audio, image, or video, should also be treated in this way.
A user agent that meets the above conditions is said to be MIME-conformant.
The meaning of this phrase is that it is assumed to be
"safe" to send virtually any kind of properly-marked data to users of
such mail systems, because such systems will at least be able to
treat the data as undifferentiated binary, and will not simply splash
it onto the screen of unsuspecting users. There is another sense in
which it is always "safe" to send data in a format that is MIME conformant,
which is that such data will not break or be broken by
any known systems that are conformant with RFC 821 and RFC 822. User
agents that are MIME-conformant have the additional guarantee that
the user will not be shown data that were never intended to be viewed
as text.
Previous: 11. Acknowledgements
Next: Appendix B -- General Guidelines For Sending Email Data