Encoding header field for internet messages
RFC 1154

Document Type RFC - Experimental (April 1990; No errata)
Obsoleted by RFC 1505
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1154 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
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)

   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:

Robinson & Ullmann                                              [Page 1]
RFC 1154      Encoding Header Field for Internet Messages     April 1990

     [<count> <keyword> [<options>], ]* [<count>] <keyword> [<options>]


        <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-

   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.


   Comments enclosed in parentheses may, of course, be inserted anywhere
   in the Encoding field.  Mail reading systems may pass the comments to

Robinson & Ullmann                                              [Page 2]
RFC 1154      Encoding Header Field for Internet Messages     April 1990

   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

      - 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
Show full document text