5. The Content-Transfer-Encoding Header Field
Up:Requests For Comments
Up:RFC 1521
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:
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:
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.
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:
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.
5. The Content-Transfer-Encoding Header Field