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.
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.
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 . 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.
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-".
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.
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
Robinson & Ullmann [Page 4]
RFC 1154 Encoding Header Field for Internet Messages April 1990
The Encoding header field provides a mechanism for mapping multi-part messages between CCITT X.400  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 18.104.22.168.