Content-type header field for Internet messages
A proposed mail header that tells a reading program what kind of content a message body really holds.
Sirbu, M.A., "Content-type header field for Internet messages", RFC 1049, DOI 10.17487/RFC1049, March 1988, <https://www.rfc-editor.org/info/rfc1049>.
@misc{rfc1049,
series = {Request for Comments},
number = 1049,
howpublished = {RFC 1049},
publisher = {RFC Editor},
doi = {10.17487/RFC1049},
url = {https://www.rfc-editor.org/info/rfc1049},
author = {M.A. Sirbu},
title = {{Content-type header field for Internet messages}},
pagetotal = 8,
year = 1988,
month = mar,
} RFC text
Contents
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
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.
RFC-767 discusses a proposed technique for structuring multi-media
mail messages. We are also aware that many users already employ mail
to send TROFF, SCRIBE, TEX, Postscript or other structured
information. Such postprocessing as is required must be invoked
manually by the message recipient who looks at the message text
displayed as conventional ASCII and recognizes that it is structured
in some way that requires additional processing to be properly
rendered. Our proposal is designed to facilitate automatic
processing of messages by a mail reading system.
2. Problems with Structured Messages
Once we introduce the notion that a message body might require some
processing other than simply painting the characters to the screen we
raise a number of fundamental questions. These generally arise due
to the certainty that some receiving systems will have the facilities
to process the received message and some will not. The problem is
what to do in the presence of systems with different levels of
capability.
First, we must recognize that the purpose of structured messages is
to be able to send types of information, ultimately intended for
human consumption, not expressable in plain ASCII. Thus, there is no
way in plain ASCII to send the italics, boldface, or greek characters
that can be expressed in Postscript. If some different processing is
necessary to render these glyphs, then that is the minimum price to
be paid in order to send them at all.
Second, by insisting that the message body contain only ASCII, we
insure that it will not "break" current mail reading systems which
are not equipped to process the structure; the result on the screen
may not be readily interpretable by the human reader, however.
If a message sender knows that the recipient cannot process
Postscript, he or she may prefer that the message be revised to
eliminate the use of italics and boldface, rather than appear
incomprehensible. If Postscript is being used because the message
contains passages in Greek, there may be no suitable ASCII
equivalent, however.
Ideally, the details of structuring the message (or not) to conform
to the capabilities of the recipient system could be completely
hidden from the message sender. The distributed Internet mail system
would somehow determine the capabilities of the recipient system, and
convert the message automatically; or, if there was no way to send
Greek text in ASCII, inform the sender that his message could not be
transmitted.
In practice, this is a difficult task. There are three possible
approaches:
1. Each mail system maintains a database of capabilities of
remote systems it knows how to send to. Such a database
would be very difficult to keep up to date.
2. The mail transport service negotiates with the receiving
system as to its capabilities. If the receiving system
cannot support the specified content type, the mail is
transformed into conventional ASCII before transmission.
This would require changes to all existing SMTP
implementations, and could not be implemented in the case
where RFC-822 type messages are being forwarded via Bitnet or
other networks which do not implement SMTP.
3. An expanded directory service maintains information on mail
processing capabilities of receiving hosts. This eliminates
the need for real-time negotiation with the final
destination, but still requires direct interaction with the
directory service. Since directory querying is part of mail
sending as opposed to mail composing/reading systems, this
requires changes to existing mailers as well as a major
change to the domain name directory service.
We note in passing that the X.400 protocol implements approach number
2, and that the Draft Recommendations for X.DS, the Directory
Service, would support option 3.
In the interest of facilitating early usage of structured messages,
we choose not to recommend any of the three approaches described
above at the present time. In a forthcoming RFC we will propose a
solution based on option 2, requiring modification to mailers to
support negotiation over capabilities. For the present, then, users
would be obliged to keep their own private list of capabilities of
recipients and to take care that they do not send Postscript, TROFF
or other structured messages to recipients who cannot process them.
The penalty for failure to do so will be the frustration of the
recipient in trying to read a raw Postscript or TROFF file painted on
his or her screen. Some System Administrators may attempt to
implement option 1 for the benefit of their users, but this does not
impose a requirement for changes on any other mail system.
We recognize that the long-term solution must require changes to
mailers. However, in order to begin now to standardize the header
fields, and to facilitate experimentation, we issue the present RFC.
3. The Content-type Header Field
Whatever structuring technique is specified by the Content-type
field, it must be known precisely to both the sender and the
recipient of the message in order for the message to be properly
interpreted. In general, this means that the allowed parameter
values for the Content-type: field must identify a well-defined,
standardized, document structuring technique. We do not preclude,
however, the use of a Content-type: parameter value to specify a
private structuring technique known only to the sender and the
recipient.
More precisely, we propose that the Content-type: header field
consist of up to four parameter values. The first, or type parameter
names the structuring technique; the second, optional, parameter is a
version number, ver-num, which indicates a particular version or
revision of the standardized structuring technique. The third
parameter is a resource reference, resource-ref, which may indicate a
standard database of information to be used in interpreting the
structured document. The last parameter is a comment.
In the Extended Backus Naur Form of RFC-822, we have:
Content-Type:= type [";" ver-num [";" 1#resource-ref]] [comment]
3.1. Type Values
Initially, the type parameter would be limited to the following set
of values:
type:= "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/
"DVI"/"X-"atom
These values are not case sensitive. POSTSCRIPT, Postscript, and
POStscriPT are all equivalent.
POSTSCRIPT Indicates the enclosed document consists of
information encoded using the Postscript Page
Definition Language developed by Adobe Systems,
Inc. [1]
SCRIBE Indicates the document contains embedded formatting
information according to the syntax used by the
Scribe document formatting language distributed by
the Unilogic Corporation. [6]
SGML Indicates the document contains structuring
information to according the rules specified for
the Standard Generalized Markup Language, IS 8879,
as published by the International Organization for
Standardization. [3] Documents structured according
to the ISO DIS 8613--Office Docment Architecture and
Interchange Format--may also be encoded using SGML
syntax.
TEX Indicates the document contains embedded formatting
information according to the syntax of the TEX
document production language. [4]
TROFF Indicates the document contains embedded formatting
information according to the syntax specified for the
TROFF formatting package developed by AT&T Bell
Laboratories. [5]
DVI Indicates the document contains information according
to the device independent file format produced by
TROFF or TEX.
"X-"atom Any type value beginning with the characters "X-" is
a private value.
3.2. Version Number
Since standard structuring techniques in fact evolve over time, we
leave room for specifying a version number for the content type.
Valid values will depend upon the type parameter.
ver-num:= local-part
In particular, we have the following valid values:
For type=POSTSCRIPT
ver-num:= "1.0"/"2.0"/"null"
For type=SCRIBE
ver-num:= "3"/"4"/"5"/"null"
For type=SGML
ver-num:="IS.8879.1986"/"null"
3.3. Resource Reference
resource-ref:= local-part
As Apple has demonstrated with their implementation of the
Laserwriter, a very general document structuring technique can be
made more efficient by defining a set of macros or other similar
resources to be used in interpreting any transmitted stream. The
Macintosh transmits a LaserPrep file to the Laserwriter containing
font and macro definitions which can be called upon by subsequent
documents. The result is that documents as sent to the Laserwriter
are considerably more compact than if they had to include the
LaserPrep file each time. The Resource Reference parameter allows
specification of a well known resource, such as a LaserPrep file,
which should be used by the receiving system when processing the
message.
Resource references could also include macro packages for use with
TEX or references to preprocessors such as eqn and tbl for use with
troff. Allowed values will vary according to the type parameter.
In particular, we propose the following values:
For type = POSTSCRIPT
resource-ref:= "laserprep2.9"/"laserprep3.0"/"laserprep3.1"/
"laserprep4.0"/local-part
For type = TROFF
resource-ref:= "eqn"/"tbl"/"me"/local-part
3.4. Comment
The comment field can be any additional comment text the user
desires. Comments are enclosed in parentheses as specified in
RFC-822.
4. Conclusion
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 strcutured 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 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.
In the near term, the major use of a Content-Type: header field is
likely to be for designating the message body as containing a Page
Definition Language representation such as Postscript.
Additional type values shall be registered with Internet Assigned
Numbers Coordinator at USC-ISI. Please contact:
Joyce K. Reynolds
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
213-822-1511 JKReynolds@ISI.EDU
REFERENCES
1. Adobe Systems, Inc. Postscript Language Reference Manual.
Addison-Wesley, Reading, Mass., 1985.
2. Crocker, David H. RFC-822: Standard for the Format of ARPA
Internet Text Messages. Network Information Center,
August 13, 1982.
3. ISO TC97/SC18. Standard Generalized Markup Language.
Tech. Rept. DIS 8879, ISO, 1986.
4. Knuth, Donald E. The TEXbook. Addison-Wesley, Reading, Mass.,
1984.
5. Ossanna, Joseph F. NROFF/TROFF User's Manual. Bell
Laboratories, Murray Hill, New Jersey, 1976. Computing Science
Technical Report No.54.
6. Unilogic. SCRIBE Document Production Software. Unilogic, 1985.
Fourth Edition.
ISO Plain Language
On this page
§1Why Mail Needed a Content Type
As defined in RFC 822, an electronic mail message consists of a number of defined header fields, some containing structured information such as date and addresses, and a message body consisting of an unstructured string of ASCII characters.
The success of the Internet mail system led to a desire to use it for sending information with a greater degree of structure while staying inside the limits of the character set. A prime example is a document with embedded TROFF formatting commands; a more sophisticated one is a message body encoded in a Page Description Language such as PostScript. In both cases, simply mapping the ASCII characters to the screen or printer in the usual way will not render the document image the sender intended, and an extra processing step is needed to produce it.
Private header fields beginning with X- were already in use by some systems to achieve such a result, for example the Andrew Message System developed at Carnegie Mellon University. The RFC proposes that a new header field, Content-Type, be recognized as the standard field for indicating the structure of the message body, with parameters that specify what structure is used. The memo is explicit that the body would still contain only the ASCII characters allowed by RFC 822, so the proposal should have no impact on existing mailers, only on mail reading systems. That restriction does eliminate more general structuring techniques such as ASN.1 as used in the X.400 messaging standard, which is octet-oriented. This is not the first proposal for structuring message bodies: RFC 767 discusses a proposed technique for structuring multi-media mail messages.
Mail bodies were plain ASCII text, with no way to say that the text was really a formatted document. This RFC proposes one header field that names the format, so a reading program can pick the right way to display the message.
§2The Problem of Differing Reader Capabilities
Structured messages raise questions because some receiving systems can process the received message and some cannot, and the RFC asks what to do about the difference.
First, the purpose of structured messages is to send information, ultimately intended for human consumption, that plain ASCII cannot express, such as italics, boldface or Greek characters. Second, insisting on ASCII means a message will not break a reader that cannot process the structure, though the result on the screen may not be readily interpretable. If the sender knows the recipient cannot process PostScript, the sender may prefer to revise the message rather than have it appear incomprehensible, although Greek passages may have no suitable ASCII equivalent.
Ideally the details would be hidden from the sender: the mail system would determine the capabilities of the recipient system and convert the message automatically, or tell the sender it could not be sent. The RFC lists three possible approaches. Each mail system could keep a database of the capabilities of remote systems it knows how to send to, which would be very difficult to keep up to date. Or the mail transport could negotiate with the receiving system and transform the mail into conventional ASCII if the content type is not supported, which would require changes to all existing SMTP implementations and could not be implemented where messages are forwarded over networks that do not implement SMTP. Or an expanded directory service could maintain information on the processing capabilities of receiving hosts, which removes the need for real-time negotiation with the destination but still needs direct interaction with the directory service, and requires changes to existing mailers and a major change to the domain name directory service. The X.400 protocol implements the second approach, and the X.DS directory service recommendations would support the third.
In the interest of facilitating early usage, the RFC recommends none of the three approaches yet, and says a forthcoming RFC will propose a solution based on the second approach. Until then, users would be obliged to keep their own private list of recipient capabilities and to take care not to send PostScript, TROFF or other structured messages to recipients who cannot process them. The penalty is the frustration of a recipient trying to read a raw PostScript or TROFF file painted on the screen. The RFC recognizes that the long-term solution must require changes to mailers, but issues the present RFC in order to begin standardizing the header fields and to facilitate experimentation.
Some readers can show a formatted message and some cannot, so a sender has to guess. The RFC lists three ways to solve that and then sets the question aside, so that the header field can be agreed first.
§3The Content-Type Header Field
Whatever structuring technique the field names, it must be known precisely to both the sender and the recipient of the message for the message to be properly interpreted. In general this means the allowed parameter values must identify a well-defined, standardized document structuring technique. The RFC does not, however, preclude the use of a parameter value to specify a private structuring technique known only to the sender and the recipient.
The field is proposed to consist of up to four parameter values. The first, the type parameter, names the structuring technique. The second, optional, is a version number, ver-num, which indicates a particular version or revision of the standardized structuring technique. The third is a resource reference, resource-ref, which may indicate a standard database of information to be used in interpreting the structured document. The last is a comment.
In the Extended Backus Naur Form of RFC 822, the RFC gives the field as: Content-Type:= type [";" ver-num [";" 1#resource-ref]] [comment]
The proposed field has up to four parts: the type of content, a version of that type, a reference to a resource the reader needs, and a free comment. The type comes first and is the only part a reader has to understand.
Content-Type:= type [";" ver-num [";" 1#resource-ref]] [comment]§3.1Type Values, Versions and Resource References
The type parameter is initially limited to a set of values, and the values are not case sensitive, so POSTSCRIPT, Postscript and POStscriPT are all equivalent. POSTSCRIPT means the document is encoded in the PostScript Page Definition Language developed by Adobe Systems. SCRIBE means the document contains embedded formatting information in the syntax of the Scribe document formatting language. SGML means the document contains structuring information according to the rules of the Standard Generalized Markup Language, IS 8879, and documents structured according to the ISO DIS 8613 Office Document Architecture and Interchange Format may also be encoded using SGML syntax. TEX means the document contains embedded formatting information in the syntax of the TEX document production language. TROFF means the document contains embedded formatting information in the syntax of the TROFF formatting package. DVI means the document contains information in the device independent file format produced by TROFF or TEX. Any type value beginning with the characters X- is a private value.
Because standard techniques evolve over time, a version number can be given, and the valid values depend on the type parameter. For POSTSCRIPT the values are 1.0, 2.0 and null. For SCRIBE they are 3, 4, 5 and null. For SGML the value is IS.8879.1986 or null.
The resource reference names a well known resource that the receiving system should use when processing the message. The RFC gives the example of a LaserPrep file, which the Macintosh transmits to the Laserwriter to supply font and macro definitions that later documents can call on, which makes those documents considerably more compact than if each had to include the LaserPrep file. Resource references could also name macro packages for use with TEX, or references to preprocessors such as eqn and tbl for use with troff. For POSTSCRIPT the proposed values are laserprep2.9, laserprep3.0, laserprep3.1, laserprep4.0 or a local part. For TROFF they are eqn, tbl, me or a local part. The comment field can be any additional comment text the user desires, enclosed in parentheses as specified in RFC 822.
The RFC lists six standard content types, from PostScript to TeX, and allows a private type that starts with X-. Each type can carry a version number and, for some types, the name of a helper file the reader should use.
- POSTSCRIPTPostScript — The document is encoded in the PostScript Page Definition Language.
- SCRIBEScribe — The document contains embedded formatting in the Scribe language syntax.
- SGMLSGML — The document carries structuring information according to IS 8879.
- TEXTEX — The document contains embedded formatting in the TEX syntax.
- TROFFTROFF — The document contains embedded formatting in the TROFF syntax.
- DVIDVI — The document uses the device independent file format produced by TROFF or TEX.
- X-Private value — Any type value beginning with X- is private.
§4Registration and the Near-Term Use
The RFC concludes that a standardized Content-Type field lets mail reading systems identify the type of a structured message body and process it for display accordingly, while the body still conforms 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, but recognizing the field and invoking the appropriate display process improves readability and allows the exchange of messages containing mathematical symbols or foreign language characters.
In the near term, the major use of a Content-Type field is likely to be for designating the message body as containing a Page Description Language representation such as PostScript. Additional type values are to be registered with the Internet Assigned Numbers Coordinator at USC-ISI.
The memo expects the field to be used first for page description languages such as PostScript, and asks that any new type be registered with the Internet Assigned Numbers Coordinator.