RFC 1505 (rfc1505) - Page 3 of 36
Encoding Header Field for Internet Messages
Alternative Format: Original Text Document
RFC 1505 Encoding Header Field August 1993
1. Introduction
STD 11, RFC 822 [2] defines an electronic mail message to consist of
two parts, the message header and the message body, separated by a
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 a blank line. Thus, conceptually, a message has a header part,
followed by one or more body parts, all separated by apparently blank
lines. Each body part has an encoding type. The default (no
Encoding field in the header) is a one part message body of type
"Text".
The purpose of Encoding is to be descriptive of the content of a mail
message without placing constraints on the content or requiring
additional structure to appear in the body of the message that will
interfere with other processing.
A similar message format is used in the network news facility, and
posted articles are often transferred by gateways between news and
mail. The Encoding field is perhaps even more useful in news, where
articles often are uuencoded or shar'd, and have a number of
different nested encodings of graphics images and so forth. In news
in particular, the Encoding header keeps the structural information
within the (usually concealed) article header, without affecting the
visual presentation by simple news-reading software.
2. 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
and a keyword or a series of nested keywords defining the encoding.
The line count is optional in the last subfield.
2.1 Format of the Encoding Field
The format of the Encoding field is:
[ [ ]* , ]*
[ ] [ ]*
where:
:= a decimal integer
:= a single alphanumeric token starting with an alpha
Costanzo, Robinson & Ullmann