Connected: An Internet Encyclopedia
Appendix A -- Minimal MIME-Conformance

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1521
Prev: 11. Acknowledgements
Next: Appendix B -- General Guidelines For Sending Email Data

Appendix A -- Minimal MIME-Conformance

Appendix A -- Minimal MIME-Conformance

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:

  1. Always generate a "MIME-Version: 1.0" header field.

  2. 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.

  3. 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.

  4. 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.

  5. 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.


Next: Appendix B -- General Guidelines For Sending Email Data

Connected: An Internet Encyclopedia
Appendix A -- Minimal MIME-Conformance