summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc806.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc806.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc806.txt')
-rw-r--r--doc/rfc/rfc806.txt6239
1 files changed, 6239 insertions, 0 deletions
diff --git a/doc/rfc/rfc806.txt b/doc/rfc/rfc806.txt
new file mode 100644
index 0000000..34ed2b5
--- /dev/null
+++ b/doc/rfc/rfc806.txt
@@ -0,0 +1,6239 @@
+Network Working Group
+Request for Comments: 806
+
+
+
+
+
+ Proposed Federal Information Processing Standard
+
+
+
+
+ SPECIFICATION FOR MESSAGE FORMAT FOR
+ COMPUTER BASED MESSAGE SYSTEMS
+
+
+
+
+ National Bureau of Standards
+ Institute for Computer Sciences and Technology
+
+
+
+
+
+
+
+ September 1981
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ TABLE OF CONTENTS
+
+
+
+
+ Page
+
+
+
+ EXECUTIVE SUMMARY 1
+
+
+
+ 1. INTRODUCTION 3
+
+
+ 1.1 Guide to Reading This Document 3
+ 1.2 Vendor-Defined Extensions to the Specification 4
+ 1.3 The Scope of the Message Format Specification 4
+ 1.4 Issues Not Within the Scope of the Message Format 4
+ Specification
+ 1.5 Relationship to Other Efforts 5
+
+
+
+ 2. A SIMPLE MODEL OF A CBMS ENVIRONMENT 6
+
+
+ 2.1 Logical Model of a CBMS 8
+ 2.2 Relationship to the ISO Reference Model for Open 10
+ Systems Interconnection
+ 2.3 Messages and Fields 10
+ 2.4 Message Originators and Recipients 11
+
+
+
+ 3. SEMANTICS 12
+
+
+ 3.1 Semantics of Message Fields 12
+ 3.1.1 Types of fields 12
+ 3.1.2 Semantic Compliance Categories 13
+ 3.1.3 Originator fields 13
+ 3.1.4 Recipient fields 14
+ 3.1.5 Date fields 15
+ 3.1.6 Cross-reference fields 16
+ 3.1.7 Message-handling fields 16
+ 3.1.8 Message-content fields 17
+ 3.1.9 Extensions 18
+
+
+
+
+ i
+
+
+
+
+ 3.2 Message Processing Functions 18
+ 3.2.1 Message creation and posting 19
+ 3.2.2 Message reissuing and forwarding 20
+ 3.2.2.1 Redistribution 22
+ 3.2.2.2 Assignment 22
+ 3.2.3 Reply generation 23
+ 3.2.4 Cross referencing 24
+ 3.2.4.1 Unique identifiers 24
+ 3.2.4.2 Serial numbering 24
+ 3.2.5 Life span functions 25
+ 3.2.6 Requests for recipient processing 25
+ 3.2.6.1 Message circulation 26
+ 3.3 Multiple Occurrences and Ordering of Fields 26
+
+
+
+ 4. SYNTAX 28
+
+
+ 4.1 Introduction 28
+ 4.1.1 Message structure 28
+ 4.1.2 Data elements 29
+ 4.1.2.1 Primitive data elements 30
+ 4.1.2.2 Constructor data elements 30
+ 4.1.3 Properties 30
+ 4.1.3.1 Printing-names 30
+ 4.1.3.2 Comments 31
+ 4.1.4 Data compression and encryption 31
+ 4.1.5 Data sharing 31
+ 4.2 Overview of Syntax Encoding 32
+ 4.2.1 Identifier Octets 32
+ 4.2.2 Length code and Qualifier components 33
+ 4.2.2.1 Length Codes 35
+ 4.2.2.2 Qualifier 36
+ 4.2.3 Property-List 38
+ 4.2.4 Data Element Contents 38
+ 4.3 Data Element Syntax 39
+ 4.3.1 Data elements 39
+ 4.3.1.1 Primitives 42
+ 4.3.1.2 Constructors 44
+ 4.3.2 Using data elements within message fields 48
+ 4.3.3 Properties and associated elements 49
+ 4.3.4 Encryption identifiers 49
+ 4.3.5 Compression identifiers 49
+ 4.3.6 Message types 50
+
+
+
+ SUMMARY OF APPENDIXES 51
+
+
+
+ ii
+
+
+
+
+
+ APPENDIX A. FIELDS -- IMPLEMENTORS' MASTER REFERENCE 52
+
+
+
+ APPENDIX B. DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE 57
+
+
+
+ APPENDIX C. DATA ELEMENT IDENTIFIER OCTETS 65
+
+
+
+ APPENDIX D. SUMMARY OF MESSAGE FIELDS BY COMPLIANCE 66
+ CATEGORY
+
+
+ D.1 REQUIRED Fields 66
+ D.2 BASIC Fields 66
+ D.3 OPTIONAL Fields 66
+
+
+
+ APPENDIX E. SUMMARY OF MESSAGE SEMANTICS BY FUNCTION 68
+
+
+ E.1 Circulation 68
+ E.2 Cross Referencing 68
+ E.3 Life spans 68
+ E.4 Delivery System 68
+ E.5 Miscellaneous Fields Used Generally 69
+ E.6 Reply Generation 69
+ E.7 Reissuing 69
+ E.8 Sending (Normal Transmission) 69
+
+
+
+ APPENDIX F. SUMMARY OF DATA ELEMENT SYNTAX 70
+
+
+
+ APPENDIX G. SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY 72
+
+
+ G.1 BASIC Data Elements 72
+ G.2 OPTIONAL Data Elements 72
+
+
+
+ APPENDIX H. EXAMPLES 74
+
+
+
+
+ iii
+
+
+
+
+
+ H.1 Primitive Data Elements 74
+ H.2 Constructor Data Elements 76
+ H.3 Fields 81
+ H.4 Messages 84
+ H.5 Unknown Lengths 88
+
+
+
+ REFERENCES 92
+
+
+
+ INDEX 94
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ iv
+
+
+
+
+
+ LIST OF FIGURES
+
+
+
+
+ FIG. 1. LOGICAL MODEL OF A COMPUTER BASED MESSAGE SYSTEM 8
+ FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION 21
+ FIG. 3. EXAMPLE OF MESSAGE CIRCULATION 27
+ FIG. 4. STRUCTURE OF IDENTIFIER OCTETS 34
+ FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH 35
+ CODES
+ FIG. 6. REPRESENTATION OF LENGTH CODES 36
+ FIG. 7. EXAMPLES OF LENGTH CODES 37
+ FIG. 8. EXAMPLES OF QUALIFIER VALUES 38
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ v
+
+
+
+
+ LIST OF TABLES
+
+
+
+
+ TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS 19
+ TABLE 2. TYPE BITS IN THE IDENTIFIER OCTET 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ vi
+
+ Executive Summary
+
+
+ EXECUTIVE SUMMARY
+
+
+
+
+ The message format specification addresses the problem of
+ exchanging messages between different computer-based message
+ systems (CBMSs). This interchange problem can be addressed on
+ several levels. One level specifies the physical
+ interconnections, another specifies how information travels
+ between CBMSs, another specifies form and meaning of messages
+ being interchanged. The highest level specifies operations on a
+ message. Each of these levels would be covered by a different
+ standard.
+
+ This message format specification addresses only the issues
+ of form and meaning of messages at the points in time when they
+ are sent from one CBMS and received by another. Messages are
+ composed of fields, containing different classes of information.
+ These fields contain information about the message originator,
+ message recipient, subject matter, precedence and security, and
+ references to previous messages, as well as the text of the
+ message. Standard formats (syntax) for messages ensure that the
+ contents of messages generated by one CBMS can be processed by
+ another CBMS. Standard meanings (sematics) for the components of
+ a message ensure standard interpretation of a message, so that
+ everyone receiving a message gets the meaning intended by its
+ sender.
+
+ Each CBMS that implements this message format specification
+ will be compatible with any other CBMS that implements the
+ specification. Compatibility ensures that the contents of a
+ message posted by one CBMS can be received and interpreted by a
+ different CBMS.
+
+ This message format specification has been developed as a
+ result of examining CBMSs currently in use in commercial and
+ research environments. Three major design perspectives helped
+ shape the message format specification.
+
+
+ o Viability. The message format specification uses
+ concepts that already work. It has been designed with
+ implementation concerns in mind.
+
+ o Compatibility. The message format specification
+ contains concepts from existing CBMSs. For this reason,
+ many CBMS would already contain functions and components
+ similar to those required to implement the message
+ format specification.
+
+
+
+ 1
+
+ Executive Summary
+
+
+
+ o Extensibility. This message format specification
+ defines a broad range of message content components and
+ requires only an elementary subset of them. This means
+ that even a very simple CBMS can implement the message
+ format specification. The message format specification
+ contains a rich set of optional components and, in
+ addition, mechanisms for user extensions and future
+ extensions to the message format specification.
+
+
+ The message format specification defines the form and
+ meaning of message contents and their components as they pass
+ from one CBMS to another through a message transfer system. The
+ message format specification does not address any of the
+ following major issues.
+
+
+ o Functions or services provided to a user by a CBMS.
+ For example, the message format specification
+ assumes that every CBMS allows a user to send and
+ receive messages. It does not specify any of the
+ details of how a send function or a message-reading
+ function might work or how it might appear to the
+ user. That is, the message format specification
+ neither limits nor mandates functions.
+
+ o Storage or format of message contents in a CBMS.
+ The message format specification defines the form
+ and contents of messages when they are transferred
+ between systems. A CBMS may or may not choose to
+ use the same format for internal storage.
+
+ o Message transfer system protocols.
+ The message format specification does not specify
+ how a message travels between CBMSs. It does
+ specify the form of its contents as it leaves and
+ arrives, assuming only that the message is moved
+ transparently by the transfer system.
+
+ o Message envelopes.
+ While a message is traveling between CBMSs, it is
+ enclosed in a message envelope. Message envelopes
+ contain all the information about a message that a
+ message transfer system needs to know. The message
+ format specification does not define the format or
+ content of a message envelope.
+
+ o How message originators and recipients are identified.
+ The message format specification does not provide a
+ representation scheme for the names or addresses of
+ message originators and recipients as they are
+ known to a CBMS.
+
+ 2
+
+ Section 1
+
+
+
+ 1. INTRODUCTION
+
+
+ A computer-based message system (CBMS) allows communication
+ between "entities" (usually people) using computers. Computers
+ serve both to mediate the actual communications between systems
+ and to provide users with facilities for creating and reading the
+ messages.
+
+ CBMSs have been developing for over ten years. More
+ recently, CBMSs have been one of the bases in industry for the
+ introduction of office automation. A growing number of
+ organizations use either their own or a commercially available
+ CBMS. The design and complexity of these systems vary widely.
+ This message format specification provides a basis for
+ interaction between different CBMSs by defining the format of
+ messages passed between them.
+
+
+
+ 1.1 Guide to Reading This Document
+
+
+ The method of presenting the material in this specification
+ is to combine the technical specification with tutorial
+ information. This approach has been taken to place the
+ specification in context and improve its readability.
+
+ The core of the technical information in the document is in
+ Section 2 "A Simple Model of a CBMS Environment", Section 3.1
+ "Semantics of Message Fields", Section 4.2 "Overview of Syntax
+ Encoding", and Section 4.3 "Data Element Syntax". Appendixes A
+ and B consolidate the technical informations. These appendices
+ are designed for ease of reference and should be read in
+ conjunction with the body of the report for a complete
+ understanding of the message format presented in the
+ specification.
+
+ Section 2 presents a simple model of operation of a CBMS.
+ Section 3 discusses the components of messages and their meaning
+ (semantics). This includes discussions of the recommended
+ relationship between message components and CBMS user functions.
+ (See Section 3.2.) Section 4 presents details of the form
+ (syntax) required for components of a message.
+
+ Appendix D summarizes the components of messages according
+ to whether they are required or optional for CBMSs implementing
+ the message format specification. Appendix E organizes the
+ message components according to the functional class of the
+ components. Appendix F provides an overview of the syntactic
+ elements defined by this message format specification; Appendix G
+
+
+ 3
+
+ Section 1.1
+
+
+
+ summarizes those elements according to whether they are required
+ or optional for a CBMS implementing the message format
+ specification. Examples of each syntactic element appear in
+ Appendix H, displaying syntax and describing the associated
+ semantics.
+
+
+
+ 1.2 Vendor-Defined Extensions to the Specification
+
+
+ This specification provides the capability of extending the
+ range of functionality by the use of vendor-defined qualifiers
+ and vendor-defined data elements. Any vendor who uses this
+ capability to provide services which are essentially equivalent
+ to those already designated as required, basic, or optional does
+ not comply with the specification.
+
+
+
+ 1.3 The Scope of the Message Format Specification
+
+
+ The purpose of this message format specification is to
+ present the semantics and syntax to be used for messages being
+ exchanged between CBMSs. Specifically, it defines the following.
+
+
+ o The meaning and form of standard fields to be used in
+ messages.
+
+ o Which fields must be present in all messages.
+
+ o Which fields complying CBMSs must be able to process.
+
+ o How messages, fields, and the data contained in fields
+ are represented.
+
+
+
+ 1.4 Issues Not Within the Scope of the Message Format
+ Specification
+
+
+ The message format specification does not address the
+ following issues, some of which are being covered by other NBS
+ standards developments. (See [BlaR-80] for a description of the
+ NBS protocols program.)
+
+
+ o The nature of a message transfer system, except to state
+ the assumption that it transfers messages transparently.
+
+ 4
+
+ Section 1.4
+
+
+
+ o The form or nature of the protocols used to transfer
+ messages (posting, relay, and delivery protocols).
+
+ o The content and representation of message envelopes.
+
+ o Representations for unique identifiers (in particular,
+ message identifiers).
+
+ o Network and internetwork addressing.
+
+ o Representations for identities of message originators
+ and recipients.
+
+ o Functions that CBMSs provide for users.
+
+ o Presentation of messages to users.
+
+ o Representations for multi-media objects.
+
+ o Data representation for messages within CBMSs.
+
+ o Data sharing or any storage management within CBMSs.
+
+ o Representations for fixed or floating point numbers.
+
+
+
+
+ 1.5 Relationship to Other Efforts
+
+
+ The message format specification is based on several
+ documents and the current state of many CBMSs available both in
+ industry and the research community. These documents include the
+ standardization efforts in the ARPANet [CroD-77, PosJ-79] and the
+ CCITT, proposed ISO and ANSI header format standards [TasG-
+ 80, ISOD-79], the work of IFIPS Working Group 6.5, and various
+ papers about the general nature of mail systems, addressing, and
+ mail delivery. (See [FeiE-79] for references.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 5
+
+ Section 2
+
+
+
+ 2. A SIMPLE MODEL OF A CBMS ENVIRONMENT
+
+
+ In order to provide a framework for presenting the message
+ format specification, this section describes a simple functional
+ model for a CBMS. The model provides a high-level description of
+ both user facilities and system architecture. Discussions of
+ messages, message originators and message recipients serve to
+ further clarify the nature of a CBMS.
+
+ A CBMS permits the transfer of a message from an originator
+ to a recipient. "Originator" and "recipient" are used in their
+ normal English senses. (See Section 2.4.) A message (in its
+ most abstract definition) is simply a unit of communication from
+ an originator to a recipient. A CBMS offers several classes of
+ functions to its users:
+
+
+ o Message Creation: The facilities used by a message
+ originator to create messages and specify to whom they
+ are to be sent.
+
+ o Message Transfer: The facilities used to convey a
+ message to its recipient(s).
+
+ o Recipient Processing: The facilities used by a message
+ recipient to process messages that have arrived.
+
+
+ These classes of functions are presented in more detail in
+ Section 3.2.
+
+ CBMSs differ from other office automation/communications
+ systems in a number of ways.
+
+
+ o Unlike other types of electronic communications, CBMS
+ messages are sent to particular individuals, not to
+ stations or telephone sets. If a recipient moves to a
+ different location, messages sent to that recipient are
+ delivered to the recipient at the new location.
+
+ o Transmission of CBMS messages is asynchronous. The
+ recipient's system need not be available when the
+ message leaves the originator's system. That is, CBMS
+ message transfer facilities are store-and-forward.
+
+ o CBMS messages can contain a wide variety of data. They
+ are not constrained to any single kind of communication.
+ CBMS messages are often simple memoranda but are not
+ restricted to text. A CBMS message may contain any kind
+
+
+ 6
+
+ Section 2
+
+
+
+ of data that an originator wishes to send to a
+ recipient. By contrast, Teletex systems and
+ communicating word processors handle the transfer of
+ final form documents; compatible communicating word
+ processors can exchange documents in editable form;
+ Telex and TWX deal in unformatted text.
+
+ o CBMSs offer message creation facilities as an important
+ part of the system. CBMSs assist users in the
+ preparation of messages by having text editing
+ facilities available and allowing users to include data
+ stored on-line in messages. Some CBMSs also interface
+ to other office automation facilities, such as
+ formatters and spelling correctors. This is not true of
+ Telex, TWX, or similar services.
+
+ o CBMSs offer recipient processing facilities as an
+ important part of the system. This is not true of most
+ other forms of electronic communications. For example,
+ Telex and TWX systems simply print messages on paper
+ when they are received, without retaining a copy in the
+ system. (Teletex systems are similar to Telex systems,
+ but some can retain a copy of the document in local
+ storage.) Communicating word processors might notify
+ their operators that a document has been received and is
+ stored on-line, but offer little in the way of other
+ recipient processing facilities. Most CBMSs offer at
+ least the following recipient processing facilities.
+
+
+ . The ability to retain a copy of a message on-line
+ after it has been read.
+
+ . The ability to examine or delete stored messages
+ individually.
+
+ . The ability to organize messages using some form of
+ electronic "file folder".
+
+ . The ability to determine if a message is recent
+ (has arrived since the last time the recipient used
+ the CBMS) or unseen (has never been examined by the
+ recipient).
+
+ . The ability to summarize stored messages. A
+ summary usually includes information such as
+ whether the message is recent or unseen, when it
+ was received, its length, who it is from, and its
+ subject.
+
+ . The ability to retrieve a stored message based upon
+
+
+ 7
+
+ Section 2
+
+
+
+ one or more of its attributes (for example, when
+ the message was received, whether or not it has
+ been seen or deleted, and the values contained in
+ its fields).
+
+ . A forward facility that allows users to include all
+ or part of a message in a new outgoing message.
+
+ . A reply facility that allows users to answer
+ messages without having to enter a new list of
+ recipients.
+
+
+
+ 2.1 Logical Model of a CBMS
+
+
+ CBMS facilities for message creation, transfer, and
+ recipient processing are reflected in a logical model of a CBMS
+ developed by IFIP Working Group 6.5 [SchP-79]. (An essentially
+ identical model is being used by CCITT Study Group VII, Question
+ 5, regarding Message Handling Facilities.) The model consists of
+ a Message Transfer System and a number of User Agents. (See
+ Figure 1.)
+
+
+
+ | |
+ | ************* |
+ ********* ------> * Message * -------> *********
+ * User * Posting * Transfer * Delivery * User *
+ * Agent * Protocol * System * Protocol * Agent *
+ ********* <------- ************* <------- *********
+ | |
+ | |
+ Posting Delivery
+ Slot Slot
+
+ Message Flow
+ Originator --------------------------------> Recipient
+
+
+
+ FIG. 1. LOGICAL MODEL OF A COMPUTER BASED MESSAGE SYSTEM
+
+
+ A User Agent is a functional entity that acts on behalf of a
+ user, assisting with creating and processing messages and
+ communicating with the Message Transfer System.
+
+ The Message Transfer System] is an entity that accepts a
+
+
+ 8
+
+ Section 2.1
+
+
+
+ message from its originator's User Agent and ultimately passes it
+ to each of its recipients' User Agents. The Message Transfer
+ System may perform routing and storage functions (among others)
+ in order to accomplish its task.
+
+ Transferring a message from an originator's User Agent to
+ the Message Transfer System is called Posting; the originator's
+ User Agent and Message Transfer System engage in a Posting
+ Protocol in order to accomplish Posting. Transferring a message
+ from the Message Transfer System to a recipient's User Agent is
+ called Delivery; the recipient's User Agent and Message Transfer
+ System engage in a Delivery Protocol in order to accomplish
+ Delivery.
+
+ The point at which responsibility for a message is
+ transferred is called a Slot. The Posting Slot is the point at
+ which responsibility for a message passes from an originator's
+ User Agent to the Message Transfer System; the Delivery Slot is
+ the point at which responsibility for a message passes from the
+ Message Transfer System to a recipient's User Agent.
+
+ The model divides messages into two parts, the message
+ content and the message envelope. The message content is the
+ information that the originator wishes to send to the recipient;
+ this message format specification deals solely with the message
+ content. The message envelope consists of all the information
+ necessary for the Message Transfer System to do its job; this
+ message format specification does not specify the message
+ envelope. Some of the data appearing on the message envelope
+ could be redundant with some data found in the message content.
+ The Message Transfer System is not expected to examine the
+ message content unless it is told to do so by the originator's or
+ recipient's User Agent.
+
+ This message format specification places no restrictions on
+ the Message Transfer System itself, except that it be transparent
+ to the contents of messages. In addition, this message format
+ specification does not dictate the form or nature of any protocol
+ used by the Message Transfer System. Finally, this message
+ format specification does not specify the content or form of the
+ message envelope. That is, the message format specification
+ defines the format for the contents of messages, not the manner
+ in which they are transmitted.
+
+ Many of today's commercially available CBMSs incorporate all
+ of the facilities represented in the logical model. Their
+ architectures may reflect the economies that can be taken when
+ implementing systems that are self-contained. For example,
+ stand-alone systems that store messages in a single central
+ database require no Message Transfer System; an implementation
+ may integrate software for User Agent and Message Transfer System
+ functions, doing away with Posting or Delivery Protocols.
+
+ 9
+
+ Section 2.1
+
+
+
+ 2.2 Relationship to the ISO Reference Model for Open Systems
+ Interconnection
+
+
+ Subcommittee TC97/SC16 of the International Standards
+ Organization (ISO) has developed a reference model for describing
+ communications between "open" systems [ISOD-81]. This model is
+ known as the ISO Reference Model for Open Systems Interconnection
+ (OSI). It divides communications protocols into seven layers,
+ ranging from physical interconnection at the lowest layer to data
+ exchange by application programs at the top.
+
+ This message format specification deals with data used by an
+ application within a system. Thus, the message format being
+ specified here is not a protocol. Since it is not a protocol, it
+ lies outside of the model for open systems interconnection. User
+ Agents are application layer entities (layer 7), however, and the
+ protocols used by a message transfer system are above the session
+ layer (layer 5).
+
+
+
+ 2.3 Messages and Fields
+
+
+ A message is a unit of communication from an originator to a
+ recipient. A message consists of a series of components called
+ fields. Fields can be described according to their meaning in a
+ message (semantics) and according to the format required for them
+ in a message (syntax).
+
+ Semantically, a field is just a component of a message; the
+ meanings of particular fields are defined by this message format
+ specification. Syntactically, a field is a unit of data whose
+ form is defined by this message format specification. Additional
+ fields can be defined by users or vendors as long as they conform
+ to the syntactic and semantic rules that this message format
+ specification defines for additional fields.
+
+ (A note on terminology: A message consists of components
+ called fields. The words "message" and "field" are used both in
+ the informal sense of the previous sentence and in a more
+ restricted sense as names of particular syntactic elements. As
+ syntactic element names, Message and Field are always
+ capitalized.)
+
+ Some CBMS functions are based on the contents of particular
+ fields; other functions (such as the ability to read a message)
+ may have little to do with the fields themselves. Section 3.2
+ discusses some of the specific functions that a CBMS might
+ provide to users and the fields that must be used to support
+ those functions.
+
+ 10
+
+ Section 2.3
+
+
+
+ 2.4 Message Originators and Recipients
+
+
+ This message format specification refers to message
+ originators and recipients. These terms were defined
+ functionally in Figure 1. When the message format specification
+ refers to the identity of a message originator or recipient, it
+ means "that information which uniquely identifies the message
+ originator or recipient within the domain of the given message
+ system." The syntax and semantics of message addressing are not
+ within the scope of the message format specification.
+
+ Originators and Recipients can be people, roles, or
+ processes.
+
+ People. People as originators and recipients are specific
+ individuals.
+
+ Roles. Roles identify functions within organizations as
+ opposed to the specific individuals who perform them. For
+ example, consider a newspaper that produces both morning and
+ evening editions and therefore operates with more than one shift.
+ Someone wishing to contact the city desk would send a message to
+ the city desk role rather than trying to determine exactly who
+ was assigned to the city desk at a specific time. (Of course,
+ messages can usually be sent to the individuals directly whether
+ or not they are actually performing a role at the time.)
+
+ Processes. A process in a computer could serve as either an
+ originator or a recipient for messages. A computer system might
+ originate a message to notify a recipient about the status of
+ some task. For example, an archive utility could notify users
+ about files that have been archived; a distributed file system
+ could notify a user that a remote file has been deposited on a
+ local file system. Messages could be used by computer systems to
+ warn about some impending condition or even to monitor the
+ performance of the computer itself. Some computer processes may
+ also be message recipients, taking action based upon message
+ contents.
+
+ In addition, some CBMSs allow messages to be sent to groups.
+ A group is a predefined list of message recipients. Using a
+ group name as a recipient permits message originators to
+ designate a potentially large number of recipients using a single
+ recipient identifier. This makes using the CBMS more convenient
+ and accurate.
+
+
+
+
+
+
+
+ 11
+
+ Section 3
+
+
+
+ 3. SEMANTICS
+
+
+ This section discusses two major topics, message processing
+ functions and message field meanings. Section 3.1 describes the
+ six functional groups of message fields. The functional groups
+ are Origination, Dates, Recipients, Cross-referencing, Message-
+ handling, and Message-contents. They are explained more fully in
+ Section 3.1.1, along with detailed discussion of the semantics of
+ all the fields in each functional group. Section 3.2 describes
+ message processing functions whose operation is based on the
+ meanings of particular message fields.
+
+
+
+ 3.1 Semantics of Message Fields
+
+
+ The definition of a message is discussed generally in
+ Sections 1 and 2. Semantically valid messages must contain one
+ From field, one To field, and one Posted-Date field. They may
+ contain, in addition, any number of other fields, depending on
+ the processing and functions supplied by the originating or
+ receiving CBMS. (Section 3.2 describes classes of functions
+ supplied by CBMSs.)
+
+
+ 3.1.1 Types of fields
+
+
+ Message receiving programs are required to interpret fields
+ according to the semantics described in the remainder of this
+ se. The message fields defined in this document are grouped
+ into the following functional categories.
+
+
+ o Originator fields indicate who or what participated in
+ the creation of the message and where replies should be
+ directed. (See Section 3.1.3.)
+
+ o Date fields record when events take place, for a variety
+ events, such as message creation or expiration. (See
+ Section 3.1.5.)
+
+ o Recipient fields indicate who or what is intended to
+ receive a message. (See Section 3.1.4.)
+
+ o Cross-reference fields label a message or refer to other
+ messages. (See Section 3.1.6.)
+
+ o Message-handling fields record the type of service a
+
+
+ 12
+
+ Section 3.1.1
+
+
+
+ message's sender requested of a message transfer system
+ or indicate how the message should be treated by its
+ recipients. (See Section 3.1.7.)
+
+ o Message-content fields either contain the primary
+ content of a message or index or summarize it. (See
+ Section 3.1.8.)
+
+ o Extension fields provide mechanisms for extending the
+ message format specification. (See Section 3.1.9.)
+
+
+ 3.1.2 Semantic Compliance Categories
+
+
+ For purposes of determining whether a CBMS complies with the
+ semantic requirements of this message format specification,
+ message fields have been divided into three categories:
+
+
+ REQUIRED These fields must be present in all messages and must
+ be processed by message receiving programs as defined
+ by the message format specification.
+
+ BASIC These fields need not be present in all messages but
+ when they do appear they must be processed by message
+ receiving programs as defined by the message format
+ specification.
+
+ OPTIONAL These fields need not be present in all messages and
+ may be ignored by message receiving programs. The
+ exact meaning of "ignored" is not specified by the
+ message format specification. In general, a CBMS must
+ recognize the existence of an optional field (that is,
+ optional fields should not cause errors) and must not
+ process the field in a manner contrary to the semantics
+ defined for that field by the message format
+ specification.
+
+
+ (Syntactic compliance is defined in Section 4.1.2.)
+
+
+ 3.1.3 Originator fields
+
+
+ A message originator may be a person, role, or process.
+ Originator fields identify a message's author, who is responsible
+ for the message, who or what sent it, and where any
+ replies should be directed. (See Section 2.4.)
+
+
+
+ 13
+
+ Section 3.1.3
+
+
+
+ From (REQUIRED)
+
+ This field contains the identity of the originator(s)
+ taking formal responsibility for this message. The
+ contents of the From field is to be used for replies
+ when no Reply-to field appears in a message.
+ Reply-To (BASIC)
+
+ This field identifies any recipients of replies to the
+ message.
+ Author (OPTIONAL)
+
+ This field identifies the individual(s) who wrote the
+ primary contents of the message. Use of the Author
+ is discouraged when the contents of the Author
+ field and the From field would be completely redundant.
+ Sender (OPTIONAL)
+
+ This field identifies the agent who sent the message.
+ It is used either when the sender is not the originator
+ responsible for the message or to indicate who among a
+ group of originators responsible for the message
+ actually sent it. Use of the Sender field is
+ discouraged when the contents of the Sender field and
+ From field would be completely redundant. Only one
+ Sender field is permitted in a message.
+
+
+ 3.1.4 Recipient fields
+
+
+ Message recipients may be people, roles, or processes. (See
+ Section 2.4). Recipient fields identify who or what is to
+ receive the message.
+ To (REQUIRED)
+
+ This field identifies the primary recipients of a
+ message.
+ Bcc (OPTIONAL)
+
+ This field identifies additional recipients of a
+ message (a "blind carbon copies" list). The contents
+ of this field are not to be included in copies of the
+ message sent to the primary and secondary recipients.
+ See section 3.2.1 for further discussion of the use of
+ blind carbon copies lists.
+ Cc (BASIC)
+
+ This field identifies secondary recipients of a message
+ (a "carbon copies" list).
+
+
+
+ 14
+
+ Section 3.1.4
+
+
+
+ Circulate-Next (OPTIONAL)
+
+ This field is used in conjunction with the Circulate-To
+ field. (See Section 3.2.6.1.) It identifies all
+ recipients in a circulation list who have not received
+ the message.
+ Circulate-To (OPTIONAL)
+
+ This field identifies recipients of a circulated
+ message. (See Section 3.2.6.1.) It is used in
+ conjunction with the Circulate-Next field.
+
+
+ 3.1.5 Date fields
+
+
+ Date fields for two kinds of uses are provided. Dates can
+ be associated with some event in the history of a message and
+ dates can delimit the span of time during which the message is
+ meaningful (its life span).
+ Posted-Date (REQUIRED)
+
+ This field contains the posting date, which is the
+ point in time when the message passes through the
+ posting slot into a message transfer system. Only one
+ Posted-Date field is permitted in a message.
+ Date (OPTIONAL)
+
+ This field contains a date that the message's
+ originator wishes to associate with a message. The
+ Date field is to the Posted-Date field as the date on a
+ letter is to the postmark added by the post office.
+ End-Date (OPTIONAL)
+
+ This field contains the date on which a message loses
+ effect. (See also Section 3.2.5.)
+ Received-Date (OPTIONAL)
+
+ 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.
+ Start-Date (OPTIONAL)
+
+ This field contains the date on which a message takes
+ effect. (See also Section 3.2.5.)
+ Warning-Date (OPTIONAL)
+
+ This field is used either alone or in conjunction with
+ an End-Date field. It contains one or more dates.
+ These dates could be used by a message processing
+
+
+ 15
+
+ Section 3.1.5
+
+
+
+ program as warnings of an impending end-date or other
+ event. (See also Section 3.2.5.)
+
+
+ 3.1.6 Cross-reference fields
+
+
+ Cross reference fields can be used to identify a message and
+ to provide cross references to other messages. (See Section
+ 3.2.4.)
+ In-Reply-To (OPTIONAL)
+
+ This field designates previous correspondence to which
+ this message is a reply. The usual contents of this
+ field would be the contents of the Message-ID field of
+ the message(s) being replied to.
+ Message-ID (OPTIONAL)
+
+ This field contains a unique identifier for a message.
+ This identifier is intended for machine generation and
+ processing. Further definition appears in Section
+ 3.2.4.1. Only one Message-ID field is permitted in a
+ message.
+ Obsoletes (OPTIONAL)
+
+ This field identifies one or more messages that this
+ one supplants.
+ Originator-Serial-Number (OPTIONAL)
+
+ This field contains one or more serial numbers assigned
+ by the message's originator. Messages with multiple
+ recipients should have the same value in the
+ Originator-Serial-Number field.
+ References (OPTIONAL)
+
+ This field identifies other correspondence that this
+ message references. If the other correspondence
+ contains a Message-ID field, the contents of the
+ References field must be the message identifier.
+
+
+ 3.1.7 Message-handling fields
+
+
+ Message-handling fields describe aspects of how a message is
+ to be handled or categorized.
+ Precedence (OPTIONAL)
+
+ This field indicates the precedence at which the
+ message was posted. Ordinarily, message precedence or
+ priority is a service request to a message transfer
+
+
+ 16
+
+ Section 3.1.7
+
+
+
+ system. A message originator, however, can include
+ precedence information in a message. One example of
+ precedence categories are those used by the U.S.
+ Military: "ROUTINE", "PRIORITY", "IMMEDIATE", "FLASH
+ OVERRIDE", and "EMERGENCY COMMAND PRECEDENCE".
+ Message-Class (OPTIONAL)
+
+ This field indicates the purpose of a message. For
+ example, it might contain values indicating that the
+ 1
+ message is a memorandum or a data-base entry.
+ Reissue-Type (OPTIONAL)
+
+ This field is used in conjunction with message
+ encapsulating (see Section 2.4.1) to differentiate
+ between messages being assigned or redistributed.
+ Received-From (OPTIONAL)
+
+ This field contains a record of a message's path
+ through a message transfer system. The
+ recipient's message receiving program could store here
+ any information about the transfer that it obtained
+ from a message transfer system.
+
+
+ 3.1.8 Message-content fields
+
+
+ The intent of most messages is to communicate some
+ particular information from originator to recipient. Several
+ fields in a message are designed to contain that information.
+ Subject (BASIC)
+
+ This field contains any information the originator
+ provided to summarize or indicate the nature of the
+ message.
+ Text (BASIC)
+
+ This field contains the primary content of the message.
+ Attachments (OPTIONAL)
+
+ This field contains additional data accompanying a
+ message. It is similar in intent to enclosures in a
+ conventional mail system.
+
+ _______________
+
+ 1
+ The message format specification is not intended to be used as
+ a specification for exchanging data-base records. Messages,
+ however, sometimes contain data from or for a database.
+
+
+ 17
+
+ Section 3.1.8
+
+
+
+ Comments (OPTIONAL)
+
+ This field permits adding comments to the message
+ without disturbing the original contents of the
+ message.
+ Keywords (OPTIONAL)
+
+ This field contains keywords or phrases for use in
+ retrieving a message.
+
+
+ 3.1.9 Extensions
+
+
+ This message format specification allows two additional
+ types of fields, vendor-defined fields and as-yet-undefined
+ (extension) fields that will be introduced by extensions to this
+ message format specification.
+
+
+ vendor-defined-field
+ Any field not defined in this message format
+ specification 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.
+
+ 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.)
+
+
+
+ 18
+
+ Section 3.2.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 2.4.1) 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.
+
+ 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 (that is, write,
+ but not necessarily enter into the CBMS) a message; 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,
+ responsible 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.
+
+ 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 designated in the To and Cc
+ fields. Some systems include the contents of the Bcc field only
+
+
+ 19
+
+ Section 3.2.1
+
+
+
+ in the originator's copy, others include include all or part of
+ the Bcc field in the copies sent to the recipients indicated in
+ the Bcc field. This specification does not mandate how the Bcc
+ field is to be treated.
+
+ Audit trail entries (such as the posting time and sender
+ identity) are automatically appended to a message by the CBMS
+ each time the message passes through a posting slot to a message
+ transfer system; a message transfer system could also provide
+ timestamps at each transfer between user agent and the transfer
+ system. A message identifier (Sections 3.2.4 and 3.1.6), placed
+ in the message by the original sender's User Agent, is preserved
+ throughout this message flow. This means that when the same
+ message is sent twice to the same recipients by the same Sender,
+ the audit trail information for the two messages is different.
+
+
+ 3.2.2 Message reissuing and 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. Make others aware of the complete and
+ unaltered contents of the message.
+
+ o Assignment. Delegate 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
+
+
+ 20
+
+ Section 3.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 "15 June 1980"
+ Field: To "John Doe"
+ Field: Subject "Next sales meeting"
+ Field: Text "The agenda for ..."
+
+ Redistribution
+ Message:
+ Field: From "John Doe" John Doe is responsible
+ Field: Posted-Date "16 June 1980" 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 "15 June 1980"
+ Field: To "John Doe"
+ Field: Subject "Next Sales Meeting"
+ Field: Text "The agenda for ..."
+
+ Forwarding
+ Message:
+ Field: From "John Doe"
+ Field: Posted-Date "16 June 1980"
+ 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 15 June 1980 Note that John's CBMS
+ Subject Next Sales Meeting has chosen to represent
+ it as a text string.
+ The agenda for ..."
+
+
+
+ FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 21
+
+ Section 3.2.2
+
+
+
+ supporting re-issuing. 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.
+
+ Authentication is an organizational policy issue associated
+ passing on previously sent messages. 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.)
+
+
+ 3.2.2.2 Assignment
+
+ Assignment is the process of designating responsibility. In
+ some organizations, formal message traffic is funneled through
+ 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.
+
+
+ _______________
+
+ 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.
+
+
+ 22
+
+ Section 3.2.3
+
+
+
+ 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
+ recipients of a reply to a message.
+
+
+ o A Reply-To field is defined by this message format
+ specification. 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.
+
+
+ 1. 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.
+
+ 2. The people responsible for receiving responses
+ might not be the people who were responsible for
+ creating the message.
+
+ 3. 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.
+
+
+ o 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
+ facilities, depending on their view of users' organizational
+ requirements.
+
+
+
+
+
+ 23
+
+ Section 3.2.4
+
+
+
+ 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 quantities that 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 individual messages
+ unambiguously. When unique identifiers are used this way, they
+ are called message identifiers. Different versions of a message
+ (for example, the message when it is reissued with comments)
+ receive new message identifiers.
+
+ 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 quantity that it can guarantee to be
+ unique within its domain. (This second quantity could be a
+ counter or a timestamp/user-id combination.)
+
+ A CBMS can provide functions for tracing chains of
+ correspondence by using unique identifers. 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.)
+
+
+ 3.2.4.2 Serial numbering
+
+ Serial numbers are for users to maintain a personal
+ numbering 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...).
+
+
+
+ 24
+
+ Section 3.2.4.2
+
+
+
+ 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 (Section 3.2.4.1) in that
+ they are not necessarily either generated or processed by a CBMS.
+ They are designed to be typed 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. A field has been provided to permit
+ this. Originator-Serial-Number is 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 is likely to 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. It 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 automatically remind the user of an
+ impending end date, such as a meeting reminder.
+
+
+ 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
+
+
+ 25
+
+ Section 3.2.6
+
+
+
+ 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
+ message 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
+ recipients, 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 at most once. 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.
+
+ Multiple occurrences of a field are not necessarily
+ equivalent 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
+
+
+ 26
+
+ 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 somebody 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
+
+
+ -----------------------------------------------------------------
+
+
+ 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.
+
+ The fields found in a single message may occur in any order.
+ The order in which they occur does not necessarily reflect the
+ order in which they were created. Nor does it constrain the
+ order in which the message recipient examines, processes, or
+ displays them.
+
+
+
+
+
+
+
+
+
+
+ 27
+
+ 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
+ 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.
+
+
+ 28
+
+ Section 4.1.1
+
+
+
+ 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.)
+
+
+ 29
+
+ Section 4.1.2.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.
+
+ 30
+
+ Section 4.1.3.1
+
+
+
+ 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.
+
+
+
+
+ 31
+
+ Section 4.2
+
+
+
+ 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.)
+
+
+
+
+
+ 32
+
+ Section 4.2.1
+
+
+
+
+
+
+ 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
+
+
+ 33
+
+ Section 4.2.2
+
+
+
+ -----------------------------------------------------------------
+
+
+ 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.
+
+
+ 34
+
+ 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.
+ +---------------+
+
+ +---------------+------//-------+
+ |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
+
+
+ 35
+
+ 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
+
+
+ -----------------------------------------------------------------
+
+
+ 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).
+
+
+ 36
+
+ Section 4.2.2.2
+
+
+
+ -----------------------------------------------------------------
+
+
+ +--------+
+ |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.
+
+
+
+
+ 37
+
+ Section 4.2.3
+
+
+
+ -----------------------------------------------------------------
+
+
+
+ +--------+
+ |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.)
+
+ 38
+
+ Section 4.2.4
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+ 39
+
+ Section 4.3.1
+
+
+
+ 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|
+ +---//---+
+
+
+ 40
+
+ Section 4.3.1
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 41
+
+ 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, 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|
+ +--------+---//---+----//-----+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 42
+
+ 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|
+ +--------+---//---+
+
+
+
+
+ 43
+
+ 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
+ alphabetical order.
+
+
+
+
+
+
+
+
+
+
+
+
+ 44
+
+ 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].
+
+
+ +--------+---//---+------//------+
+ |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|
+ +--------+---//---+---//---+--------//--------+
+
+
+
+
+
+ 45
+
+ Section 4.3.1.2
+
+
+
+ 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 |
+ +--------//---------//---------//---------//--------+
+
+
+
+
+
+
+
+
+
+ 46
+
+ Section 4.3.1.2
+
+
+
+ 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|
+ +--------+---//---+---//---+
+
+
+ 47
+
+ Section 4.3.1.2
+
+
+
+ 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.
+
+
+
+
+
+
+
+ 48
+
+ Section 4.3.3
+
+
+
+ 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.
+
+
+ 49
+
+ Section 4.3.6
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 50
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 51
+
+ Appendix A
+
+
+
+ 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.
+
+
+
+ 52
+
+ Appendix A
+
+
+
+ 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.
+
+
+ 53
+
+ Appendix A
+
+
+
+ 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.
+
+
+ 54
+
+ Appendix A
+
+
+
+ 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.
+
+
+
+ 55
+
+ Appendix A
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 56
+
+ Appendix B
+
+
+
+ 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|
+ +--------+---//---+----//-----+
+
+
+
+
+
+ 57
+
+ Appendix B
+
+
+
+ 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 |
+ +--------+---//---+--------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 58
+
+ Appendix B
+
+
+
+ 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 |
+ +--------+---//---+------//------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 59
+
+ Appendix B
+
+
+
+ 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|
+ +--------+---//---+---//---+---//---+
+
+
+
+
+
+ 60
+
+ Appendix B
+
+
+
+ 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 |
+ +--------//---------//---------//---------//--------+
+
+
+
+
+ 61
+
+ Appendix B
+
+
+
+ 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|
+ +--------+---//---+-------//--------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 62
+
+ Appendix B
+
+
+
+ Property (OPTIONAL) 45 105
+ 16 8
+ constructor
+
+ This data element uses a Qualifier data element
+ component. The Qualifier component contains
+ a Property-Identifier (PID) to indicate which specific
+ property is being represented. (See Section 4.3.3.)
+
+
+ +--------+---//---+---//---+---//---+
+ |P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+ +--------+---//---+---//---+---//---+
+
+
+ Sequence (OPTIONAL) 0A 012
+ 16 8
+ constructor
+
+ This data element contains any series of data elements.
+ Sequence differs from Set in that the data elements
+ making up the Data Element Contents must be considered
+ as an ordered sequence (according to their order of
+ appearance in the sequence.)
+
+
+ +--------+---//---+---//---+
+ |P0001010|Lxxxxxxx|elements|
+ +--------+---//---+---//---+
+
+
+ Set (OPTIONAL) 0B 013
+ 16 8
+ constructor
+
+ This data element contains any series of data elements
+ with no ordering of the elements implied. (Sequence
+ provides an ordered series.) Although the data
+ elements contained in a Set must be stored
+ sequentially, the order in which they are stored is not
+ defined and not processed.
+
+
+ +--------+---//---+---//---+
+ |P0001011|Lxxxxxxx|elements|
+ +--------+---//---+---//---+
+
+
+
+
+
+
+
+ 63
+
+ Appendix B
+
+
+
+ Unique-ID (OPTIONAL) 09 011
+ 16 8
+ constructor
+
+ This data element is a unique identifier. It need not
+ be human-readable. The Data Element Contents may be an
+ ASCII-String, a Bit-String, or an Integer.
+
+
+ +--------+---//---+---//---+
+ |P0001001|Lxxxxxxx| element|
+ +--------+---//---+---//---+
+
+
+ Vendor-Defined (OPTIONAL) 7F 177
+ 16 8
+ constructor
+
+ This data element is used to represent vendor-defined
+ data elements. A Qualifier component extends the
+ encoding space for identifiers. The Qualifier
+ component is not guaranteed to be unique among all
+ interconnected ems. 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|
+ +--------+---//---+---+---//---+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 64
+
+ Appendix C
+
+
+
+ APPENDIX C
+ DATA ELEMENT IDENTIFIER OCTETS
+
+
+
+
+ Identifier Identifier Data Element Name
+
+ 00 000 No-Op
+ 01 001 End-of-Constructor
+ 02 002 ASCII-String
+ 08 010 Boolean
+ 09 011 Unique-ID
+ 0A 012 Sequence
+ 0B 013 Set
+ 20 040 Integer
+ 21 041 Padding
+ 24 044 Property-List
+ 28 050 Date
+ 43 103 Bit-String
+ 45 105 Property
+ 46 106 Compressed
+ 47 107 Encrypted
+ 4C 114 Field
+ 4D 115 Message
+ 7E 176 Extension
+ 7F 177 Vendor-Defined
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 65
+
+ Appendix D
+
+
+
+ APPENDIX D
+ SUMMARY OF MESSAGE FIELDS BY COMPLIANCE CATEGORY
+
+
+
+
+ This appendix is for reference use. It contains no new
+ information, but rather abstracts from that presented in Section
+ 3.1.
+
+ This appendix contains the message field names arranged
+ alphabetically within compliance category. (Appendix E orders
+ the field names within functional category.) Complete field
+ definitions appear in Appendix A.
+
+ Required fields must appear in a message. Basic fields must
+ be recognized and processed by all CBM systems. Optional fields
+ need not be supported by a CBMS but, if supported, must be
+ processed according to the meanings defined by the message format
+ specification.
+
+
+
+ D.1 REQUIRED Fields
+
+
+ From
+ Posted-Date
+ To
+
+
+
+ D.2 BASIC Fields
+
+
+ Cc
+ Reply-To
+ Subject
+ Text
+
+
+
+ D.3 OPTIONAL Fields
+
+
+ Attachments
+ Author
+ Bcc
+ Circulate-Next
+ Circulate-To
+ Comments
+
+
+ 66
+
+ Appendix D
+
+
+
+ Date
+ End-Date
+ In-Reply-To
+ Keywords
+ Message-Class
+ Message-ID
+ Obsoletes
+ Originator-Serial-Number
+ Precedence
+ Received-Date
+ Received-From
+ References
+ Reissue-Type
+ Sender
+ Start-Date
+ Warning-Date
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 67
+
+ Appendix E
+
+
+
+ APPENDIX E
+ SUMMARY OF MESSAGE SEMANTICS BY FUNCTION
+
+
+
+
+ This appendix is for reference use. It contains no new
+ information, but rather abstracts from that presented in Section
+ 3.1.
+
+ This appendix contains the message field names arranged
+ alphabetically within functional class. (Appen orders the
+ field names within compliance class.) Complete field definitions
+ appear in Appendix A.
+
+
+
+ E.1 Circulation
+
+
+ Circulate-Next
+ Circulate-To
+
+
+
+ E.2 Cross Referencing
+
+
+ In-Reply-To
+ Message-ID
+ Obsoletes
+ Originator-Serial-Number
+ References
+
+
+
+ E.3 Life spans
+
+
+ End-Date
+ Start-Date
+ Warning-Date
+
+
+
+ E.4 Delivery System
+
+
+ Received-Date
+ Received-From
+
+
+
+ 68
+
+ Appendix E
+
+
+
+ E.5 Miscellaneous Fields Used Generally
+
+
+ Attachments
+ Comments
+ Keywords
+ Message-Class
+ Precedence
+ Subject
+ Text
+
+
+
+ E.6 Reply Generation
+
+
+ Reply-To
+
+
+
+ E.7 Reissuing
+
+
+ Reissue-Type
+
+
+
+ E.8 Sending (Normal Transmission)
+
+
+ Author
+ Bcc
+ Cc
+ Date
+ From
+ Posted-Date
+ Sender
+ To
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 69
+
+ Appendix F
+
+
+
+ APPENDIX F
+ SUMMARY OF DATA ELEMENT SYNTAX
+
+
+
+
+ This appendix summarizes data element syntax by diagramming
+ the components of data elements. Detailed presentation of data
+ element syntax appears in Section 4.3.1.
+
+ In these diagrams, required components of a data element
+ appear as follows. (The double border signifies "required".)
+
+
+ +========+ +===//===+
+ | | | |
+ +========+ +===//===+
+ always one one or more
+ octet long octets long
+
+
+ Optional components of data elements are represented as
+ follows. (The single border signifies "not required".)
+
+
+ +--------+ +---//---+
+ | | | |
+ +--------+ +---//---+
+ always one one or more
+ octet long octets long
+
+
+ The first octet in a data element is the identifier octet.
+ In diagrams of data elements, all eight bits of the identifier
+ octet are always shown. Bits with fixed values show the fixed
+ values as 1s and 0s. Bits with variable values are shown as x's
+ and y's.
+
+ The first bit in an identifier octet is the P-bit. Its
+ value indicates whether a data element contains a property list.
+ (A P-bit value of 1 indicates the presence of a property list.)
+ The remaining seven bits contain the rest of the identifier.
+
+ Other octets in a data element belong to one of four
+ classes, Length Code, Qualifier, Property-List, and Contents. In
+ diagrams of syntax the data element components are labeled
+ according to their class.
+
+
+
+
+
+
+ 70
+
+ Appendix F
+
+
+
+ Component Class Label
+
+ Length code Length
+ Qualifier Qual
+ Property-List P-List
+ Contents Contents
+
+
+ Data elements must follow this form.
+
+
+ +========+===//===+---//---+---//---+---//---+
+ |Pxxxxxxx| Length | Qual | P-List |contents|
+ +========+===//===+---//---+---//---+---//---+
+
+
+ The value of the Length component is the total number of octets
+ following the length code octet in the data element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 71
+
+ Appendix G
+
+
+
+ APPENDIX G
+ SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY
+
+
+
+
+ Compliance categories for syntactic elements are basic and
+ optional. Every CBMS is required to recognize and process basic
+ elements. A CBMS is not required to process optional elements
+ although many are strongly recommended by the semantics.
+
+ This appendix summarizes data elements by listing them
+ according to their compliance category.
+
+
+
+ G.1 BASIC Data Elements
+
+
+ ASCII-String (primitive) 02 002
+ 16 8
+ Date (constructor) 28 050
+ 16 8
+ End-Of-Constructor (primitive) 01 001
+ 16 8
+ Field (constructor) 4C 114
+ 16 8
+ Message (constructor) 4D 115
+ 16 8
+
+
+ G.2 OPTIONAL Data Elements
+
+
+ Bit-String (primitive) 43 103
+ 16 8
+ Boolean (primitive) 08 010
+ 16 8
+ Compressed (constructor) 46 106
+ 16 8
+ Encrypted (constructor) 47 107
+ 16 8
+ Extension (constructor) 7E 176
+ 16 8
+ Integer (primitive) 20 040
+ 16 8
+ No-Op (primitive) 00 000
+ 16 8
+ Padding (primitive) 21 041
+ 16 8
+
+
+
+ 72
+
+ Appendix G
+
+
+
+ Property (constructor) 45 105
+ 16 8
+ Property-List (constructor) 24 044
+ 16 8
+ Sequence (constructor) 0A 012
+ 16 8
+ Set (constructor) 0B 013
+ 16 8
+ Unique-ID (constructor) 09 011
+ 16 8
+ Vendor-Defined (constructor) 7F 377
+ 16 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 73
+
+ Appendix H
+
+
+
+ APPENDIX H
+ EXAMPLES
+
+
+
+
+ This appendix presents at least one example for each of the
+ data elements defined in this message format specification. In
+ these examples, identifier octets are represented in binary form.
+ All other numbers are presented in hexadecimal. ASCII strings
+ are shown as characters rather than their numerical
+ representation. Although this message format specification does
+ not define the syntax of names and addresses, message originators
+ and recipients are identified by their names. This does not
+ imply anything about how naming and addressing can or should be
+ done; it is simply a convenient way to identify message
+ originators and recipients in these examples.
+
+
+
+ H.1 Primitive Data Elements
+
+
+ This section contains an example of each of the primitive
+ data elements. Each example contains a short explanation and a
+ series of octets.
+ No-Op data element:
+
+
+ +--------+--------+
+ |00000000|00000000|
+ +--------+--------+
+
+
+
+
+
+ End-of-Constructor data element:
+
+
+ +--------+--------+
+ |00000001|00000000|
+ +--------+--------+
+
+
+
+
+
+
+
+
+
+
+ 74
+
+ Appendix H
+
+
+
+ Boolean data element whose value is true:
+
+
+ +--------+--------+--------+
+ |00001000|00000001|11111111|
+ +--------+--------+--------+
+
+
+
+
+
+ Integer data element containing five octets of data. Its
+ value is 4,294,967,296 (decimal):
+
+
+ +--------+--------+--------+--------+--------+
+ |00100000| 0 5 | 0 1 0 0 0 0
+ +--------+--------+--------+--------+--------+
+
+ +--------+--------+
+ 0 0 0 0 |
+ +--------+--------+
+
+
+
+
+
+ Padding data element containing three octets of padding.
+ The values of those three octets are meaningless:
+
+
+ +--------+--------+--------+--------+--------+
+ |00100001| 0 3 | F F F F F F |
+ +--------+--------+--------+--------+--------+
+
+
+
+
+
+ ASCII-String data element containing nine characters. Its
+ value is "Hi There.":
+
+
+ +--------+--------+---- ----+
+ |00000010| 0 9 |Hi There.|
+ +--------+--------+---- ----+
+
+
+
+
+
+
+
+ 75
+
+ Appendix H
+
+
+
+ Bit-String data element containing 44 bits of data (((7-1) x
+ 8) - 4). Six octets are used to hold those 44 bits. The last 4
+ bits in the final octet are padding and are therefore ignored.
+
+
+ Bit-String Length Spare
+ +--------+--------+--------+--------+--------+
+ |01000011| 0 7 | 0 4 | 0 A 3 B
+ +--------+--------+--------+--------+--------+
+
+ +--------+--------+--------+--------+
+ 5 F 2 9 1 C D 0 |
+ +--------+--------+--------+--------+
+
+
+
+
+
+ H.2 Constructor Data Elements
+
+
+ This section contains an example of each of the constructor
+ data elements. Each example contains a short explanation and
+ then an annotated series of the data elements making up the
+ constructor.
+ Property-List data element containing one Property data
+ element. The property is Printing-Name and its value is
+ "Distribution":
+
+
+ Prop-List Length Property Length PID
+ +--------+--------+--------+--------+--------+
+ |00100100| 1 1 |01000101| 0 F | 0 2 |
+ +--------+--------+--------+--------+--------+
+
+ ASCII Length
+ +--------+--------+---- ----+
+ |00000010| 0 C |Distribution|
+ +--------+--------+---- ----+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 76
+
+ Appendix H
+
+
+
+ Printing-Name Property. The value of the Printing-Name is
+ "Distribution":
+
+
+ Property Length PID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01000101| 0 F | 0 2 |00000010| 0 C |
+ +--------+--------+--------+--------+--------+
+
+ +---- ----+
+ |Distribution|
+ +---- ----+
+
+
+
+
+
+ Compressed data element. Its contents were compressed using
+ an as-yet-undefined NBS standard data compression algorithm. The
+ compressed data is in a bit-string that is 56 bits long, fully
+ filling 7 octets:
+
+
+ Compressed Length CID Bit-String Length
+ +--------+--------+--------+--------+--------+
+ |01000110| 0 B | 0 1 |01000011| 0 8 |
+ +--------+--------+--------+--------+--------+
+
+ Spare
+ +--------+--------+--------+--------+
+ | 0 0 | 1 C 5 F 2 D
+ +--------+--------+--------+--------+
+
+ +--------+--------+--------+--------+
+ 7 7 B A F 6 2 9 |
+ +--------+--------+--------+--------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 77
+
+ Appendix H
+
+
+
+ Encrypted data element. The encryption method used to
+ encrypt its contents has been intentionally not specified. This
+ element contains a Bit-String which contains 22 bits (((4-1) x 8)
+ - 2) of data. These 22 bits are represented in octets; the final
+ 2 bits in the final octet are padding and are therefore ignored:
+
+
+ Encrypted Length EID Bit-String Length
+ +--------+--------+--------+--------+--------+
+ |01000111| 0 7 | 0 0 |01000011| 0 4 |
+ +--------+--------+--------+--------+--------+
+
+ Spare
+ +--------+--------+--------+--------+
+ | 0 2 | A 3 7 8 1 C |
+ +--------+--------+--------+--------+
+
+
+
+
+
+ Date data element. This example includes a date but no
+ time. The date shown in this example is August 15, 1980:
+
+
+ Date Length ASCII Length
+ +--------+--------+--------+--------+--- ---+
+ |00101000| 0 A |00000010| 0 8 |19800815|
+ +--------+--------+--------+--------+--- ---+
+
+
+
+
+
+ Unique-ID data element, which is represented as an Integer
+ data element whose value is 129 (decimal).
+
+
+ Unique-ID Length Integer Length
+ +--------+--------+--------+--------+--------+--------+
+ |00001001| 0 4 |00100000| 0 2 | 0 0 8 1 |
+ +--------+--------+--------+--------+--------+--------+
+
+
+
+
+
+
+
+
+
+
+
+ 78
+
+ Appendix H
+
+
+
+ Sequence data element containing two ASCII-String data
+ elements. The first ASCII-String is "This is" while the second
+ string is " a list":
+
+
+ Sequence Length ASCII Length
+ +--------+--------+--------+--------+--- ---+
+ |00001010| 1 2 |00000010| 0 7 |This is|
+ +--------+--------+--------+--------+--- ---+
+
+ ASCII Length
+ +--------+--------+--- ---+
+ |00000010| 0 7 | a list|
+ +--------+--------+--- ---+
+
+
+
+
+
+ Set data element containing two Integer data elements. The
+ first integer has a value of 519 (decimal) while the value of the
+ second is 71 (decimal). (These two value have no ordering
+ because they belong to a set.)
+
+
+ Set Length Integer Length
+ +--------+--------+--------+--------+--------+--------+
+ |00001011| 0 8 |00100000| 0 2 | 0 2 0 7 |
+ +--------+--------+--------+--------+--------+--------+
+
+ Integer Length
+ +--------+--------+--------+--------+
+ |00100000| 0 2 | 0 0 4 7 |
+ +--------+--------+--------+--------+
+
+
+
+
+
+ Field data element. The specific field shown is the Text
+ field with the contents "I will see you at lunch.":
+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 B | 0 4 |00000010| 1 8 |
+ +--------+--------+--------+--------+--------+
+
+ +---- ----+
+ |I will see you at lunch.|
+ +---- ----+
+
+
+ 79
+
+ Appendix H
+
+
+
+ Message containing four fields, Posted-Date, From, Text, and
+ To. It was sent on July 4, 1980 at 6 p.m. eastern daylight time.
+ It is from a person named Smith. The text of the message is a
+ question asking the recipient "Are you going to watch the
+ fireworks?". The message is sent to Jones:
+
+
+ Message Length Type Field Length
+ +--------+--------+--------+--------+--------+
+ |01001101| 5 8 | 0 1 |01001100| 1 7 |
+ +--------+--------+--------+--------+--------+
+
+ FID Date Length ASCII
+ +--------+--------+--------+--------+
+ | 0 2 |00101000| 1 4 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+---- ----+
+ | 1 2 |19800704-180000EDT|
+ +--------+---- ----+
+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 8 | 0 1 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+-- --+
+ | 0 5 |Smith|
+ +--------+-- --+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 2 8 | 0 4 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+
+ | 2 5 |
+ +--------+
+
+ +---- ----+
+ |Are you going to watch the fireworks?|
+ +---- ----+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 8 | 0 5 |00000010|
+ +--------+--------+--------+--------+
+
+
+ 80
+
+ Appendix H
+
+
+
+
+ Length
+ +--------+-- --+
+ | 0 5 |Jones|
+ +--------+-- --+
+
+
+
+
+
+ Extension data element containing a length code and 3
+ octets. The octet immediately following the length code
+ identifies it as Extension Data Element 7. The Data Element
+ Contents is the final two octets. The interpretation of the Data
+ Element Contents would be defined in an extension or successor to
+ this message format specification. [Note: this is an example.
+ Any actual extension data element 7 (if it were ever used) would
+ be completely different from anything done here.]:
+
+
+ Extension Length
+ +--------+--------+--------+--------+--------+
+ |01111110| 0 3 | 0 7 | 4 A E 9 |
+ +--------+--------+--------+--------+--------+
+
+
+
+
+
+ Vendor-Defined data element containing a length code and 3
+ octets. The first octet identifies this as vendor-defined data
+ element number 114 (decimal), which this particular vendor has
+ defined to contain three printable ASCII characters in two
+ octets. (Data element 114 (decimal) for another user would be
+ completely different. For example, it might contain a floating
+ point number.):
+
+
+ User Length
+ +--------+--------+--------+--------+--------+
+ |01111111| 0 3 | 7 2 | P O E |
+ +--------+--------+--------+--------+--------+
+
+
+
+ H.3 Fields
+
+
+ This section contains examples of Field data element
+ constructors for each several different fields (Keywords, Text,
+ Subject, Vendor-Defined).
+
+
+ 81
+
+ Appendix H
+
+
+
+ Field data element for keywords . The field contains two
+ keywords, Message and Computer, each represented in a separate
+ ASCII-string data element.
+
+
+ Field Length Keywords ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 4 | 1 4 |00000010| 0 7 |
+ +--------+--------+--------+--------+--------+
+
+ +--- ---+
+ |Message|
+ +--- ---+
+
+ ASCII Length
+ +--------+--------+--- ---+
+ |00000010| 0 8 |Computer|
+ +--------+--------+--- ---+
+
+
+
+
+
+ Field data element for Text with a Property-List data
+ element containing a comment attached. The text field contains
+ the ASCII-String data element "Do you want lunch?"; the Property-
+ List data element contains a comment property, which consists of
+ an ASCII-string data element containing "Now?":
+
+
+ Field Length Text Prop-List Length
+ +--------+--------+--------+--------+--------+
+ |11001100| 2 0 | 0 4 |00100100| 0 9 |
+ +--------+--------+--------+--------+--------+
+
+ Property Length PID ASCII
+ +--------+--------+--------+--------+
+ |01000101| 0 7 | 0 1 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+- -+
+ | 0 4 |Now?|
+ +--------+- -+
+
+ ASCII Length
+ +--------+--------+---- ----+
+ |00000010| 1 2 |Do you want lunch?|
+ +--------+--------+---- ----+
+
+
+
+
+ 82
+
+ Appendix H
+
+
+
+ Field data element for Subject containing an ASCII-String
+ data element ("Good restaurants in Detroit" followed by a
+ carriage return and a line feed). (A recipient would expect the
+ message to contain some information about restaurants in the
+ Detroit area.):
+
+
+ Field Length Subject ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 2 1 | 0 7 |00000010| 1 E |
+ +--------+--------+--------+--------+--------+
+
+ +---- ----+
+ |Good restaurants in Detroit.<cr><lf>|
+ +---- ----+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 83
+
+ Appendix H
+
+
+
+ Field data element whose form and meaning was defined by a
+ vendor. This vendor has defined vendor-defined field 12
+ (decimal) to be a field with a printing name of "Reply-by" and
+ contents consisting of a date; January 7, 1981 in this case.
+ (The meaning of vendor-defined field 12 is unique to the vendor;
+ the same field number would have different meaning for other
+ vendors.):
+
+
+ Field Length Qualifier User number
+ +--------+--------+--------+--------+--------+
+ |11001100| 1 F | 8 2 | 0 0 0 C |
+ +--------+--------+--------+--------+--------+
+
+ Prop-List Length Property Length
+ +--------+--------+--------+--------+
+ |00100100| 0 E |01000101| 0 C |
+ +--------+--------+--------+--------+
+
+ PID ASCII Length
+ +--------+--------+--------+---- ----+
+ | 0 2 |00000010| 0 9 |Reply-By:|
+ +--------+--------+--------+---- ----+
+
+ Date Length ASCII Length
+ +--------+--------+--------+--------+
+ |00101000| 0 A |00000010| 0 8 |
+ +--------+--------+--------+--------+
+
+ +--- ---+
+ |19810107|
+ +--- ---+
+
+
+
+ H.4 Messages
+
+
+ This section contains several examples of complete messages
+ and shows the results of reissuing a message. (See Section
+ 3.2.2.)
+
+
+
+
+
+
+
+
+
+
+
+
+ 84
+
+ Appendix H
+
+
+
+ The following sample message had Stevens as its originator
+ and Johnson as its recipient. The message was sent on August 14,
+ 1980 at 10 am EDT. The subject of the message is "Project
+ Deadline" and the message is a reminder that the deadline is the
+ next day and that the section of the report for the project being
+ done by Johnson should be turned in to Stevens by 3 pm that day.
+
+
+ Message Length Type
+ +--------+--------+--------+--------+
+ |01001101| 8 1 | B 4 | 0 1 |
+ +--------+--------+--------+--------+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 A | 0 5 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+--- ---+
+ | 0 7 |Johnson|
+ +--------+--- ---+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 A | 0 1 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+--- ---+
+ | 0 7 |Stevens|
+ +--------+--- ---+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 3 | 0 7 |00000010| 1 0 |
+ +--------+--------+--------+--------+--------+
+
+ +---- ----+
+ |Project Deadline|
+ +---- ----+
+
+ Field Length FID Date Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 5 | 0 2 |00101000| 1 2 |
+ +--------+--------+--------+--------+--------+
+
+ ASCII Length
+ +--------+--------+---- ----+
+ |00000010| 1 0 |19800814-1000EDT|
+ +--------+--------+---- ----+
+
+
+ 85
+
+ Appendix H
+
+
+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 6 D | 0 4 |00000010| 6 A |
+ +--------+--------+--------+--------+--------+
+
+ +----
+ |Don't forget the project report is
+ +----
+
+ due tomorrow. Please have<CrLf>
+
+ your section to me by three this
+
+ ----+
+ afternoon.|
+ ----+
+
+
+
+
+
+ The following example illustrates the results of reissuing
+ the first message in this section. This message contains the
+ original message (as a Message data element), To, From, and
+ Posted-Date fields, and a Reissue-Type field with Redistributed
+ as its value:
+
+
+ Message Length Type
+ +--------+--------+--------+--------+
+ |01001101| 8 1 | F 8 | 0 1 |
+ +--------+--------+--------+--------+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 9 | 0 5 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+-- --+
+ | 0 6 |Cooper|
+ +--------+-- --+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 A | 0 1 |00000010|
+ +--------+--------+--------+--------+
+
+
+
+
+
+ 86
+
+ Appendix H
+
+
+
+
+ Length
+ +--------+--- ---+
+ | 0 7 |Johnson|
+ +--------+--- ---+
+
+ Field Length FID Date Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 5 | 0 2 |00101000| 1 2 |
+ +--------+--------+--------+--------+--------+
+
+ ASCII Length
+ +--------+--------+---- ----+
+ |00000010| 1 0 |19800814-1030EDT|
+ +--------+--------+---- ----+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 0 | 2 5 |00000010| 0 D |
+ +--------+--------+--------+--------+--------+
+
+ +---- ----+
+ |Redistributed|
+ +---- ----+
+
+ Message Length Type
+ +--------+--------+--------+--------+
+ |01001101| 8 1 | B 4 | 0 1 |
+ +--------+--------+--------+--------+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 A | 0 5 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+--- ---+
+ | 0 7 |Johnson|
+ +--------+--- ---+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 A | 0 1 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+--- ---+
+ | 0 7 |Stevens|
+ +--------+--- ---+
+
+
+
+
+ 87
+
+ Appendix H
+
+
+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 3 | 0 7 |00000010| 1 0 |
+ +--------+--------+--------+--------+--------+
+
+ +---- ----+
+ |Project Deadline|
+ +---- ----+
+
+ Field Length FID Date Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 5 | 0 2 |00101000| 1 2 |
+ +--------+--------+--------+--------+--------+
+
+ ASCII Length
+ +--------+--------+---- ----+
+ |00000010| 1 0 |19800814-1000EDT|
+ +--------+--------+---- ----+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 6 D | 0 4 |00000010| 6 A |
+ +--------+--------+--------+--------+--------+
+
+ +----
+ |Don't forget the project report is
+ +----
+
+ due tomorrow. Please have<CrLf>
+
+ your section to me by three this
+
+ ----+
+ afternoon.|
+ ----+
+
+
+
+ H.5 Unknown Lengths
+
+
+ This section contains two examples of data elements with an
+ unknown length. The two examples have been presented in sections
+ H.2 and H.4, but with a known rather than an unknown length.
+
+
+
+
+
+
+
+
+ 88
+
+ Appendix H
+
+
+
+ Set data element with an unknown length containing two
+ Integer data elements. The first integer has a value of 519
+ (decimal) while the value of the second is 71 (decimal). (These
+ two value have no ordering because they belong to a set.)
+
+
+ Set Length Integer Length
+ +--------+--------+--------+--------+--------+--------+
+ |00001011| 8 0 |00100000| 0 2 | 0 2 0 7 |
+ +--------+--------+--------+--------+--------+--------+
+
+ Integer Length
+ +--------+--------+--------+--------+
+ |00100000| 0 2 | 0 0 4 7 |
+ +--------+--------+--------+--------+
+
+ End-of-Con Length
+ +--------+--------+
+ |00000000|00000000|
+ +--------+--------+
+
+
+
+
+
+
+ The following sample message with an unknown length had
+ Stevens as its originator and Johnson as its recipient. The
+ message was sent on August 14, 1980 at 10 am EDT. The subject of
+ the message is "Project Deadline" and the message is a reminder
+ that the deadline is the next day and that the section of the
+ report for the project being done by Johnson should be turned in
+ to Stevens by 3 pm that day.
+
+
+ Message Length Type
+ +--------+--------+--------+
+ |01001101| 8 0 | 0 1 | +--------+--------+--------+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 A | 0 5 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+--- ---+
+ | 0 7 |Johnson|
+ +------- ---+
+
+
+
+
+ 89
+
+ Appendix H
+
+
+
+
+ Field Length FID ASCII
+ +--------+--------+--------+--------+
+ |01001100| 0 A | 0 1 |00000010|
+ +--------+--------+--------+--------+
+
+ Length
+ +--------+--- ---+
+ | 0 7 |Stevens|
+ +--------+--- ---+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 3 | 0 7 |00000010| 1 0 |
+ +--------+--------+--------+--------+--------+
+
+ +---- ----+
+ |Project Deadline|
+ +---- ----+
+
+ Field Length FID Date Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 1 5 | 0 2 |00101000| 1 2 |
+ +--------+--------+--------+--------+--------+
+
+ ASCII Length
+ +--------+--------+---- ----+
+ |00000010| 1 0 |19800814-1000EDT|
+ +--------+--------+---- ----+
+
+ Field Length FID ASCII Length
+ +--------+--------+--------+--------+--------+
+ |01001100| 6 D | 0 4 |00000010| 6 A |
+ +--------+--------+--------+--------+--------+
+
+ +----
+ |Don't forget the project report is
+ +----
+
+ due tomorrow. Please have<CrLf>
+
+ your section to me by three this
+
+ ----+
+ afternoon.|
+ ----+
+
+ End-of-Con Length
+ +--------+--------+
+ |00000000|00000000|
+ +--------+--------+
+
+
+ 90
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 91
+
+
+
+
+
+ REFERENCES
+
+
+
+
+ [BlaR-80]
+ R. P. Blanc and J. F. Heafner. The NBS Program in Computer
+ Network Protocol Standards. In Proceedings, ICCC 80. 1980.
+
+ [CroD-77]
+ David H. Crocker, John J. Vittal, Kenneth T. Pogran,
+ D. Austin Henderson, Jr. Standard for the Format of ARPA
+ Network Text Messages. RFC 733, The Rand Corporation, Bolt
+ Beranek and Newman Inc, Massachussets Institute of
+ Technology, Bolt Beranek and Newman Inc., November, 1977.
+
+ [FeiE-79]
+ E. Feinler, J. Pickens, and A. Sjoberg. Computer Message
+ Services Bibliography. Technical Report NIC-BIBLIO-791201,
+ SRI International, December, 1979.
+
+ [ISOD-79]
+ ISO/TC97/SC6 Data Communications. Second Draft Proposed
+ Communication Heading Format Standard. ISO/TC97/SC6 N 1948,
+ ISO International Organization for Standardization
+ Organization Internationale de Normalisation, September,
+ 1979. Secretariat: USA (ANSI).
+
+ [ISOD-81]
+ ISO/TC97/SC16. Open Systems Interconnection Basic Reference
+ Model. ISO/TC97/SC16 N, ISO International Ozation for
+ Standardization Organization Internationale de
+ Normalisation, 1981.
+
+ [NatB-68]
+ National Bureau of Standards. Calendar Date. Federal
+ Information Processing Standards Publication 4, U.S.
+ Department of Commerce / National Bureau of Standards,
+ November, 1968.
+
+ [NatB-77]
+ National Bureau of Standards. Data Encryption Standard.
+ Federal Information Processing Standards Publication 46,
+ U.S. Department of Commerce / National Bureau of Standards,
+ January, 1977.
+
+ [NatB-79a]
+ National Bureau of Standards. Representations of Local Time
+ of the Day for Information Interchange. Federal Information
+ Processing Standards Publication 58, U.S. Department of
+ Commerce / National Bureau of Standards, February, 1979.
+
+
+ 92
+
+
+
+
+
+ [NatB-79b]
+ National Bureau of Standards. Representations of Universal
+ Time, Local Time Differentials, and United States Time Zone
+ References for Information Interchange. Federal Information
+ Processing Standards Publication 59, U.S. Department of
+ Commerce / National Bureau of Standards, February, 1979.
+
+ [PosJ-79]
+ Jonathan B. Postel. INTERNET MESSAGE PROTOCOL. RFC 753,
+ Information Sciences Institute, March, 1979.
+
+ [SchP-79]
+ Peter Schicker. The Computer Based Mail Environment: An
+ Overview. Technical Report, Bell-Northern Research Ltd.,
+ Ottawa, Ontario, Canada, December, 1979.
+
+ [TasG-80]
+ Task Group X3S33 on Data Communications Formats, ANSI
+ Subcommittee X3S3 on Data Communications. Third Draft
+ Proposed American National Standard for Heading Format
+ Structure for Code Independent Communication Headings. ANSI
+ document X3S37/80-01, Computer and Business Equipment
+ Manufacturers Association, 1980.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 93
+
+
+
+
+
+ INDEX
+
+
+
+
+
+ ASCII-String 29, 30, 42, 45, 47, 49, 53, 54, 55, 57,
+ 59, 63
+ Assignment 17, 22, 55
+ Attachments 17, 52
+ Audit trail 20
+ Author 14, 52
+
+ BASIC 13
+ BASIC Data Elements
+ ASCII-String 42, 57
+ Date 45, 59
+ End-of-Constructor 43, 60
+ Field 46, 60
+ Message 46, 61
+ BASIC fields
+ Cc 14
+ Reply-To 14
+ Subject 17
+ Text 17
+ BASIC syntactic elements 29
+ Bcc 14, 19, 20, 52
+ Bit numbering in octets 32
+ Bit-String 30, 37, 42, 44, 45, 47, 57, 58, 59, 63
+ Boolean 30, 43, 58
+
+ Cc 14, 19, 52
+ Chains of correspondence 24
+ Circulate-Next 15, 26, 53
+ Circulate-To 15, 26, 53
+ Circulation 26
+ Comment 30, 31, 38, 49
+ Comments 18, 53
+ Compliance requirements 34
+ Compressed 31, 37, 44, 49, 58
+ Compression identifier 44, 58
+ Compression Identifiers
+ NBS-Standard 49
+ Unspecified 49
+ Constructor data element 29, 30
+ Contents 32, 70
+ Cross Referencing 24
+
+ Data Element Contents 37, 38, 39, 81, 36, 39, 47, 63,
+ 36, 38, 39, 41, 42, 47, 57, 63, 81
+ Data Elements
+
+
+ 94
+
+
+
+
+
+ ASCII-String (BASIC) 42, 57
+ Bit-String (OPTIONAL) 42, 57
+ Boolean (OPTIONAL) 43, 58
+ Compressed (OPTIONAL) 44, 58
+ Date (BASIC) 45, 59
+ Encrypted (OPTIONAL) 45, 59
+ End-of-Constructor (BASIC) 43, 60
+ Extension (OPTIONAL) 45, 60
+ Field (BASIC) 46, 60
+ Integer (OPTIONAL) 43, 61
+ Message (BASIC) 46, 61
+ No-Op (OPTIONAL) 44, 61
+ Padding (OPTIONAL) 44, 62
+ Property (OPTIONAL) 47, 62
+ Property-List (OPTIONAL) 46, 62
+ Sequence (OPTIONAL) 47, 63
+ Set (OPTIONAL) 47, 63
+ Unique-ID (OPTIONAL) 47, 63
+ Vendor-Defined (OPTIONAL) 48, 64
+ Date 15, 45, 53, 54, 55, 56, 59
+ Dating 25
+ Delivery 9, 15, 54
+ Delivery Protocol 9
+ Delivery Slot 9
+
+ Encapsulating 22
+ Encrypted 31, 37, 45, 49, 59
+ Encryption identifier 45, 59
+ Encryption Identifiers
+ NBS-Standard 49
+ Unspecified 49
+ End-Date 15, 25, 53, 56
+ End-Of-Constructor 30, 36, 39, 43, 60
+ Extension 41, 45, 60
+
+ Field 10, 26, 29, 30, 31, 37, 46, 60, 61, 66
+ Field Identifier 46, 60
+ Field label presentation 29
+ Fields
+ Attachments (OPTIONAL) 52, 17
+ Author (OPTIONAL) 52, 14
+ Bcc (OPTIONAL) 52, 14
+ Cc (BASIC) 52, 14
+ Circulate-Next (OPTIONAL) 53, 15
+ Circulate-To (OPTIONAL) 53, 15
+ Comments (OPTIONAL) 53, 18
+ Date (OPTIONAL) 53, 15
+ End-Date (OPTIONAL) 53, 15
+ From (REQUIRED) 53, 14
+ In-Reply-To (OPTIONAL) 53, 16
+ Keywords (OPTIONAL) 53, 18
+
+
+ 95
+
+
+
+
+
+ Message-Class (OPTIONAL) 54, 17
+ Message-ID (OPTIONAL) 54, 16
+ Obsoletes (OPTIONAL) 54, 16
+ Originator-Serial-Number (OPTIONAL) 54, 16
+ Posted-Date (REQUIRED) 54, 15
+ Precedence (OPTIONAL) 54, 16
+ Received-Date (OPTIONAL) 54, 15
+ Received-From (OPTIONAL) 55, 17
+ References (OPTIONAL) 55, 16
+ Reissue-Type (OPTIONAL) 55, 17
+ Reply-To (BASIC) 55, 14
+ Sender (OPTIONAL) 55, 14
+ Start-Date (OPTIONAL) 55, 15
+ Subject (BASIC) 55, 17
+ Text (BASIC) 56, 17
+ To (REQUIRED) 56, 14
+ Warning-Date (OPTIONAL) 56, 15
+ From 12, 14, 23, 52, 53, 55
+
+ Globally unique identifiers 24
+
+ Identifier octet 33, 35, 32, 33, 36, 39, 40, 70
+ Identifiers
+ globally unique 24
+ In-Reply-To 16, 24, 53
+ Indefinite length code 35
+ Integer 30, 43, 47, 61, 63
+
+ Keywords 18, 53, 81
+
+ Length Code 34, 36, 32, 33, 34, 35, 36, 37, 39, 40,
+ 70, 71, 81
+ Long length code 35
+
+ Message Transfer System 8, 9, 17, 54
+ Message 10, 12, 29, 30, 31, 37, 46, 61
+ Message content 9
+ Message envelope 9
+ Message stores 25
+ Message Transfer System 9, 17, 20, 55, 8, 9, 10, 12,
+ 15, 16, 20, 54, 55
+ Message Types
+ NBS-Standard 50
+ Message-Class 17, 54
+ Message-ID 16, 24, 26, 53, 54, 55
+
+ NBS-Standard 49, 50
+ No-Op 44, 61
+ Numbering bits in octets 32
+
+ Obsoletes 16, 24, 54
+
+
+ 96
+
+
+
+
+
+ Octets
+ bit numbering in 32
+ OPTIONAL 13
+ OPTIONAL Data Elements
+ Bit-String 42, 57
+ Boolean 43, 58
+ Compressed 44, 58
+ Encrypted 45, 59
+ Extension 45, 60
+ Integer 43, 61
+ No-Op 44, 61
+ Padding 44, 62
+ Property 47, 62
+ Property-List 46, 62
+ Sequence 47, 63
+ Set 47, 63
+ Unique-ID 47, 63
+ Vendor-Defined 48, 64
+ OPTIONAL fields
+ Attachments 17
+ Author 14
+ Bcc 14
+ Circulate-Next 15
+ Circulate-To 15
+ Comments 18
+ Date 15
+ End-Date 15
+ In-Reply-To 16
+ Keywords 18
+ Message-Class 17
+ Message-ID 16
+ Obsoletes 16
+ Originator-Serial-Number 16
+ Precedence 16
+ Received-Date 15
+ Received-From 17
+ References 16
+ Reissue-Type 17
+ Sender 14
+ Start-Date 15
+ Warning-Date 15
+ OPTIONAL syntactic elements 29
+ Originator 11, 13, 15, 25, 52, 53, 55
+ Originator-Serial-Number 16, 25, 54
+
+ Padding 44, 62
+ Person 13
+ Posted-Date 12, 15, 26, 53, 54
+ Posting 9
+ Posting Protocol 9
+ Posting Slot 9
+
+
+ 97
+
+
+
+
+
+ Precedence 16, 54
+ Precedence categories 17
+ Precedence scheme 54
+ Presentation
+ field label 29
+ Primitive data element 30, 29, 30
+ Printing-Name 30, 38, 49, 76
+ Process 13
+ Properties
+ Comment 49
+ Printing-Name 49
+ Property 32, 37, 46, 47, 62
+ Property-Identifier 47, 62
+ Property-List 30, 32, 33, 38, 39, 40, 46, 62, 70
+
+ Qualifier 32, 33, 34, 36, 37, 39, 40, 42, 44, 45, 46,
+ 47, 48, 57, 58, 59, 60, 62, 64, 70
+ Qualifiers 37
+
+ Received-Date 15, 54
+ Received-From 17, 55
+ Recipient 11, 14, 17, 52, 53, 55, 56
+ Redistribution 17, 22, 55
+ References 16, 24, 55
+ Reissue-Type 17, 55
+ Reply 13, 23
+ Reply-to 14, 23, 53, 55
+ REQUIRED 13
+ REQUIRED fields
+ From 14
+ Posted-Date 15
+ To 14
+ Requirements
+ compliance 34
+ Role 13
+
+ Sender 14, 26, 55
+ Sequence 29, 30, 47, 63
+ Sequences 30
+ Serial Numbers 16, 24, 54
+ Set 30, 47, 63
+ Short length code 35
+ Slot 9
+ Start-Date 15, 25, 55
+ Subject 17, 55
+ Syntactic reissuing 22
+
+ Text 17, 26, 56
+ To 12, 14, 19, 26, 30, 56
+
+ Unique identifiers 24
+
+
+ 98
+
+
+
+
+ Unique-ID 47, 53, 54, 55, 63
+ Unspecified 49
+ User Agent 8, 9, 20
+ User interface 29
+
+ Vendor-Defined 41, 48, 64
+
+ Warning-Date 15, 25, 56
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 99
+
+