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

Top: 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

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.

          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.

          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
5.2. Base64 Content-Transfer-Encoding

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

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