Browse Prior Art Database

Content-type header field for Internet messages (RFC1049)

IP.com Disclosure Number: IPCOM000001855D
Original Publication Date: 1988-Mar-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 8 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.A. Sirbu: AUTHOR

Related Documents

10.17487/RFC1049: DOI

Abstract

This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 19% of the total text.

Network Working Group M. Sirbu Request for Comments: 1049 CMU March 1988

A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES

STATUS OF THIS MEMO

This RFC suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

ABSTRACT

A standardized Content-type field allows mail reading systems to automatically identify the type of a structured message body and to process it for display accordingly. The structured message body must still conform to the RFC-822 requirements concerning allowable characters. A mail reading system need not take any specific action upon receiving a message with a valid Content-Type header field. The ability to recognize this field and invoke the appropriate display process accordingly will, however, improve the readability of messages, and allow the exchange of messages containing mathematical symbols, or foreign language characters.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Problems with Structured Messages . . . . . . . . . . . . . . . 3 3. The Content-type Header Field . . . . . . . . . . . . . . . . . 5 3.1. Type Values . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Version Number . . . . . . . . . . . . . . . . . . . . . 6 3.3. Resource Reference . . . . . . . . . . . . . . . . . . . 6 3.4. Comment. . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

As defined in RFC-822, [2], an electronic mail message consists of a number of defined header fields, some containing structured information (e.g., date, addresses), and a message body consisting of an unstructured string of ASCII characters.

The success of the Internet mail system has led to a desire to use the mail system for sending around information with a greater degree of structure, while remaining within the constraints imposed by the limited character set. A prime example is the use of mail to send a

Sirbu [Page 1]

RFC 1049 Mail Content Type March 1988

document with embedded TROFF formatting commands. A more sophisticated example would be a message body encoded in a Page Description Language (PDL) such as Postscript. In both cases, simply mapping the ASCII characters to the screen or printer in the usual fashion will not render the document image intended by the sender; an additional processing step is required to produce an image of the message text on a display device or a piece of paper.

In both of these examples, the message body contains only the legal character set, but the content has a structure which produces some desirable result after appropriate processing by the recipient. If a message header field could be used to indicate the structuring technique used in the message body, then a sophisticated mail system could use such a field to automatically invoke the appropriate processing of the messa...

Processing...
Loading...