Connected: An Internet Encyclopedia
5. The Content-Transfer-Encoding Header Field

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1521
Prev: 4. The Content-Type Header Field
Next: 5.1. Quoted-Printable Content-Transfer-Encoding

5. The Content-Transfer-Encoding Header Field

5. The Content-Transfer-Encoding Header Field

Many Content-Types which could usefully be transported via email are represented, in their "natural" format, as 8-bit character or binary data. Such data cannot be transmitted over some transport protocols. For example, RFC 821 restricts mail messages to 7-bit US-ASCII data with lines no longer than 1000 characters. It is necessary, therefore, to define a standard mechanism for re- encoding such data into a 7-bit short-line format. This document specifies that such encodings will be indicated by a new "Content- Transfer-Encoding" header field. The Content-Transfer-Encoding field is used to indicate the type of transformation that has been used in order to represent the body in an acceptable manner for transport.

Unlike Content-Types, a proliferation of Content-Transfer-Encoding values is undesirable and unnecessary. However, establishing only a single Content-Transfer-Encoding mechanism does not seem possible. There is a tradeoff between the desire for a compact and efficient encoding of largely-binary data and the desire for a readable encoding of data that is mostly, but not entirely, 7-bit data. For this reason, at least two encoding mechanisms are necessary: a "readable" encoding and a "dense" encoding.

The Content-Transfer-Encoding field is designed to specify an invertible mapping between the "native" representation of a type of data and a representation that can be readily exchanged using 7 bit mail transport protocols, such as those defined by RFC 821 (SMTP). This field has not been defined by any previous standard. The field's value is a single token specifying the type of encoding, as enumerated below. Formally:

   encoding := "Content-Transfer-Encoding" ":" mechanism

   mechanism :=     "7bit"  ;  case-insensitive
                  / "quoted-printable"
                  / "base64"
                  / "8bit"
                  / "binary"
                  / x-token

These values are not case sensitive. That is, Base64 and BASE64 and bAsE64 are all equivalent. An encoding type of 7BIT requires that the body is already in a seven-bit mail-ready representation. This is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.

The values "8bit", "7bit", and "binary" all mean that NO encoding has been performed. However, they are potentially useful as indications of the kind of data contained in the object, and therefore of the kind of encoding that might need to be performed for transmission in a given transport system. In particular:

       "7bit" means that the data is all represented as short
            lines of US-ASCII data.

       "8bit" means that the lines are short, but there may be
            non-ASCII characters (octets with the high-order
            bit set).

       "Binary" means that not only may non-ASCII characters
            be present, but also that the lines are not
            necessarily short enough for SMTP transport.

The difference between "8bit" (or any other conceivable bit-width token) and the "binary" token is that "binary" does not require 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 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.

      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.

      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.

      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.

Next: 5.1. Quoted-Printable Content-Transfer-Encoding

Connected: An Internet Encyclopedia
5. The Content-Transfer-Encoding Header Field