Content-type header field for Internet messages
RFC 1049
|
Document |
Type |
|
RFC - Historic
(March 1988; No errata)
|
|
Authors |
|
|
|
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 1049 (Historic)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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 message body. For example, a header field which
indicated that the message body was encoded using Postscript could be
used to direct a mail system running under Sun Microsystem's NEWS
window manager to process the Postscript to produce the appropriate
page image on the screen.
Private header fields (beginning with "X-") are already being used by
some systems to affect such a result (e.g., the Andrew Message System
developed at Carnegie Mellon University). However, the widespread
use of such techniques will require general agreement on the name and
allowed parameter values for a header field to be used for this
purpose.
We propose that a new header field, "Content-type:" be recognized as
the standard field for indicating the structure of the message body.
The contents of the "Content-Type:" field are parameters which
specify what type of structure is used in the message body.
Note that we are not proposing that the message body contain anything
other than ASCII characters as specified in RFC-822. Whatever
structuring is contained in the message body must be represented
using only the allowed ASCII characters. Thus, this proposal should
have no impact on existing mailers, only on mail reading systems.
At the same time, this restriction eliminates the use of more general
structuring techniques such as Abstract Syntax Notation, (CCITT
Recommendation X.409) as used in the X.400 messaging standard, which
are octet-oriented.
This is not the first proposal for structuring message bodies.
Show full document text