Encoding header field for internet messages
A header field for describing multi-part email messages and how to decode each part.
Robinson, D. and R. Ullmann, "Encoding header field for internet messages", RFC 1154, DOI 10.17487/RFC1154, April 1990, <https://www.rfc-editor.org/info/rfc1154>.
@misc{rfc1154,
series = {Request for Comments},
number = 1154,
howpublished = {RFC 1154},
publisher = {RFC Editor},
doi = {10.17487/RFC1154},
url = {https://www.rfc-editor.org/info/rfc1154},
author = {D. Robinson and R. Ullmann},
title = {{Encoding header field for internet messages}},
pagetotal = 7,
year = 1990,
month = apr,
} RFC text
Contents
Network Working Group D. Robinson
Request for Comments: 1154 R. Ullmann
Prime Computer, Inc.
April 1990
Encoding Header Field for Internet Messages
1. Status of the Memo
This RFC proposes an elective experimental Encoding header field to
permit the mailing of multi-part, multi-structured messages.
The use of Encoding updates RFC 1049 (Content-Type), and is a
suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement)
[4,7,8].
Distribution of this memo is unlimited.
2. Introduction
RFC 822 [2] defines an electronic mail message to consist of two
parts, the message header and the message body, separated by an
apparently blank line.
The Encoding header field permits the message body itself to be
further broken up into parts, each part also separated from the next
by an apparently blank line.
Thus, conceptually, a message has a header part, followed by one or
more body parts, all separated by blank lines.
Each body part has an encoding type. The default (no Encoding field
in the header) is a message body of one part of type "text".
3. The Encoding Field
The Encoding field consists of one or more subfields, separated by
commas. Each subfield corresponds to a part of the message, in the
order of that part's appearance. A subfield consists of a line
count, a keyword defining the encoding, and optional information
relevant only to the specific encoding. The line count is optional
in the last subfield.
3.1. Format of the Encoding Field
The format of the Encoding field is:
[<count> <keyword> [<options>], ]* [<count>] <keyword> [<options>]
where:
<count> := a decimal integer
<keyword> := a single alphanumeric token starting with an alpha
<options> := keyword-dependent options
3.2. <count>
The line count is a decimal number specifying the number of text
lines in the part. Parts are separated by a blank line, which is not
included in the count of either the proceeding or following part.
Because a count always begins with a digit and a keywords always
begins with an letter, it is always possible to determine if the
count is present. (The count is first because it is the only
information of interest when skipping over the part.)
The count is not required on the last or only part.
3.3. <keyword>
The keyword defines the encoding type. The keyword is a common
single word name for the encoding type. The keywords are not case-
sensitive.
The list of standard keywords is intended to be the same as the list
used for the Content-Type: header described in [6]. This RFC
proposes additions to the list. Implementations can then treat
"Content-Type" as an alias of "Encoding", which will always have only
one body part.
3.4. <options>
The optional information is used to specify additional keyword-
specific information needed for interpreting the contents of the
encoded part. It is any sequence of tokens not containing a comma.
3.5. Encoding Version Numbers
In general, version numbers for encodings, when not actually
available within the contents of the encoded information, will be
handled as options.
3.6. Comments
Comments enclosed in parentheses may, of course, be inserted anywhere
in the Encoding field. Mail reading systems may pass the comments to
their clients. Comments must not be used by mail reading systems for
content interpretation; that is the function of options.
4. Encodings
This section describes some of the defined encodings used.
As with the other keyword-defined parts of the header format
standard, extensions in the form of new keywords are expected and
welcomed. Several basic principles should be followed in adding
encodings:
- The keyword should be the most common single word name for the
encoding, including acronyms if appropriate. The intent is that
different implementors will be likely to choose the same name for
the same encoding.
- Keywords not be too general: "binary" would have been a bad
choice for the "hex" encoding.
- The encoding should be as free from unnecessary idiosyncracies
as possible, except when conforming to an existing standard, in
which case there is nothing that can be done.
- The encoding should, if possible, use only the 7 bit ASCII
printing characters if it is a complete transformation of a source
document (e.g., "hex" or "uuencode"). If it is essentially a text
format, the full range may be used. If there is an external
standard, the character set may already be defined.
Keywords beginning with "X-" are permanently reserved to
implementation-specific use. No standard registered encoding keyword
will ever begin with "X-".
4.1. Text
This indicates that the message is in no particular encoded format,
but is to be presented to the user as is.
The full range of the ASCII character set is used. The message is
expected to consist of lines of reasonable length (less than 1000
characters).
On some transport services, only the 7 bit subset of ASCII can be
used. Where full 8 bit transparency is available, the text is
assumed to be ISO 8859-1 [3] (ASCII-8).
4.2. Message
This encoding indicates that the body part is itself in the format of
an Internet message, with its own header part and body part(s). A
"message" body part's message header may be a full internet message
header or it may consist only of an Encoding field.
Using the message encoding on returned mail makes it practical for a
mail reading system to implement a reliable resending function, if
the mailer generates it when returning contents. It is also useful
in a "copy append" MUA operation.
Message encoding is also used when mapping to X.400 to handle
recursively included X.400 P2 messages.
4.3. Hex
The encoding indicates that the body part contains binary data,
encoded as 2 hexadecimal digits per byte, highest significant nibble
first.
Lines consist of an even number of hexadecimal digits. Blank lines
are not permitted. The decode process must accept lines with between
2 and 1000 characters, inclusive.
4.4. EVFU
EVFU (Electronic Vertical Format Unit) specifies that each line
begins with a one-character "channel selector". The original purpose
was to select a channel on a paper tape loop controlling the printer.
This encoding is sometimes called "FORTRAN" format. It is the default
output format of FORTRAN programs on a number of computer systems.
The legal characters are '0' to '9', '+', '-', and space. These
correspond to the 12 rows (and absence of a punch) on a printer
control tape (used when the control unit was electromechanical).
The channels that have generally agreed definitions are:
1 advances to the first print line on the next page
0 skip a line, i.e., double-space
+ over-print the preceeding line
- skip 2 lines, i.e., triple-space
(space) print on the next line, single-space
4.5. EDI
The EDI (Electronic Document Interchange) keyword indicates that the
message or part is a business document, formatted according to ANSI
X12 or related standards.
The first word after the EDI keyword indicates the particular
interchange standard.
A message containing a note and 2 X12 purchase orders might have an
encoding of:
Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12
4.6. X.400
The Encoding header field provides a mechanism for mapping multi-part
messages between CCITT X.400 [1] and RFC 822.
The X.400 keyword specifies a section that is converted from an X.400
body part type not known to the gateway, or not corresponding to a
useful internet encoding.
If the message transits another gate, or if the receiving user has
the appropriate software, it can be decoded and used.
The X.400 keyword is followed by a second token indicating the method
used. The simplest form is "X.400 HEX", with the complete X.409
encoding of the body part in hexadecimal. More compact is "X.400
3/4", using the 3-byte to 4-character encoding as specified in RFC
1113, section 4.3.2.4.
4.7. uuencode
The uuencode keyword specifies a section consisting of the output of
the uuencode program supplied as part of uucp.
4.8. encrypted
The encrypted keyword indicates that the section is encrypted with
the methods in RFC 1115 [8]. This replaces the possible use of RFC
934 [5] encapsulation.
References
[1] International Telegraph and Telephone Consultative Committee,
"Data Communication Networks: Message Handling Systems", In CCITT
Recommendations X.400 to X.430, VIIIth Plenary Assembly, Malaga-
Torremolinos, 1984, Fascicle VIII.7 ("Red Book").
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, University of Delaware, August 1982.
[3] International Organization for Standardization, "Information
processing - 8-bit single-byte coded graphic character sets -
Part 1: Latin alphabet No. 1", ISO 8859-1, ISO, 1987.
[4] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I -- Message Encipherment and Authentication Procedures", RFC
1113, IAB Privacy Task Force, August 1989.
[5] Rose, M., and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC 943, University of Delaware and NMA, January
1985.
[6] Sirbu, M., "Content-type Header Field for Internet Messages", RFC
1049, CMU, March 1988.
[7] Kent, S., and J. Linn, "Privacy Enhancement for Internet
Electronic Mail: Part II -- Certificate-Based Key Management",
RFC 1114, IAB Privacy Task Force, August 1989.
[8] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy
Task Force, August 1989.
Security Considerations
Security issues are not addressed in this memo.
Authors' Addresses
David Robinson 10-30
Prime Computer, Inc.
500 Old Connecticut Path
Framingham, MA 01701
Phone: +1 508 879 2960 x1774
Email: DRB@Relay.Prime.COM
Robert Ullmann 10-30
Prime Computer, Inc.
500 Old Connecticut Path
Framingham, MA 01701
Phone: +1 508 879 2960 x1736
Email: Ariel@Relay.Prime.COM
AI ELI5
On this page
§1Multi-part Email Messages
RFC 822 defines email messages as having two parts: a header and a body, separated by a blank line. The Encoding header field extends this model to allow the message body to contain multiple parts, each separated from the next by a blank line.
Without the Encoding field, the message body is assumed to be a single part of type text. With it, each part can have a different encoding, allowing mail systems to transmit and properly decode binary data, structured documents, and other content types within a single message.
Normally an email is like a letter: one thing with text. This RFC lets you put several different things in one envelope, each labeled with what it is.
§2The Encoding Field Format
The Encoding field consists of one or more subfields separated by commas. Each subfield describes one message part in the order it appears in the message body.
A subfield has three components: an optional line count (a decimal number specifying the number of text lines in the part), a keyword defining the encoding type, and optional parameters specific to that encoding. The line count is required for all parts except the last one, because skipping over parts to reach a later one is faster with the count available.
Comments enclosed in parentheses can appear anywhere in the Encoding field, and mail reading systems may show them to users but must not use them for interpreting the content.
Think of a label for each item: how many pages it has, what kind of thing it is, and any special instructions for opening it. The last item does not need the page count because you go through it all.
§3Encoding Types
The RFC defines eight encoding types:
Text is the default, for message body text in ASCII or ISO 8859-1, with lines of reasonable length (under 1000 characters).
Message indicates that the body part is itself a complete Internet message with its own header and body. This is useful for resending replies and for recursively including X.400 messages.
Hex represents binary data encoded as two hexadecimal digits per byte.
EVFU (Electronic Vertical Format Unit) is a format where each line begins with a channel selector character to control printer output, sometimes called FORTRAN format.
EDI (Electronic Document Interchange) marks business documents formatted according to ANSI X12 or related standards.
X.400 provides a mapping between CCITT X.400 body parts and RFC 822 messages, either as hexadecimal-encoded X.409 or using a 3-byte to 4-character encoding.
uuencode marks sections using the output of the uuencode program from uucp.
encrypted indicates a section encrypted with methods defined in RFC 1115. Keywords beginning with X- are permanently reserved for implementation-specific use.
Different types of things need different ways to pack them. Text is just words, but binary data needs hex numbers, documents need EDI format, and secret messages need encryption.
§4Design Principles and Examples
When adding new encoding types, several principles should be followed: use the most common single-word name for the encoding, avoid overly general keywords, keep encodings free of unnecessary idiosyncrasies, and prefer 7-bit ASCII printing characters for complete transformations of a source document.
An example from the RFC illustrates a message containing a note and two X12 purchase orders with an Encoding field of: 17 TEXT, 146 EDI X12, 69 EDI X12. The first part is 17 lines of plain text, followed by two EDI parts with 146 and 69 lines respectively.
The Encoding field provides a mechanism for mapping multi-part messages between X.400 and RFC 822 formats, enabling gateways to translate between these mail systems by preserving the structure and encoding of each part.
When you have a mix of things to send—a cover note, two purchase orders—you write how many lines each one is and what format it is in. That way anyone opening the mail knows exactly what they have.
§5Status and Relationship to Other Standards
The Encoding header field was proposed as an elective experimental protocol, updating the Content-Type idea from RFC 1049. It was intended as a suggested update to the Privacy Enhancement RFCs (1113, 1114, 1115), which needed a way to handle multi-part encrypted messages.
The design intended for implementations to treat Content-Type as an alias of Encoding (when a message has only one body part), creating a unified approach to describing message structure. RFC 1154 is an Experimental status protocol from April 1990 and has been obsoleted by RFC 1505, which provided a more comprehensive and widely adopted solution for multi-part message handling.
This was an early try at solving the multi-part email problem. It worked, but later versions did it better and became the standard everyone uses.