able to display the unencoded text if the character set
          is "US-ASCII".  For the ISO-8859-* character sets, the
          mail reading program must at least be able to display
          the characters which are also in the US-ASCII set.

   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.

3.  Guidelines for Sending Email Data

   Internet email is not a perfect, homogeneous system.  Mail may become
   corrupted at several stages in its travel to a final destination.
   Specifically, email sent throughout the Internet may travel across
   many networking technologies. Many networking and mail technologies
   do not support the full functionality possible in the SMTP transport
   environment.  Mail traversing these systems is likely to be modified
   in order that it can be transported.

   There exist many widely-deployed non-conformant MTAs in the Internet.
   These MTAs, speaking the SMTP protocol, alter messages on the fly to
   take advantage of the internal data structure of the hosts they are
   implemented on, or are just plain broken.





 
RFC 2049                    MIME Conformance               November 1996


   The following guidelines may be useful to anyone devising a data
   format (media type) that is supposed to survive the widest range of
   networking technologies and known broken MTAs unscathed.  Note that
   anything encoded in the base64 encoding will satisfy these rules, but
   that some well-known mechanisms, notably the UNIX uuencode facility,
   will not.  Note also that anything encoded in the Quoted-Printable
   encoding will survive most gateways intact, but possibly not some
   gateways to systems that use the EBCDIC character set.

    (1)   Under some circumstances the encoding used for data may
          change as part of normal gateway or user agent
          operation.  In particular, conversion from base64 to
          quoted-printable and vice versa may be necessary.  This
          may result in the confusion of CRLF sequences with line
          breaks in text bodies.  As such, the persistence of
          CRLF as something other than a line break must not be
          relied on.

    (2)   Many systems may elect to represent and store text data
          using local newline conventions.  Local newline
          conventions may not match the RFC822 CRLF convention --
          systems are known that use plain CR, plain LF, CRLF, or
          counted records.  The result is that isolated CR and LF
          characters are not well tolerated in general; they may
          be lost or converted to delimiters on some systems, and
          hence must not be relied on.

    (3)   The transmission of NULs (US-ASCII value 0) is
          problematic in Internet mail.  (This is largely the
          result of NULs being used as a termination character by
          many of the standard runtime library routines in the C
          programming language.) The practice of using NULs as
          termination characters is so entrenched now that
          messages should not rely on them being preserved.

    (4)   TAB (HT) characters may be misinterpreted or may be
          automatically converted to variable numbers of spaces.
          This is unavoidable in some environments, notably those
          not based on the US-ASCII character set.  Such
          conversion is STRONGLY DISCOURAGED, but it may occur,
          and mail formats must not rely on the persistence of
          TAB (HT) characters.

    (5)   Lines longer than 76 characters may be wrapped or
          truncated in some environments.  Line wrapping or line
          truncation imposed by mail transports is STRONGLY
          DISCOURAGED, but unavoidable in some cases.
          Applications which require long lines must somehow




 
RFC 2049                    MIME Conformance               November 1996


          differentiate between soft and hard line breaks.  (A
          simple way to do this is to use the quoted-printable