adherence to any limits on line length or to the SMTP CRLF semantics,
   while the bit-width tokens do require such adherence.  If the body
   contains data in any bit-width other than 7-bit, the appropriate
   bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"
   for unencoded 8 bit wide data).  If the body contains binary data,
   the "binary" Content-Transfer-Encoding token must be used.

      NOTE: The distinction between the Content-Transfer-Encoding values
      of "binary", "8bit", etc.  may seem unimportant, in that all of
      them really mean "none" -- that is, there has been no encoding of
      the data for transport.  However, clear labeling will be of
      enormous value to gateways between future mail transport systems
      with differing capabilities in transporting data that do not meet
      the restrictions of RFC 821 transport.

      Mail transport for unencoded 8-bit data is defined in RFC-1426
      [RFC-1426].  As of the publication of this document, there are no
      standardized Internet mail transports for which it is legitimate
      to include unencoded binary data in mail bodies.  Thus there are
      no circumstances in which the "binary" Content-Transfer-Encoding
      is actually legal on the Internet.  However, in the event that
      binary mail transport becomes a reality in Internet mail, or when
      this document is used in conjunction with any other binary-capable
      transport mechanism, binary bodies should be labeled as such using
      this mechanism.

      NOTE: The five values defined for the Content-Transfer-Encoding
      field imply nothing about the Content-Type other than the
      algorithm by which it was encoded or the transport system
      requirements if unencoded.

   Implementors may, if necessary, define new Content-Transfer-Encoding
   values, but must use an x-token, which is a name prefixed by "X-" to
   indicate its non-standard status, e.g., "Content-Transfer-Encoding:
   x-my-new-encoding".  However, unlike Content-Types and subtypes, the
   creation of new Content-Transfer-Encoding values is explicitly and
   strongly discouraged, as it seems likely to hinder interoperability
   with little potential benefit.  Their use is allowed only as the




 
RFC 1521                          MIME                    September 1993


   result of an agreement between cooperating user agents.

   If a Content-Transfer-Encoding header field appears as part of a
   message header, it applies to the entire body of that message.  If a
   Content-Transfer-Encoding header field appears as part of a body
   part's headers, it applies only to the body of that body part.  If an
   entity is of type "multipart" or "message", the Content-Transfer-
   Encoding is not permitted to have any value other than a bit width
   (e.g., "7bit", "8bit", etc.) or "binary".

   It should be noted that email is character-oriented, so that the
   mechanisms described here are mechanisms for encoding arbitrary octet
   streams, not bit streams.  If a bit stream is to be encoded via one
   of these mechanisms, it must first be converted to an 8-bit byte
   stream using the network standard bit order ("big-endian"), in which
   the earlier bits in a stream become the higher-order bits in a byte.
   A bit stream not ending at an 8-bit boundary must be padded with
   zeroes.  This document provides a mechanism for noting the addition
   of such padding in the case of the application Content-Type, which
   has a "padding" parameter.

   The encoding mechanisms defined here explicitly encode all data in
   ASCII.  Thus, for example, suppose an entity has header fields such
   as:

        Content-Type: text/plain; charset=ISO-8859-1
        Content-transfer-encoding: base64

   This must be interpreted to mean that the body is a base64 ASCII
   encoding of data that was originally in ISO-8859-1, and will be in
   that character set again after decoding.

   The following sections will define the two standard encoding
   mechanisms.  The definition of new content-transfer-encodings is
   explicitly discouraged and should only occur when absolutely
   necessary.  All content-transfer-encoding namespace except that
   beginning with "X-" is explicitly reserved to the IANA for future
   use.  Private agreements about content-transfer-encodings are also
   explicitly discouraged.

   Certain Content-Transfer-Encoding values may only be used on certain
   Content-Types.  In particular, it is expressly forbidden to use any
   encodings other than "7bit", "8bit", or "binary" with any Content-
   Type that recursively includes other Content-Type fields, notably the
   "multipart" and "message" Content-Types.  All encodings that are
   desired for bodies of type multipart or message must be done at the
   innermost level, by encoding the actual body that needs to be
   encoded.




 
RFC 1521                          MIME                    September 1993