message format specification.
vendor-defined-field
Any field not defined in this message format specifi-
cation or any extension or successor to it is a vendor-
defined field. Names for vendor-defined fields could
be preempted by extensions to this message format
specification.
23
Section 3.1.9
extension-field
Any field that is defined in a document published as a
formal extension or replacement to this message format
specification.
3.2 Message Processing Functions
A CBMS provides three basic classes of functions: creating
messages, transmitting messages to their recipient, and post-
receipt processing. Although the message format specification
does not define the number or nature of user functions in CBMSs,
the meanings for the fields clearly assume certain kinds of
functions. For example, fields specifying recipients of replies
to messages assume some kind of reply function; fields specifying
message life span assume some kind of date processing functions.
This section provides more detail on the processing that
might be done by these kinds of functions, discussing the message
fields that would be used and how they would be used. (See
summary in Table 1.)
Processing Function Fields Involved
Message creation Author, From, Sender, To,
and posting Cc, Bcc
Message reissuing Reissue-Type
Reply generation Reply-To
Cross-referencing Message-ID, In-Reply-To, References,
Obsoletes, Originator-Serial-Number
Life span functions Start-Date, End-Date,
Warning-Date
Recipient processing Circulate-To, Circulate-Next
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS
3.2.1 Message creation and posting
Messages can be created either by reissuing an existing
message to a new recipient (see Section 3.2.2) or by creating a
new message. The process of message creation might mean that
some fields of a new message are filled in from the contents of
some other message. Reply functions (Section 3.2.3) provide an
example of this.
24
Section 3.2.1
Different individuals could be involved in different phases
of originating a message: creating it, taking responsibility for
it, and explicitly interacting with a CBMS to send it to its
recipient. One or more individuals may create a message (that
is, write, but not necessarily enter it into the CBMS); they are
said to be the message's authors, identified by the Author field.
One or more individuals may take responsibility for its contents
and the decision to post it; they are identified by the From
field. One individual explicitly posts a given message; this
person is called the message's sender (identified by the Sender
field).
The sender and author(s) are often, but not always, respon-
sible for the message. A common case in which the sender is not
responsible for the message is when a secretary enters and posts
messages for someone else. An example of a situation in which a
message's author is not responsible for the message itself is
when an administrative assistant prepares a report that is sent
under a manager's signature.
The use of the Cc field is identical to current business
practice. This field contains the formal secondary recipients of
the message.
Messages containing Bcc fields are treated specially by
CBMSs. The contents of this field are not included in copies of
the message sent to the recipients other than the originator who
are not included in the Bcc field itself. Some systems include
the contents of the Bcc field only in the originator's copy;
others include all or part of the Bcc field in the copies sent to
the recipients indicated in the Bcc field. This specification
does not indicate exactly how the Bcc field is to be treated.
3.2.2 Message reissuing and forwarding
Reissuing and forwarding both serve the general user goal of
passing a message on to a new set of recipients. Forwarding is
the term used for an informal mechanism, which CBMSs implement by
copying some or all of the original message into the contents of
a field in the new message. Reissuing is the term used for a
formal mechanism to ensure that the message being passed on never
loses its integrity as a previously sent message. CBMSs use
reissuing to implement several different functions, depending on
the purposes being served:
o Redistribution. Making others aware of the complete and
unaltered contents of the message.
25
Section 3.2.2
o Assignment. Delegating the responsibility for a message
to somebody else.
These purposes are exemplified in Figure 2.
When a CBMS examines a forwarded message, it cannot always
distinguish the old message from what was added when the
forwarding took place. In addition, the forwarded information
might no longer have the form of a message. This is usually
because the format of the message has been changed (for example,
to pure unformatted text). (See Figure 2 for an example of how a
CBMS might forward a message.) In contrast, a reissued message
can always be separated from its enclosing message and never
loses its identity as a correctly formed message.
This specification provides the Reissue-Type field for
supporting reissuing. Forwarding, since it is an informal means
of serving the purpose of passing on information, has no
supporting fields in the specification.
This specification provides for reissuing of messages by
encapsulating. This method embeds the entire original message
inside a new message. Encapsulating adds structure around the
2
message . This allows any part of it to be easily extracted.
This procedure for passing on previously sent messages is a
matter of organizational policy and has authentication as an
associated issue. Each organization must decide if the CBMS it
acquires should support reissuing or simply supply forwarding.
3.2.2.1 Redistribution
Redistribution is a CBMS function for sending the original
contents of a message intact and unchanged to new recipients. A
redistributed message is identical to the original message with
the exception of added information about the reissuing. For
reissuing with this purpose, the Reissue-Type field contains the
ASCII string "Redistribution." The original message has been
included directly in a new message. (See Figure 2.)
_______________
2
A message can contain another message, and that message can
contain another message, and so on to any depth of encapsulating.
This can occur by reissuing a message repeatedly.
26
Section 3.2.2.2
The Original Message
John Doe wishes Jane Jones to get a copy of the following
message:
Message:
Field: From "Jean Smith"
Field: Posted-Date "27 January 1983"
Field: To "John Doe"
Field: Subject "Next Project Meeting"
Field: Text "The agenda for ..."
Redistribution
Message:
Field: From "John Doe" John Doe is responsible
Field: Posted-Date "28 January 1983" for the redistribution.
Field: To "Jane Jones"
Field: Reissue-Type "Redistribution" This message directly
Message: incorporates a
Field: From "Jean Smith" redistributed message.
Field: Posted-Date "27 January 1983"
Field: To "John Doe"
Field: Subject "Next Project Meeting"
Field: Text "The agenda for ..."
Forwarding
Message:
Field: From "John Doe"
Field: Posted-Date "28 January 1983"
Field: To "Jane Jones"
Field: Text A realization of the
"From Jean Smith original message is
To John Doe copied into the Text field.
Sent on 27 January 1983 Note that John's CBMS
Subject Next Project Meeting has chosen to represent
it as a text string.
The agenda for ..."
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION
27
Section 3.2.2.2
3.2.2.2 Assignment
Assignment is the process of designating responsibility. In
some organizations, formal message traffic is distributed to one
or more parts of the organization (called offices) where it is
directed to the appropriate individuals or other offices for
final disposition. Assignment is done by reissuing a message
with the Reissue-Type field containing the ASCII string
"Assigned." A message which contains this field is to be
interpreted as meaning that the addressees in the "To" field have
had the reissued message assigned to them for some action. Any
addressee in the "Cc" field has had the message assigned for
information. The "From" field records who assigned the message
and the "Posted-Date" field records when the message was
assigned.
3.2.3 Reply generation
Reply generation involves creating a new message in direct
reply to some other message by drawing on the contents of fields
in the other message to fill fields in the new message. Many
CBMSs provide reply facilities that determine the intended recip-
ients of a reply.
A Reply-To field is defined by this message format specifi-
cation. When a message contains a Reply-To field, the CBMS
should send replies to the recipients designated in the Reply-To
field instead of to the recipients designated in the From field.
This statement applies to original messages only, not to reissued
messages. The message format specification makes no
recommendations concerning replies to reissued messages.
Reply-To has several possible applications:
o The individual(s) responsible for the message might not
have regular access to a CBMS and would indicate an
alternate recipient, for example, a secretary.
o The people responsible for receiving responses might not
be the people who were responsible for creating the
message.
o Discussion and conference groups could use this feature
to ensure correct distribution of any submission by
having the conference group itself designated in the
Reply-To field.
28
Section 3.2.3
When the message does not contain a Reply-To field, the
recipient should reply to the originators enumerated in the From
field. The sender and authors should not be added automatically
to the list of those receiving the reply.
Replies could also be sent to the other recipients of the
original message. Vendors might offer additional reply facil-
ities, depending on their view of users' organizational require-
ments.
3.2.4 Cross-referencing
A CBMS message may include designator(s) which identify
other message(s). The designators are used to refer to related
messages so that all information in a chain of correspondence can
be determined by a CBMS user. The designator used to identify
and cross-reference messages can take either of two forms, unique
identifiers or serial numbers.
3.2.4.1 Unique identifiers
Unique identifiers are machine-generated and are intended
primarily for processing by computers. While they could be
examined by a human user, unique identifiers are not necessarily
useful or convenient for people.
Unique identifiers occur in several contexts. They are
often used to identify the contents of idual messages
unambiguously. When unique identifiers are used this way, they
are called message identifiers. Different versions of a message
receive new message identifiers; an example of this is reissuing
a message with comments.
When a CBMS generates a message identifier, it must be able
to guarantee that it is unique, both within the domain of the
individual CBMS and globally, across all connected CBMSs. CBMSs
could generate globally unique identifiers in several ways, all
of which require prior agreement on behalf of the connected
CBMSs. One method is to assign each connected CBMS a unique
code. A CBMS then generates unique identifiers by using its code
as a prefix to some other value that it can guarantee to be
unique within its domain. (This second value could be a counter
or a timestamp/user-id combination.)
A CBMS can provide functions for tracing chains of corre-
spondence by using unique identifiers. The message format
specification defines fields for which a CBMS provides unique
identifiers as values. They are Message-ID, References,
Obsoletes, and In-Reply-To. (See Section 3.1.6.)
29
Section 3.2.4.1
3.2.4.2 Serial numbering
Serial numbers are for users to maintain a personal num-
bering system for messages. The numbers are composed of both
letters and digits so that users could maintain several sets of
sequences concurrently (for example, A1, A2, A3... and B1, B2,
B3...).
Serial numbers are assigned at a defined point in the
history of a message. Serial numbers are not unique identifiers;
they differ from unique identifiers in that they are not neces-
sarily generated or processed by a CBMS. They are designed to be
entered and read by CBMS users. They can be as simple or complex
as the user requires. Serial numbers are intended to be used to
designate messages about a specific topic, or messages a given
user has sent. Serial numbers are intended to be a permanent
part of the message, just as unique identifiers are.
A CBMS can provide functions allowing originators to add
serial numbers to messages. Originator-Serial-Number is the
field provided for an originator to add a serial number to a
message before sending it.
3.2.5 Life span functions
Messages have life spans, usually delimited by the creation
date and the time when the last copy of the message is destroyed.
Messages could be meaningless before a certain time or irrelevant
after a certain time. For example, a reminder to attend a
meeting on 5 June loses most of its value on the sixth; a
reminder to attend that same meeting may be of little use on 5
May (although not for the same reason).
A CBMS can define a message's life span explicitly using the
Start-Date and End-Date fields. A third field, Warning-Date,
when used in conjunction with the End-Date, may be used to signal
the approach of the End-Date. Warning-Date may also stand alone
and be used by a periodic warning (alarm clock) mechanism.
A CBMS could use these fields to help users manage their
message stores. For example, a message whose start date has not
yet passed could be bypassed by a retrieval command unless the
user requested such messages explicitly. A CBMS could use the
end date to help with message store housekeeping either by
archiving or deleting the expired messages automatically or by
asking the user for some action to be taken on them. The warning
date could be used to remind the user automatically of an
impending end date, such as a meeting reminder.
30
Section 3.2.6
3.2.6 Requests for recipient processing
Recipients have a wide variety of needs for examining and
processing a message, ranging from automatic output on some
specified device to the execution of a program embedded in the
message itself. Because many of these needs are highly
specialized, and support for them not widely implemented, this
message format specification does not constrain the requests for
processing that may be included in a message.
The message format specification does provide two fields
that permit an originator to request circulation list processing
from the recipient. These fields are Circulate-To and Circulate-
Next.
3.2.6.1 Message circulation
Message circulation involves serial distribution of a mes-
sage to its recipients, based on a distribution list that is part
of the message. The message is delivered first to the first
recipient on the distribution list. This recipient, or someone
the recipient delegates, sends the message on to the second
recipient on the list, perhaps after commenting on or adding to
the message. This continues until all recipients on the
distribution list have received the message.
This message format specification provides two fields to
support message circulation. The Circulate-To field contains the
complete distribution list, indicating the full set of recip-
ients, and the Circulate-Next field indicates which recipients
have not seen the message. See Figure 3 for an example of
message circulation using these two fields.
3.3 Multiple Occurrences and Ordering of Fields
Most message fields may occur more than once in a message;
the exceptions are the Posted-Date, Sender, and Message-ID
fields, which may occur once, at most. What this means is that a
received message may contain any number of instances of a
particular field (such as the "To" field). If a message contains
more than one instance of a particular field, that field "occurs
multiply" and that message has "multiple occurrences" of that
field.
A particular instance of a message field is not superseded
by later instances of the same field. The To field is an example
of this.
31
Section 3.3
-----------------------------------------------------------------
A message originator wishes to circulate a message to
recipients A, B and C. The originator includes the
following fields in the message:
To: A
Circulate-To: A, B, C
Circulate-Next: B, C
When recipient A or someone A delegates causes the
message to be further circulated, the message is sent
to the first address in the Circulate-Next field, and
that name is removed from that field:
To: B
Circulate-To: A, B, C
Circulate-Next: C
B now sends the message on to its final recipient:
To: C
Circulate-To: A, B, C
FIG. 3. EXAMPLE OF MESSAGE CIRCULATION
-----------------------------------------------------------------
Multiple occurrences of a field are not necessarily equiv-
alent to a single field containing the concatenated contents of
the several instances of the given field. For example, with the
Text field, concatenating the contents of several instances might
lose important distinctions between the contents. A single
message could be used to send three different documents, each one
in a different Text field. However, putting the three documents
into a single Text field would make it much more difficult to
extract any individual document.
Encapsulated messages are exceptions to the multiple
occurrences rule. For example, the To field in an encapsulated
message is not a multiple occurrence of the To field in the
enclosing message.
The fields found in a single message may occur in any order.
The order in which they occur does not necessarily reflect the
32
Section 3.3
order in which they were created. Nor does it constrain the
order in which the message recipient examines, processes, or
displays them.
33
Section 4
4. SYNTAX
This section begins with an introduction to the concepts and
elements that constitute the syntax for messages. The second
section presents an overview of the encoding scheme. The third
section describes in detail the elements of the message syntax.
4.1 Introduction
This specification defines syntactic requirements for mes-
sages when they are passed from one CBMS to another. The
specification is designed to meet the following goals.
o Provide a concise, flexible representation scheme.
o Simplify message parsing.
o Support non-textual components in messages (for example,
3
facsimile, graphics, or speech ).
4.1.1 Message structure
Messages have two classes of components, fields and
messages. A field corresponds to one of the semantic components
defined in this message format specification. A message is
simply another message.
The type of a field in a message determines both its meaning
and the form for its contents. (See Section 4.3.2.)
Fields in a message are composed of syntactic elements
called data elements. A Message data element is used to
represent messages; a Field data element is used to represent
fields. (The term "field" is simply a semantic construct,
distinct from "Field Data Element," which is a syntactic
_______________
3
While this message format specification is not intended to be
used as a basis for the interchange of all facsimile information,
it does recognize that CBMS messages may contain facsimile
components.
34
Section 4.1.1
construct.) Many of the fields defined in this message format
specification are restricted to containing only one kind of data
element. (See Section 4.3.2.)
Each field defined in this message format specification has
been assigned a unique numeric identifier that is used in
conjunction with the Field data element. Separate identifiers
are provided for vendor-defined fields and for extending the
identifier encoding space. A list of fields and identifiers
appears in Section 4.3.2 and in Appendix C.
Throughout the message format specification, fields are
referred to by label name rather than by their numeric identi-
fiers. Field labels are names like "Sender," "Warning-Date," or
"Circulate-To." The field labels chosen for the specification
are names that are in common use in current CBMSs. The
specification does not require a CBMS to use these field labels
in displaying fields to the user.
4.1.2 Data elements
For the purpose of determining compliance with the syntax
defined in this specification, data elements are divided into two
groups:
BASIC All message receiving systems must process these
syntactic elements, interpreting their values according
to the message format specification.
OPTIONAL Message receiving systems need not process these
syntactic elements in order to be in compliance.
In addition, complying CBMSs must meet requirements
regarding their ability to process the components found inside
data elements. These requirements are discussed in Section
4.2.2.
This message format specification classifies data element
types as either primitives or constructors. Primitive data
elements, such as ASCII-String, are basic building blocks.
Constructor data elements, such as Message or Sequence, contain
one or more primitive or constructor data elements. Some
constructors, such as Sequence, may be composed of any other data
element. Some, such as Message, may contain only certain data
elements. Two data elements, Extension and Vendor-Defined, may be
classified as either primitives or constructors, depending on how
they are used to extend this specification. The general
syntactic form for data elements is discussed in section 4.3.1.
35
Section 4.1.2
4.1.2.1 Primitive data elements
A primitive data element contains a basic item of
information; it is not composed of other data elements. In
current CBMSs, the most commonly used primitive data element is
4
ASCII-String, a series of ASCII characters. Other primitive data
elements are Integer, 2's complement integers; Bit-String, a
series of bits; and Boolean, either True or False.
One primitive data element, End-Of-Constructor, is used only
as a structural element within constructor data elements and has
no meaning by itself. End-of-Constructor is used to provide an
end marker for constructor data elements that do not have an
explicit length; any other use is not valid syntactically.
4.1.2.2 Constructor data elements
The Data Element Contents of constructor data elements
contain one or more data elements. The most general form of a
constructor is a Sequence or a Set, since both Sequences and Sets
may contain any data element. Other constructors are specialized
forms of 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 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
Section 4.1.3.1
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.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)
37
Section 4.2
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 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
Section 4.2.1
-----------------------------------------------------------------
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
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
39
Section 4.2.2
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.
-----------------------------------------------------------------
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
Section 4.2.2
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 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.
4.2.2.1 Length Codes
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
Section 4.2.2.1
-----------------------------------------------------------------
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.)
4.2.2.2 Qualifier
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
Section 4.2.2.2
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.
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
Section 4.2.3
4.2.3 Property-List
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.
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
44
Section 4.3
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), 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
Section 4.3.1
shown as a "P" followed by an identifier represented in binary.
(See Figure 4.)
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 combi-
nation 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.
46
Section 4.3.1
-----------------------------------------------------------------
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 [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
Section 4.3.1.1
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
Section 4.3.1.1
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 alpha-
betical order.
49
Section 4.3.1.2
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
Section 4.3.1.2
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
Section 4.3.1.2
Sequence (OPTIONAL) 0A 012