As per Relevance of the word identifier, we have this rfc below:
Network Working
Request for Comments: 806
Proposed Federal Information Processing
SPECIFICATION FOR MESSAGE FORMAT FOR
COMPUTER BASED MESSAGE
National Bureau of
Institute for Computer Sciences and
September 1981
TABLE OF
EXECUTIVE SUMMARY 1
1. INTRODUCTION 3
1.1 Guide to Reading This Document 3
1.2 Vendor-Defined Extensions to the Specification 4
1.3 The Scope of the Message Format Specification 4
1.4 Issues Not Within the Scope of the Message Format 4
1.5 Relationship to Other Efforts 5
2. A SIMPLE MODEL OF A CBMS ENVIRONMENT 6
2.1 Logical Model of a CBMS 8
2.2 Relationship to the ISO Reference Model for Open 10
Systems
2.3 Messages and Fields 10
2.4 Message Originators and Recipients 11
3. SEMANTICS 12
3.1 Semantics of Message Fields 12
3.1.1 Types of fields 12
3.1.2 Semantic Compliance Categories 13
3.1.3 Originator fields 13
3.1.4 Recipient fields 14
3.1.5 Date fields 15
3.1.6 Cross-reference fields 16
3.1.7 Message-handling fields 16
3.1.8 Message-content fields 17
3.1.9 Extensions 18
i
3.2 Message Processing Functions 18
3.2.1 Message creation and posting 19
3.2.2 Message reissuing and forwarding 20
3.2.2.1 Redistribution 22
3.2.2.2 Assignment 22
3.2.3 Reply generation 23
3.2.4 Cross referencing 24
3.2.4.1 Unique identifiers 24
3.2.4.2 Serial numbering 24
3.2.5 Life span functions 25
3.2.6 Requests for recipient processing 25
3.2.6.1 Message circulation 26
3.3 Multiple Occurrences and Ordering of Fields 26
4. SYNTAX 28
4.1 Introduction 28
4.1.1 Message structure 28
4.1.2 Data elements 29
4.1.2.1 Primitive data elements 30
4.1.2.2 Constructor data elements 30
4.1.3 Properties 30
4.1.3.1 Printing-names 30
4.1.3.2 Comments 31
4.1.4 Data compression and encryption 31
4.1.5 Data sharing 31
4.2 Overview of Syntax Encoding 32
4.2.1 Identifier Octets 32
4.2.2 Length code and Qualifier components 33
4.2.2.1 Length Codes 35
4.2.2.2 Qualifier 36
4.2.3 Property-List 38
4.2.4 Data Element Contents 38
4.3 Data Element Syntax 39
4.3.1 Data elements 39
4.3.1.1 Primitives 42
4.3.1.2 Constructors 44
4.3.2 Using data elements within message fields 48
4.3.3 Properties and associated elements 49
4.3.4 Encryption identifiers 49
4.3.5 Compression identifiers 49
4.3.6 Message types 50
SUMMARY OF APPENDIXES 51
ii
APPENDIX A. FIELDS -- IMPLEMENTORS' MASTER REFERENCE 52
APPENDIX B. DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE 57
APPENDIX C. DATA ELEMENT IDENTIFIER OCTETS 65
APPENDIX D. SUMMARY OF MESSAGE FIELDS BY COMPLIANCE 66
D.1 REQUIRED Fields 66
D.2 BASIC Fields 66
D.3 OPTIONAL Fields 66
APPENDIX E. SUMMARY OF MESSAGE SEMANTICS BY FUNCTION 68
E.1 Circulation 68
E.2 Cross Referencing 68
E.3 Life spans 68
E.4 Delivery System 68
E.5 Miscellaneous Fields Used Generally 69
E.6 Reply Generation 69
E.7 Reissuing 69
E.8 Sending (Normal Transmission) 69
APPENDIX F. SUMMARY OF DATA ELEMENT SYNTAX 70
APPENDIX G. SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY 72
G.1 BASIC Data Elements 72
G.2 OPTIONAL Data Elements 72
APPENDIX H. EXAMPLES 74
iii
H.1 Primitive Data Elements 74
H.2 Constructor Data Elements 76
H.3 Fields 81
H.4 Messages 84
H.5 Unknown Lengths 88
REFERENCES 92
INDEX 94
iv
LIST OF
FIG. 1. LOGICAL MODEL OF A COMPUTER BASED MESSAGE SYSTEM 8
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION 21
FIG. 3. EXAMPLE OF MESSAGE CIRCULATION 27
FIG. 4. STRUCTURE OF IDENTIFIER OCTETS 34
FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH 35
FIG. 6. REPRESENTATION OF LENGTH CODES 36
FIG. 7. EXAMPLES OF LENGTH CODES 37
FIG. 8. EXAMPLES OF QUALIFIER VALUES 38
LIST OF
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS 19
TABLE 2. TYPE BITS IN THE IDENTIFIER OCTET 33
vi
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
interconnections, another specifies how information
between CBMSs, another specifies form and meaning of
being 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 ensure that
contents of messages generated by one CBMS can be processed
another CBMS. Standard meanings (sematics) for the components
a message ensure standard interpretation of a message, so
everyone receiving a message gets the meaning intended by
sender
Each CBMS that implements this message format
will be compatible with any other CBMS that implements
specification. Compatibility ensures that the contents of
message posted by one CBMS can be received and interpreted by
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
1
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
2
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
organizations use either their own or a commercially
CBMS. The design and complexity of these systems vary widely
This message format specification provides a basis
interaction between different CBMSs by defining the format
messages passed between them
1.1 Guide to Reading This
The method of presenting the material in this
is to combine the technical specification with
information. This approach has been taken to place
specification 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 informations. 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
specification
Section 2 presents a simple model of operation of a CBMS
Section 3 discusses the components of messages and their
(semantics). This includes 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
3
Section 1.1
summarizes those elements according to whether they are
or optional for a CBMS implementing the message
specification. Examples of each syntactic element appear
Appendix H, displaying syntax and describing the
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
The message format specification does not address
following issues, some of which are being covered by other
standards developments. (See [BlaR-80] for a description of
NBS protocols program.)
o The nature of a message transfer system, except to
the assumption that it transfers messages transparently
4
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 Functions that CBMSs provide for users
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
documents 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
5
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
message 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
message 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
6
Section 2
of data that an originator wishes to send to
recipient. By contrast, Teletex systems
communicating word processors handle the transfer
final form documents; compatible communicating
processors can exchange documents in editable form
Telex and TWX deal in unformatted text
o CBMSs offer message creation facilities as an
part of the system. CBMSs assist users in
preparation of messages by having text
facilities available and allowing users to include
stored on-line in messages. Some CBMSs also
to other office automation facilities, such
formatters and spelling correctors. This is not true
Telex, TWX, or similar services
o CBMSs offer recipient processing facilities as
important part of the system. This is not true of
other forms of electronic communications. For example
Telex and TWX systems simply print messages on
when they are received, without retaining a copy in
system. (Teletex systems are similar to Telex systems
but some can retain a copy of the document in
storage.) Communicating word processors might
their operators that a document has been received and
stored on-line, but offer little in the way of
recipient processing facilities. Most CBMSs offer
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
7
Section 2
one or more of its attributes (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
messages without having to enter a new list
recipients
2.1 Logical Model of a
CBMS facilities for message creation, transfer,
recipient processing are reflected in a logical model of a
developed by IFIP Working Group 6.5 [SchP-79]. (An
identical model is being used by CCITT Study Group VII,
5, regarding Message Handling Facilities.) The model consists
a Message Transfer System and a number of User Agents. (
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 is a functional entity that acts on behalf of
user, assisting with creating and processing messages
communicating with the Message Transfer System
The Message Transfer System] is an entity that accepts
8
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
transferred is called a Slot. The Posting Slot is the point
which responsibility for a message passes from an originator'
User Agent to the Message Transfer System; the Delivery Slot
the 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
to the contents of messages. In addition, this message
specification does not dictate the form or nature of any
used by the Message Transfer System. Finally, this
format specification does not specify the content or form of
message envelope. That is, the message format
defines the format for the contents of messages, not the
in which they 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
database require no Message Transfer System; an
may integrate software for User Agent and Message Transfer
functions, doing away with Posting or Delivery Protocols
9
Section 2.1
2.2 Relationship to the ISO Reference Model for Open
Subcommittee TC97/SC16 of the International
Organization (ISO) has developed a reference model for
communications between "open" systems [ISOD-81]. This model
known as the ISO Reference Model for Open Systems
(OSI). It divides communications protocols into seven layers
ranging from physical interconnection at the lowest layer to
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.)
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
10
Section 2.3
2.4 Message Originators and
This message format specification refers to
originators and recipients. These terms were
functionally in Figure 1. When the message format
refers to the identity of a message originator or recipient,
means "that information which uniquely identifies the
originator or recipient within the domain of the given
system." The syntax and semantics of message addressing are
within the scope of the message format specification
Originators and Recipients can be people, roles,
processes
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
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
11
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
se. 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
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
12
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 or summarize it. (
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
message 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. In general, 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
specification
(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.)
13
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
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. Only
Sender field is permitted in a message
3.1.4 Recipient
Message recipients may be people, roles, or processes. (
Section 2.4). Recipient fields identify who or what is
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
Cc (BASIC
This field identifies secondary recipients of a
(a "carbon copies" list).
14
Section 3.1.4
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
Delivery date. This field may be added to a message
the recipient's message receiving program.
indicates when the message left the delivery system
entered the recipient's message 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
15
Section 3.1.5
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 supplants
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
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
16
Section 3.1.7
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 2.4.1) 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
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
_______________
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
17
Section 3.1.8
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
specification or any extension or successor to it is
vendor-defined field. Names for vendor-defined
could be preempted by extensions to this message
specification
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.)
18
Section 3.2.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 2.4.1) 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
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 (that is, write
but not necessarily enter into the CBMS) a message; they are
to be the message's authors, identified by the Author field.
or more individuals may take responsibility for its contents
the decision to post it; they are identified by the From field
One individual explicitly posts a given message; this person
called the message's sender (identified by the Sender field).
The sender and author(s) are often, but not always
responsible for the message. A common case in which the
is not responsible for the message is when a secretary enters
posts messages for someone else. An example of a situation
which a message's author is not responsible for the
itself is when an administrative assistant prepares a report
is sent under a manager's signature
Messages containing Bcc fields are treated specially
CBMSs. The contents of this field are not included in copies
the message sent to the recipients designated in the To and
fields. Some systems include the contents of the Bcc field
19
Section 3.2.1
in the originator's copy, others include include all or part
the Bcc field in the copies sent to the recipients indicated
the Bcc field. This specification does not mandate how the
field is to be treated
Audit trail entries (such as the posting time and
identity) are automatically appended to a message by the
each time the message passes through a posting slot to a
transfer system; a message transfer system could also
timestamps at each transfer between user agent and the
system. A message identifier (Sections 3.2.4 and 3.1.6),
in the message by the original sender's User Agent, is
throughout this message flow. This means that when the
message is sent twice to the same recipients by the same Sender
the audit trail information for the two messages is different
3.2.2 Message reissuing and
Reissuing and forwarding both serve the general user goal
passing a message on to a new set of recipients. Forwarding
the term used for an informal mechanism, which CBMSs implement
copying some or all of the original message into the contents
a field in the new message. Reissuing is the term used for
formal mechanism to ensure that the message being passed on
loses its integrity as a previously sent message. CBMSs
reissuing to implement several different functions, depending
the purposes being served
o Redistribution. Make others aware of the complete
unaltered contents of the message
o Assignment. Delegate the responsibility for a
to somebody else
These purposes are exemplified in Figure 2.
When a CBMS examines a forwarded message, it cannot
distinguish the old message from what was added when
forwarding took place. In addition, the forwarded
might no longer have the form of a message. This is
because the format of the message has been changed (for example
to pure unformatted text). (See Figure 2 for an example of how
CBMS might forward a message.) In contrast, a reissued
can always be separated from its enclosing message and
loses its identity as a correctly formed message
This specification provides the Reissue-Type field
20
Section 3.2.2
The Original
John Doe wishes Jane Jones to get a copy of the
message
Message
Field: From "Jean Smith
Field: Posted-Date "15 June 1980"
Field: To "John Doe
Field: Subject "Next sales meeting
Field: Text "The agenda for ..."
Message
Field: From "John Doe" John Doe is
Field: Posted-Date "16 June 1980" for the redistribution
Field: To "Jane Jones
Field: Reissue-Type "Redistribution" This message
Message: incorporates
Field: From "Jean Smith" redistributed message
Field: Posted-Date "15 June 1980"
Field: To "John Doe
Field: Subject "Next Sales Meeting
Field: Text "The agenda for ..."
Message
Field: From "John Doe
Field: Posted-Date "16 June 1980"
Field: To "Jane Jones
Field: Text A realization of
"From Jean Smith original message
To John Doe copied into the Text field
Sent on 15 June 1980 Note that John's
Subject Next Sales Meeting has chosen to
it as a text string
The agenda for ..."
FIG. 2. MESSAGE FORWARDING AND
21
Section 3.2.2
supporting re-issuing. Forwarding, since it is an informal
of serving the purpose of passing on information, has
supporting fields in the specification
This specification provides for reissuing of messages
encapsulating. This method embeds the entire original
inside a new message. Encapsulating adds structure around
2
message . This allows any part of it to be easily extracted
Authentication is an organizational policy issue
passing on previously sent messages. Each organization
decide if the CBMS it acquires should support reissuing or
supply forwarding
3.2.2.1
Redistribution is a CBMS function for sending the
contents of a message intact and unchanged to new recipients.
redistributed message is identical to the original message
the exception of added information about the reissuing.
reissuing with this purpose, the Reissue-Type field contains
ASCII string "Redistribution". The original message has
included directly in a new message. (See Figure 2.)
3.2.2.2
Assignment is the process of designating responsibility.
some organizations, formal message traffic is funneled
one or more parts of the organization (called offices) where
is directed to the appropriate individuals or other offices
final disposition. Assignment is done by reissuing a
with the Reissue-Type field containing the ASCII
"Assigned." A message which contains this field is to
interpreted as meaning that the addressees in the "To" field
had the reissued message assigned to them for some action.
addressee in the "Cc" field has had the message assigned
information. The "From" field records who assigned the
and the "Posted-Date" field records when the message
assigned
_______________
2
A message can contain another message, and that message
contain another message, and so on to any depth of encapsulating
This can occur by reissuing a message repeatedly
22
Section 3.2.3
3.2.3 Reply
Reply generation involves creating a new message in
reply to some other message by drawing on the contents of
in the other message to fill fields in the new message.
CBMSs provide reply facilities that determine the
recipients of a reply to a message
o A Reply-To field is defined by this message
specification. When a message contains a Reply-
field, the CBMS should send replies to the
designated in the Reply-To field instead of to
recipients designated in the From field. This
applies to original messages only, not to
messages. The message format specification makes
recommendations concerning replies to reissued messages
Reply-To has several possible applications
1. The individual(s) responsible for the
might not have regular access to a CBMS and
indicate an alternate recipient, for example,
secretary
2. The people responsible for receiving
might not be the people who were responsible
creating the message
3. Discussion and conference groups could use
feature to ensure correct distribution of
submission by having the conference group
designated in the Reply-To field
o When the message does not contain a Reply-To field,
recipient should reply to the originators enumerated
the From field. The sender and authors should not
added automatically to the list of those receiving
reply
Replies could also be sent to the other recipients of
original message. Vendors might offer additional
facilities, depending on their view of users'
requirements
23
Section 3.2.4
3.2.4 Cross
A CBMS message may include designator(s) which
other message(s). The designators are used to refer to
messages so that all information in a chain of correspondence
be determined by a CBMS user. The designator used to
and cross-reference messages can take either of two forms,
identifiers or serial numbers
3.2.4.1 Unique
Unique identifiers are machine-generated quantities that
intended primarily for processing by computers. While they
be examined by a human user, unique identifiers are
necessarily useful or convenient for people
Unique identifiers occur in several contexts. They
often used to identify the contents of individual
unambiguously. When unique identifiers are used this way,
are called message identifiers. Different versions of a
(for example, the message when it is reissued with comments
receive new message identifiers
When a CBMS generates a message identifier, it must be
to guarantee that it is unique, both within the domain of
individual CBMS and globally, across all connected CBMSs.
could generate globally unique identifiers in several ways,
of which require prior agreement on behalf of the
CBMSs. One method is to assign each connected CBMS a
code. A CBMS then generates unique identifiers by using its
as a prefix to some other quantity that it can guarantee to
unique within its domain. (This second quantity could be
counter or a timestamp/user-id combination.)
A CBMS can provide functions for tracing chains
correspondence by using unique identifers. The message
specification defines fields for which a CBMS provides
identifiers as values. They are Message-ID, References
Obsoletes, and In-Reply-To. (See Section 3.1.6.)
3.2.4.2 Serial
Serial numbers are for users to maintain a
numbering system for messages. The numbers are composed of
letters and digits so that users could maintain several sets
sequences concurrently (for example, A1, A2, A3... and B1, B2,
B3...).
24
Section 3.2.4.2
Serial numbers are assigned at a defined point in
history of a message. Serial numbers are not unique identifiers
they differ from unique identifiers (Section 3.2.4.1) in
they are not necessarily either generated or processed by a CBMS
They are designed to be typed and read by CBMS users. They
be as simple or complex as the user requires. Serial numbers
intended to be used to designate messages about a specific topic
or messages a given user has sent. Serial numbers are
to be a permanent part of the message, just as unique
are
A CBMS can provide functions allowing originators to
serial numbers to messages. A field has been provided to
this. Originator-Serial-Number is for an originator to add
serial number to a message before sending it
3.2.5 Life span
Messages have life spans, usually delimited by the
date and the time when the last copy of the message is destroyed
Messages could be meaningless before a certain time or
after a certain time. For example, a reminder to attend
meeting on 5 June loses most of its value on the sixth;
reminder to attend that same meeting is likely to be of
use on 5 May (although not for the same reason).
A CBMS can define a message's life span explicitly using
Start-Date and End-Date fields. A third field, Warning-Date
when used in conjunction with the End-Date, may be used to
the approach of the End-Date. It may also stand alone and
used by a periodic warning (alarm clock) mechanism
A CBMS could use these fields to help users manage
message stores. For example, a message whose start date has
yet passed could be bypassed by a retrieval command unless
user requested such messages explicitly. A CBMS could use
end date to help with message store housekeeping either
archiving or deleting the expired messages automatically or
asking the user for some action to be taken on them. The
date could be used to automatically remind the user of
impending end date, such as a meeting reminder
3.2.6 Requests for recipient
Recipients have a wide variety of needs for examining
processing a message, ranging from automatic output on
specified device to the execution of a program embedded in
25
Section 3.2.6
message itself. Because many of these needs are
specialized, and support for them not widely implemented,
message format specification does not constrain the 