RFC 841
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.
Page
EXECUTIVE SUMMARY 5
i
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
ii
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
iii
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
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
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS 24
TABLE 2. HIGH-ORDER BITS IN THE IDENTIFIER OCTET 39
vi
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.
National Standard Code (ASCII) for Information
Interchange, X3.41-1974, FIPS PUB 35.
1
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
(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
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
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.
5
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.
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.
6
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.
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
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.
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:
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.)
8
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
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:
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.
sage leaves the originator's system. That is, CBMS
message transfer facilities are store-and-forward.
10
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
. 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.
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
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
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).
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
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
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
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.
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.)
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.
17
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.)
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
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.
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
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.
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
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.)
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
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.
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
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.
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
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
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
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.
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:
25
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.
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
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
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.
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:
28
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.
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.
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
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.
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
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.
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.
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
-----------------------------------------------------------------
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
33
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.
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.
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
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.
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
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.
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 sequences.
A Message data element is a constructor. It may contain
only Field data elements, other Message data elements, or
encrypted or data compressed forms of these elements. A Field
data element can contain any data element. It also indicates
which specific field is being represented. The contents of some
fields are restricted to a single type of data element, such as
ASCII-String or Date.
Any data element may have associated with it a Property- List, which contains properties such as a Printing-Name or one or
more Comments. Comment A mechanism to support vendor-defined
properties has been supplied by this specification, as well as a
mechanism to extend the list of property identifiers.
_______________
4
An ASCII-String is not limited to ASCII characters however.
The ASCII code table can be extended through standardized
techniques as described in FIPS Pub 35, Code Extension Techniques
in 7 or 8 Bits [NatB-75].
36
Printing-Names are used to provide labels that can be
displayed along with their respective data elements. For
example, a message originator may use a Printing-Name property to
request that the To field of a message be labeled "Distribution:"
when it is printed by its recipients.
The Comment property is used to allow comments to be associated with any data element without affecting its actual
contents. For example, someone reviewing the text of a message
could add the comment "This looks good" to the Text field without
either altering the body itself or adding a separate comment
field.
Two constructor data elements, Compressed and Encrypted, have been provided for use by a CBMS that supports data
compression or encryption. They may be used to hold the
compressed or encrypted contents of any data element, including
Messages and Fields, and may occur wherever their compressed or
encrypted contents may appear. A mechanism is included to allow
the user to identify the encryption or compression algorithm used
(Sections 4.3.4 and 4.3.5).
This section provides an overview of the notation and terminology used to represent the syntactic elements (data elements) defined in this message format specification.
All data elements consist of a series of components. Each of the components is composed of a series of 8-bit groups called
octets. In this document, the bits are numbered starting from
the low-order bit. That is, the low-order (or least significant)
bit is called "bit 0" and the high-order (or most significant)
bit is called "bit 7."
Five different components may appear in a data element.
37
These components always appear in this order. Not all components are present in all data elements, but the components that are present maintain this relative order.
The identifier octet is a numeric code containing infor- mation that identifies a data element. It is always the first component in a data element. The Identifier octet contains a one-bit flag, indicating whether or not the data element contains a Property-List, and a 7-bit unique identifier for the data element. The value of the data element identifier also indicates whether the data element has a Qualifier.
The most significant bit (Bit 7) of the identifier octet is set to 1 if there are properties associated with the data element; it is set to 0 if there are none. This bit is independent of the remaining seven bits in the identifier octet, which are called the identifier, and provide unique identifi-
cation for data elements. The associated properties are
specified in a Property-List component.
The second most significant bit (Bit 6) of the identifier octet (the most significant bit of the identifier itself) signifies whether or not the data element has a Qualifier. If the bit is set to 1, then the data element has a Qualifier; if it
is a 0, the data element does not have a Qualifier. The seven
bits of the identifier uniquely identify the data element.
Table 2 shows the settings of the high-order bits of the
identifier octet and their associated meaning. Figure 4
demonstrates the bit-level structure of the identifier octet. In
this figure, bit 7 is indiciated with P to show its special use.
38
-----------------------------------------------------------------
bit 7 6 5 4 3 2 1 0
+---------------+
|P 0 x x x x x x| 0xxxxxx uniquely identifies a
+---------------+ data element without a Qualifier.
+---------------+
|P 1 x x x x x x| 1xxxxxx uniquely identifies a
+---------------+ data element with a Qualifier.
FIG. 4. STRUCTURE OF IDENTIFIER OCTETS
-----------------------------------------------------------------
Bit Value Meaning
7 0 The data element does not have properties asso-
ciated.
1 The data element has properties associated.
6 0 The data element does not have a Qualifier.
1 The data element has a Qualifier.
TABLE 2. HIGH-ORDER BITS IN THE IDENTIFIER OCTET
The Length Code and the Qualifier are both usually one octet
in length. They use an encoding scheme that permits extending
the component to the size necessary to represent the length of
the data element or the value of the Qualifier component.
The most significant bit of the Length Code or Qualifier components determines whether it is one or several octets in length. When the most significant bit is 0, the component is one
39
A single octet is sufficient for most Length Code and Qualifier components. For those cases where the value of the Length Code or the Qualifier must be greater than 127, extra
octets can be added, up to a maximum of 127 octets. Figure 5
shows the encoding scheme, as well as an example of a value less
than 127 and one greater than 127.
-----------------------------------------------------------------
bit 7 6 5 4 3 2 1 0
+---------------+
|0 x x x x x x x| xxxxxxx is the value.
+---------------+
+---------------+------//-------+
|1 n n n n n n n|y y y y y y y y| nnnnnnn is the
+---------------+------//-------+ number of octets
that contain the
value yyyyyyyy.
+---------------+
|0 0 0 0 1 0 0 1| This is an example with a
+---------------+ value of 9 (decimal).
+---------------+---------------+
|1 0 0 0 0 0 0 1|1 0 0 0 0 0 1 0| This example has a
+---------------+---------------+ value of 130 (decimal).
+---------------+---------------+
|1 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|
+---------------+---------------+
+---------------+
|0 0 1 0 1 1 0 0| This example has a
+---------------+ value of 300 (decimal).
FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH CODES
-----------------------------------------------------------------
40
16
2 -1). This message format specification places no limitation
on the value of a length code or qualifier generated by a CBMS
(except for the absolute limitation inherent in the represen-
tation scheme). However, the use of length codes and qualifiers
32
with larger values (particularly values in excess of 2 -1)
should be avoided unless it is known that the receiving system
can handle them.
Both Length Codes and Qualifiers have a special convention for dealing with special situations. Length Codes can specify that a data element has indeterminate length; a Qualifier can
specify that a data element is implementation defined. These
cases are explained further in the next two sections.
The length code component immediately follows the identifier
octet. It is present in every data element. The Length Code
indicates the number of octets following it in a data element
(that is, excluding the identifier octet and the length code
itself). Length Codes appear in one of three formats: short,
long, and indefinite.
A short Length Code is one octet long. Its most significant bit (Bit 7) is set to 0 and its value is in the range 0 through 127.
A long Length Code is at least two octets long. The first octet always has its most significant bit (Bit 7) set to 1. The other seven bits of this octet contain the number of octets making up the rest of the Length Code, and these octets contain
1016
(2 - 1) (that is, 127 octets to represent the value).
An indefinite Length Code is one octet long. Its most significant bit (Bit 7) is set to 1 and its other bits are all 0. (See Figure 6.) An indefinite Length Code may appear only as part of a constructor data element; it may not occur in a
41
-----------------------------------------------------------------
bit 7 6 5 4 3 2 1 0
+---------------+
|0 x x x x x x x| xxxxxxx is the value of the
+---------------+ length code.
+---------------+------//-------+
|1 n n n n n n n|y y y y y y y y| nnnnnnn is the number
+---------------+------//-------+ of octets that contain
the value of the length
code; these are represented
as yyyyyyy.
+---------------+
|1 0 0 0 0 0 0 0| The "indefinite" length code
+---------------+
FIG. 6. REPRESENTATION OF LENGTH CODES
-----------------------------------------------------------------
5
primitive data element . A constructor data element with an
indefinite length code has an End-Of-Constructor data element as
the last data element in its Data Element Contents. (The length
of such a constructor data element is unrestricted, although it
must contain at least one data element -- the End-of-Constructor
that terminates it -- in its Data Element Contents.)
If present,the Qualifier component immediately follows the code component. It is used to provide information essential to the interpretation of the data element contents that is beyond that encoded in the identifier octet or length code. For example, the identifier octet could contain the code for a field, and the Qualifier component would specify what kind of field.
The Qualifier component appears in only a few data elements.
_______________
5
This is the result of most primitive elements being able to
contain any bit pattern (including the identifier for End-Of-
Constructor).
42
The length of the Qualifier component depends on the encoding of the Qualifier. (See Figure 7.) A short Qualifier is one octet long. Its most significant bit is 0 and its value is in the range 0 through 127. A long Qualifier is at least two octets in length. The most significant bit is always 1 and the other 7 bits indicate the number of octets in the value of the Qualifier.
-----------------------------------------------------------------
+--------+--------+--------+
|10000010|00000001 00001010| Qualifier with value
+--------+--------+--------+ 266 (decimal).
+--------+--------+--------+--------+
|10000011|00000000|00000001 00001010| Vendor-Defined
+--------+--------+--------+--------+ Qualifier with
value 266.
+--------+
|10000000| Undefined value for a Qualifier.
+--------+
FIG. 7. EXAMPLES OF QUALIFIER VALUES
-----------------------------------------------------------------
This message format specification allows implementations to define their own values for Qualifiers. A vendor-defined Qual- ifier is any long Qualifier in which the first octet in the value
is 0. The value used to identify this Qualifier is not
guaranteed to be unique and the same value may be used by
different implementations to define different Qualifiers.
43
A Property is an attribute being associated with, but not
essential to the interpretation of, a data element. The
properties currently defined by this message format specification
are Printing-Name and Comment. A Property-List component of a
data element is represented by a Property-List data element that
in turn contains Property data elements.
A data element contains at most one Property-List. The most significant bit in the identifier octet of the data element indicates whether a Property-List is present.
The Data Element Contents component of a data element is the
actual data or information represented by a data element. (The
other components provide the information necessary to identify
and interpret the Data Element Contents.)
In a primitive data element, the Data Element Contents is a series of octets interpreted according to the identifier octet and any qualifier.
In a constructor data element, the Data Element Contents is a series of data elements. When the Length Code component of a constructor data element is "indefinite," the last data element in the constructor's Data Element Contents is End-of-Constructor.
The length of the Data Element Contents (in octets) is the difference between the value of the Length Code and the sum of the following:
This message format specification defines nineteen (19) different data elements. Section 4.3.1 defines the encoding form for data elements in general and the syntax for each data element. Section 4.3.2 describes the use of specific data
44
This section presents the general syntactic form for all data elements defined by this message format specification and the detailed syntax for each data element. The data elements are presented by syntactic class: primitive data elements (Section 4.3.1.1), constructors (Section 4.3.1.2), and data elements which can be either (Section 4.3.1.3).
For convenience, the following terminology is used in this section.
Term Meaning
Primitive a Primitive Data Element
Constructor a Constructor Data Element
Element any Data Element
The syntax of each Element is presented in graphic form. The following conventions apply in the diagrams. A single octet is represented as follows.
+--------+
| |
+--------+
Components that vary in length are represented as follows.
+---//---+
| |
+---//---+
Each Element has up to five components: an Identifier, a Length Code, a Qualifier, a Property-List, and the Data Element Contents.
In the diagrams, the contents of the identifier octet is
45
A length code is always represented in the following manner:
+---//---+
|Lxxxxxxx|
+---//---+
A qualifier is always represented in the following manner:
+---//---+
|Qxxxxxxx|
+---//---+
A Property-List (if present) always immediately precedes any occurrence of Data Element Contents.
The Data Element Contents appears in diagrams as one of the following:
Two data elements have been reserved for special purposes. The Extension data element is provided to allow for future expansion of the possible data elements. The Vendor-Defined data element allows CBMS vendors to define their own data elements. Vendor-Defined data elements are not guaranteed to be unique, since two implementations could define different data elements using the same identifier. Vendor-Defined data elements should be used and interpreted by prior agreement.
In the following sections, each element is presented with its name, compliance classification (BASIC or OPTIONAL), its
identifier (both in hexadecimal and in octal), a brief
description of its use, and a graphic representation. Each data
element description has the following form.
46
-----------------------------------------------------------------
Data Element (Compliance) identifier identifier
Name ( Category ) octet octet
16 8
Description of the syntax of the data element.
+---//---+
| | Diagram representing data element
+---//---+
-----------------------------------------------------------------
The data elements in this section are arranged in
alphabetical order by name. (Appendix C presents the identifiers
in numeric order.)
ASCII-String (BASIC) 02 002
16 8
This data element contains a series of ASCII
characters [NatB-80], each character right-justified in
one octet. For 7-bit ASCII characters, the most
significant bit of each octet must be 0.
Note: The ASCII code table can be extended through standardized techniques [NatB-75] to introduce addi- tional 7-bit or 8-bit characters or additional code tables.
+--------+---//---+----//-----+
|P0000010|Lxxxxxxx|ASCII chars|
+--------+---//---+----//-----+
47
Bit-String (OPTIONAL) 43 103
16 8
This data element contains a series of bits. It uses
the Qualifier data element component to record the
number of bits of padding (as an eight bit unsigned
integer) needed to fill the final octet of the Data
Element Contents to an even octet boundary. These
padding bits have no meaning and occur in the low order
bits of the final octet. The valid values for the
Qualifier component are 0 through 7. The number of
bits in the Data Element Contents is calculated from
the following formula.
8 * number of octets - value of
in the Data Qualifier component
Element Contents
+--------+---//---+---//---+---//---+
|P1000011|Lxxxxxxx|Qxxxxxxx| bits |
+--------+---//---+---//---+---//---+
Boolean (OPTIONAL) 08 010
16 8
This data element contains one octet whose value is
either true or false. False is represented by all bits
being 0; true is represented by all bits being 1
(although any non-zero value should be interpreted as
true).
+--------+---//---+--------+
|P0001000|Lxxxxxxx| T or F |
+--------+---//---+--------+
End-of-Constructor (BASIC) 01 001
16 8
This data element terminates the Data Element Contents
in a constructor data element that has indefinite
length. This data element has no Contents component.
(Use of this element is described in Section 4.2.2.1.)
+--------+---//---+
|P0000001|Lxxxxxxx|
+--------+---//---+
48
Integer (OPTIONAL) 20 040
16 8
This data element contains a 2's complement integer of
variable length, high order octet first. It is
recommended that the data element contents be either 2
or 4 octets long whenever possible.
+--------+---//---+---//---+
|P0100000|Lxxxxxxx| Integer|
+--------+---//---+---//---+
No-Op (OPTIONAL) 00 000
16 8
This data element does nothing. No-Op is used whenever
it is necessary to include a data element that means
"no operation." It is a short placeholder.
+--------+---//---+
|P0000000|Lxxxxxxx|
+--------+---//---+
Padding (OPTIONAL) 21 041
16 8
This data element is used to fill any number of octets.
The contents of a Padding element are undefined and
convey no information.
+--------+---//---+---//---+
|P0100001|Lxxxxxxx|anything|
+--------+---//---+---//---+
The data elements in this section are arranged in alpha- betical order.
49
Compressed (OPTIONAL) 46 106
16 8
This data element must contain a Bit-String data
element. It is used to represent any data that has
been compressed; it may be used wherever its
uncompressed contents may appear. A Qualifier data
component appears in each Compressed data element; it
contains a compression identifier (CID) to identify
the compression algorithm used. (See Section 4.3.5.)
The Data Element Contents contains the product of the
compression process.
+--------+---//---+---//---+--------//--------+
|P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
Date (BASIC) 28 050
16 8
This data element contains an ASCII-String data
element, which is a representation of a date and time
formatted in accordance with PUBS 4 [NatB-68],
58 [NatB-79a] and 59 [NatB-79b]. The use of time and
time zone is optional. It is recommended that numeric
offsets be used to indicate time zone rather than
alphabetic abbreviations.
+--------+---//---+------//------+
|P0101000|Lxxxxxxx| ASCII-String |
+--------+---//---+------//------+
Encrypted (OPTIONAL) 47 107
16 8
This data element must contain a Bit-String. It is
used to represent any data that has been encrypted; it
may be used wherever its unencrypted contents may
appear. A Qualifier data component appears in each
Encrypted data element; it contains an encryption
identifier (EID) identifying the encryption algorithm
used. The Data Element Contents is the product of the
encryption process.
+--------+---//---+---//---+--------//--------+
|P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
50
Field (BASIC) 4C 114
16 8
This data element uses a Qualifier data element
component. The Qualifier component contains a Field
Identifier (FID) indicating which specific field is
being represented.
+--------+---//---+---//---+---//---+
|P1001100|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
Message (BASIC) 4D 115
16 8
This data element may contain Field or Message data
elements. Its Qualifier component contains a Message
type (MID) indicating the type of the message. (The
MID is completely different from the message identifier
in the Message-ID field and should not be confused with
it.)
+--------+---//---+---//---+
|P1001101|Lxxxxxxx|Qxxxxxxx|
+--------+---//---+---//---+
+--------//---------//---------//---------//--------+
| Field, Message, Encrypted, or Compressed Elements |
+--------//---------//---------//---------//--------+
Property-List (OPTIONAL) 24 044
16 8
This data element contains a series of Property data
elements to be associated with another data element.
+--------+---//---+-------//--------+
|P0100100|Lxxxxxxx|Property Elements|
+--------+---//---+-------//--------+
Property (OPTIONAL) 45 105
16 8
This data element uses a Qualifier data element
component. The Qualifier component contains
a Property-Identifier (PID) to indicate which specific
property is being represented.
+--------+---//---+---//---+---//---+
|P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
51
Sequence (OPTIONAL) 0A 012
16 8
This data element contains any series of data elements.
Sequence differs from Set in that the data elements
making up the Data Element Contents must be considered
as an ordered sequence (according to their order of
appearance in the sequence.)
+--------+---//---+---//---+
|P0001010|Lxxxxxxx|elements|
+--------+---//---+---//---+
Set (OPTIONAL) 0B 013
16 8
This data element contains any series of data elements
with no ordering of the elements implied. (Sequence
provides an ordered series.) Although the data
elements contained in a Set must be stored
sequentially, the order in which they are stored is not
defined and not processed.
+--------+---//---+---//---+
|P0001011|Lxxxxxxx|elements|
+--------+---//---+---//---+
Unique-ID (OPTIONAL) 09 011
16 8
This data element is a unique identifier. It need not
be human-readable. The Data Element Contents may be an
ASCII-String, a Bit-String, or an Integer.
+--------+---//---+---//---+
|P0001001|Lxxxxxxx| element|
+--------+---//---+---//---+
There are two data elements that are used to extend this specification. They can be classified as either primitive or constructor data elements, depending on the extension.
52
Extension (OPTIONAL) 7E 176
16 8
This data element is used to extend the number of
available data elements beyond the 128 that are
possible using a 7-bit identifier. A Qualifier
component extends the encoding space for identifiers.
(Extension and Vendor-Defined have the same syntax.)
+--------+---//---+---//---+---//---+
|P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
Vendor-Defined (OPTIONAL) 7F 177
16 8
This data element is used to represent vendor- and
user-defined data elements. A Qualifier component
extends the encoding space for identifiers. The
Qualifier component is not guaranteed to be unique
among all interconnected systems. This data element is
interpreted according to prior agreement between
systems. (Extension and Vendor-Defined data elements
have the same syntax.)
+--------+---//---+---//---+---//---+
|P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
The Data Element Contents of a particular field in a message must contain at least one data element. The types of data elements that can appear in the Data Element Contents of a field are restricted according to what kind of field it is. Appendix A (the master reference appendix for fields) defines which data elements are valid as the Contents for each of the fields.
Some fields have a Data Element Contents that contains
"originators" or "recipients." No data element represents the
identities of originators or recipients (because that encoding is
not within the scope of this message format specification.)
These descriptions simply list "originators" or "recipients",
implying no restrictions on how the identifiers for originators
or recipients are represented.
53
This message format specification defines two properties.
Comment 01 001
16 8
This property may contain any series of data elements;
it most commonly contains one or more ASCII-Strings.
Printing-Name 02 002
16 8
This property contains one ASCII-String. In this case,
the ASCII-String may contain only the printing ASCII
characters plus the "space" character.
This message format specification defines two encryption identification codes.
Unspecified 00 000
16 8
Use of this encryption identifier as part of the
Encrypted data element indicates that the encryption
method being used was not specified for inclusion as
part of the data element.
FIPS-Standard 01 001
16 8
Use of this encryption identifier as part of the
Encrypted data element indicates that the Federal
Information Processing Standard method for data
encryption was [NatB-77].
This message format specification defines one compression identification code for use with the Compressed data element.
Unspecified 00 000
16 8
Use of this compression identifier as part of the
Compressed data element indicates that the compression
method being used was not specified for inclusion as
part of the data element.
54
This message format specification defines message type (MID) codes for use in classifying the type of a message. The message type could be confused with the message identifier in the Message-Id field; they are completely distinct concepts.
FIPS-Standard 01 01
16 8
This message type marks messages defined by this
message format specification.
55
use by implementors. It contains semantic
definitions of fields from Section 3.1. It also
defines Field Identifier values and specifies which
data elements are valid as the Contents for each of
the fields.
Appendix B Defines the data elements in the message format specification. This alphabetically ordered appendix is for reference use by implementors. It consol- idates information from Section 4.3.
Appendix C Provides a reference table listing the data elements in numerical order by their identifier octets.
Appendix D Provides a reference table summarizing the components of messages according to whether they are required or optional for CBMSs implementing the specification.
Appendix E Provides a reference table organizing 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 Summarizes syntactic elements according to whether they are required or optional for a CBMS implementing the message format specification.
Appendix H Examples of each syntactic element displaying their syntax and describing their associated semantics.
56
This appendix defines all of the fields in the message
format specification for reference use by implementors. It
contains semantics definitions of fields from Section 3.1. It
also defines Field Identifier values and which data elements are
valid as the Contents for each of the fields. The field
definitions appear alphabetically.
Each field in the list has the following form:
------------------------------------------------------------
Field Name Compliance identifier identifier
value value
16 8
Description of the field semantics. Names of data elements that are valid in the Data Element Contents of this kind of field.
------------------------------------------------------------
Attachments OPTIONAL 08 010
16 8
This field contains additional data accompanying a
message. It is similar in intent to enclosures in a
conventional mail system. Contents of this field are
unrestricted.
Author OPTIONAL 0C 014
16 8
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.
This field contains one or more originator identities.
57
Bcc OPTIONAL 0D 015
16 8
This field identifies additional recipients for 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. This field contains one or
more recipient identities.
Cc BASIC 06 006
16 8
This field identifies secondary recipients for a
message (a "carbon copies" list). This field contains
one or more recipient identities.
Circulate-Next OPTIONAL 0E 016
16 8
This field is used in conjunction with the Circulate-To
field. (See Section 3.2.6.1 for further discussion.)
It identifies all recipients in a circulation list who
have not yet received the message. This field contains
one or more recipient identities.
Circulate-To OPTIONAL 0F 017
16 8
This field identifies recipients for a circulated
message. (See Section 3.2.6.1 for further discussion.)
It is used in conjunction with the Circulate-Next
field. This field contains one or more recipient
identities.
Comments OPTIONAL 10 020
16 8
This field permits adding comments onto the message
without disturbing the original contents of the
message. While the Comments field will usually contain
one or more ASCII-Strings, there are no restrictions on
its contents.
Date OPTIONAL 11 021
16 8
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.
This field contains one Date.
58
End-Date OPTIONAL 12 022
16 8
This field contains the date on which a message loses
effect. (See also Section 3.2.5 for further
discussion.) This field contains one Date.
From REQUIRED 01 001
16 8
This field contains the identity of the originators
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. This
field contains one or more originator identities.
In-Reply-To OPTIONAL 13 023
16 8
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. This field contains
one or more Unique-IDs or ASCII-Strings.
Keywords OPTIONAL 14 024
16 8
This field contains keywords or phrases for use in
retrieving a message. This field contains one or more
ASCII-Strings. (Each keyword or phrase is represented
by a separate ASCII-String.)
Message-Class OPTIONAL 15 025
16 8
This field indicates the purpose of a message. For
example, it might contain values indicating that the
message is a memorandum or a data-base entry. This
field contains one data element, an ASCII-String.
Message-ID OPTIONAL 16 026
16 8
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. This field contains one data element, a
Unique-ID.
Obsoletes OPTIONAL 26 046
16 8
This field identifies one or more messages that this
one supplants. This field contains at least one
Unique-ID and may contain more than one.
59
Originator-Serial-Number OPTIONAL 17 027
16 8
This field contains one or more serial numbers assigned
by the message's originator. (Messages with multiple
recipients should all have the same value in the
Originator-Serial-Number field. This field contains
one or more ASCII-Strings. (One ASCII-String is used
for each serial number.)
Posted-Date REQUIRED 02 002
16 8
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. This
field contains one Date.
Precedence OPTIONAL 18 030
16 8
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. This field indicates the precedence at
which the message was posted. One example of a
precedence scheme is the US Military categories
"ROUTINE", "PRIORITY", "IMMEDIATE", "FLASH OVERRIDE",
and "EMERGENCY COMMAND PRECEDENCE". This field
contains one ASCII-String.
Received-Date OPTIONAL 19 031
16 8
This field is also called Delivery date. It may be
added to a message by the recipient's message receiving
program. It indicates when the message left the
delivery system and entered the recipient's message
processing domain. This field contains one Date.
Received-From OPTIONAL 1A 032
16 8
This field contains a record of a message's path
through a message transfer system. The
recipient's message receiving program may store any
such information that it obtains from a message
transfer system in this field. The contents of this
field are unrestricted.
60
References OPTIONAL 20 040
16 8
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. This
field contains one or more Unique-IDs or ASCII-Strings.
Reissue-Type OPTIONAL 25 045
16 8
This field is used in conjunction with message
encapsulating (see Section 3.2.2) to differentiate
between messages being assigned or redistributed. This
field contains one data element, usually an ASCII-
String.
Reply-To BASIC 03 003
16 8
This field identifies any recipients for replies to the
message. This field contains one or more recipient
identities.
Sender OPTIONAL 22 042
16 8
This field identifies the agent who sent the message.
It is intended either for 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. Only one
Sender field is permitted in a message. This field
contains one originator identity.
Start-Date OPTIONAL 23 043
16 8
This field contains the date on which a message takes
effect. (See Section 3.2.5 for further discussion.)
This field contains one Date.
Subject BASIC 07 007
16 8
This field contains whatever information the originator
provided to summarize or indicate the nature of the
message. This field contains one or more ASCII-
Strings.
Text BASIC 04 004
16 8
This field contains the primary content of the message.
Contents of this field are unrestricted.
61
To REQUIRED 05 005
16 8
This field identifies primary recipients for a message.
This field contains one or more recipient identities.
Warning-Date OPTIONAL 24 044
16 8
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 Section 3.2.5 for further discussion.)
This field contains one or more Dates.
62
The appendix defines all of the data elements in the message format specification, for reference use by implementors. It contains no new information but rather consolidates the syntactic information from Section 4.3.
Each data element description has the following form.
-----------------------------------------------------------------
Data Element (Compliance) identifier identifier
Name ( Category ) octet octet
16 8
Constructive class (primitive or constructor)
Description of the syntax of the data element.
+---//---+
| | Diagram representing data element
+---//---+
-----------------------------------------------------------------
63
ASCII-String (BASIC) 02 002
16 8
primitive
This data element contains a series of ASCII characters
[NatB-80], each character right-justified in one
octet. For 7-bit ASCII characters, the most
significant bit of each octet must be 0.
Note: The ASCII code table can be extended through standardized techniques [NatB-75] to introduce addi- tional 7-bit or 8-bit characters or additional code tables.
+--------+---//---+----//-----+
|P0000010|Lxxxxxxx|ASCII chars|
+--------+---//---+----//-----+
Bit-String (OPTIONAL) 43 103
16 8
primitive
This data element contains a series of bits. It uses the Qualifier data element component to record the number of bits of padding (as an 8-bit unsigned integer) needed to fill the final octet of the Data
Element Contents to an even octet boundary. These
padding bits have no meaning and occur in the low order
bits of the final octet. The valid values for the
Qualifier component are 0 through 7. The number of
bits in the Data Element Contents is calculated from
the following formula.
8 * number of octets - value of
in the Data Qualifier component
Element Contents
+--------+---//---+---//---+---//---+
|P1000011|Lxxxxxxx|Qxxxxxxx| bits |
+--------+---//---+---//---+---//---+
64
Boolean (OPTIONAL) 08 010
16 8
primitive
This data element contains one octet whose value is either true or false. False is represented by all bits being 0; true is represented by all bits being 1 (although any non-zero value should be interpreted as true).
+--------+---//---+--------+
|P0001000|Lxxxxxxx| T or F |
+--------+---//---+--------+
Compressed (OPTIONAL) 46 106
16 8
constructor
This data element must contain a Bit-String data
element. It is used to represent any data that has
been compressed; it may be used wherever its
uncompressed contents may appear. A Qualifier data
component appears in each Compressed data element; it
contains a compression identifier (CID) to identify the
compression algorithm used. (See Section 4.3.5.) The
Data Element Contents contains the product of the
compression process.
+--------+---//---+---//---+--------//--------+
|P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
Date (BASIC) 28 050
16 8
constructor
This data element contains an ASCII-String data
element, which is a representation of a date and time
formatted in accordance with FIPS PUBS 4 [NatB-68],
58 [NatB-79a], and 59 [NatB-79b]. The use of time and
time zone is optional. It is recommended that numeric
offsets be used to indicate time zone rather than
alphabetic abbreviations.
+--------+---//---+------//------+
|P0101000|Lxxxxxxx| ASCII-String |
+--------+---//---+------//------+
65
Encrypted (OPTIONAL) 47 107
16 8
constructor
This data element must contain a Bit-String. It is used to represent any data that has been encrypted; it may be used wherever its unencrypted contents may appear. A Qualifier data component appears in each Encrypted data element; it contains an encryption identifier (EID) identifying the encryption algorithm used. (See Section 4.3.4 for further discussion.) The Data Element Contents is the product of the encryption process.
+--------+---//---+---//---+--------//--------+
|P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
End-of-Constructor (BASIC) 01 001
16 8
primitive
This data element terminates the Data Element Contents in a constructor data element that has indefinite length. This data element has no Contents component. (Use of this element is described in Section 4.2.2.1.)
+--------+---//---+
|P0000001|Lxxxxxxx|
+--------+---//---+
Extension (OPTIONAL) 7E 176
16 8
either
This data element is used to extend the number of
available data elements beyond the 128 that are
possible using a 7-bit identifier. A Qualifier
component extends the encoding space for identifiers.
(Extension and Vendor-Defined have the same syntax.)
+--------+---//---+---//---+---//---+
|P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
66
Field (BASIC) 4C 114
16 8
constructor
This data element uses a Qualifier data element
component. The Qualifier component contains a Field
Identifier (FID) indicating which specific field is
being represented. (See Section 4.3.2 for further
discussion.)
+--------+---//---+---//---+---//---+
|P1001100|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
Integer (OPTIONAL) 20 040
16 8
primitive
This data element contains a 2's complement integer of
variable length, high-order octet first. It is
recommended that the data element contents be either 2
or 4 octets long whenever possible.
+--------+---//---+---//---+
|P0100000|Lxxxxxxx| Integer|
+--------+---//---+---//---+
Message (BASIC) 4D 115
16 8
constructor
This data element may contain Field or Message data
elements. Its Qualifier component contains a Message
type (MID) indicating the type of the message. (See
Section 4.3.6 for further discussion.) (The MID is
completely different from the message identifier in the
Message-ID field and should not be confused with it.)
+--------+---//---+---//---+
|P1001101|Lxxxxxxx|Qxxxxxxx|
+--------+---//---+---//---+
+--------//---------//---------//---------//--------+
| Field, Message, Encrypted, or Compressed Elements |
+--------//---------//---------//---------//--------+
67
No-Op (OPTIONAL) 00 000
16 8
primitive
This data element does nothing. No-Op is used whenever it is necessary to include a data element that means "no operation." It is a short placeholder.
+--------+---//---+
|P0000000|Lxxxxxxx|
+--------+---//---+
Padding (OPTIONAL) 21 041
16 8
primitive
This data element is used to fill any number of octets. The contents of a Padding element are undefined and convey no information.
+--------+---//---+---//---+
|P0100001|Lxxxxxxx|anything|
+--------+---//---+---//---+
Property-List (OPTIONAL) 24 044
16 8
constructor
This data element contains a series of Property data elements to be associated with another data element.
+--------+---//---+-------//--------+
|P0100100|Lxxxxxxx|Property Elements|
+--------+---//---+-------//--------+
68
Property (OPTIONAL) 45 105
16 8
constructor
This data element uses a Qualifier data element
component. The Qualifier component contains
a Property-Identifier (PID) to indicate which specific
property is being represented. (See Section 4.3.3 for
further discussion.)
+--------+---//---+---//---+---//---+
|P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
Sequence (OPTIONAL) 0A 012
16 8
constructor
This data element contains any series of data elements. Sequence differs from Set in that the data elements making up the Data Element Contents must be considered as an ordered sequence (according to their order of appearance in the sequence.)
+--------+---//---+---//---+
|P0001010|Lxxxxxxx|elements|
+--------+---//---+---//---+
Set (OPTIONAL) 0B 013
16 8
constructor
This data element contains any series of data elements
with no ordering of the elements implied. (Sequence
provides an ordered series.) Although the data
elements contained in a Set must be stored
sequentially, the order in which they are stored is not
defined and not processed.
+--------+---//---+---//---+
|P0001011|Lxxxxxxx|elements|
+--------+---//---+---//---+
69
Unique-ID (OPTIONAL) 09 011
16 8
constructor
This data element is a unique identifier. It need not be human-readable. The Data Element Contents may be an ASCII-String, a Bit-String, or an Integer.
+--------+---//---+---//---+
|P0001001|Lxxxxxxx| element|
+--------+---//---+---//---+
Vendor-Defined (OPTIONAL) 7F 177
16 8
either
This data element is used to represent vendor-defined
data elements. A Qualifier component extends the
encoding space for identifiers. The Qualifier
component is not guaranteed to be unique among all
interconnected systems. This data element is
interpreted according to prior agreement between
systems. (Extension and Vendor-Defined data elements
have the same syntax.)
+--------+---//---+---//---+---//---+
|P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
70
Identifier Identifier Data Element Name
00 000 No-Op
01 001 End-of-Constructor
02 002 ASCII-String
08 010 Boolean
09 011 Unique-ID
0A 012 Sequence
0B 013 Set
20 040 Integer
21 041 Padding
24 044 Property-List
28 050 Date
43 103 Bit-String
45 105 Property
46 106 Compressed
47 107 Encrypted
4C 114 Field
4D 115 Message
7E 176 Extension
7F 177 Vendor-Defined
71
This appendix is for reference use. It contains no new information, but rather abstracts from that presented in Section 3.1.
This appendix contains the message field names arranged alphabetically within compliance category. (Appendix E orders the field names within functional category.) Complete field definitions appear in Appendix A.
Required fields must appear in a message. Basic fields must be recognized and processed by all CBMS systems. Optional fields need not be supported by a CBMS but, if supported, must be processed according to the meanings defined by the message format specification.
From
Posted-Date
To
Cc
Reply-To
Subject
Text
Attachments
Author
Bcc
Circulate-Next
Circulate-To
Comments
72
73
This appendix is for reference use. It contains no new information, but rather abstracts from that presented in Section 3.1.
This appendix contains the message field names arranged alphabetically within functional class. (Appendix D orders the field names within compliance class.) Complete field definitions appear in Appendix A.
Circulate-Next
Circulate-To
In-Reply-To
Message-ID
Obsoletes
Originator-Serial-Number
References
End-Date
Start-Date
Warning-Date
Received-Date
Received-From
74
Attachments
Comments
Keywords
Message-Class
Precedence
Subject
Text
Reply-To
Reissue-Type
Author
Bcc
Cc
Date
From
Posted-Date
Sender
To
75
This appendix summarizes data element syntax by diagramming the components of data elements. Detailed presentation of data element syntax appears in Section 4.3.1.
In these diagrams, required components of a data element appear as follows. (The double border signifies "required.")
+========+ +===//===+
| | | |
+========+ +===//===+
always one one or more
octet long octets long
Optional components of data elements are represented as follows. (The single border signifies "not required.")
+--------+ +---//---+
| | | |
+--------+ +---//---+
always one one or more
octet long octets long
The first octet in a data element is the identifier octet. In diagrams of data elements, all eight bits of the identifier octet are always shown. Bits with fixed values show the fixed values as 1s and 0s. Bits with variable values are shown as x's and y's.
The first bit in an identifier octet is the P-bit. Its value indicates whether a data element contains a property list. (A P-bit value of 1 indicates the presence of a property list.) The remaining seven bits contain the rest of the identifier.
Other octets in a data element belong to one of four
classes: Length Code, Qualifier, Property-List, and Contents.
In diagrams of syntax the data element components are labeled
according to their class.
76
Component Class Label
Length code Length
Qualifier Qual
Property-List P-List
Contents Contents
Data elements must follow this form.
+========+===//===+---//---+---//---+---//---+
|Pxxxxxxx| Length | Qual | P-List |contents|
+========+===//===+---//---+---//---+---//---+
The value of the Length component is the total number of octets following the length code octet in the data element.
77
Compliance categories for syntactic elements are basic and optional. Every CBMS is required to recognize and process basic
elements. A CBMS is not required to process optional elements
although many are strongly recommended by the semantics.
This appendix summarizes data elements by listing them according to their compliance category.
ASCII-String (primitive) 02 002
16 8
Date (constructor) 28 050
16 8
End-Of-Constructor (primitive) 01 001
16 8
Field (constructor) 4C 114
16 8
Message (constructor) 4D 115
16 8
Bit-String (primitive) 43 103
16 8
Boolean (primitive) 08 010
16 8
Compressed (constructor) 46 106
16 8
Encrypted (constructor) 47 107
16 8
Extension (either) 7E 176
16 8
Integer (primitive) 20 040
16 8
No-Op (primitive) 00 000
16 8
Padding (primitive) 21 041
16 8
78
Property (constructor) 45 105
16 8
Property-List (constructor) 24 044
16 8
Sequence (constructor) 0A 012
16 8
Set (constructor) 0B 013
16 8
Unique-ID (constructor) 09 011
16 8
Vendor-Defined (either) 7F 377
16 8
79
This appendix presents at least one example for each of the
data elements defined in this message format specification. In
these examples, identifier octets are represented in binary form.
All other numbers are presented in hexadecimal. ASCII strings
are shown as characters rather than their numerical represen-
tation. Although this message format specification does not
define the syntax of names and addresses, message originators and
recipients are identified by their names. This does not imply
anything about how naming and addressing can or should be done;
it is simply a convenient way to identify message originators and
recipients in these examples.
This section contains an example of each of the primitive data elements. Each example contains a short explanation and a series of octets.
No-Op data element:
+--------+--------+
|00000000|00000000|
+--------+--------+
End-of-Constructor data element:
+--------+--------+
|00000001|00000000|
+--------+--------+
80
+--------+--------+--------+
|00001000|00000001|11111111|
+--------+--------+--------+
Integer data element containing five octets of data. Its value is 4,294,967,296 (decimal):
+--------+--------+--------+--------+--------+
|00100000| 0 5 | 0 1 0 0 0 0
+--------+--------+--------+--------+--------+
+--------+--------+
0 0 0 0 |
+--------+--------+
Padding data element containing three octets of padding. The values of those three octets are meaningless:
+--------+--------+--------+--------+--------+
|00100001| 0 3 | F F F F F F |
+--------+--------+--------+--------+--------+
ASCII-String data element containing nine characters. Its value is "Hi There.":
+--------+--------+---- ----+
|00000010| 0 9 |Hi There.|
+--------+--------+---- ----+
81
Bit-String Length Spare
+--------+--------+--------+--------+--------+
|01000011| 0 7 | 0 4 | 0 A 3 B
+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+
5 F 2 9 1 C D 0 |
+--------+--------+--------+--------+
This section contains an example of each of the constructor
data elements. Each example contains a short explanation and
then an annotated series of the data elements making up the
constructor.
Property-List data element containing one Property data
element. The property is Printing-Name and its value is
"Distribution":
Prop-List Length Property Length PID
+--------+--------+--------+--------+--------+
|00100100| 1 1 |01000101| 0 F | 0 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 C |Distribution|
+--------+--------+---- ----+
82
Property Length PID ASCII Length
+--------+--------+--------+--------+--------+
|01000101| 0 F | 0 2 |00000010| 0 C |
+--------+--------+--------+--------+--------+
+---- ----+
|Distribution|
+---- ----+
Compressed data element. Its contents were compressed using an unspecified data compression algorithm. The compressed data is in a bit-string that is 56 bits long, fully filling 7 octets:
Compressed Length CID Bit-String Length
+--------+--------+--------+--------+--------+
|01000110| 0 B | 0 0 |01000011| 0 8 |
+--------+--------+--------+--------+--------+
Spare
+--------+--------+--------+--------+
| 0 0 | 1 C 5 F 2 D
+--------+--------+--------+--------+
+--------+--------+--------+--------+
7 7 B A F 6 2 9 |
+--------+--------+--------+--------+
83
Encrypted data element. The encryption method used to
encrypt its contents has been intentionally not specified. This
element contains a Bit-String which contains 22 bits (((4-1) x 8)
- 2) of data. These 22 bits are represented in octets; the final
2 bits in the final octet are padding and are therefore ignored:
Encrypted Length EID Bit-String Length
+--------+--------+--------+--------+--------+
|01000111| 0 7 | 0 0 |01000011| 0 4 |
+--------+--------+--------+--------+--------+
Spare
+--------+--------+--------+--------+
| 0 2 | A 3 7 8 1 C |
+--------+--------+--------+--------+
Date data element. This example includes a date but no
time. The date shown in this example is August 15, 1980:
Date Length ASCII Length
+--------+--------+--------+--------+--- ---+
|00101000| 0 A |00000010| 0 8 |19800815|
+--------+--------+--------+--------+--- ---+
Unique-ID data element, which is represented as an Integer data element whose value is 129 (decimal).
Unique-ID Length Integer Length
+--------+--------+--------+--------+--------+--------+
|00001001| 0 4 |00100000| 0 2 | 0 0 8 1 |
+--------+--------+--------+--------+--------+--------+
84
Sequence Length ASCII Length
+--------+--------+--------+--------+--- ---+
|00001010| 1 2 |00000010| 0 7 |This is|
+--------+--------+--------+--------+--- ---+
ASCII Length
+--------+--------+--- ---+
|00000010| 0 7 | a list|
+--------+--------+--- ---+
Set data element containing two Integer data elements. The first integer has a value of 519 (decimal) while the value of the second is 71 (decimal). (These two values have no ordering because they belong to a set.)
Set Length Integer Length
+--------+--------+--------+--------+--------+--------+
|00001011| 0 8 |00100000| 0 2 | 0 2 0 7 |
+--------+--------+--------+--------+--------+--------+
Integer Length
+--------+--------+--------+--------+
|00100000| 0 2 | 0 0 4 7 |
+--------+--------+--------+--------+
Field data element. The specific field shown is the Text field with the contents "I will see you at lunch.":
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 B | 0 4 |00000010| 1 8 |
+--------+--------+--------+--------+--------+
+---- ----+
|I will see you at lunch.|
+---- ----+
85
Message Length Type Field Length
+--------+--------+--------+--------+--------+
|01001101| 5 A | 0 1 |01001100| 1 9 |
+--------+--------+--------+--------+--------+
FID Date Length ASCII
+--------+--------+--------+--------+
| 0 2 |00101000| 1 6 |00000010|
+--------+--------+--------+--------+
Length
+--------+---- ----+
| 1 4 |19800704-180000-0400|
+--------+---- ----+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 8 | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+-- --+
| 0 5 |Smith|
+--------+-- --+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 2 8 | 0 4 |00000010|
+--------+--------+--------+--------+
Length
+--------+
| 2 5 |
+--------+
+---- ----+
|Are you going to watch the fireworks?|
+---- ----+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 8 | 0 5 |00000010|
+--------+--------+--------+--------+
86
+--------+-- --+
| 0 5 |Jones|
+--------+-- --+
This section contains examples of data elements used to extend this specification. These data elements can be either primitives or constructors, depending on the extension. Extension data element containing a length code and 3 octets. The octet immediately following the length code iden- tifies it as Extension Data Element 7. The Data Element Contents is the final two octets. The interpretation of the Data Element Contents would be defined in an extension or successor to this
message format specification. [Note: this is an example. Any
actual extension data element 7 (if it were ever used) would be
completely different from anything done here.]:
Extension Length
+--------+--------+--------+--------+--------+
|01111110| 0 3 | 0 7 | 4 A E 9 |
+--------+--------+--------+--------+--------+
Vendor-Defined data element containing a length code and 3 octets. The first octet identifies this as vendor-defined data element number 114 (decimal), which this particular vendor has defined to contain three printable ASCII characters in two
octets. (Data element 114 (decimal) for another user would be
completely different. For example, it might contain a floating
point number.):
User Length
+--------+--------+--------+--------+--------+
|01111111| 0 3 | 7 2 | P O E |
+--------+--------+--------+--------+--------+
87
This section contains examples of Field data element con-
structors for each of several different fields (Keywords, Text,
Subject, Vendor-Defined).
Field data element for keywords . The field contains two
keywords, Message and Computer, each represented in a separate
ASCII-string data element.
Field Length Keywords ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 4 | 1 4 |00000010| 0 7 |
+--------+--------+--------+--------+--------+
+--- ---+
|Message|
+--- ---+
ASCII Length
+--------+--------+--- ---+
|00000010| 0 8 |Computer|
+--------+--------+--- ---+
88
Field Length Text Prop-List Length
+--------+--------+--------+--------+--------+
|11001100| 2 0 | 0 4 |00100100| 0 9 |
+--------+--------+--------+--------+--------+
Property Length PID ASCII
+--------+--------+--------+--------+
|01000101| 0 7 | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+- -+
| 0 4 |Now?|
+--------+- -+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |Do you want lunch?|
+--------+--------+---- ----+
Field data element for Subject containing an ASCII-String data element ("Good restaurants in Detroit" followed by a carriage return and a line feed). (A recipient would expect the message to contain some information about restaurants in the Detroit area.):
Field Length Subject ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 2 1 | 0 7 |00000010| 1 E |
+--------+--------+--------+--------+--------+
+---- ----+
|Good restaurants in Detroit.<cr><lf>|
+---- ----+
89
vendor. This vendor has defined vendor-defined field 12
(decimal) to be a field with a printing name of "Reply-by" and
contents consisting of a date; January 7, 1981 in this case.
(The meaning of vendor-defined field 12 is unique to the vendor;
the same field number would have different meaning for other
vendors.):
Field Length Qualifier User number
+--------+--------+--------+--------+--------+
|11001100| 1 F | 8 2 | 0 0 0 C |
+--------+--------+--------+--------+--------+
Prop-List Length Property Length
+--------+--------+--------+--------+
|00100100| 0 E |01000101| 0 C |
+--------+--------+--------+--------+
PID ASCII Length
+--------+--------+--------+---- ----+
| 0 2 |00000010| 0 9 |Reply-By:|
+--------+--------+--------+---- ----+
Date Length ASCII Length
+--------+--------+--------+--------+
|00101000| 0 A |00000010| 0 8 |
+--------+--------+--------+--------+
+--- ---+
|19810107|
+--- ---+
This section contains several examples of complete messages
and shows the results of reissuing a message. (See Section
3.2.2.)
90
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | B 6 | 0 1 |
+--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
91
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1000-0400|
+--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
due tomorrow. Please have<CrLf>
your section to me by three this
----+
afternoon.|
----+
The following example illustrates the results of reissuing the first message in this section. This message contains the original message (as a Message data element), To, From, and Posted-Date fields, and a Reissue-Type field with Redistributed as its value:
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | F C | 0 1 |
+--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 9 | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+-- --+
| 0 6 |Cooper|
+--------+-- --+
92
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1030-0400|
+--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 0 | 2 5 |00000010| 0 D |
+--------+--------+--------+--------+--------+
+---- ----+
|Redistributed|
+---- ----+
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | B 6 | 0 1 |
+--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
93
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1000-0400|
+--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
due tomorrow. Please have<CrLf>
your section to me by three this
----+
afternoon.|
----+
This section contains two examples of data elements with an unknown length. The two examples have been presented in sections H.2 and H.5, but with a known rather than an unknown length.
94
Set Length Integer Length
+--------+--------+--------+--------+--------+--------+
|00001011| 8 0 |00100000| 0 2 | 0 2 0 7 |
+--------+--------+--------+--------+--------+--------+
Integer Length
+--------+--------+--------+--------+
|00100000| 0 2 | 0 0 4 7 |
+--------+--------+--------+--------+
End-of-Con Length
+--------+--------+
|00000000|00000000|
+--------+--------+
The following sample message with an unknown length had Stevens as its originator and Johnson as its recipient. The message was sent on August 14, 1980 at 10 a.m. EDT. The subject of the message is "Project Deadline" and the message is a reminder that the deadline is the next day and that the section of the report for the project being done by Johnson should be turned in to Stevens by 3 p.m. that day.
Message Length Type
+--------+--------+--------+
|01001101| 8 0 | 0 1 |
+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
95
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1000-0400|
+--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
due tomorrow. Please have<CrLf>
your section to me by three this
----+
afternoon.|
----+
End-of-Con Length
+--------+--------+
|00000000|00000000|
+--------+--------+
96
This example is provided to illustrate the encoding of non- FIPS format messages in the FIPS format. It is the intent of the standard to deal with computer based message systems which are primarily intended for person-to-person use. This example deals with the definition and use of vendor-defined fields to extend the use of the standard to station-to-station messaging. The context is a military message using the military standard JANAP- 128 format.
JANAP-128
RTTUZYUW RUABCDE0010 0330930-UUUU--RUXABYE.
ZNR UUUUU
R 020830Z FEB 82
FM Commander,Atlantic Fleet
TO USS SHIPA
BT
UNCLAS
MESSAGE BODY
BT
#0010
NNNN
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | D 0 | 0 1 |
+--------+--------+--------+--------+
Field Length FID
+--------+--------+--------+
|01001100| 0 4 | 1 8 |
+--------+--------+--------+
97
ASCII Length
+--------+--------+--------+
|00000010| 0 1 | R |
+--------+--------+--------+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 7 | 8 2 | 0 0 | 0 1 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+--------+--------+
|00000010| 0 2 | T | T |
+--------+--------+--------+--------+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 6 | 8 2 | 0 0 | 0 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+--------+
|00000010| 0 1 | U |
+--------+--------+--------+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 9 | 8 2 | 0 0 | 0 3 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | ZYUW |
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 A | 2 2 |
+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 7 | RUABCDE |
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 7 | 1 7 |
+--------+--------+--------+
98
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | 0010 |
+--------+--------+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 8 | 0 2 |00101000| 1 5 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 3 |19820202093000-0000|
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 9 | 8 2 | 0 0 | 0 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | UUUU |
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 C | 8 2 | 0 0 | 0 4 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 7 | RUXABYE |
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 A | 8 2 | 0 0 | 0 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 5 | UUUUU |
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 4 | 1 8 |
+--------+--------+--------+
99
ASCII Length
+--------+--------+--------+
|00000010| 0 1 | R |
+--------+--------+--------+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 4 | 1 1 |00101000| 1 1 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 F |8202020830-0000|
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 1 B | 0 1 |
+--------+--------+--------+
ASCII Length
+--------+--------+
|00000010| 1 8 |
+--------+--------+
+---- ----+
|Commander,Atlantic Fleet|
+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 C | 0 5 |
+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 9 | USS SHIPA |
+--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 7 | 0 4 |
+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | BODY |
+--------+--------+---- ----+
100
Field Length FID
+--------+--------+--------+
|01001100| 0 7 | 1 7 |
+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | 0010 |
+--------+--------+---- ----+
JANAP-128 Field FIPS Format Field
Precedence Precedence (Appendix A)
Language Media Format Vendor-Defined
Security Vendor-Defined
Content Indicator Code Vendor-Defined
Origination Station Sender (Appendix A)
Routing Indication
Station Serial Number Originator-Serial-Number
(Appendix A)
Time of File Posted-Date (Appendix A)
Security Vendor-Defined
Destination Station Vendor-Defined
Routing Indicator
Security Vendor-Defined
Precedence Precedence (Appendix A)
Date/Time Group Date (Appendix A)
FM From (Appendix A)
TO To (Appendix A)
Body of Message Text (Appendix A)
Station Serial Number Originator-Serial-Number
(Appendix A)
101
Field Name Identifier Value
8
Description
-----------------------------------------------------------------
Language Media Format 01
8
This field contains two ASCII characters; the first
indicates the input media and the second the output media.
Security 02
8
This field contains a variable length ASCII character
indicator of the security classification of the messages.
Content Indicator Code 03
8
This field contains four ASCII characters and provides
information describing the message content and message handling
actions to be performed.
Destination Station Routing Indicator 04
8
This field contains four ASCII characters indicating the CPU
and terminal device to which the message should be sent.
102
[CCIT-82]
CCITT Study Group VII/5. Draft recommendation X.MHS1:
Message Handling Systems: System Model - Service Elements
(Version 2). Technical Report, International Telegraph and
Telephone Consultative Committee (CCITT), December, 1982.
[CroD-77]
David H. Crocker, John J. Vittal, Kenneth T. Pogran,
D. Austin Henderson, Jr. Standard for the Format of ARPA
Network Text Messages. RFC 733, The Rand Corporation, Bolt
Beranek and Newman Inc, Massachussets Institute of
Technology, Bolt Beranek and Newman Inc., November, 1977.
[FeiE-79]
[ISOD-79]
ISO/TC97/SC6 Data Communications. Second Draft Proposed
Communication Heading Format Standard. ISO/TC97/SC6 N 1948,
ISO International Organization for Standardization
Organization Internationale de Normalisation, September,
1979. Secretariat: USA (ANSI).
[ISOD-82]
ISO/TC97/SC16. Information Processing Systems - Open Systems
Interconnection - Basic Reference Model. ISO/DIS 7498, ISO
International Organization for Standardization Organization
Internationale de Normalisation, December, 1982.
[NatB-68]
National Bureau of Standards. Calendar Date. Federal
Information Processing Standards Publication 4, U.S.
Department of Commerce / National Bureau of Standards,
November, 1968.
[NatB-75]
National Bureau of Standards. Code Extension Techniques in 7
or 8 Bits. Federal Information Processing Standards
Publication 35, U.S. Department of Commerce / National
Bureau of Standards, June, 1975.
103
[NatB-79a]
National Bureau of Standards. Representations 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.
[NatB-79b]
National Bureau of Standards. Representations 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.
[NatB-80]
National Bureau of Standards. Code for Information
Interchange. Federal Information Processing Standards
Publication 1-1, U.S. Department of Commerce / National
Bureau of Standards, December, 1980.
[PosJ-79]
Jonathan B. Postel. INTERNET MESSAGE PROTOCOL. RFC 753,
Information Sciences Institute, March, 1979.
[TasG-80]
Task Group X3S33 on Data Communications Formats, ANSI
Subcommittee X3S3 on Data Communications. Third Draft
Proposed American National Standard for Heading Format
Structure for Code Independent Communication Headings. ANSI
document X3S37/80-01, Computer and Business Equipment
Manufacturers Association, 1980.
104
ASCII-String 35, 36, 47, 50, 52, 54, 58, 59, 60, 61,
63, 65, 69
Assignment 22, 28, 61
Attachments 23, 57
Author 19, 57
BASIC 18
BASIC Data Elements
ASCII-String 47, 63
Date 50, 65
End-of-Constructor 48, 66
Field 50, 66
Message 51, 67
BASIC fields
Cc 20
Reply-To 19
Subject 23
Text 23
BASIC syntactic elements 35
Bcc 19, 25, 57
Bit numbering in octets 37
Bit-String 36, 42, 47, 49, 50, 52, 64, 65, 69
Boolean 36, 48, 64
Cc 20, 58
Chains of correspondence 29
Circulate-Next 20, 31, 58
Circulate-To 20, 31, 58
Circulation 31
Comment 36, 37, 44, 54
Comments 23, 58
Compliance requirements 41
Compressed 37, 43, 49, 54, 65
Compression identifier 49, 65
Compression Identifiers
Unspecified 54
Constructor data element 35, 36
Contents 38, 76
Cross Referencing 29
Data Element Contents 43, 44, 87, 42, 44, 52, 69, 42,
44, 46, 47, 51, 64, 69, 87
Data Elements
ASCII-String (BASIC) 47, 63
Bit-String (OPTIONAL) 47, 64
105
Compressed (OPTIONAL) 49, 65
Date (BASIC) 50, 65
Encrypted (OPTIONAL) 50, 65
End-of-Constructor (BASIC) 48, 66
Extension (OPTIONAL) 52, 66
Field (BASIC) 50, 66
Integer (OPTIONAL) 48, 67
Message (BASIC) 51, 67
No-Op (OPTIONAL) 49, 67
Padding (OPTIONAL) 49, 68
Property (OPTIONAL) 51, 68
Property-List (OPTIONAL) 51, 68
Sequence (OPTIONAL) 51, 69
Set (OPTIONAL) 52, 69
Unique-ID (OPTIONAL) 52, 69
Vendor-Defined (OPTIONAL) 53, 70
Date 20, 50, 58, 60, 61, 62, 65
Dating 30
Delivery 13, 20, 60
Delivery Protocol 13
Delivery Slot 13
Encapsulating 26
Encrypted 37, 43, 50, 54, 65
Encryption identifier 50, 65
Encryption Identifiers
FIPS-Standard 54
Unspecified 54
End-Date 20, 21, 30, 58, 62
End-Of-Constructor 36, 42, 44, 48, 66
Extension 35, 46, 52, 66
Field 14, 31, 35, 36, 37, 43, 50, 51, 66, 67, 72
Field Identifier 50, 66
Field label presentation 35
Fields
Attachments (OPTIONAL) 57, 23
Author (OPTIONAL) 57, 19
Bcc (OPTIONAL) 57, 19
Cc (BASIC) 58, 20
Circulate-Next (OPTIONAL) 58, 20
Circulate-To (OPTIONAL) 58, 20
Comments (OPTIONAL) 58, 23
Date (OPTIONAL) 58, 20
End-Date (OPTIONAL) 58, 20
From (REQUIRED) 59, 19
In-Reply-To (OPTIONAL) 59, 21
Keywords (OPTIONAL) 59, 23
Message-Class (OPTIONAL) 59, 22
Message-ID (OPTIONAL) 59, 21
106
Originator-Serial-Number (OPTIONAL) 59, 21
Posted-Date (REQUIRED) 60, 20
Precedence (OPTIONAL) 60, 22
Received-Date (OPTIONAL) 60, 20
Received-From (OPTIONAL) 60, 22
References (OPTIONAL) 60, 22
Reissue-Type (OPTIONAL) 61, 22
Reply-To (BASIC) 61, 19
Sender (OPTIONAL) 61, 19
Start-Date (OPTIONAL) 61, 21
Subject (BASIC) 61, 23
Text (BASIC) 61, 23
To (REQUIRED) 61, 19
Warning-Date (OPTIONAL) 62, 21
FIPS-Standard 54, 55
From 17, 19, 29, 57, 59, 61
Globally unique identifiers 29
Identifier octet 38, 41, 37, 38, 42, 44, 76
Identifiers
globally unique 29
In-Reply-To 21, 29, 59
Indefinite length code 41
Integer 36, 48, 52, 67, 69
Keywords 23, 59, 88
Length Code 40, 41, 42, 38, 39, 40, 41, 42, 44, 46,
76, 77, 87
Long length code 41
Message Transfer System 13, 22, 60
Message 14, 17, 35, 36, 37, 43, 51, 67
Message content 13
Message envelope 13
Message stores 30
Message Transfer System 13, 22, 60, 12, 13, 14, 17,
20, 22, 60
Message Types
FIPS-Standard 55
Message-Class 22, 59
Message-ID 21, 22, 29, 31, 59, 60
No-Op 49, 67
Numbering bits in octets 37
Obsoletes 21, 29, 59
Octets
bit numbering in 37
107
Bit-String 47, 64
Boolean 48, 64
Compressed 49, 65
Encrypted 50, 65
Extension 52, 66
Integer 48, 67
No-Op 49, 67
Padding 49, 68
Property 51, 68
Property-List 51, 68
Sequence 51, 69
Set 52, 69
Unique-ID 52, 69
Vendor-Defined 53, 70
OPTIONAL fields
Attachments 23
Author 19
Bcc 19
Circulate-Next 20
Circulate-To 20
Comments 23
Date 20
End-Date 20
In-Reply-To 21
Keywords 23
Message-Class 22
Message-ID 21
Obsoletes 21
Originator-Serial-Number 21
Precedence 22
Received-Date 20
Received-From 22
References 22
Reissue-Type 22
Sender 19
Start-Date 21
Warning-Date 21
OPTIONAL syntactic elements 35
Originator 15, 18, 20, 30, 57, 58, 59, 61
Originator-Serial-Number 21, 30, 59
Padding 49, 68
Person 18
Posted-Date 17, 20, 31, 58, 60
Posting 13
Posting Protocol 13
Posting Slot 13
Precedence 22, 60
Precedence categories 22
108
Presentation
field label 35
Primitive data element 36, 35, 36
Printing-Name 36, 37, 44, 54, 82
Process 18
Properties
Comment 54
Printing-Name 54
Property 38, 43, 51, 68
Property-Identifier 51, 68
Property-List 36, 38, 44, 46, 51, 68, 76
Qualifier 38, 39, 40, 41, 42, 43, 44, 46, 47, 49, 50,
51, 52, 53, 64, 65, 66, 68, 70, 76
Qualifiers 43
Received-Date 20, 60
Received-From 22, 60
Recipient 15, 19, 20, 22, 57, 58, 60, 61
Redistribution 22, 26, 61
References 22, 29, 60
Reissue-Type 22, 61
Reply 18, 28
Reply-to 19, 28, 59, 61
REQUIRED 18
REQUIRED fields
From 19
Posted-Date 20
To 19
Requirements
compliance 41
Role 18
Sender 19, 31, 61
Sequence 35, 36, 51, 69
Sequences 36
Serial Numbers 21, 30, 59
Set 36, 51, 52, 69
Short length code 41
Slot 13
Start-Date 21, 30, 61
Subject 23, 61
Syntactic reissuing 26
Text 23, 32, 61
To 17, 19, 31, 37, 61
Unique identifiers 29
Unique-ID 52, 59, 60, 69
Unspecified 54
109
User interface 35
Vendor-Defined 35, 46, 53, 70
Warning-Date 21, 30, 62
110