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.