As per Relevance of the word contents, we have this rfc below:
RFC 841
FIPS Pub 98
SPECIFICATION FOR MESSAGE FORMAT FOR
BASED MESSAGE
27 January 1983
National Bureau of
This RFC is FIPS 98. The purpose of distributing this
as an RFC is to make it easily accesible to the ARPA
community. This RFC does not specify a standard for the
Internet
TABLE OF
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
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
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
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
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
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
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
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
H.7.3 Field Mappings of JANAP-128 to FIPS Format 101
H.7.4 Vendor-Defined Fields 101
REFERENCES 103
INDEX 105
LIST OF
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
FIG. 6. REPRESENTATION OF LENGTH CODES 42
FIG. 7. EXAMPLES OF QUALIFIER VALUES 43
LIST OF
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS 24
TABLE 2. HIGH-ORDER BITS IN THE IDENTIFIER OCTET 39
Federal
Processing Standards Publication 98
27 January 1983
Announcing the Standard
MESSAGE
COMPUTER BASED MESSAGE
Federal Information Processing Standards Publications are
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
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
Systems (FIPS PUB 98).
Category of Standard. Software Standard; Interchange Codes,
and Data Files
Explanation. This standard separates information so that
Computer Based Message System can locate and operate on
information (which is found in the fields of messages). This
the first of a family of standards which will ensure
interchange among Computer Based Message Systems
Approving Authority. Secretary of
Maintenance Agency. Department of Commerce, National Bureau
Standards (Institute for Computer Sciences and Technology).
Cross Index. Not Applicable
Related Documents
a. American National Standard Code for
Interchange (ASCII), X3.4-1977,FIPS PUBS 1-1.
b. American National Standard Code Extension
for Use with the 7-bit Coded Character Set of
National Standard Code (ASCII) for
Interchange, X3.41-1974, FIPS PUB 35.
c. National Bureau of Standards. Calendar Date.
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
46, U.S. Department of Commerce/National Bureau
Standards, January, 1977.
e. National Bureau of Standards. Representation of
Time of the Day for Information Interchange.
Information Processing Standards Publication 58, U.S
Department of Commerce / National Bureau of Standards
February 1979.
f. National Bureau of Standards. Representation
Universal Time, Local Time Differentials, and
States Time Zone References for
Interchange. Federal Information Processing
Publication 59, U.S. Department of Commerce /
Bureau of Standards, February, 1979.
Applicability. This message format standard applies to
departments and agencies in their acquisition and use
computer-based message systems (CBMS) and services in
systems, except for certain single-processor systems
Specifically, the standard does not apply to a CBMS if it is
stand-alone system which is not interconnected with any
CBMS: nevertheless, conformance with the standard is
under these circumstances particularly if there is a
that use of another central processing unit, or
with another system, will be required in the future. Where a
CBMS node is incorporated into an existing network, the
applies at the interface between CBMS's. In this instance
previously existing nodes may accommodate the standard
through retrofit or by the use of a translator. In addition
networks that are established strictly for the purpose
supporting research in computer science or communications
exempt from complying with this standard
Subcommittee TC97/SC16 of the International Organization
Standardization (ISO) has developed a reference model
describing communications between "open" systems. (ISO/TC97/SC16
DIS7498) This model is known as the ISO Reference Model for
Systems Interconnection (OSI). It divides
protocols into seven layers, ranging from
interconnection at the lowest layer to data exchange
applications programs at the top
The NBS message format deals with data used by an
within a system; it is not a protocol. Messages defined by
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
communication from an originator to a recipient, exclusive of
message heading or control information (often referred to as
message envelope). An originator and recipient are
people but may be roles or processes. A role identifies
function within an organization as opposed to an individual
performs that function. A process refers to a computer
that might originate or receive a message
Special Information. Certain characteristics distinguish a
from other systems for sending messages. Originators
recipients may be terminal users or processes (
software). A system in which the originator addresses
particular terminal device rather than a particular recipient
not considered to be a CBMS. The recipient's system need not
available when the originator sends a message. The message
be stored in the originator's system or at an intermediate
in the network until the recipient's system becomes available
In addition, a CBMS offers both message creation and
processing facilities as part of the system. A CBMS offers
editing facilities to assist the user in the preparation of
message. The recipient CBMS stores the message until
recipient chooses to read it. Message systems which do
provide these minimum functions are not considered CBMS's
The intent of the message format standard is to allow users
different computer based message systems to send messages to
other. The standard does not make demands on the
transfer system except that it transports messages transparently
The standard makes some simple demands on the CBMS. The
must recognize fields within the message, process fields
predetermined ways, create messages in the correct form,
recognize and create data elements of messages in the
format. The standard does not dictate or constrain the
that the CBMS provides for users, or the way that messages
stored, represented, manipulated, or presented to the user by
CBMS
The standard does constrain the format of the message at
interface between systems. This guarantees that, whatever
source of the message, it arrives at the receiving system in
standard format. The message format standard
information into fields so that the CBMS can locate and
on that information. The message is converted from the
used within the originator's CBMS to the standard format (
different) on leaving the originator's CBMS. The message
converted from the standard format to the format used within
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.
Implementation Schedule. All applicable equipment or
ordered on or after 24 months from the date of issuance of
FIPS PUB, and all CBMS development initiated inhouse on or
12 months from the date of issuance of this FIPS PUB must be
conformance with this standard unless a waiver has been
in accordance with the procedure described below. An
to this standard is made when procurement actions are into
solicitation phase on the date of issuance of this FIPS PUB
Waivers. Heads of agencies may request that the requirements
this standard be waived in instances where it can be
demonstrated that there are appreciable performance or
advantages to be gained and that the overall interests of
Federal Government are best served by granting the
waiver. Such waiver requests will be reviewed by and are
to the approval of the Secretary of Commerce. The waiver
must address the criteria stated above as the justification
the waiver
Forty-five days should be allowed for review and response by
Secretary of Commerce. Waiver requests shall be submitted to
Secretary of Commerce, Washington, D.C. 20230, and labeled as
Request for a Waiver to a Federal Information
Standard. No agency shall take any action to deviate from
standard prior to the receipt of a waiver approval from
Secretary of Commerce. No agency shall begin any process
implementation or acquisition of non-conforming equipment
it has already obtained such approval
Where to Obtain Copies. Either paper or microfiche copies of
Federal Information Processing Standard, including
specifications, may be purchased from the National
Information Service (NTIS) by ordering Federal
Processing Standard Publication (FIPS-PUB-98), Message Format
Computer Based Message Systems. Ordering information,
prices and delivery alternatives, may be obtained by
the National Technical Information Service (NTIS), U. S
Department of Commerce, Springfield, Virginia 22161,
number (703) 487-4650. Payment may be made by check,
order, purchase order, credit card, or deposit account
4
Executive
EXECUTIVE
The message format specification addresses the problem
exchanging messages between different computer-based
systems (CBMSs). This interchange problem can be addressed
several levels. One level specifies the physical inter
connections, another specifies how information travels
CBMSs, another specifies form and meaning of messages
interchanged. The highest level specifies operations on
message. Each of these levels would be covered by a
standard
This message format specification addresses only the
of form and meaning of messages at the points in time when
are sent from one CBMS and received by another. Messages
composed of fields, containing different classes of information
These fields contain information about the message originator
message recipient, subject matter, precedence and security,
references to previous messages, as well as the text of
message. Standard formats (syntax) for messages provide a
for the contents of messages generated by one CBMS to
processed by another CBMS. Standard meanings (semantics) for
components of a message facilitate standard interpretation of
message, so that everyone receiving a message gets the
intended by its sender
Each CBMS that implements this message format
will be compatible with any other CBMS that implements
specification, provided that the use of optional fields and
elements is negotiated in advance. This ensures that
contents of a message posted by one CBMS can be received
interpreted by a different CBMS
This message format specification has been developed as
result of examining CBMSs currently in use in commercial
research environments. Three major design perspectives
shape the message format specification
o Viability. The message format specification
concepts that already work. It has been designed
implementation concerns in mind
o Compatibility. The message format
contains concepts from existing CBMSs. For this reason
many CBMS would already contain functions and
similar to those required to implement the
format specification
5
Executive
o Extensibility. This message format
defines a broad range of message content components
requires only an elementary subset of them. This
that even a very simple CBMS can implement the
format specification. The message format
contains a rich set of optional components and,
addition, mechanisms for user extensions and
extensions to the message format specification
The message format specification defines the form
meaning of message contents and their components as they
from one CBMS to another through a message transfer system.
message format specification does not address any of
following major issues
o Functions or services provided to a user by a CBMS
For example, the message format
assumes that every CBMS allows a user to send
receive messages. It does not specify any of
details of how a send function or a message-
function might work or how it might appear to
user. That is, the message format
neither limits nor mandates functions
o Storage or format of message contents in a CBMS
The message format specification defines the
and contents of messages when they are
between systems. A CBMS may or may not choose
use the same format for internal storage
o Message transfer system protocols
The message format specification does not
how a message travels between CBMSs. It
specify the form of its contents as it leaves
arrives, assuming only that the message is
transparently by the transfer system
o Message envelopes
While a message is traveling between CBMSs, it
enclosed in a message envelope. Message
contain all the information about a message that
message transfer system needs to know. The
format specification does not define the format
content of a message envelope
o How message originators and recipients are identified
The message format specification does not provide
representation scheme for the names or addresses
message originators and recipients as they
known to a CBMS
6
Section 1
1.
A computer-based message system (CBMS) allows
between "entities" (usually people) using computers.
serve both to mediate the actual communications between
and to provide users with facilities for creating and reading
messages
CBMSs have been developing for over ten years.
recently, CBMSs have been one of the bases in industry for
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.
message format specification provides a basis for
between different CBMSs by defining the format of messages
between them
1.1 Guide to Reading This
The method of presenting the material in this
is to combine the technical specification with tutorial infor
mation. This approach has been taken to place the
in context and improve its readability
The core of the technical information in the document is
Section 2, "A Simple Model of a CBMS Environment"; Section 3.1,
"Semantics of Message Fields"; Section 4.2, "Overview of
Encoding"; and Section 4.3, "Data Element Syntax". Appendixes
and B consolidate the technical information. These
are designed for ease of reference and should be read
conjunction with the body of the report for a
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
(semantics), including discussions of the
relationship between message components and CBMS user functions
(See Section 3.2.) Section 4 presents details of the
(syntax) required for components of a message
Appendix D summarizes the components of messages
to whether they are required or optional for CBMSs
the message format specification. Appendix E organizes
message components according to the functional class of
components. Appendix F provides an overview of the
elements defined by this message format specification; Appendix
7
Section 1.1
summarizes those elements according to whether they are
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
This specification provides the capability of extending
range of functionality by the use of vendor-defined
and vendor-defined data elements. Any vendor who uses
capability to provide services which are essentially
to those already designated as required, basic, or optional
not comply with the specification
1.3 The Scope of the Message Format
The purpose of this message format specification is
present the semantics and syntax to be used for messages
exchanged between CBMSs. Specifically, it defines the following
o The meaning and form of standard fields to be used
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
are represented
1.4 Issues Not Within the Scope of the Message Format Specifi
The message format specification does not address
following issues, some of which are being covered by other
standards development programs at the Institute for
Sciences and Technology (ICST). (See [BlaR-80] for a
of the ICST network protocols program.)
o The nature of a message transfer system, except to
the assumption that it transfers messages transparently
8
Section 1.4
o The form or nature of the protocols used to
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
and recipients
o Certain message processing functions that CBMSs
for users, e.g., those concerned with the creation
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
The message format specification is based on several docu
ments and the current state of many CBMSs available both
industry and the research community. These documents include
standardization efforts in the ARPANet [CroD-77, PosJ-79] and
CCITT, proposed ISO and ANSI header format standards [TasG
80, ISOD-79], the work of IFIPS Working Group 6.5, and
papers about the general nature of mail systems, addressing,
mail delivery. (See [FeiE-79] for references
9
Section 2
2. A SIMPLE MODEL OF A CBMS
In order to provide a framework for presenting the
format specification, this section describes a simple
model for a CBMS. The model provides a high-level description
both user facilities and system architecture. Discussions
messages, message originators, and message recipients serve
further clarify the nature of a CBMS
A CBMS permits the transfer of a message from an
to a recipient. "Originator" and "recipient" are used in
normal English senses. (See Section 2.4.) A message (in
most abstract definition) is simply a unit of communication
an originator to a recipient. A CBMS offers several classes
functions to its users
o Message Creation: The facilities used by a
originator to create messages and specify to whom
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
recipient to process messages that have arrived
These classes of functions are presented in more detail
Section 3.2.
CBMSs differ from other office automation/
systems in a number of ways
o Unlike other types of electronic communications,
messages are sent to particular individuals, not
stations or telephone sets. If a recipient moves to
different location, messages sent to that recipient
delivered to the recipient at the new location
o Transmission of CBMS messages is asynchronous.
recipient's system need not be available when the mes
sage leaves the originator's system. That is,
message transfer facilities are store-and-forward
o CBMS messages can contain a wide variety of data.
are not constrained to any single kind of communication
CBMS messages are often simple memoranda but are
restricted to text. A CBMS message may contain any
10
Section 2
of data that an originator wishes to send to a recip
ient. By contrast, Teletex systems and
word processors handle the transfer of final
documents; compatible communicating word processors
exchange documents in editable form; Telex and TWX
in unformatted text
o CBMSs offer message creation facilities as an
part of the system. CBMSs assist users in the prepa
ration of messages by having text editing
available and allowing users to include data stored on
line in messages. Some CBMSs also interface to
office automation facilities, such as formatters
spelling correctors. This is not true of Telex, TWX,
similar services
o CBMSs offer recipient processing facilities as an impor
tant part of the system. This is not true of most
forms of electronic communications. For example,
and TWX systems simply print messages on paper when
are received, without retaining a copy in the system
(Teletex systems are similar to Telex systems, but
can retain a copy of the document in local storage.)
Communicating word processors might notify
operators that a document has been received and
stored on-line, but they offer little in the way
other recipient processing facilities. Most CBMSs
at least the following recipient processing facilities
. The ability to retain a copy of a message on-
after it has been read
. The ability to examine or delete stored
individually
. The ability to organize messages using some form
electronic "file folder."
. The ability to determine if a message is
(has arrived since the last time the recipient
the CBMS) or unseen (has never been examined by
recipient).
. The ability to summarize stored messages.
summary usually includes information such
whether the message is recent or unseen, when
was received, its length, who it is from, and
subject
. The ability to retrieve a stored message based
11
Section 2
one or more of its attributves (for example,
the message was received, whether or not it
been seen or deleted, and the values contained
its fields).
. A forward facility that allows users to include
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 facilities for message creation, transfer, and recip
ient processing are reflected in a logical model of a
developed by IFIP Working Group 6.5. (An essentially
model is being used by CCITT Study Group VII, Question 5,
regarding Message Handling Systems [CCIT-82].) The
consists of a Message Transfer System and a number of
Agents. (See Figure 1.)
| |
| ************* |
********* ------> * Message * -------> *********
* User * Posting * Transfer * Delivery * User *
* Agent * Protocol * System * Protocol * Agent *
********* <------- ************* <------- *********
| |
| |
Posting
Slot
Message
Originator -------------------------------->
FIG. 1. LOGICAL MODEL OF A COMPUTER-BASED MESSAGE
A User Agent (UA) is a functional entity that acts on
of a user, assisting with creating and processing messages
communicating with the Message Transfer System
The Message Transfer System(MTS) is an entity that accepts
12
Section 2.1
message from its originator's User Agent and ultimately passes
to each of its recipients' User Agents. The Message
System may perform routing and storage functions (among others
in order to accomplish its task
Transferring a message from an originator's User Agent
the Message Transfer System is called Posting; the originator'
User Agent and Message Transfer System engage in a
Protocol in order to accomplish Posting. Transferring a
from the Message Transfer System to a recipient's User Agent
called Delivery; the recipient's User Agent and Message
System engage in a Delivery Protocol in order to
Delivery
The point at which responsibility for a message is trans
ferred is called a Slot. The Posting Slot is the point at
responsibility for a message passes from an originator's
Agent to the Message Transfer System; the Delivery Slot is
point at which responsibility for a message passes from
Message Transfer System to a recipient's User Agent
The model divides messages into two parts, the
content and the message envelope. The message content is
information that the originator wishes to send to the recipient
this message format specification deals solely with the
content. The message envelope consists of all the
necessary for the Message Transfer System to do its job;
message format specification does not specify the
envelope. Some of the data appearing on the message
could be redundant with some data found in the message content
The Message Transfer System is not expected to examine
message content unless it is told to do so by the originator's
recipient's User Agent
This message format specification places no restrictions
the Message Transfer System itself, except that it be able
transfer messages between originating and receiving UAs
reading or altering the contents of messages unless
instructed by the UAs. In addition, this message format specifi
cation does not dictate the form or nature of any protocol
by the Message Transfer System. Finally, this message
specification does not specify the content or form of the
envelope. That is, the message format specification defines
format for the contents of messages, not the manner in which
are transmitted
Many of today's commercially available CBMSs incorporate
of the facilities represented in the logical model.
architectures may reflect the economies that can be taken
implementing systems that are self-contained. For example
stand-alone systems that store messages in a single
13
Section 2.1
database require no Message Transfer System; an
may integrate software for User Agent and Message Transfer
functions, doing away with Posting or Delivery Protocols
2.2 Relationship to the ISO Reference Model for Open
Subcommittee TC97/SC16 of the International Organization
Standardization (ISO) has developed a reference model
describing communications between "open" systems [ISOD-82].
model is known as the ISO Reference Model for Open
Interconnection (OSI). It divides communications protocols
seven layers, ranging from physical interconnection at the
layer to data exchange by application programs at the top
This message format specification deals with data used by
application within a system. Thus, the message format
specified here is not a protocol. Since it is not a protocol,
lies outside of the model for open systems interconnection.
Agents are application layer entities (layer 7), however, and
protocols used by a message transfer system are above the
layer (layer 5).
2.3 Messages and
A message is a unit of communication from an originator to
recipient. A message consists of a series of components
fields. Fields can be described according to their meaning in
message (semantics) and according to the format required for
in a message (syntax).
Semantically, a field is just a component of a message;
meanings of particular fields are defined by this message
specification. Syntactically, a field is a unit of data
form is defined by this message format specification.
fields can be defined by users or vendors as long as they
to the syntactic and semantic rules that this message
specification defines for additional fields
(A note on terminology: A message consists of
called fields. The words "message" and "field" are used both
the informal sense of the previous sentence and in a
restricted sense as names of particular syntactic elements.
syntactic element names, Message and Field are
capitalized.)
14
Section 2.3
Some CBMS functions are based on the contents of
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
provide to users and the fields that must be used to
those functions
2.4 Message Originators and
This message format specification refers to message origi
nators and recipients. These terms were defined functionally
Figure 1. When the message format specification refers to
identity of a message originator or recipient, it means "
information which uniquely identifies the message originator
recipient within the domain of the given message system."
syntax and semantics of message addressing are not within
scope of the message format specification
Originators and recipients can be people, roles,
or groups
People. People as originators and recipients are
individuals
Roles. Roles identify functions within organizations
opposed to the specific individuals who perform them.
example, consider a newspaper that produces both morning
evening editions and therefore operates with more than one shift
Someone wishing to contact the city desk would send a message
the city desk role rather than trying to determine exactly
was assigned to the city desk at a specific time. (Of course
messages can usually be sent to the individuals directly
or not they are actually performing a role at the time.)
Processes. A process in a computer could serve as either
originator or a recipient for messages. A computer system
originate a message to notify a recipient about the status
some task. For example, an archive utility could notify
about files that have been archived; a distributed file
could notify a user that a remote file has been deposited on
local file system. Messages could be used by computer systems
warn about some impending condition or even to monitor
performance of the computer itself. Some computer processes
also be message recipients, taking action based upon
contents
In addition, some CBMSs allow messages to be sent to groups
A group is a predefined list of message recipients. Using
15
Section 2.4
group name as a recipient permits message originators
designate a potentially large number of recipients using a
recipient identifier. This makes using the CBMS more
and accurate
16
Section 3
3.
This section discusses two major topics, message
functions and message field meanings. Section 3.1 describes
six functional groups of message fields. The functional
are Origination, Dates, Recipients, Cross-referencing, Message
handling, and Message-contents. They are explained more fully
Section 3.1.1, along with detailed discussion of the semantics
all the fields in each functional group. Section 3.2
message processing functions whose operation is based on
meanings of particular message fields
3.1 Semantics of Message
The definition of a message is discussed generally
Sections 1 and 2. Semantically valid messages must contain
From field, one To field, and one Posted-Date field. They
contain, in addition, any number of other fields, depending
the processing and functions supplied by the originating
receiving CBMS. (Section 3.2 describes classes of
supplied by CBMSs.)
3.1.1 Types of
Message receiving programs are required to interpret
according to the semantics described in the remainder of
section. The message fields defined in this document are
into the following functional categories
o Originator fields indicate who or what participated
the creation of the message and where replies should
directed. (See Section 3.1.3.)
o Date fields record when events take place, for a
of events, such as message creation or expiration. (
Section 3.1.5.)
o Recipient fields indicate who or what is intended
receive a message. (See Section 3.1.4.)
o Cross-reference fields label a message or refer to
messages. (See Section 3.1.6.)
o Message-handling fields record the type of service
17
Section 3.1.1
message's sender requested of a message transfer
or indicate how the message should be treated by
recipients. (See Section 3.1.7.)
o Message-content fields either contain the
content of a message, or index the message, or
the message. (See Section 3.1.8.)
o Extension fields provide mechanisms for extending
message format specification. (See Section 3.1.9.)
3.1.2 Semantic Compliance
For purposes of determining whether a CBMS complies with
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
be processed by message receiving programs as
by the message format specification
BASIC These fields need not be present in all messages
when they do appear, they must be processed by
receiving programs as defined by the message
specification
OPTIONAL These fields need not be present in all messages
may be ignored by message receiving programs.
exact meaning of "ignored" is not specified by
message format specification. However, a CBMS
recognize the existence of an optional field (that is
optional fields should not cause errors) and must
process the field in a manner contrary to the
defined for that field by the message format specifi
cation. It is left to the discretion of a recipient'
CBMS what action is to be taken when an instance of
locally unimplemented optional field is detected
(Syntactic compliance is defined in Section 4.1.2.)
3.1.3 Originator
A message originator may be a person, role, or process
Originator fields identify a message's author, who is
for the message, who or what sent it, and where
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.
contents of the From field is to be used for
when no Reply-to field appears in a message
Reply-To (BASIC
This field identifies any recipients of replies to
message
Author (OPTIONAL
This field identifies the individual(s) who wrote
primary contents of the message. Use of the
field is discouraged when the contents of the
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
responsible for the message or to indicate who among
group of originators responsible for the
actually sent it. Use of the Sender field
discouraged when the contents of the Sender field
From field would be completely redundant. The
field may specify only one originator identity
appear only once in a message
3.1.4 Recipient
Message recipients may be people, roles, processes,
groups. (See Section 2.4). Recipient fields identify who
what is to receive the message
To (REQUIRED
This field identifies the primary recipients of
message
Bcc (OPTIONAL
This field identifies additional recipients of
message (a "blind carbon copies" list). The
of this field are not to be included in copies of
message sent to the primary and secondary recipients
See section 3.2.1 for further discussion of the use
blind carbon copies lists
19
Section 3.1.4
Cc (BASIC
This field identifies secondary recipients of a
(a "carbon copies" list).
Circulate-Next (OPTIONAL
This field is used in conjunction with the Circulate-
field. (See Section 3.2.6.1.) It identifies
recipients in a circulation list who have not
the message
Circulate-To (OPTIONAL
This field identifies recipients of a
message. (See Section 3.2.6.1.) It is used
conjunction with the Circulate-Next field
3.1.5 Date
Date fields for two kinds of uses are provided. Dates
be associated with some event in the history of a message
dates can delimit the span of time during which the message
meaningful (its life span).
Posted-Date (REQUIRED
This field contains the posting date, which is
point in time when the message passes through
posting slot into a message transfer system. Only
Posted-Date field is permitted in a message
Date (OPTIONAL
This field contains a date that the message'
originator wishes to associate with a message.
Date field is to the Posted-Date field as the date on
letter is to the postmark added by the post office
End-Date (OPTIONAL
This field contains the date on which a message
effect. (See also Section 3.2.5.)
Received-Date (OPTIONAL
This field is also called Delivery date. This
may be added to a message by the recipient's
receiving program. It indicates when the message
20
Section 3.1.5
the delivery system and entered the recipient's
processing domain
Start-Date (OPTIONAL
This field contains the date on which a message
effect. (See also Section 3.2.5.)
Warning-Date (OPTIONAL
This field is used either alone or in conjunction
an End-Date field. It contains one or more dates
These dates could be used by a message
program as warnings of an impending end-date or
event. (See also Section 3.2.5.)
3.1.6 Cross-reference
Cross-reference fields can be used to identify a message
to provide cross-references to other messages. (See
3.2.4.)
In-Reply-To (OPTIONAL
This field designates previous correspondence to
this message is a reply. The usual contents of
field would be the contents of the Message-ID field
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
processing. Further definition appears in
3.2.4.1. Only one Message-ID field is permitted in
message
Obsoletes (OPTIONAL
This field identifies one or more messages that
one replaces
Originator-Serial-Number (OPTIONAL
This field contains one or more serial numbers
by the message's originator. Messages with
recipients should have the same value in
Originator-Serial-Number field
21
Section 3.1.6
References (OPTIONAL
This field identifies other correspondence that
message references. If the other
contains a Message-ID field, the contents of
References field must be the message identifier
3.1.7 Message-handling
Message-handling fields describe aspects of how a message
to be handled or categorized
Precedence (OPTIONAL
This field indicates the precedence at which
message was posted. Ordinarily, message precedence
priority is a service request to a message
system. A message originator, however, can
precedence information in a message. One example
precedence categories are those used by the U.S
Military: "ROUTINE," "PRIORITY," "IMMEDIATE," "
OVERRIDE," and "EMERGENCY COMMAND PRECEDENCE."
Message-Class (OPTIONAL
This field indicates the purpose of a message.
example, it might contain values indicating that
1
message is a memorandum or a data-base entry.
Reissue-Type (OPTIONAL
This field is used in conjunction with
encapsulating (see Section 3.2.2) to
between messages being assigned or redistributed
Received-From (OPTIONAL
This field contains a record of a message's
through a message transfer system.
recipient's message receiving program could store
any information about the transfer that it
from a message transfer system
_______________
1
The message format specification is not intended to be used
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
The intent of most messages is to communicate
particular information from originator to recipient.
fields in a message are designed to contain that information
Subject (BASIC
This field contains any information the
provided to summarize or indicate the nature of
message
Text (BASIC
This field contains the primary content of the message
Attachments (OPTIONAL
This field contains additional data accompanying
message. It is similar in intent to enclosures in
conventional mail system
Comments (OPTIONAL
This field permits adding comments to the
without disturbing the original contents of
message
Keywords (OPTIONAL
This field contains keywords or phrases for use
retrieving a message
3.1.9
This message format specification allows two
types of fields, vendor-defined fields and as-yet-
(extension) fields that will be introduced by extensions to
message format specification
vendor-defined-
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
be preempted by extensions to this message
specification
23
Section 3.1.9
extension-
Any field that is defined in a document published as
formal extension or replacement to this message
specification
3.2 Message Processing
A CBMS provides three basic classes of functions:
messages, transmitting messages to their recipient, and post
receipt processing. Although the message format
does not define the number or nature of user functions in CBMSs
the meanings for the fields clearly assume certain kinds
functions. For example, fields specifying recipients of
to messages assume some kind of reply function; fields
message life span assume some kind of date processing functions
This section provides more detail on the processing
might be done by these kinds of functions, discussing the
fields that would be used and how they would be used. (
summary in Table 1.)
Processing Function Fields
Message creation Author, From, Sender, To
and posting Cc,
Message reissuing Reissue-
Reply generation Reply-
Cross-referencing Message-ID, In-Reply-To, References
Obsoletes, Originator-Serial-
Life span functions Start-Date, End-Date
Warning-
Recipient processing Circulate-To, Circulate-
TABLE 1. FIELDS USED IN MESSAGE PROCESSING
3.2.1 Message creation and
Messages can be created either by reissuing an
message to a new recipient (see Section 3.2.2) or by creating
new message. The process of message creation might mean
some fields of a new message are filled in from the contents
some other message. Reply functions (Section 3.2.3) provide
example of this
24
Section 3.2.1
Different individuals could be involved in different
of originating a message: creating it, taking responsibility
it, and explicitly interacting with a CBMS to send it to
recipient. One or more individuals may create a message (
is, write, but not necessarily enter it into the CBMS); they
said to be the message's authors, identified by the Author field
One or more individuals may take responsibility for its
and the decision to post it; they are identifi