Browse Prior Art Database

Encoding header field for internet messages (RFC1154) Disclosure Number: IPCOM000001965D
Original Publication Date: 1990-Apr-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 6 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Robinson: AUTHOR [+2]


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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 28% of the total text.

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:

[ [], ]* [] []


:= a decimal integer

:= a single alphanumeric token starting with an alpha

:= keyword-dependent options


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-


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.


The optional information...