RFC 841
FIPS Pub 98
SPECIFICATION FOR MESSAGE FORMAT FOR COMPUTER
BASED MESSAGE SYSTEMS
27 January 1983
National Bureau of Standards
This RFC is FIPS 98. The purpose of distributing this document
as an RFC is to make it easily accesible to the ARPA research
community. This RFC does not specify a standard for the ARPA
Internet.
TABLE OF CONTENTS
Page
EXECUTIVE SUMMARY 5
1. INTRODUCTION 7
1.1 Guide to Reading This Document 7
1.2 Vendor-Defined Extensions to the Specification 8
1.3 The Scope of the Message Format Specification 8
1.4 Issues Not Within the Scope of the Message Format 8
Specification
1.5 Relationship to Other Efforts 9
2. A SIMPLE MODEL OF A CBMS ENVIRONMENT 10
2.1 Logical Model of a CBMS 12
2.2 Relationship to the ISO Reference Model for Open 14
Systems Interconnection
2.3 Messages and Fields 14
2.4 Message Originators and Recipients 15
3. SEMANTICS 17
3.1 Semantics of Message Fields 17
3.1.1 Types of fields 17
3.1.2 Semantic Compliance Categories 18
3.1.3 Originator fields 18
3.1.4 Recipient fields 19
3.1.5 Date fields 20
3.1.6 Cross-reference fields 21
3.1.7 Message-handling fields 22
3.1.8 Message-content fields 23
3.1.9 Extensions 23
i
3.2 Message Processing Functions 24
3.2.1 Message creation and posting 24
3.2.2 Message reissuing and forwarding 25
3.2.2.1 Redistribution 26
3.2.2.2 Assignment 28
3.2.3 Reply generation 28
3.2.4 Cross-referencing 29
3.2.4.1 Unique identifiers 29
3.2.4.2 Serial numbering 30
3.2.5 Life span functions 30
3.2.6 Requests for recipient processing 31
3.2.6.1 Message circulation 31
3.3 Multiple Occurrences and Ordering of Fields 31
4. SYNTAX 34
4.1 Introduction 34
4.1.1 Message structure 34
4.1.2 Data elements 35
4.1.2.1 Primitive data elements 36
4.1.2.2 Constructor data elements 36
4.1.3 Properties 36
4.1.3.1 Printing-names 37
4.1.3.2 Comments 37
4.1.4 Data compression and encryption 37
4.2 Overview of Syntax Encoding 37
4.2.1 Identifier Octets 38
4.2.2 Length code and Qualifier components 39
4.2.2.1 Length Codes 41
4.2.2.2 Qualifier 42
4.2.3 Property-List 44
4.2.4 Data Element Contents 44
4.3 Data Element Syntax 44
4.3.1 Data elements 45
4.3.1.1 Primitives 47
4.3.1.2 Constructors 49
4.3.1.3 Data Elements that Extend this Speci- 52
fication
4.3.2 Using data elements within message fields 53
4.3.3 Properties and associated elements 54
4.3.4 Encryption identifiers 54
4.3.5 Compression identifiers 54
4.3.6 Message types 55
ii
SUMMARY OF APPENDIXES 56
APPENDIX A. FIELDS -- IMPLEMENTORS' MASTER REFERENCE 57
APPENDIX B. DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE 63
APPENDIX C. DATA ELEMENT IDENTIFIER OCTETS 71
APPENDIX D. SUMMARY OF MESSAGE FIELDS BY COMPLIANCE CATE- 72
GORY
D.1 REQUIRED Fields 72
D.2 BASIC Fields 72
D.3 OPTIONAL Fields 72
APPENDIX E. SUMMARY OF MESSAGE SEMANTICS BY FUNCTION 74
E.1 Circulation 74
E.2 Cross-Referencing 74
E.3 Life Spans 74
E.4 Delivery System 74
E.5 Miscellaneous Fields Used Generally 75
E.6 Reply Generation 75
E.7 Reissuing 75
E.8 Sending (Normal Transmission) 75
APPENDIX F. SUMMARY OF DATA ELEMENT SYNTAX 76
APPENDIX G. SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY 78
G.1 BASIC Data Elements 78
G.2 OPTIONAL Data Elements 78
iii
APPENDIX H. EXAMPLES 80
H.1 Primitive Data Elements 80
H.2 Constructor Data Elements 82
H.3 Data Elements that Extend this Specification 87
H.4 Fields 88
H.5 Messages 90
H.6 Unknown Lengths 94
H.7 Message Encoding Using Vendor-Defined Fields 97
H.7.1 Example of a JANAP-128 Message 97
H.7.2 Encoding of Example using the FIPS Message 97
Format
H.7.3 Field Mappings of JANAP-128 to FIPS Format 101
H.7.4 Vendor-Defined Fields 101
REFERENCES 103
INDEX 105
iv
LIST OF FIGURES
FIG. 1. LOGICAL MODEL OF A COMPUTER-BASED MESSAGE SYSTEM 12
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION 27
FIG. 3. EXAMPLE OF MESSAGE CIRCULATION 32
FIG. 4. STRUCTURE OF IDENTIFIER OCTETS 39
FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH 40
CODES
FIG. 6. REPRESENTATION OF LENGTH CODES 42
FIG. 7. EXAMPLES OF QUALIFIER VALUES 43
v
LIST OF TABLES
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS 24
TABLE 2. HIGH-ORDER BITS IN THE IDENTIFIER OCTET 39
vi
Federal Information
Processing Standards Publication 98
27 January 1983
Announcing the Standard for
MESSAGE FORMAT
FOR
COMPUTER BASED MESSAGE SYSTEMS
Federal Information Processing Standards Publications are issued
by the National Bureau of Standards pursuant to section 111(f)(2)
of the Federal Property and Administrative Services Act of 1949,
as amended, Public Law 89-306 (79 Stat. 1127), Executive Order
11717 (38 FR 12315, dated May 11, 1973), and Part 6 of Title 15
Code of Federal Regulations (CFR).
Name of Standard. Message Format for Computer Based Message
Systems (FIPS PUB 98).
Category of Standard. Software Standard; Interchange Codes, Media
and Data Files.
Explanation. This standard separates information so that a
Computer Based Message System can locate and operate on that
information (which is found in the fields of messages). This is
the first of a family of standards which will ensure information
interchange among Computer Based Message Systems.
Approving Authority. Secretary of Commerce
Maintenance Agency. Department of Commerce, National Bureau of
Standards (Institute for Computer Sciences and Technology).
Cross Index. Not Applicable.
Related Documents.
a. American National Standard Code for Information
Interchange (ASCII), X3.4-1977,FIPS PUBS 1-1.
b. American National Standard Code Extension Techniques
for Use with the 7-bit Coded Character Set of American
National Standard Code (ASCII) for Information
Interchange, X3.41-1974, FIPS PUB 35.
c. National Bureau of Standards. Calendar Date. Federal
Information Processing Standards Publication 4, U.S.
1
Department of Commerce / National Bureau of Standards,
November, 1968.
d. National Bureau of Standards. Data Encryption Standard.
Federal Information Processing Standards Publication
46, U.S. Department of Commerce/National Bureau of
Standards, January, 1977.
e. National Bureau of Standards. Representation of Local
Time of the Day for Information Interchange. Federal
Information Processing Standards Publication 58, U.S.
Department of Commerce / National Bureau of Standards,
February 1979.
f. National Bureau of Standards. Representation of
Universal Time, Local Time Differentials, and United
States Time Zone References for Information
Interchange. Federal Information Processing Standards
Publication 59, U.S. Department of Commerce / National
Bureau of Standards, February, 1979.
Applicability. This message format standard applies to Federal
departments and agencies in their acquisition and use of
computer-based message systems (CBMS) and services in networked
systems, except for certain single-processor systems.
Specifically, the standard does not apply to a CBMS if it is a
stand-alone system which is not interconnected with any other
CBMS: nevertheless, conformance with the standard is recommended
under these circumstances particularly if there is a possibility
that use of another central processing unit, or interconnection
with another system, will be required in the future. Where a new
CBMS node is incorporated into an existing network, the standard
applies at the interface between CBMS's. In this instance,
previously existing nodes may accommodate the standard either
through retrofit or by the use of a translator. In addition,
networks that are established strictly for the purpose of
supporting research in computer science or communications are
exempt from complying with this standard.
Subcommittee TC97/SC16 of the International Organization for
Standardization (ISO) has developed a reference model for
describing communications between "open" systems. (ISO/TC97/SC16
DIS7498) This model is known as the ISO Reference Model for Open
Systems Interconnection (OSI). It divides communications
protocols into seven layers, ranging from physical
interconnection at the lowest layer to data exchange by
applications programs at the top.
The NBS message format deals with data used by an application
within a system; it is not a protocol. Messages defined by the
2
NBS message format would be manipulated by a layer 7
(Application) protocol.
A message as referenced by the NBS message format is a unit of
communication from an originator to a recipient, exclusive of any
message heading or control information (often referred to as a
message envelope). An originator and recipient are typically
people but may be roles or processes. A role identifies a
function within an organization as opposed to an individual who
performs that function. A process refers to a computer process
that might originate or receive a message.
Special Information. Certain characteristics distinguish a CBMS
from other systems for sending messages. Originators and
recipients may be terminal users or processes (discrete
software). A system in which the originator addresses a
particular terminal device rather than a particular recipient is
not considered to be a CBMS. The recipient's system need not be
available when the originator sends a message. The message can
be stored in the originator's system or at an intermediate node
in the network until the recipient's system becomes available.
In addition, a CBMS offers both message creation and message
processing facilities as part of the system. A CBMS offers text
editing facilities to assist the user in the preparation of a
message. The recipient CBMS stores the message until the
recipient chooses to read it. Message systems which do not
provide these minimum functions are not considered CBMS's.
The intent of the message format standard is to allow users of
different computer based message systems to send messages to each
other. The standard does not make demands on the message
transfer system except that it transports messages transparently.
The standard makes some simple demands on the CBMS. The CBMS
must recognize fields within the message, process fields in
predetermined ways, create messages in the correct form, and
recognize and create data elements of messages in the correct
format. The standard does not dictate or constrain the services
that the CBMS provides for users, or the way that messages are
stored, represented, manipulated, or presented to the user by the
CBMS.
The standard does constrain the format of the message at the
interface between systems. This guarantees that, whatever the
source of the message, it arrives at the receiving system in the
standard format. The message format standard separates
information into fields so that the CBMS can locate and operate
on that information. The message is converted from the format
used within the originator's CBMS to the standard format (if
different) on leaving the originator's CBMS. The message is
converted from the standard format to the format used within the
recipient's CBMS (if different) on entering the recipient's CBMS.
3
Specifications. Federal Information Processing Standard (FIPS),
Message Format for Computer Based Message Systems (affixed).
Qualifications. None
Implementation Schedule. All applicable equipment or services
ordered on or after 24 months from the date of issuance of this
FIPS PUB, and all CBMS development initiated inhouse on or after
12 months from the date of issuance of this FIPS PUB must be in
conformance with this standard unless a waiver has been obtained
in accordance with the procedure described below. An exception
to this standard is made when procurement actions are into the
solicitation phase on the date of issuance of this FIPS PUB.
Waivers. Heads of agencies may request that the requirements of
this standard be waived in instances where it can be clearly
demonstrated that there are appreciable performance or cost
advantages to be gained and that the overall interests of the
Federal Government are best served by granting the requested
waiver. Such waiver requests will be reviewed by and are subject
to the approval of the Secretary of Commerce. The waiver request
must address the criteria stated above as the justification for
the waiver.
Forty-five days should be allowed for review and response by the
Secretary of Commerce. Waiver requests shall be submitted to the
Secretary of Commerce, Washington, D.C. 20230, and labeled as a
Request for a Waiver to a Federal Information Processing
Standard. No agency shall take any action to deviate from the
standard prior to the receipt of a waiver approval from the
Secretary of Commerce. No agency shall begin any process of
implementation or acquisition of non-conforming equipment unless
it has already obtained such approval.
Where to Obtain Copies. Either paper or microfiche copies of this
Federal Information Processing Standard, including technical
specifications, may be purchased from the National Technical
Information Service (NTIS) by ordering Federal Information
Processing Standard Publication (FIPS-PUB-98), Message Format for
Computer Based Message Systems. Ordering information, including
prices and delivery alternatives, may be obtained by contacting
the National Technical Information Service (NTIS), U. S.
Department of Commerce, Springfield, Virginia 22161, telephone
number (703) 487-4650. Payment may be made by check, money
order, purchase order, credit card, or deposit account.
4
Executive Summary
EXECUTIVE SUMMARY
The message format specification addresses the problem of
exchanging messages between different computer-based message
systems (CBMSs). This interchange problem can be addressed on
several levels. One level specifies the physical inter-
connections, another specifies how information travels between
CBMSs, another specifies form and meaning of messages being
interchanged. The highest level specifies operations on a
message. Each of these levels would be covered by a different
standard.
This message format specification addresses only the issues
of form and meaning of messages at the points in time when they
are sent from one CBMS and received by another. Messages are
composed of fields, containing different classes of information.
These fields contain information about the message originator,
message recipient, subject matter, precedence and security, and
references to previous messages, as well as the text of the
message. Standard formats (syntax) for messages provide a basis
for the contents of messages generated by one CBMS to be
processed by another CBMS. Standard meanings (semantics) for the
components of a message facilitate standard interpretation of a
message, so that everyone receiving a message gets the meaning
intended by its sender.
Each CBMS that implements this message format specification
will be compatible with any other CBMS that implements the
specification, provided that the use of optional fields and data
elements is negotiated in advance. This ensures that the
contents of a message posted by one CBMS can be received and
interpreted by a different CBMS.
This message format specification has been developed as a
result of examining CBMSs currently in use in commercial and
research environments. Three major design perspectives helped
shape the message format specification.
o Viability. The message format specification uses
concepts that already work. It has been designed with
implementation concerns in mind.
o Compatibility. The message format specification
contains concepts from existing CBMSs. For this reason,
many CBMS would already contain functions and components
similar to those required to implement the message
format specification.
5
Executive Summary
o Extensibility. This message format specification
defines a broad range of message content components and
requires only an elementary subset of them. This means
that even a very simple CBMS can implement the message
format specification. The message format specification
contains a rich set of optional components and, in
addition, mechanisms for user extensions and future
extensions to the message format specification.
The message format specification defines the form and
meaning of message contents and their components as they pass
from one CBMS to another through a message transfer system. The
message format specification does not address any of the
following major issues.
o Functions or services provided to a user by a CBMS.
For example, the message format specification
assumes that every CBMS allows a user to send and
receive messages. It does not specify any of the
details of how a send function or a message-reading
function might work or how it might appear to the
user. That is, the message format specification
neither limits nor mandates functions.
o Storage or format of message contents in a CBMS.
The message format specification defines the form
and contents of messages when they are transferred
between systems. A CBMS may or may not choose to
use the same format for internal storage.
o Message transfer system protocols.
The message format specification does not specify
how a message travels between CBMSs. It does
specify the form of its contents as it leaves and
arrives, assuming only that the message is moved
transparently by the transfer system.
o Message envelopes.
While a message is traveling between CBMSs, it is
enclosed in a message envelope. Message envelopes
contain all the information about a message that a
message transfer system needs to know. The message
format specification does not define the format or
content of a message envelope.
o How message originators and recipients are identified.
The message format specification does not provide a
representation scheme for the names or addresses of
message originators and recipients as they are
known to a CBMS.
6
Section 1
1. INTRODUCTION
A computer-based message system (CBMS) allows communication
between "entities" (usually people) using computers. Computers
serve both to mediate the actual communications between systems
and to provide users with facilities for creating and reading the
messages.
CBMSs have been developing for over ten years. More
recently, CBMSs have been one of the bases in industry for the
introduction of office automation. A growing number of organi-
zations use either their own or a commercially available CBMS.
The design and complexity of these systems vary widely. This
message format specification provides a basis for interaction
between different CBMSs by defining the format of messages passed
between them.
1.1 Guide to Reading This Document
The method of presenting the material in this specification
is to combine the technical specification with tutorial infor-
mation. This approach has been taken to place the specification
in context and improve its readability.
The core of the technical information in the document is in
Section 2, "A Simple Model of a CBMS Environment"; Section 3.1,
"Semantics of Message Fields"; Section 4.2, "Overview of Syntax
Encoding"; and Section 4.3, "Data Element Syntax". Appendixes A
and B consolidate the technical information. These appendices
are designed for ease of reference and should be read in
conjunction with the body of the report for a complete
understanding of the message format presented in the specifi-
cation.
Section 2 presents a simple model of operation of a CBMS.
Section 3 discusses the components of messages and their meaning
(semantics), including discussions of the recommended
relationship between message components and CBMS user functions.
(See Section 3.2.) Section 4 presents details of the form
(syntax) required for components of a message.
Appendix D summarizes the components of messages according
to whether they are required or optional for CBMSs implementing
the message format specification. Appendix E organizes the
message components according to the functional class of the
components. Appendix F provides an overview of the syntactic
elements defined by this message format specification; Appendix G
7
Section 1.1
summarizes those elements according to whether they are required
or optional for a CBMS implementing the message format specifi-
cation. Examples of each syntactic element appear in Appendix H,
displaying syntax and describing the associated semantics.
1.2 Vendor-Defined Extensions to the Specification
This specification provides the capability of extending the
range of functionality by the use of vendor-defined qualifiers
and vendor-defined data elements. Any vendor who uses this
capability to provide services which are essentially equivalent
to those already designated as required, basic, or optional does
not comply with the specification.
1.3 The Scope of the Message Format Specification
The purpose of this message format specification is to
present the semantics and syntax to be used for messages being
exchanged between CBMSs. Specifically, it defines the following:
o The meaning and form of standard fields to be used in
messages.
o Which fields must be present in all messages.
o Which fields complying CBMSs must be able to process.
o How messages, fields, and the data contained in fields
are represented.
1.4 Issues Not Within the Scope of the Message Format Specifi-
cation
The message format specification does not address the
following issues, some of which are being covered by other NBS
standards development programs at the Institute for Computer
Sciences and Technology (ICST). (See [BlaR-80] for a description
of the ICST network protocols program.)
o The nature of a message transfer system, except to state
the assumption that it transfers messages transparently.
8
Section 1.4
o The form or nature of the protocols used to transfer
messages (posting, relay, and delivery protocols).
o The content and representation of message envelopes.
o Representations for unique identifiers (in particular,
message identifiers).
o Network and internetwork addressing.
o Representations for identities of message originators
and recipients.
o Certain message processing functions that CBMSs provide
for users, e.g., those concerned with the creation and
editing of text.
o Presentation of messages to users.
o Representations for multi-media objects.
o Data representation for messages within CBMSs.
o Data sharing or any storage management within CBMSs.
o Representations for fixed or floating point numbers.
1.5 Relationship to Other Efforts
The message format specification is based on several docu-
ments and the current state of many CBMSs available both in
industry and the research community. These documents include the
standardization efforts in the ARPANet [CroD-77, PosJ-79] and the
CCITT, proposed ISO and ANSI header format standards [TasG-
80, ISOD-79], the work of IFIPS Working Group 6.5, and various
papers about the general nature of mail systems, addressing, and
mail delivery. (See [FeiE-79] for references.
9
Section 2
2. A SIMPLE MODEL OF A CBMS ENVIRONMENT
In order to provide a framework for presenting the message
format specification, this section describes a simple functional
model for a CBMS. The model provides a high-level description of
both user facilities and system architecture. Discussions of
messages, message originators, and message recipients serve to
further clarify the nature of a CBMS.
A CBMS permits the transfer of a message from an originator
to a recipient. "Originator" and "recipient" are used in their
normal English senses. (See Section 2.4.) A message (in its
most abstract definition) is simply a unit of communication from
an originator to a recipient. A CBMS offers several classes of
functions to its users:
o Message Creation: The facilities used by a message
originator to create messages and specify to whom they
are to be sent.
o Message Transfer: The facilities used to convey a mes-
sage to its recipient(s).
o Recipient Processing: The facilities used by a message
recipient to process messages that have arrived.
These classes of functions are presented in more detail in
Section 3.2.
CBMSs differ from other office automation/communications
systems in a number of ways.
o Unlike other types of electronic communications, CBMS
messages are sent to particular individuals, not to
stations or telephone sets. If a recipient moves to a
different location, messages sent to that recipient are
delivered to the recipient at the new location.
o Transmission of CBMS messages is asynchronous. The
recipient's system need not be available when the mes-
sage leaves the originator's system. That is, CBMS
message transfer facilities are store-and-forward.
o CBMS messages can contain a wide variety of data. They
are not constrained to any single kind of communication.
CBMS messages are often simple memoranda but are not
restricted to text. A CBMS message may contain any kind
10
Section 2
of data that an originator wishes to send to a recip-
ient. By contrast, Teletex systems and communicating
word processors handle the transfer of final form
documents; compatible communicating word processors can
exchange documents in editable form; Telex and TWX deal
in unformatted text.
o CBMSs offer message creation facilities as an important
part of the system. CBMSs assist users in the prepa-
ration of messages by having text editing facilities
available and allowing users to include data stored on-
line in messages. Some CBMSs also interface to other
office automation facilities, such as formatters and
spelling correctors. This is not true of Telex, TWX, or
similar services.
o CBMSs offer recipient processing facilities as an impor-
tant part of the system. This is not true of most other
forms of electronic communications. For example, Telex
and TWX systems simply print messages on paper when they
are received, without retaining a copy in the system.
(Teletex systems are similar to Telex systems, but some
can retain a copy of the document in local storage.)
Communicating word processors might notify their
operators that a document has been received and is
stored on-line, but they offer little in the way of
other recipient processing facilities. Most CBMSs offer
at least the following recipient processing facilities:
. The ability to retain a copy of a message on-line
after it has been read.
. The ability to examine or delete stored messages
individually.
. The ability to organize messages using some form of
electronic "file folder."
. The ability to determine if a message is recent
(has arrived since the last time the recipient used
the CBMS) or unseen (has never been examined by the
recipient).
. The ability to summarize stored messages. A
summary usually includes information such as
whether the message is recent or unseen, when it
was received, its length, who it is from, and its
subject.
. The ability to retrieve a stored message based upon
11
Section 2
one or more of its attributves (for example, when
the message was received, whether or not it has
been seen or deleted, and the values contained in
its fields).
. A forward facility that allows users to include all
or part of a message in a new outgoing message.
. A reply facility that allows users to answer mes-
sages without having to enter a new list of recip-
ients.
2.1 Logical Model of a CBMS
CBMS facilities for message creation, transfer, and recip-
ient processing are reflected in a logical model of a CBMS
developed by IFIP Working Group 6.5. (An essentially identical
model is being used by CCITT Study Group VII, Question 5,
regarding Message Handling Systems [CCIT-82].) The model
consists of a Message Transfer System and a number of User
Agents. (See Figure 1.)
| |
| ************* |
********* ------> * Message * -------> *********
* User * Posting * Transfer * Delivery * User *
* Agent * Protocol * System * Protocol * Agent *
********* <------- ************* <------- *********
| |
| |
Posting Delivery
Slot Slot
Message Flow
Originator --------------------------------> Recipient
FIG. 1. LOGICAL MODEL OF A COMPUTER-BASED MESSAGE SYSTEM
A User Agent (UA) is a functional entity that acts on behalf
of a user, assisting with creating and processing messages and
communicating with the Message Transfer System.
The Message Transfer System(MTS) is an entity that accepts a
12
Section 2.1
message from its originator's User Agent and ultimately passes it
to each of its recipients' User Agents. The Message Transfer
System may perform routing and storage functions (among others)
in order to accomplish its task.
Transferring a message from an originator's User Agent to
the Message Transfer System is called Posting; the originator's
User Agent and Message Transfer System engage in a Posting
Protocol in order to accomplish Posting. Transferring a message
from the Message Transfer System to a recipient's User Agent is
called Delivery; the recipient's User Agent and Message Transfer
System engage in a Delivery Protocol in order to accomplish
Delivery.
The point at which responsibility for a message is trans-
ferred is called a Slot. The Posting Slot is the point at which
responsibility for a message passes from an originator's User
Agent to the Message Transfer System; the Delivery Slot is the
point at which responsibility for a message passes from the
Message Transfer System to a recipient's User Agent.
The model divides messages into two parts, the message
content and the message envelope. The message content is the
information that the originator wishes to send to the recipient;
this message format specification deals solely with the message
content. The message envelope consists of all the information
necessary for the Message Transfer System to do its job; this
message format specification does not specify the message
envelope. Some of the data appearing on the message envelope
could be redundant with some data found in the message content.
The Message Transfer System is not expected to examine the
message content unless it is told to do so by the originator's or
recipient's User Agent.
This message format specification places no restrictions on
the Message Transfer System itself, except that it be able to
transfer messages between originating and receiving UAs without
reading or altering the contents of messages unless otherwise
instructed by the UAs. In addition, this message format specifi-
cation does not dictate the form or nature of any protocol used
by the Message Transfer System. Finally, this message format
specification does not specify the content or form of the message
envelope. That is, the message format specification defines the
format for the contents of messages, not the manner in which they
are transmitted.
Many of today's commercially available CBMSs incorporate all
of the facilities represented in the logical model. Their
architectures may reflect the economies that can be taken when
implementing systems that are self-contained. For example,
stand-alone systems that store messages in a single central
13
Section 2.1
database require no Message Transfer System; an implementation
may integrate software for User Agent and Message Transfer System
functions, doing away with Posting or Delivery Protocols.
2.2 Relationship to the ISO Reference Model for Open Systems
Interconnection
Subcommittee TC97/SC16 of the International Organization for
Standardization (ISO) has developed a reference model for
describing communications between "open" systems [ISOD-82]. This
model is known as the ISO Reference Model for Open Systems
Interconnection (OSI). It divides communications protocols into
seven layers, ranging from physical interconnection at the lowest
layer to data exchange by application programs at the top.
This message format specification deals with data used by an
application within a system. Thus, the message format being
specified here is not a protocol. Since it is not a protocol, it
lies outside of the model for open systems interconnection. User
Agents are application layer entities (layer 7), however, and the
protocols used by a message transfer system are above the session
layer (layer 5).
2.3 Messages and Fields
A message is a unit of communication from an originator to a
recipient. A message consists of a series of components called
fields. Fields can be described according to their meaning in a
message (semantics) and according to the format required for them
in a message (syntax).
Semantically, a field is just a component of a message; the
meanings of particular fields are defined by this message format
specification. Syntactically, a field is a unit of data whose
form is defined by this message format specification. Additional
fields can be defined by users or vendors as long as they conform
to the syntactic and semantic rules that this message format
specification defines for additional fields.
(A note on terminology: A message consists of components
called fields. The words "message" and "field" are used both in
the informal sense of the previous sentence and in a more
restricted sense as names of particular syntactic elements. As
syntactic element names, Message and Field are always
capitalized.)
14
Section 2.3
Some CBMS functions are based on the contents of particular
fields; other functions (such as the ability to read a message)
may have little to do with the fields themselves. Section 3.2
discusses some of the specific functions that a CBMS might
provide to users and the fields that must be used to support
those functions.
2.4 Message Originators and Recipients
This message format specification refers to message origi-
nators and recipients. These terms were defined functionally in
Figure 1. When the message format specification refers to the
identity of a message originator or recipient, it means "that
information which uniquely identifies the message originator or
recipient within the domain of the given message system." The
syntax and semantics of message addressing are not within the
scope of the message format specification.
Originators and recipients can be people, roles, processes
or groups.
People. People as originators and recipients are specific
individuals.
Roles. Roles identify functions within organizations as
opposed to the specific individuals who perform them. For
example, consider a newspaper that produces both morning and
evening editions and therefore operates with more than one shift.
Someone wishing to contact the city desk would send a message to
the city desk role rather than trying to determine exactly who
was assigned to the city desk at a specific time. (Of course,
messages can usually be sent to the individuals directly whether
or not they are actually performing a role at the time.)
Processes. A process in a computer could serve as either an
originator or a recipient for messages. A computer system might
originate a message to notify a recipient about the status of
some task. For example, an archive utility could notify users
about files that have been archived; a distributed file system
could notify a user that a remote file has been deposited on a
local file system. Messages could be used by computer systems to
warn about some impending condition or even to monitor the
performance of the computer itself. Some computer processes may
also be message recipients, taking action based upon message
contents.
In addition, some CBMSs allow messages to be sent to groups.
A group is a predefined list of message recipients. Using a
15
Section 2.4
group name as a recipient permits message originators to
designate a potentially large number of recipients using a single
recipient identifier. This makes using the CBMS more convenient
and accurate.
16
Section 3
3. SEMANTICS
This section discusses two major topics, message processing
functions and message field meanings. Section 3.1 describes the
six functional groups of message fields. The functional groups
are Origination, Dates, Recipients, Cross-referencing, Message-
handling, and Message-contents. They are explained more fully in
Section 3.1.1, along with detailed discussion of the semantics of
all the fields in each functional group. Section 3.2 describes
message processing functions whose operation is based on the
meanings of particular message fields.
3.1 Semantics of Message Fields
The definition of a message is discussed generally in
Sections 1 and 2. Semantically valid messages must contain one
From field, one To field, and one Posted-Date field. They may
contain, in addition, any number of other fields, depending on
the processing and functions supplied by the originating or
receiving CBMS. (Section 3.2 describes classes of functions
supplied by CBMSs.)
3.1.1 Types of fields
Message receiving programs are required to interpret fields
according to the semantics described in the remainder of this
section. The message fields defined in this document are grouped
into the following functional categories.
o Originator fields indicate who or what participated in
the creation of the message and where replies should be
directed. (See Section 3.1.3.)
o Date fields record when events take place, for a variety
of events, such as message creation or expiration. (See
Section 3.1.5.)
o Recipient fields indicate who or what is intended to
receive a message. (See Section 3.1.4.)
o Cross-reference fields label a message or refer to other
messages. (See Section 3.1.6.)
o Message-handling fields record the type of service a
17
Section 3.1.1
message's sender requested of a message transfer system
or indicate how the message should be treated by its
recipients. (See Section 3.1.7.)
o Message-content fields either contain the primary
content of a message, or index the message, or summarize
the message. (See Section 3.1.8.)
o Extension fields provide mechanisms for extending the
message format specification. (See Section 3.1.9.)
3.1.2 Semantic Compliance Categories
For purposes of determining whether a CBMS complies with the
semantic requirements of this message format specification, mes-
sage fields have been divided into three categories:
REQUIRED These fields must be present in all messages and must
be processed by message receiving programs as defined
by the message format specification.
BASIC These fields need not be present in all messages but
when they do appear, they must be processed by message
receiving programs as defined by the message format
specification.
OPTIONAL These fields need not be present in all messages and
may be ignored by message receiving programs. The
exact meaning of "ignored" is not specified by the
message format specification. However, a CBMS must
recognize the existence of an optional field (that is,
optional fields should not cause errors) and must not
process the field in a manner contrary to the semantics
defined for that field by the message format specifi-
cation. It is left to the discretion of a recipient's
CBMS what action is to be taken when an instance of a
locally unimplemented optional field is detected.
(Syntactic compliance is defined in Section 4.1.2.)
3.1.3 Originator fields
A message originator may be a person, role, or process.
Originator fields identify a message's author, who is responsible
for the message, who or what sent it, and where any
replies should be directed. (See Section 2.4.)
18
Section 3.1.3
From (REQUIRED)
This field contains the identity of the originator(s)
taking formal responsibility for this message. The
contents of the From field is to be used for replies
when no Reply-to field appears in a message.
Reply-To (BASIC)
This field identifies any recipients of replies to the
message.
Author (OPTIONAL)
This field identifies the individual(s) who wrote the
primary contents of the message. Use of the Author
field is discouraged when the contents of the Author
field and the From field would be completely redundant.
Sender (OPTIONAL)
This field identifies the agent who sent the message.
It is used either when the sender is not the originator
responsible for the message or to indicate who among a
group of originators responsible for the message
actually sent it. Use of the Sender field is
discouraged when the contents of the Sender field and
From field would be completely redundant. The sender
field may specify only one originator identity and
appear only once in a message.
3.1.4 Recipient fields
Message recipients may be people, roles, processes, or
groups. (See Section 2.4). Recipient fields identify who or
what is to receive the message.
To (REQUIRED)
This field identifies the primary recipients of a
message.
Bcc (OPTIONAL)
This field identifies additional recipients of a
message (a "blind carbon copies" list). The contents
of this field are not to be included in copies of the
message sent to the primary and secondary recipients.
See section 3.2.1 for further discussion of the use of
blind carbon copies lists.
19
Section 3.1.4
Cc (BASIC)
This field identifies secondary recipients of a message
(a "carbon copies" list).
Circulate-Next (OPTIONAL)
This field is used in conjunction with the Circulate-To
field. (See Section 3.2.6.1.) It identifies all
recipients in a circulation list who have not received
the message.
Circulate-To (OPTIONAL)
This field identifies recipients of a circulated
message. (See Section 3.2.6.1.) It is used in
conjunction with the Circulate-Next field.
3.1.5 Date fields
Date fields for two kinds of uses are provided. Dates can
be associated with some event in the history of a message and
dates can delimit the span of time during which the message is
meaningful (its life span).
Posted-Date (REQUIRED)
This field contains the posting date, which is the
point in time when the message passes through the
posting slot into a message transfer system. Only one
Posted-Date field is permitted in a message.
Date (OPTIONAL)
This field contains a date that the message's
originator wishes to associate with a message. The
Date field is to the Posted-Date field as the date on a
letter is to the postmark added by the post office.
End-Date (OPTIONAL)
This field contains the date on which a message loses
effect. (See also Section 3.2.5.)
Received-Date (OPTIONAL)
This field is also called Delivery date. This field
may be added to a message by the recipient's message
receiving program. It indicates when the message left
20
Section 3.1.5
the delivery system and entered the recipient's message
processing domain.
Start-Date (OPTIONAL)
This field contains the date on which a message takes
effect. (See also Section 3.2.5.)
Warning-Date (OPTIONAL)
This field is used either alone or in conjunction with
an End-Date field. It contains one or more dates.
These dates could be used by a message processing
program as warnings of an impending end-date or other
event. (See also Section 3.2.5.)
3.1.6 Cross-reference fields
Cross-reference fields can be used to identify a message and
to provide cross-references to other messages. (See Section
3.2.4.)
In-Reply-To (OPTIONAL)
This field designates previous correspondence to which
this message is a reply. The usual contents of this
field would be the contents of the Message-ID field of
the message(s) being replied to.
Message-ID (OPTIONAL)
This field contains a unique identifier for a message.
This identifier is intended for machine generation and
processing. Further definition appears in Section
3.2.4.1. Only one Message-ID field is permitted in a
message.
Obsoletes (OPTIONAL)
This field identifies one or more messages that this
one replaces.
Originator-Serial-Number (OPTIONAL)
This field contains one or more serial numbers assigned
by the message's originator. Messages with multiple
recipients should have the same value in the
Originator-Serial-Number field.
21
Section 3.1.6
References (OPTIONAL)
This field identifies other correspondence that this
message references. If the other correspondence
contains a Message-ID field, the contents of the
References field must be the message identifier.
3.1.7 Message-handling fields
Message-handling fields describe aspects of how a message is
to be handled or categorized.
Precedence (OPTIONAL)
This field indicates the precedence at which the
message was posted. Ordinarily, message precedence or
priority is a service request to a message transfer
system. A message originator, however, can include
precedence information in a message. One example of
precedence categories are those used by the U.S.
Military: "ROUTINE," "PRIORITY," "IMMEDIATE," "FLASH
OVERRIDE," and "EMERGENCY COMMAND PRECEDENCE."
Message-Class (OPTIONAL)
This field indicates the purpose of a message. For
example, it might contain values indicating that the
1
message is a memorandum or a data-base entry.
Reissue-Type (OPTIONAL)
This field is used in conjunction with message
encapsulating (see Section 3.2.2) to differentiate
between messages being assigned or redistributed.
Received-From (OPTIONAL)
This field contains a record of a message's path
through a message transfer system. The
recipient's message receiving program could store here
any information about the transfer that it obtained
from a message transfer system.
_______________
1
The message format specification is not intended to be used as
a specification for exchanging data-base records. Messages,
however, sometimes contain data from or for a database.
22
Section 3.1.7
3.1.8 Message-content fields
The intent of most messages is to communicate some
particular information from originator to recipient. Several
fields in a message are designed to contain that information.
Subject (BASIC)
This field contains any information the originator
provided to summarize or indicate the nature of the
message.
Text (BASIC)
This field contains the primary content of the message.
Attachments (OPTIONAL)
This field contains additional data accompanying a
message. It is similar in intent to enclosures in a
conventional mail system.
Comments (OPTIONAL)
This field permits adding comments to the message
without disturbing the original contents of the
message.
Keywords (OPTIONAL)
This field contains keywords or phrases for use in
retrieving a message.
3.1.9 Extensions
This message format specification allows two additional
types of fields, vendor-defined fields and as-yet-undefined
(extension) fields that will be introduced by extensions to this
message format specification.
vendor-defined-field
Any field not defined in this message format specifi-
cation or any extension or successor to it is a vendor-
defined field. Names for vendor-defined fields could
be preempted by extensions to this message format
specification.
23
Section 3.1.9
extension-field
Any field that is defined in a document published as a
formal extension or replacement to this message format
specification.
3.2 Message Processing Functions
A CBMS provides three basic classes of functions: creating
messages, transmitting messages to their recipient, and post-
receipt processing. Although the message format specification
does not define the number or nature of user functions in CBMSs,
the meanings for the fields clearly assume certain kinds of
functions. For example, fields specifying recipients of replies
to messages assume some kind of reply function; fields specifying
message life span assume some kind of date processing functions.
This section provides more detail on the processing that
might be done by these kinds of functions, discussing the message
fields that would be used and how they would be used. (See
summary in Table 1.)
Processing Function Fields Involved
Message creation Author, From, Sender, To,
and posting Cc, Bcc
Message reissuing Reissue-Type
Reply generation Reply-To
Cross-referencing Message-ID, In-Reply-To, References,
Obsoletes, Originator-Serial-Number
Life span functions Start-Date, End-Date,
Warning-Date
Recipient processing Circulate-To, Circulate-Next
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS
3.2.1 Message creation and posting
Messages can be created either by reissuing an existing
message to a new recipient (see Section 3.2.2) or by creating a
new message. The process of message creation might mean that
some fields of a new message are filled in from the contents of
some other message. Reply functions (Section 3.2.3) provide an
example of this.
24
Section 3.2.1
Different individuals could be involved in different phases
of originating a message: creating it, taking responsibility for
it, and explicitly interacting with a CBMS to send it to its
recipient. One or more individuals may create a message (that
is, write, but not necessarily enter it into the CBMS); they are
said to be the message's authors, identified by the Author field.
One or more individuals may take responsibility for its contents
and the decision to post it; they are identified by the From
field. One individual explicitly posts a given message; this
person is called the message's sender (identified by the Sender
field).
The sender and author(s) are often, but not always, respon-
sible for the message. A common case in which the sender is not
responsible for the message is when a secretary enters and posts
messages for someone else. An example of a situation in which a
message's author is not responsible for the message itself is
when an administrative assistant prepares a report that is sent
under a manager's signature.
The use of the Cc field is identical to current business
practice. This field contains the formal secondary recipients of
the message.
Messages containing Bcc fields are treated specially by
CBMSs. The contents of this field are not included in copies of
the message sent to the recipients other than the originator who
are not included in the Bcc field itself. Some systems include
the contents of the Bcc field only in the originator's copy;
others include all or part of the Bcc field in the copies sent to
the recipients indicated in the Bcc field. This specification
does not indicate exactly how the Bcc field is to be treated.
3.2.2 Message reissuing and forwarding
Reissuing and forwarding both serve the general user goal of
passing a message on to a new set of recipients. Forwarding is
the term used for an informal mechanism, which CBMSs implement by
copying some or all of the original message into the contents of
a field in the new message. Reissuing is the term used for a
formal mechanism to ensure that the message being passed on never
loses its integrity as a previously sent message. CBMSs use
reissuing to implement several different functions, depending on
the purposes being served:
o Redistribution. Making others aware of the complete and
unaltered contents of the message.
25
Section 3.2.2
o Assignment. Delegating the responsibility for a message
to somebody else.
These purposes are exemplified in Figure 2.
When a CBMS examines a forwarded message, it cannot always
distinguish the old message from what was added when the
forwarding took place. In addition, the forwarded information
might no longer have the form of a message. This is usually
because the format of the message has been changed (for example,
to pure unformatted text). (See Figure 2 for an example of how a
CBMS might forward a message.) In contrast, a reissued message
can always be separated from its enclosing message and never
loses its identity as a correctly formed message.
This specification provides the Reissue-Type field for
supporting reissuing. Forwarding, since it is an informal means
of serving the purpose of passing on information, has no
supporting fields in the specification.
This specification provides for reissuing of messages by
encapsulating. This method embeds the entire original message
inside a new message. Encapsulating adds structure around the
2
message . This allows any part of it to be easily extracted.
This procedure for passing on previously sent messages is a
matter of organizational policy and has authentication as an
associated issue. Each organization must decide if the CBMS it
acquires should support reissuing or simply supply forwarding.
3.2.2.1 Redistribution
Redistribution is a CBMS function for sending the original
contents of a message intact and unchanged to new recipients. A
redistributed message is identical to the original message with
the exception of added information about the reissuing. For
reissuing with this purpose, the Reissue-Type field contains the
ASCII string "Redistribution." The original message has been
included directly in a new message. (See Figure 2.)
_______________
2
A message can contain another message, and that message can
contain another message, and so on to any depth of encapsulating.
This can occur by reissuing a message repeatedly.
26
Section 3.2.2.2
The Original Message
John Doe wishes Jane Jones to get a copy of the following
message:
Message:
Field: From "Jean Smith"
Field: Posted-Date "27 January 1983"
Field: To "John Doe"
Field: Subject "Next Project Meeting"
Field: Text "The agenda for ..."
Redistribution
Message:
Field: From "John Doe" John Doe is responsible
Field: Posted-Date "28 January 1983" for the redistribution.
Field: To "Jane Jones"
Field: Reissue-Type "Redistribution" This message directly
Message: incorporates a
Field: From "Jean Smith" redistributed message.
Field: Posted-Date "27 January 1983"
Field: To "John Doe"
Field: Subject "Next Project Meeting"
Field: Text "The agenda for ..."
Forwarding
Message:
Field: From "John Doe"
Field: Posted-Date "28 January 1983"
Field: To "Jane Jones"
Field: Text A realization of the
"From Jean Smith original message is
To John Doe copied into the Text field.
Sent on 27 January 1983 Note that John's CBMS
Subject Next Project Meeting has chosen to represent
it as a text string.
The agenda for ..."
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION
27
Section 3.2.2.2
3.2.2.2 Assignment
Assignment is the process of designating responsibility. In
some organizations, formal message traffic is distributed to one
or more parts of the organization (called offices) where it is
directed to the appropriate individuals or other offices for
final disposition. Assignment is done by reissuing a message
with the Reissue-Type field containing the ASCII string
"Assigned." A message which contains this field is to be
interpreted as meaning that the addressees in the "To" field have
had the reissued message assigned to them for some action. Any
addressee in the "Cc" field has had the message assigned for
information. The "From" field records who assigned the message
and the "Posted-Date" field records when the message was
assigned.
3.2.3 Reply generation
Reply generation involves creating a new message in direct
reply to some other message by drawing on the contents of fields
in the other message to fill fields in the new message. Many
CBMSs provide reply facilities that determine the intended recip-
ients of a reply.
A Reply-To field is defined by this message format specifi-
cation. When a message contains a Reply-To field, the CBMS
should send replies to the recipients designated in the Reply-To
field instead of to the recipients designated in the From field.
This statement applies to original messages only, not to reissued
messages. The message format specification makes no
recommendations concerning replies to reissued messages.
Reply-To has several possible applications:
o The individual(s) responsible for the message might not
have regular access to a CBMS and would indicate an
alternate recipient, for example, a secretary.
o The people responsible for receiving responses might not
be the people who were responsible for creating the
message.
o Discussion and conference groups could use this feature
to ensure correct distribution of any submission by
having the conference group itself designated in the
Reply-To field.
28
Section 3.2.3
When the message does not contain a Reply-To field, the
recipient should reply to the originators enumerated in the From
field. The sender and authors should not be added automatically
to the list of those receiving the reply.
Replies could also be sent to the other recipients of the
original message. Vendors might offer additional reply facil-
ities, depending on their view of users' organizational require-
ments.
3.2.4 Cross-referencing
A CBMS message may include designator(s) which identify
other message(s). The designators are used to refer to related
messages so that all information in a chain of correspondence can
be determined by a CBMS user. The designator used to identify
and cross-reference messages can take either of two forms, unique
identifiers or serial numbers.
3.2.4.1 Unique identifiers
Unique identifiers are machine-generated and are intended
primarily for processing by computers. While they could be
examined by a human user, unique identifiers are not necessarily
useful or convenient for people.
Unique identifiers occur in several contexts. They are
often used to identify the contents of idual messages
unambiguously. When unique identifiers are used this way, they
are called message identifiers. Different versions of a message
receive new message identifiers; an example of this is reissuing
a message with comments.
When a CBMS generates a message identifier, it must be able
to guarantee that it is unique, both within the domain of the
individual CBMS and globally, across all connected CBMSs. CBMSs
could generate globally unique identifiers in several ways, all
of which require prior agreement on behalf of the connected
CBMSs. One method is to assign each connected CBMS a unique
code. A CBMS then generates unique identifiers by using its code
as a prefix to some other value that it can guarantee to be
unique within its domain. (This second value could be a counter
or a timestamp/user-id combination.)
A CBMS can provide functions for tracing chains of corre-
spondence by using unique identifiers. The message format
specification defines fields for which a CBMS provides unique
identifiers as values. They are Message-ID, References,
Obsoletes, and In-Reply-To. (See Section 3.1.6.)
29
Section 3.2.4.1
3.2.4.2 Serial numbering
Serial numbers are for users to maintain a personal num-
bering system for messages. The numbers are composed of both
letters and digits so that users could maintain several sets of
sequences concurrently (for example, A1, A2, A3... and B1, B2,
B3...).
Serial numbers are assigned at a defined point in the
history of a message. Serial numbers are not unique identifiers;
they differ from unique identifiers in that they are not neces-
sarily generated or processed by a CBMS. They are designed to be
entered and read by CBMS users. They can be as simple or complex
as the user requires. Serial numbers are intended to be used to
designate messages about a specific topic, or messages a given
user has sent. Serial numbers are intended to be a permanent
part of the message, just as unique identifiers are.
A CBMS can provide functions allowing originators to add
serial numbers to messages. Originator-Serial-Number is the
field provided for an originator to add a serial number to a
message before sending it.
3.2.5 Life span functions
Messages have life spans, usually delimited by the creation
date and the time when the last copy of the message is destroyed.
Messages could be meaningless before a certain time or irrelevant
after a certain time. For example, a reminder to attend a
meeting on 5 June loses most of its value on the sixth; a
reminder to attend that same meeting may be of little use on 5
May (although not for the same reason).
A CBMS can define a message's life span explicitly using the
Start-Date and End-Date fields. A third field, Warning-Date,
when used in conjunction with the End-Date, may be used to signal
the approach of the End-Date. Warning-Date may also stand alone
and be used by a periodic warning (alarm clock) mechanism.
A CBMS could use these fields to help users manage their
message stores. For example, a message whose start date has not
yet passed could be bypassed by a retrieval command unless the
user requested such messages explicitly. A CBMS could use the
end date to help with message store housekeeping either by
archiving or deleting the expired messages automatically or by
asking the user for some action to be taken on them. The warning
date could be used to remind the user automatically of an
impending end date, such as a meeting reminder.
30
Section 3.2.6
3.2.6 Requests for recipient processing
Recipients have a wide variety of needs for examining and
processing a message, ranging from automatic output on some
specified device to the execution of a program embedded in the
message itself. Because many of these needs are highly
specialized, and support for them not widely implemented, this
message format specification does not constrain the requests for
processing that may be included in a message.
The message format specification does provide two fields
that permit an originator to request circulation list processing
from the recipient. These fields are Circulate-To and Circulate-
Next.
3.2.6.1 Message circulation
Message circulation involves serial distribution of a mes-
sage to its recipients, based on a distribution list that is part
of the message. The message is delivered first to the first
recipient on the distribution list. This recipient, or someone
the recipient delegates, sends the message on to the second
recipient on the list, perhaps after commenting on or adding to
the message. This continues until all recipients on the
distribution list have received the message.
This message format specification provides two fields to
support message circulation. The Circulate-To field contains the
complete distribution list, indicating the full set of recip-
ients, and the Circulate-Next field indicates which recipients
have not seen the message. See Figure 3 for an example of
message circulation using these two fields.
3.3 Multiple Occurrences and Ordering of Fields
Most message fields may occur more than once in a message;
the exceptions are the Posted-Date, Sender, and Message-ID
fields, which may occur once, at most. What this means is that a
received message may contain any number of instances of a
particular field (such as the "To" field). If a message contains
more than one instance of a particular field, that field "occurs
multiply" and that message has "multiple occurrences" of that
field.
A particular instance of a message field is not superseded
by later instances of the same field. The To field is an example
of this.
31
Section 3.3
-----------------------------------------------------------------
A message originator wishes to circulate a message to
recipients A, B and C. The originator includes the
following fields in the message:
To: A
Circulate-To: A, B, C
Circulate-Next: B, C
When recipient A or someone A delegates causes the
message to be further circulated, the message is sent
to the first address in the Circulate-Next field, and
that name is removed from that field:
To: B
Circulate-To: A, B, C
Circulate-Next: C
B now sends the message on to its final recipient:
To: C
Circulate-To: A, B, C
FIG. 3. EXAMPLE OF MESSAGE CIRCULATION
-----------------------------------------------------------------
Multiple occurrences of a field are not necessarily equiv-
alent to a single field containing the concatenated contents of
the several instances of the given field. For example, with the
Text field, concatenating the contents of several instances might
lose important distinctions between the contents. A single
message could be used to send three different documents, each one
in a different Text field. However, putting the three documents
into a single Text field would make it much more difficult to
extract any individual document.
Encapsulated messages are exceptions to the multiple
occurrences rule. For example, the To field in an encapsulated
message is not a multiple occurrence of the To field in the
enclosing message.
The fields found in a single message may occur in any order.
The order in which they occur does not necessarily reflect the
32
Section 3.3
order in which they were created. Nor does it constrain the
order in which the message recipient examines, processes, or
displays them.
33
Section 4
4. SYNTAX
This section begins with an introduction to the concepts and
elements that constitute the syntax for messages. The second
section presents an overview of the encoding scheme. The third
section describes in detail the elements of the message syntax.
4.1 Introduction
This specification defines syntactic requirements for mes-
sages when they are passed from one CBMS to another. The
specification is designed to meet the following goals.
o Provide a concise, flexible representation scheme.
o Simplify message parsing.
o Support non-textual components in messages (for example,
3
facsimile, graphics, or speech ).
4.1.1 Message structure
Messages have two classes of components, fields and
messages. A field corresponds to one of the semantic components
defined in this message format specification. A message is
simply another message.
The type of a field in a message determines both its meaning
and the form for its contents. (See Section 4.3.2.)
Fields in a message are composed of syntactic elements
called data elements. A Message data element is used to
represent messages; a Field data element is used to represent
fields. (The term "field" is simply a semantic construct,
distinct from "Field Data Element," which is a syntactic
_______________
3
While this message format specification is not intended to be
used as a basis for the interchange of all facsimile information,
it does recognize that CBMS messages may contain facsimile
components.
34
Section 4.1.1
construct.) Many of the fields defined in this message format
specification are restricted to containing only one kind of data
element. (See Section 4.3.2.)
Each field defined in this message format specification has
been assigned a unique numeric identifier that is used in
conjunction with the Field data element. Separate identifiers
are provided for vendor-defined fields and for extending the
identifier encoding space. A list of fields and identifiers
appears in Section 4.3.2 and in Appendix C.
Throughout the message format specification, fields are
referred to by label name rather than by their numeric identi-
fiers. Field labels are names like "Sender," "Warning-Date," or
"Circulate-To." The field labels chosen for the specification
are names that are in common use in current CBMSs. The
specification does not require a CBMS to use these field labels
in displaying fields to the user.
4.1.2 Data elements
For the purpose of determining compliance with the syntax
defined in this specification, data elements are divided into two
groups:
BASIC All message receiving systems must process these
syntactic elements, interpreting their values according
to the message format specification.
OPTIONAL Message receiving systems need not process these
syntactic elements in order to be in compliance.
In addition, complying CBMSs must meet requirements
regarding their ability to process the components found inside
data elements. These requirements are discussed in Section
4.2.2.
This message format specification classifies data element
types as either primitives or constructors. Primitive data
elements, such as ASCII-String, are basic building blocks.
Constructor data elements, such as Message or Sequence, contain
one or more primitive or constructor data elements. Some
constructors, such as Sequence, may be composed of any other data
element. Some, such as Message, may contain only certain data
elements. Two data elements, Extension and Vendor-Defined, may be
classified as either primitives or constructors, depending on how
they are used to extend this specification. The general
syntactic form for data elements is discussed in section 4.3.1.
35
Section 4.1.2
4.1.2.1 Primitive data elements
A primitive data element contains a basic item of
information; it is not composed of other data elements. In
current CBMSs, the most commonly used primitive data element is
4
ASCII-String, a series of ASCII characters. Other primitive data
elements are Integer, 2's complement integers; Bit-String, a
series of bits; and Boolean, either True or False.
One primitive data element, End-Of-Constructor, is used only
as a structural element within constructor data elements and has
no meaning by itself. End-of-Constructor is used to provide an
end marker for constructor data elements that do not have an
explicit length; any other use is not valid syntactically.
4.1.2.2 Constructor data elements
The Data Element Contents of constructor data elements
contain one or more data elements. The most general form of a
constructor is a Sequence or a Set, since both Sequences and Sets
may contain any data element. Other constructors are specialized
forms of
|
