5. The Content-Transfer-Encoding Header Field (original) (raw)

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

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.

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

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