1. INTRODUCTION
1.1. SCOPE
This standard specifies a syntax for text messages that are sent among computer users, within the framework of "electronic mail". The standard supersedes the one specified in ARPANET Request for Comments #733, "Standard for the Format of ARPA Net- work Text Messages".
In this context, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. The contents compose the object to be delivered to the recipient. This stan- dard applies only to the format and some of the semantics of mes- sage contents. It contains no specification of the information in the envelope.
However, some message systems may use information from the contents to create the envelope. It is intended that this stan- dard facilitate the acquisition of such information by programs.
Some message systems may store messages in formats that differ from the one specified in this standard. This specifica- tion is intended strictly as a definition of what message content format is to be passed BETWEEN hosts.
Note: This standard is NOT intended to dictate the internal for- mats used by sites, the specific message system features that they are expected to support, or any of the charac- teristics of user interface programs that create or read messages.
A distinction should be made between what the specification REQUIRES and what it ALLOWS. Messages can be made complex and rich with formally-structured components of information or can be kept small and simple, with a minimum of such information. Also, the standard simplifies the interpretation of differing visual formats in messages; only the visual aspect of a message is affected and not the interpretation of information within it. Implementors may choose to retain such visual distinctions.
The formal definition is divided into four levels. The bot- tom level describes the meta-notation used in this document. The second level describes basic lexical analyzers that feed tokens to higher-level parsers. Next is an overall specification for messages; it permits distinguishing individual fields. Finally, there is definition of the contents of several structured fields.
1.2. COMMUNICATION FRAMEWORK
Messages consist of lines of text. No special provisions are made for encoding drawings, facsimile, speech, or structured text. No significant consideration has been given to questions of data compression or to transmission and storage efficiency, and the standard tends to be free with the number of bits con- sumed. For example, field names are specified as free text, rather than special terse codes.
A general "memo" framework is used. That is, a message con- sists of some information in a rigid format, followed by the main part of the message, with a format that is not specified in this document. The syntax of several fields of the rigidly-formated ("headers") section is defined in this specification; some of these fields must be included in all messages.
The syntax that distinguishes between header fields is specified separately from the internal syntax for particular fields. This separation is intended to allow simple parsers to operate on the general structure of messages, without concern for the detailed structure of individual header fields. Appendix B is provided to facilitate construction of these parsers.
In addition to the fields specified in this document, it is expected that other fields will gain common use. As necessary, the specifications for these "extension-fields" will be published through the same mechanism used to publish this document. Users may also wish to extend the set of fields that they use privately. Such "user-defined fields" are permitted.
The framework severely constrains document tone and appear- ance and is primarily useful for most intra-organization communi- cations and well-structured inter-organization communication. It also can be used for some types of inter-process communica- tion, such as simple file transfer and remote job entry. A more robust framework might allow for multi-font, multi-color, multi- dimension encoding of information. A less robust one, as is present in most single-machine message systems, would more severely constrain the ability to add fields and the decision to include specific fields. In contrast with paper-based communica- tion, it is interesting to note that the RECEIVER of a message can exercise an extraordinary amount of control over the message's appearance. The amount of actual control available to message receivers is contingent upon the capabilities of their individual message systems.