As per Relevance of the word structure, we have this rfc below:
Network Working Group M.
Request for Comments: 1049
March 1988
A CONTENT-TYPE HEADER FIELD FOR INTERNET
STATUS OF THIS
This RFC suggests proposed additions to the Internet Mail Protocol
RFC-822, for the Internet community, and requests discussion
suggestions for improvements. Distribution of this memo
unlimited
A standardized Content-type field allows mail reading systems
automatically identify the type of a structured message body and
process it for display accordingly. The structured message body
still conform to the RFC-822 requirements concerning
characters. A mail reading system need not take any specific
upon receiving a message with a valid Content-Type header field.
ability to recognize this field and invoke the appropriate
process accordingly will, however, improve the readability
messages, and allow the exchange of messages containing
symbols, or foreign language characters
Table of
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.
As defined in RFC-822, [2], an electronic mail message consists of
number of defined header fields, some containing
information (e.g., date, addresses), and a message body consisting
an unstructured string of ASCII characters
The success of the Internet mail system has led to a desire to
the mail system for sending around information with a greater
of structure, while remaining within the constraints imposed by
limited character set. A prime example is the use of mail to send
Sirbu [Page 1]
RFC 1049 Mail Content Type March 1988
document with embedded TROFF formatting commands. A
sophisticated example would be a message body encoded in a
Description Language (PDL) such as Postscript. In both cases,
mapping the ASCII characters to the screen or printer in the
fashion will not render the document image intended by the sender;
additional processing step is required to produce an image of
message text on a display device or a piece of paper
In both of these examples, the message body contains only the
character set, but the content has a structure which produces
desirable result after appropriate processing by the recipient. If
message header field could be used to indicate the
technique used in the message body, then a sophisticated mail
could use such a field to automatically invoke the
processing of the message body. For example, a header field
indicated that the message body was encoded using Postscript could
used to direct a mail system running under Sun Microsystem's
window manager to process the Postscript to produce the
page image on the screen
Private header fields (beginning with "X-") are already being used
some systems to affect such a result (e.g., the Andrew Message
developed at Carnegie Mellon University). However, the
use of such techniques will require general agreement on the name
allowed parameter values for a header field to be used for
purpose
We propose that a new header field, "Content-type:" be recognized
the standard field for indicating the structure of the message body
The contents of the "Content-Type:" field are parameters
specify what type of structure is used in the message body
Note that we are not proposing that the message body contain
other than ASCII characters as specified in RFC-822.
structuring is contained in the message body must be
using only the allowed ASCII characters. Thus, this proposal
have no impact on existing mailers, only on mail reading systems
At the same time, this restriction eliminates the use of more
structuring techniques such as Abstract Syntax Notation, (
Recommendation X.409) as used in the X.400 messaging standard,
are octet-oriented
This is not the first proposal for structuring message bodies
RFC-767 discusses a proposed technique for structuring multi-
mail messages. We are also aware that many users already employ
to send TROFF, SCRIBE, TEX, Postscript or other
information. Such postprocessing as is required must be
Sirbu [Page 2]
RFC 1049 Mail Content Type March 1988
manually by the message recipient who looks at the message
displayed as conventional ASCII and recognizes that it is
in some way that requires additional processing to be
rendered. Our proposal is designed to facilitate
processing of messages by a mail reading system
2. Problems with Structured
Once we introduce the notion that a message body might require
processing other than simply painting the characters to the screen
raise a number of fundamental questions. These generally arise
to the certainty that some receiving systems will have the
to process the received message and some will not. The problem
what to do in the presence of systems with different levels
capability
First, we must recognize that the purpose of structured messages
to be able to send types of information, ultimately intended
human consumption, not expressable in plain ASCII. Thus, there is
way in plain ASCII to send the italics, boldface, or greek
that can be expressed in Postscript. If some different processing
necessary to render these glyphs, then that is the minimum price
be paid in order to send them at all
Second, by insisting that the message body contain only ASCII,
insure that it will not "break" current mail reading systems
are not equipped to process the structure; the result on the
may not be readily interpretable by the human reader, however
If a message sender knows that the recipient cannot
Postscript, he or she may prefer that the message be revised
eliminate the use of italics and boldface, rather than
incomprehensible. If Postscript is being used because the
contains passages in Greek, there may be no suitable
equivalent, however
Ideally, the details of structuring the message (or not) to
to the capabilities of the recipient system could be
hidden from the message sender. The distributed Internet mail
would somehow determine the capabilities of the recipient system,
convert the message automatically; or, if there was no way to
Greek text in ASCII, inform the sender that his message could not
transmitted
Sirbu [Page 3]
RFC 1049 Mail Content Type March 1988
In practice, this is a difficult task. There are three
approaches
1. Each mail system maintains a database of capabilities
remote systems it knows how to send to. Such a
would be very difficult to keep up to date
2. The mail transport service negotiates with the
system as to its capabilities. If the receiving
cannot support the specified content type, the mail
transformed into conventional ASCII before transmission
This would require changes to all existing
implementations, and could not be implemented in the
where RFC-822 type messages are being forwarded via Bitnet
other networks which do not implement SMTP
3. An expanded directory service maintains information on
processing capabilities of receiving hosts. This
the need for real-time negotiation with the
destination, but still requires direct interaction with
directory service. Since directory querying is part of
sending as opposed to mail composing/reading systems,
requires changes to existing mailers as well as a
change to the domain name directory service
We note in passing that the X.400 protocol implements approach
2, and that the Draft Recommendations for X.DS, the
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
above at the present time. In a forthcoming RFC we will propose
solution based on option 2, requiring modification to mailers
support negotiation over capabilities. For the present, then,
would be obliged to keep their own private list of capabilities
recipients and to take care that they do not send Postscript,
or other structured messages to recipients who cannot process them
The penalty for failure to do so will be the frustration of
recipient in trying to read a raw Postscript or TROFF file painted
his or her screen. Some System Administrators may attempt
implement option 1 for the benefit of their users, but this does
impose a requirement for changes on any other mail system
We recognize that the long-term solution must require changes
mailers. However, in order to begin now to standardize the
fields, and to facilitate experimentation, we issue the present RFC
Sirbu [Page 4]
RFC 1049 Mail Content Type March 1988
3. The Content-type Header
Whatever structuring technique is specified by the Content-
field, it must be known precisely to both the sender and
recipient of the message in order for the message to be
interpreted. In general, this means that the allowed
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
private structuring technique known only to the sender and
recipient
More precisely, we propose that the Content-type: header
consist of up to four parameter values. The first, or type
names the structuring technique; the second, optional, parameter is
version number, ver-num, which indicates a particular version
revision of the standardized structuring technique. The
parameter is a resource reference, resource-ref, which may indicate
standard database of information to be used in interpreting
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
Initially, the type parameter would be limited to the following
of values
type:= "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/
"DVI"/"X-"
These values are not case sensitive. POSTSCRIPT, Postscript,
POStscriPT are all equivalent
POSTSCRIPT Indicates the enclosed document consists
information encoded using the Postscript
Definition Language developed by Adobe Systems
Inc. [1]
SCRIBE Indicates the document contains embedded
information according to the syntax used by
Scribe document formatting language distributed
the Unilogic Corporation. [6]
SGML Indicates the document contains
information to according the rules specified
Sirbu [Page 5]
RFC 1049 Mail Content Type March 1988
the Standard Generalized Markup Language, IS 8879,
as published by the International Organization
Standardization. [3] Documents structured
to the ISO DIS 8613--Office Docment Architecture
Interchange Format--may also be encoded using
syntax
TEX Indicates the document contains embedded
information according to the syntax of the
document production language. [4]
TROFF Indicates the document contains embedded
information according to the syntax specified for
TROFF formatting package developed by AT&T
Laboratories. [5]
DVI Indicates the document contains information
to the device independent file format produced
TROFF or TEX
"X-"atom Any type value beginning with the characters "X-"
a private value
3.2. Version
Since standard structuring techniques in fact evolve over time,
leave room for specifying a version number for the content type
Valid values will depend upon the type parameter
ver-num:= local-
In particular, we have the following valid values
For type=
ver-num:= "1.0"/"2.0"/"null
For type=
ver-num:= "3"/"4"/"5"/"null
For type=
ver-num:="IS.8879.1986"/"null
3.3. Resource
resource-ref:= local-
Sirbu [Page 6]
RFC 1049 Mail Content Type March 1988
As Apple has demonstrated with their implementation of
Laserwriter, a very general document structuring technique can
made more efficient by defining a set of macros or other
resources to be used in interpreting any transmitted stream.
Macintosh transmits a LaserPrep file to the Laserwriter
font and macro definitions which can be called upon by
documents. The result is that documents as sent to the
are considerably more compact than if they had to include
LaserPrep file each time. The Resource Reference parameter
specification of a well known resource, such as a LaserPrep file
which should be used by the receiving system when processing
message
Resource references could also include macro packages for use
TEX or references to preprocessors such as eqn and tbl for use
troff. Allowed values will vary according to the type parameter
In particular, we propose the following values
For type =
resource-ref:= "laserprep2.9"/"laserprep3.0"/"laserprep3.1"/
"laserprep4.0"/local-
For type =
resource-ref:= "eqn"/"tbl"/"me"/local-
3.4.
The comment field can be any additional comment text the
desires. Comments are enclosed in parentheses as specified
RFC-822.
4.
A standardized Content-type field allows mail reading systems
automatically identify the type of a structured message body and
process it for display accordingly. The strcutured message body
still conform to the RFC-822 requirements concerning
characters. A mail reading system need not take any specific
upon receiving a message with valid Content-Type header field.
ability to recognize this field and invoke the appropriate
process accordingly will, however, improve the readability
messages, and allow the exchange of messages containing
symbols, or foreign language characters
Sirbu [Page 7]
RFC 1049 Mail Content Type March 1988
In the near term, the major use of a Content-Type: header field
likely to be for designating the message body as containing a
Definition Language representation such as Postscript
Additional type values shall be registered with Internet
Numbers Coordinator at USC-ISI. Please contact
Joyce K.
USC Information Sciences
4676 Admiralty
Marina del Rey, CA 90292-6695
213-822-1511 JKReynolds@ISI.
1. Adobe Systems, Inc. Postscript Language Reference Manual
Addison-Wesley, Reading, Mass., 1985.
2. Crocker, David H. RFC-822: Standard for the Format of
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.
Laboratories, Murray Hill, New Jersey, 1976. Computing
Technical Report No.54.
6. Unilogic. SCRIBE Document Production Software. Unilogic, 1985.
Fourth Edition
Sirbu [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
