RFC 0806
Proposed Federal Information Processing Standard: Specification for message format for computer based message systems
4. SYNTAX
This section begins with an introduction to the concepts and
elements that constitute the syntax for messages. The second
section presents an overview of the encoding scheme. The third
section describes in detail the elements of the message syntax.
4.1 Introduction
This specification defines syntactic requirements for
messages when they are passed from one CBMS to another. The
specification is designed to meet the following goals.
o Provide a concise flexible representation scheme.
o Simplify message parsing.
o Support non-textual components in messages (for example,
3
facsimile, graphics, or speech ).
4.1.1 Message structure
Messages have two classes of components, fields and
messages. A field corresponds to one of the semantic components
defined in this message format specification. A message is
simply another message.
The type of a field in a message determines both its meaning
and the form for its contents. (See Section 4.3.2.)
Fields in a message are composed of syntactic elements
called data elements. A Message data element is used to
represent messages; a Field data element is used to represent
fields. (The term "field" is simply a semantic construct,
distinct from "Field Data Element", which is a syntactic
_______________
3
While this message format specification is not intended to be
used as a basis for the intnge of all facsimile information,
it does recognize that CBMS messages may contain facsimile
components.
construct.) Many of the fields defined in this message format
specification estricted 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
identifiers. 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, although such usage is
encouraged to provide a common user interface.
4.1.2 Data elements
For the purpose of determining compliance with the syntax
defined in this specification, data elements are divided into two
groups, basic and optional.
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. (Semantic compliance is defined in Section 3.1.2.)
This message format specification classifies data element
types as either primitives or constructors. (See Sections
4.1.2.1 and 4.1.2.2.) 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. (See Section
4.3.1.)
4.1.2.1 Primitive data elements
A primitive data element contains a basic item of
information; it is not composed of other data elements. In
current CBMSs, the most commonly used primitive data element is
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. (See Section 4.2.2.1.) Any other use is not
valid syntactically.
4.1.2.2 Constructor data elements
The Data Element Contents of constructor data elements
contain one or more data elements. The most general form of a
constructor is a Sequence or a Set, since both Sequences and Sets
may contain any data element. Other constructors are specialized
forms of 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.
4.1.3 Properties
Any data element may have associated with it a Property-
List, which contains properties such as a Printing-Name (Section
4.1.3.1) or one or more Comments (Section 4.1.3.2). 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.1.3.1 Printing-names
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.
4.1.3.2 Comments
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.
4.1.4 Data compression and encryption
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).
4.1.5 Data sharing
Data sharing is the multiple use of a data element via
references to a single copy. It is used in two situations.
o For economy when a large object appears more than once
in a message. Data sharing may be used in this
situation to economize on storage and transmission
costs.
o For consistency when the same object appears more than
once in a message. If one instance of that object is
altered, all instances must reflect this alteration. In
this case several copies of the same object will not
serve the purpose as well as data sharing.
While there is a demonstrable need for facilities to support
data sharing, this specification does not define such a
mechanism. At this time there is insufficient experience with
data sharing in messages to allow standardization. The
specification is sufficiently flexible however to allow
extensions to the syntax for supporting data sharing at a later
time.
4.2 Overview of Syntax Encoding
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.
o Identifier octet (identifying particular type of data
element)
o Length Code (specifying number of octets that appear
following it in a data element)
o Qualifier (supplying additional identifying information)
o Property-List component (a Property-List data element
containing Property data elements)
o Data Element Contents (containing actual data of the
data element)
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.
4.2.1 Identifier Octets
The identifier octet is a numeric code containing
information 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 seven-bit unique identifier for
the data element. The value of the data element identifier also
indicates whether the data element has a Qualifier. (See Table
2.)
Bit Value Meaning
7 0 The data element does not have properties
associated.
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. TYPE BITS IN THE IDENTIFIER OCTET
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
identification 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. (See
Figure 4.)
Data elements all have a Length Code component immediately
following the identifier octet. (See 4.2.2.1.)
4.2.2 Length code and Qualifier components
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
-----------------------------------------------------------------
bit 7 6 5 4 3 2 1 0
+---------------+
|P 0 x x x x x x| P0xxxxxx uniquely identifies a
+---------------+ data element without a Qualifier.
+---------------+
|P 1 x x x x x x| P1xxxxxx uniquely identifies a
+---------------+ data element with a Qualifier.
FIG. 4. STRUCTURE OF IDENTIFIER OCTETS
-----------------------------------------------------------------
octet in length. When the most significant bit is 1, the other
seven bits of the first octet encode the number of octets in the
rest of the component. The actual value begins in the next octet
and is interpreted as an unsigned integer.
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.
In order to comply with this message format specification,
CBMSs must be able to determine the value of any length code or
qualifier that is expressed in three octets or less. (The
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
representation scheme). However, the use of length codes and
32
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 had indeterminate length; a Qualifier can
specify that a data element is implementation defined. These
cases are explained further in Sections 4.2.2.1 and 4.2.2.2.
-----------------------------------------------------------------
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.
FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH CODES
-----------------------------------------------------------------
4.2.2.1 Length Codes
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
-----------------------------------------------------------------
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
-----------------------------------------------------------------
part of a constructor data element; it may not occur in a
4
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.)
Figure 7 shows the Length Codes for three elements; their
values are 38, 201, and 300.
4.2.2.2 Qualifier
The Qualifier component of a data element 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
_______________
4
This is the result of most primitive elements being able to
contain any bit pattern (including the identifier for End-Of-
Constructor).
-----------------------------------------------------------------
+--------+
|00100110| Length code for 38
+--------+
+--------+--------+
|10000001|11001001| Length code for 201
+--------+--------+
+--------+--------+--------+
|10000010|00000001 00101100| Length code for 300
+--------+--------+--------+
FIG. 7. EXAMPLES OF LENGTH CODES
-----------------------------------------------------------------
code for a field and the Qualifier component would specify what
kind of field.
The Qualifier component appears in only a few data elements.
In the Bit-String data element, it indicates the number of unused
bits in the final octet of the Data Element Contents. In the
Field and Property data elements, it indicates which field or
property the data element represents. In the Compressed and
Encrypted data elements, it indicates which compression or
encryption algorithm has been used. In the Message data element,
it indicates the type of message.
In the sequence of data element components, the Qualifier
occurs between the Length Code and the Property-List components.
The length of the Qualifier component depends on the encoding of
the Qualifier. (See Figure 8.) 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.
This message format specification allows implementations to
define their own values for Qualifiers. A vendor-defined
Qualifier 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.
-----------------------------------------------------------------
+--------+
|00011011| Qualifier with value 28 (decimal).
+--------+
+--------+--------+--------+
|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. 8. EXAMPLES OF QUALIFIER VALUES
-----------------------------------------------------------------
4.2.3 Property-List
A Property is an attribute being associated with 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. (See Section
4.2.1.)
4.2.4 Data Element Contents
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:
o the length of the Qualifier component (depends on the
data element)
o the length of the Property-List component
4.3 Data Element Syntax
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
elements as part of the Data Element Contents of a Field data
element. A summary of the syntactic form appears in Appendix F;
summaries of the data element syntax appear in Appendix G.
4.3.1 Data elements
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), and constructors (Section 4.3.1.2).
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. (See Section 4.2.)
In the diagrams, the contents of the identifier octet is
shown as a "P" followed by an identifier represented in binary.
(See Figure 4.) The identifier itself is a seven bit quantity,
right justified in the identifier octet. Full details on
identifier octets appear in Section 4.2.1.
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.
o "element(s)", which may be any data element(s)
o "anything", which is undefined and may be any
combination of bits
o a specific data element
o the interpretation to be applied to the bits within the
octets that constitute the element (such as ASCII or
Integer)
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.
-----------------------------------------------------------------
Data Element (Compliance) identifier identifier
Name ( Category ) octet octet
16 8
Description of the syntax of the data element.
+---//---+
| | Diagram representing data element
+---//---+
-----------------------------------------------------------------
4.3.1.1 Primitives
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, each character right-justified in one
octet. For seven-bit ASCII characters, the most
significant bit of each octet must be 0.
+--------+---//---+----//-----+
|P0000010|Lxxxxxxx|ASCII chars|
+--------+---//---+----//-----+
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|
+--------+---//---+
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|
+--------+---//---+---//---+
4.3.1.2 Constructors
The data elements in this section are arranged in
alphabetical order.
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].
+--------+---//---+------//------+
|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. (See Section 4.3.4.) The Data Element Contents
is the product of the encryption process.
+--------+---//---+---//---+--------//--------+
|P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
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|
+--------+---//---+---//---+---//---+
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. (See Section 4.3.2.)
+--------+---//---+---//---+---//---+
|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. (See
Section 4.3.6.) (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 another data element.
+--------+---//---+-------//--------+
|P0100100|Lxxxxxxx|Property Elements|
+--------+---//---+-------//--------+
Property (OPTIONAL) 45 105
16 8
This data element uses a Quali data element
component. The Qualifier component contains
a Property-Identifier (PID) to indicate which specific
property is being represented. (See Section 4.3.3.)
+--------+---//---+---//---+---//---+
|P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
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|
+--------+---//---+---//---+
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|
+--------+---//---+---//---+---//---+
4.3.2 Using data elements within message fields
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) nes 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.
4.3.3 Properties and associated elements
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.
4.3.4 Encryption identifiers
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.
NBS-Standard 01 001
16 8
Use of this encryption identifier as part of the
Encrypted data element indicates that the NBS standard
method for data encryption [NatB-77] was used.
4.3.5 Compression identifiers
This message format specification defines two compression
identification codes 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.
NBS-Standard 01 001
16 8
Use of this compression identifier as part of the
Compressed data element is reserved at the present
time. It will be used in the future to indicate that
the NBS standard method for data compression was used
once the data compression standard is defined.
4.3.6 Message types
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.
NBS-Standard 01 01
16 8
This message type marks messages defined by this
message format specification.
SUMMARY OF APPENDIXES
Appendix A Defines the fields in the message format
specification. This alphabetical appendix is for
reference 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
consolidates 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
otional 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.
APPENDIX A
FIELDS -- IMPLEMENTORS' MASTER REFERENCE
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.
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.) 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.) 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.
End-Date OPTIONAL 12 022
16 8
This field contains the date on which a message loses
effect. (See also Section 3.2.5.) 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.
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
Delivery date. This field 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.
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 also Section 3.2.5.) 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.
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 also Section 3.2.5.) This field contains
one or more Dates.
APPENDIX B
DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE
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
+---//---+
-----------------------------------------------------------------
ASCII-String (BASIC) 02 002
16 8
primitive
This data element contains a series of ASCII
characters, each character right-justified in one
octet. For seven-bit ASCII characters, the most
significant bit of each octet must be 0.
+--------+---//---+----//-----+
|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 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
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 Publications 4 [NatB-
68], 59 [NatB-79b], and 58 [NatB-79a].
+--------+---//---+------//------+
|P0101000|Lxxxxxxx| ASCII-String |
+--------+---//---+------//------+
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.) 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
constructor
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|
+--------+---//---+---//---+---//---+
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.)
+--------+---//---+---//---+---//---+
|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.) (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 |
+--------//---------//---------//---------//--------+
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|
+--------+---//---+-------//--------+
(next page on part 3)
