NOTE ON ENCODING RESTRICTIONS: Though the prohibition against
      using content-transfer-encodings on data of type multipart or
      message may seem overly restrictive, it is necessary to prevent
      nested encodings, in which data are passed through an encoding
      algorithm multiple times, and must be decoded multiple times in
      order to be properly viewed.  Nested encodings add considerable
      complexity to user agents: aside from the obvious efficiency
      problems with such multiple encodings, they can obscure the basic
      structure of a message.  In particular, they can imply that
      several decoding operations are necessary simply to find out what
      types of objects a message contains.  Banning nested encodings may
      complicate the job of certain mail gateways, but this seems less
      of a problem than the effect of nested encodings on user agents.

      NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
      TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding
      could be inferred from the characteristics of the Content-Type
      that is to be encoded, or, at the very least, that certain
      Content-Transfer-Encodings could be mandated for use with specific
      Content-Types. There are several reasons why this is not the case.
      First, given the varying types of transports used for mail, some
      encodings may be appropriate for some Content-Type/transport
      combinations and not for others.  (For example, in an 8-bit
      transport, no encoding would be required for text in certain
      character sets, while such encodings are clearly required for 7-
      bit SMTP.)  Second, certain Content-Types may require different
      types of transfer encoding under different circumstances. For
      example, many PostScript bodies might consist entirely of short
      lines of 7-bit data and hence require little or no encoding.
      Other PostScript bodies (especially those using Level 2
      PostScript's binary encoding mechanism) may only be reasonably
      represented using a binary transport encoding. Finally, since
      Content-Type is intended to be an open-ended specification
      mechanism, strict specification of an association between
      Content-Types and encodings effectively couples the specification
      of an application protocol with a specific lower-level transport.
      This is not desirable since the developers of a Content-Type
      should not have to be aware of all the transports in use and what
      their limitations are.

      NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64
      encodings are designed so that conversion between them is
      possible.  The only issue that arises in such a conversion is the
      handling of line breaks.  When converting from quoted-printable to
      base64 a line break must be converted into a CRLF sequence.
      Similarly, a CRLF sequence in base64 data must be converted to a
      quoted-printable line break, but ONLY when converting text data.





 
RFC 1521                          MIME                    September 1993


      NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in
      earlier drafts of this memo, regarding the model for when email
      data was to be converted to canonical form and encoded, and in
      particular how this process would affect the treatment of CRLFs,
      given that the representation of newlines varies greatly from
      system to system, and the relationship between content-transfer-
      encodings and character sets.  For this reason, a canonical model
      for encoding is presented as Appendix G.

5.1.  Quoted-Printable Content-Transfer-Encoding

   The Quoted-Printable encoding is intended to represent data that
   largely consists of octets that correspond to printable characters in
   the ASCII character set.  It encodes the data in such a way that the
   resulting octets are unlikely to be modified by mail transport.  If
   the data being encoded are mostly ASCII text, the encoded form of the
   data remains largely recognizable by humans.  A body which is
   entirely ASCII may also be encoded in Quoted-Printable to ensure the
   integrity of the data should the message pass through a character-
   translating, and/or line-wrapping gateway.

   In this encoding, octets are to be represented as determined by the
   following rules:

      Rule #1: (General 8-bit representation) Any octet, except those
      indicating a line break according to the newline convention of the
      canonical (standard) form of the data being encoded, may be
      represented by an "=" followed by a two digit hexadecimal
      representation of the octet's value.  The digits of the
      hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".
      Uppercase letters must be used when sending hexadecimal data,
      though a robust implementation may choose to recognize lowercase
      letters on receipt.  Thus, for example, the value 12 (ASCII form
      feed) can be represented by "=0C", and the value 61 (ASCII EQUAL
      SIGN) can be represented by "=3D".  Except when the following
      rules allow an alternative encoding, this rule is mandatory.

      Rule #2: (Literal representation) Octets with decimal values of 33
      through 60 inclusive, and 62 through 126, inclusive, MAY be
      represented as the ASCII characters which correspond to those
      octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN
      through TILDE, respectively).