Browse Prior Art Database

Encoding header field for internet messages (RFC1154)

IP.com Disclosure Number: IPCOM000001965D
Original Publication Date: 1990-Apr-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 7 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Robinson: AUTHOR [+1]

Related Documents

10.17487/RFC1154: DOI

Abstract

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

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 30% 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) [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:

Robinson & Ullmann [Page 1]

RFC 1154 Encoding Header Field for Internet Messages April 1990

[<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, versi...

Processing...
Loading...