[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

Tweet
This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC841

UNKNOWN
      RFC 841
      
      
      FIPS Pub 98
      
      
      
      
      
      SPECIFICATION FOR MESSAGE FORMAT FOR COMPUTER
      BASED MESSAGE SYSTEMS
      
      
      
      
      
      
      
      
      
      
      
      
      
      27 January 1983
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      National Bureau of Standards
      
      
      This RFC is FIPS 98.  The purpose of distributing this document
as an RFC is to make it easily accesible to the ARPA research community. This RFC does not specify a standard for the ARPA
      Internet.
      
      
      
      
      
      

      
                        TABLE OF CONTENTS
      
      
      
      
                                                                   Page
      
      
      
      EXECUTIVE SUMMARY                                               5
      
      
      
      1.  INTRODUCTION                                                7
      
      
          1.1  Guide to Reading This Document                         7
          1.2  Vendor-Defined Extensions to the Specification         8
          1.3  The Scope of the Message Format Specification          8
          1.4  Issues Not Within the Scope of the Message Format      8
Specification
          1.5  Relationship to Other Efforts                          9
      
      
      
      2.  A SIMPLE MODEL OF A CBMS ENVIRONMENT                       10
      
      
          2.1  Logical Model of a CBMS                               12
2.2 Relationship to the ISO Reference Model for Open 14
Systems Interconnection
2.3 Messages and Fields 14
          2.4  Message Originators and Recipients                    15
      
      
      
      3.  SEMANTICS                                                  17
      
      
          3.1  Semantics of Message Fields                           17
3.1.1 Types of fields 17 3.1.2 Semantic Compliance Categories 18 3.1.3 Originator fields 18 3.1.4 Recipient fields 19 3.1.5 Date fields 20 3.1.6 Cross-reference fields 21 3.1.7 Message-handling fields 22 3.1.8 Message-content fields 23
               3.1.9  Extensions                                     23
      
      
      
      
      
      
                                      i

    3.2  Message Processing Functions                          24
3.2.1 Message creation and posting 24 3.2.2 Message reissuing and forwarding 25 3.2.2.1 Redistribution 26 3.2.2.2 Assignment 28 3.2.3 Reply generation 28 3.2.4 Cross-referencing 29 3.2.4.1 Unique identifiers 29 3.2.4.2 Serial numbering 30 3.2.5 Life span functions 30 3.2.6 Requests for recipient processing 31
3.2.6.1 Message circulation 31
          3.3  Multiple Occurrences and Ordering of Fields           31
      
      
      
      4.  SYNTAX                                                     34
      
      
          4.1  Introduction                                          34
4.1.1 Message structure 34 4.1.2 Data elements 35 4.1.2.1 Primitive data elements 36 4.1.2.2 Constructor data elements 36
4.1.3 Properties 36
4.1.3.1 Printing-names 37 4.1.3.2 Comments 37
4.1.4 Data compression and encryption 37
4.2 Overview of Syntax Encoding 37
4.2.1 Identifier Octets 38 4.2.2 Length code and Qualifier components 39 4.2.2.1 Length Codes 41 4.2.2.2 Qualifier 42 4.2.3 Property-List 44 4.2.4 Data Element Contents 44
4.3 Data Element Syntax 44
4.3.1 Data elements 45
4.3.1.1 Primitives 47 4.3.1.2 Constructors 49 4.3.1.3 Data Elements that Extend this Speci- 52
fication
4.3.2 Using data elements within message fields 53 4.3.3 Properties and associated elements 54 4.3.4 Encryption identifiers 54 4.3.5 Compression identifiers 54
               4.3.6  Message types                                  55
      
      
      
      
      
      
      
      
      
                                     ii

SUMMARY OF APPENDIXES                                          56
      
      
      
      APPENDIX A.  FIELDS -- IMPLEMENTORS' MASTER REFERENCE          57
      
      
      
      APPENDIX B.  DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE   63
      
      
      
      APPENDIX C.  DATA ELEMENT IDENTIFIER OCTETS                    71
      
      
      
      APPENDIX D.  SUMMARY OF MESSAGE FIELDS BY COMPLIANCE CATE-     72
                   GORY
      
      
          D.1  REQUIRED Fields                                       72
D.2 BASIC Fields 72
          D.3  OPTIONAL Fields                                       72
      
      
      
      APPENDIX E.  SUMMARY OF MESSAGE SEMANTICS BY FUNCTION          74
      
      
          E.1  Circulation                                           74
E.2 Cross-Referencing 74 E.3 Life Spans 74 E.4 Delivery System 74 E.5 Miscellaneous Fields Used Generally 75 E.6 Reply Generation 75 E.7 Reissuing 75
          E.8  Sending (Normal Transmission)                         75
      
      
      
      APPENDIX F.  SUMMARY OF DATA ELEMENT SYNTAX                    76
      
      
      
      APPENDIX G.  SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY   78
      
      
          G.1  BASIC Data Elements                                   78
          G.2  OPTIONAL Data Elements                                78
      
      
      
      
      
      
                                     iii

APPENDIX H.  EXAMPLES                                          80
      
      
          H.1  Primitive Data Elements                               80
          H.2  Constructor Data Elements                             82
          H.3  Data Elements that Extend this Specification          87
          H.4  Fields                                                88
H.5 Messages 90
          H.6  Unknown Lengths                                       94
          H.7  Message Encoding Using Vendor-Defined Fields          97
               H.7.1  Example of a JANAP-128 Message                 97
H.7.2 Encoding of Example using the FIPS Message 97
Format
H.7.3 Field Mappings of JANAP-128 to FIPS Format 101
               H.7.4  Vendor-Defined Fields                         101
      
      
      
      REFERENCES                                                    103
      
      
      
      INDEX                                                         105
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     iv

                         LIST OF FIGURES
      
      
      
      
      FIG. 1.    LOGICAL MODEL OF A COMPUTER-BASED MESSAGE SYSTEM    12
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION 27 FIG. 3. EXAMPLE OF MESSAGE CIRCULATION 32 FIG. 4. STRUCTURE OF IDENTIFIER OCTETS 39 FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH 40
CODES
FIG. 6. REPRESENTATION OF LENGTH CODES 42
      FIG. 7.    EXAMPLES OF QUALIFIER VALUES                        43
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                      v

                         LIST OF TABLES
      
      
      
      
      TABLE 1.    FIELDS USED IN MESSAGE PROCESSING FUNCTIONS        24
      TABLE 2.    HIGH-ORDER BITS IN THE IDENTIFIER OCTET            39
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     vi

                       Federal Information
Processing Standards Publication 98
27 January 1983
                         Announcing the Standard for
      
      
                               MESSAGE FORMAT
FOR
                       COMPUTER BASED MESSAGE SYSTEMS
      
      
      
      Federal  Information Processing Standards Publications are issued
by the National Bureau of Standards pursuant to section 111(f)(2) of the Federal Property and Administrative Services Act of 1949, as amended, Public Law 89-306 (79 Stat. 1127), Executive Order
      11717 (38 FR 12315, dated May 11, 1973), and Part 6 of  Title  15
      Code of Federal Regulations (CFR).
      
      Name  of  Standard.  Message  Format  for  Computer Based Message
      Systems (FIPS PUB 98).
      
      Category of Standard. Software Standard; Interchange Codes, Media
      and Data Files.
      
      Explanation.  This  standard  separates  information  so  that  a
Computer Based Message System can locate and operate on that information (which is found in the fields of messages). This is the first of a family of standards which will ensure information
      interchange among Computer Based Message Systems.
      
      Approving Authority. Secretary of Commerce
      
      Maintenance Agency. Department of Commerce,  National  Bureau  of
      Standards (Institute for Computer Sciences and Technology).
      
      Cross Index. Not Applicable.
      
      Related Documents.
      
      
         a. American   National   Standard   Code  for  Information
            Interchange (ASCII), X3.4-1977,FIPS PUBS 1-1.
      
         b. American National Standard  Code  Extension  Techniques
for Use with the 7-bit Coded Character Set of American National Standard Code (ASCII) for Information
            Interchange, X3.41-1974, FIPS PUB 35.
      
         c. National  Bureau  of Standards.  Calendar Date. Federal
            Information Processing Standards  Publication  4,  U.S.
      
      
      
      
                                      1

      Department  of Commerce / National Bureau of Standards,
            November, 1968.
      
         d. National Bureau of Standards. Data Encryption Standard.
Federal Information Processing Standards Publication 46, U.S. Department of Commerce/National Bureau of
            Standards, January, 1977.
      
         e. National Bureau of Standards. Representation  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.
      
         f. National  Bureau  of   Standards.   Representation   of
Universal Time, Local Time Differentials, and United States Time Zone References for Information Interchange. Federal Information Processing Standards Publication 59, U.S. Department of Commerce / National
            Bureau of Standards, February, 1979.
      
      
      Applicability.  This  message  format standard applies to Federal
departments and agencies in their acquisition and use of computer-based message systems (CBMS) and services in networked systems, except for certain single-processor systems. Specifically, the standard does not apply to a CBMS if it is a stand-alone system which is not interconnected with any other CBMS: nevertheless, conformance with the standard is recommended under these circumstances particularly if there is a possibility that use of another central processing unit, or interconnection with another system, will be required in the future. Where a new CBMS node is incorporated into an existing network, the standard applies at the interface between CBMS's. In this instance, previously existing nodes may accommodate the standard either through retrofit or by the use of a translator. In addition, networks that are established strictly for the purpose of supporting research in computer science or communications are
      exempt from complying with this standard.
      
      Subcommittee TC97/SC16  of  the  International  Organization  for
Standardization (ISO) has developed a reference model for describing communications between "open" systems. (ISO/TC97/SC16 DIS7498) This model is known as the ISO Reference Model for Open Systems Interconnection (OSI). It divides communications protocols into seven layers, ranging from physical interconnection at the lowest layer to data exchange by
      applications programs at the top.
      
      The NBS message format deals with data  used  by  an  application
      within  a  system; it is not a protocol.  Messages defined by the
      
      
      
      
                                      2

NBS   message   format   would   be  manipulated  by  a  layer  7
      (Application) protocol.
      
      A message as referenced by the NBS message format is  a  unit  of
communication from an originator to a recipient, exclusive of any message heading or control information (often referred to as a message envelope). An originator and recipient are typically people but may be roles or processes. A role identifies a function within an organization as opposed to an individual who performs that function. A process refers to a computer process
      that might originate or receive a message.
      
      Special Information. Certain characteristics distinguish  a  CBMS
from other systems for sending messages. Originators and recipients may be terminal users or processes (discrete software). A system in which the originator addresses a particular terminal device rather than a particular recipient is not considered to be a CBMS. The recipient's system need not be available when the originator sends a message. The message can be stored in the originator's system or at an intermediate node in the network until the recipient's system becomes available. In addition, a CBMS offers both message creation and message processing facilities as part of the system. A CBMS offers text editing facilities to assist the user in the preparation of a message. The recipient CBMS stores the message until the recipient chooses to read it. Message systems which do not
      provide these minimum functions are not considered CBMS's.
      
      The intent of the message format standard is to  allow  users  of
different computer based message systems to send messages to each other. The standard does not make demands on the message transfer system except that it transports messages transparently. The standard makes some simple demands on the CBMS. The CBMS must recognize fields within the message, process fields in predetermined ways, create messages in the correct form, and recognize and create data elements of messages in the correct format. The standard does not dictate or constrain the services that the CBMS provides for users, or the way that messages are stored, represented, manipulated, or presented to the user by the
      CBMS.
      
      The standard does constrain the format  of  the  message  at  the
interface between systems. This guarantees that, whatever the source of the message, it arrives at the receiving system in the standard format. The message format standard separates information into fields so that the CBMS can locate and operate on that information. The message is converted from the format used within the originator's CBMS to the standard format (if different) on leaving the originator's CBMS. The message is converted from the standard format to the format used within the
      recipient's CBMS (if different) on entering the recipient's CBMS.
      
      
      
      
                                      3

Specifications.  Federal  Information Processing Standard (FIPS),
      Message Format for Computer Based Message Systems (affixed).
      
      Qualifications. None
      
      Implementation Schedule. All  applicable  equipment  or  services
ordered on or after 24 months from the date of issuance of this FIPS PUB, and all CBMS development initiated inhouse on or after
      12  months  from the date of issuance of this FIPS PUB must be in
conformance with this standard unless a waiver has been obtained in accordance with the procedure described below. An exception to this standard is made when procurement actions are into the
      solicitation phase on the date of issuance of this FIPS PUB.
      
      Waivers.  Heads  of agencies may request that the requirements of
this standard be waived in instances where it can be clearly demonstrated that there are appreciable performance or cost advantages to be gained and that the overall interests of the Federal Government are best served by granting the requested waiver. Such waiver requests will be reviewed by and are subject to the approval of the Secretary of Commerce. The waiver request must address the criteria stated above as the justification for
      the waiver.
      
      Forty-five  days should be allowed for review and response by the
Secretary of Commerce. Waiver requests shall be submitted to the Secretary of Commerce, Washington, D.C. 20230, and labeled as a Request for a Waiver to a Federal Information Processing Standard. No agency shall take any action to deviate from the standard prior to the receipt of a waiver approval from the Secretary of Commerce. No agency shall begin any process of implementation or acquisition of non-conforming equipment unless
      it has already obtained such approval.
      
      Where to Obtain Copies. Either paper or microfiche copies of this
Federal Information Processing Standard, including technical specifications, may be purchased from the National Technical Information Service (NTIS) by ordering Federal Information Processing Standard Publication (FIPS-PUB-98), Message Format for Computer Based Message Systems. Ordering information, including prices and delivery alternatives, may be obtained by contacting the National Technical Information Service (NTIS), U. S. Department of Commerce, Springfield, Virginia 22161, telephone number (703) 487-4650. Payment may be made by check, money
      order, purchase order, credit card, or deposit account.
      
      
      
      
      
      
      
      
      
      
                                      4

                                                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 inter- connections, another specifies how information travels between CBMSs, another specifies form and meaning of messages being interchanged. The highest level specifies operations on a message. Each of these levels would be covered by a different
      standard.
      
           This  message format specification addresses only the issues
of form and meaning of messages at the points in time when they are sent from one CBMS and received by another. Messages are composed of fields, containing different classes of information. These fields contain information about the message originator, message recipient, subject matter, precedence and security, and references to previous messages, as well as the text of the message. Standard formats (syntax) for messages provide a basis for the contents of messages generated by one CBMS to be processed by another CBMS. Standard meanings (semantics) for the components of a message facilitate standard interpretation of a message, so that everyone receiving a message gets the meaning
      intended by its sender.
      
           Each CBMS that implements this message format  specification
will be compatible with any other CBMS that implements the specification, provided that the use of optional fields and data elements is negotiated in advance. This ensures that the contents of a message posted by one CBMS can be received and
      interpreted by a different CBMS.
      
           This  message  format  specification has been developed as a
result of examining CBMSs currently in use in commercial and research environments. Three major design perspectives helped
      shape the message format specification.
      
      
        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.
      
      
      
      
                                      5

                                                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.
      
      
      
                                      6

                                                        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 organi- zations use either their own or a commercially available CBMS. The design and complexity of these systems vary widely. This message format specification provides a basis for interaction between different CBMSs by defining the format of messages passed
      between them.
      
      
      
      1.1  Guide to Reading This Document
      
      
           The method of presenting the material in this  specification
is to combine the technical specification with tutorial infor- mation. This approach has been taken to place the specification
      in context and improve its readability.
      
           The  core of the technical information in the document is in
Section 2, "A Simple Model of a CBMS Environment"; Section 3.1, "Semantics of Message Fields"; Section 4.2, "Overview of Syntax Encoding"; and Section 4.3, "Data Element Syntax". Appendixes A and B consolidate the technical information. These appendices are designed for ease of reference and should be read in conjunction with the body of the report for a complete understanding of the message format presented in the specifi-
      cation.
      
           Section  2  presents  a simple model of operation of a CBMS.
Section 3 discusses the components of messages and their meaning (semantics), including discussions of the recommended relationship between message components and CBMS user functions. (See Section 3.2.) Section 4 presents details of the form
      (syntax) required for components of a message.
      
           Appendix D summarizes the components of  messages  according
to whether they are required or optional for CBMSs implementing the message format specification. Appendix E organizes the message components according to the functional class of the components. Appendix F provides an overview of the syntactic
      elements defined by this message format specification; Appendix G
      
      
      
      
                                      7

                                                      Section 1.1
      
      summarizes  those elements according to whether they are required
or optional for a CBMS implementing the message format specifi- cation. 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 Specifi- cation

           The  message  format  specification  does  not  address  the
following issues, some of which are being covered by other NBS standards development programs at the Institute for Computer Sciences and Technology (ICST). (See [BlaR-80] for a description
      of the ICST network protocols program.)
      
      
        o  The nature of a message transfer system, except to state
           the assumption that it transfers messages transparently.
      
      
      
                                      8

                                                      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  Certain message processing functions that CBMSs  provide
for users, e.g., those concerned with the creation and
           editing of text.
      
        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 docu-
ments and the current state of many CBMSs available both in industry and the research community. These documents include the standardization efforts in the ARPANet [CroD-77, PosJ-79] and the CCITT, proposed ISO and ANSI header format standards [TasG- 80, ISOD-79], the work of IFIPS Working Group 6.5, and various papers about the general nature of mail systems, addressing, and
      mail delivery.  (See [FeiE-79] for references.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                      9

                                                        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  mes-
           sage 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 mes- sage 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
      
      
      
      
                                     10

                                                        Section 2
      
           of  data  that  an originator wishes to send to a recip-
ient. 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 prepa- ration 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 impor-
tant 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 they offer little in the way of other recipient processing facilities. Most CBMSs offer
           at least the following recipient processing facilities:
      
      
             .  The  ability  to retain a copy of a message on-line
                after it has been read.
      
             .  The ability to examine or  delete  stored  messages
                individually.
      
             .  The ability to organize messages using some form of
                electronic "file folder."
      
             .  The  ability  to  determine  if a message is recent
(has arrived since the last time the recipient used the CBMS) or unseen (has never been examined by the
                recipient).
      
             .  The  ability  to  summarize  stored  messages.    A
summary usually includes information such as whether the message is recent or unseen, when it was received, its length, who it is from, and its
                subject.
      
             .  The ability to retrieve a stored message based upon
      
      
      
      
                                     11

                                                        Section 2
      
                one  or  more of its attributves (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  mes-
sages without having to enter a new list of recip-
                ients.
      
      
      
      2.1  Logical Model of a CBMS
      
      
           CBMS facilities for message creation, transfer,  and  recip-
ient processing are reflected in a logical model of a CBMS developed by IFIP Working Group 6.5. (An essentially identical model is being used by CCITT Study Group VII, Question 5, regarding Message Handling Systems [CCIT-82].) The model consists of a Message Transfer System and a number of User
      Agents.  (See Figure 1.)
      
      
      
                    |                  |
                    |     *************     |
      *********  ------>  *  Message  *  ------->  *********
      * User  *  Posting  * Transfer  *  Delivery  * User  *
      * Agent *  Protocol *  System   *  Protocol  * Agent *
      *********  <------- *************  <-------  *********
                    |                       |
                    |                       |
                 Posting                Delivery
                  Slot                    Slot
      
                          Message Flow
      Originator --------------------------------> Recipient
      
      
      
      FIG. 1.  LOGICAL MODEL OF A COMPUTER-BASED MESSAGE SYSTEM
      
      
           A User Agent (UA) is a functional entity that acts on behalf
of a user, assisting with creating and processing messages and
      communicating with the Message Transfer System.
      
           The Message Transfer System(MTS) is an entity that accepts a
      
      
      
      
                                     12

                                                      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  trans-
ferred is called a Slot. The Posting Slot is the point at which responsibility for a message passes from an originator's User Agent to the Message Transfer System; the Delivery Slot is the point at which responsibility for a message passes from the
      Message Transfer System to a recipient's User Agent.
      
           The  model  divides  messages  into  two  parts, the message
content and the message envelope. The message content is the information that the originator wishes to send to the recipient; this message format specification deals solely with the message content. The message envelope consists of all the information necessary for the Message Transfer System to do its job; this message format specification does not specify the message envelope. Some of the data appearing on the message envelope could be redundant with some data found in the message content. The Message Transfer System is not expected to examine the message content unless it is told to do so by the originator's or
      recipient's User Agent.
      
           This  message format specification places no restrictions on
the Message Transfer System itself, except that it be able to transfer messages between originating and receiving UAs without reading or altering the contents of messages unless otherwise instructed by the UAs. In addition, this message format specifi- cation does not dictate the form or nature of any protocol used by the Message Transfer System. Finally, this message format specification does not specify the content or form of the message envelope. That is, the message format specification defines the format for the contents of messages, not the manner in which they
      are transmitted.
      
           Many of today's commercially available CBMSs incorporate all
of the facilities represented in the logical model. Their architectures may reflect the economies that can be taken when implementing systems that are self-contained. For example,
      stand-alone  systems  that  store  messages  in  a single central
      
      
      
      
                                     13

                                                      Section 2.1
      
      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.
      
      
      
2.2 Relationship to the ISO Reference Model for Open Systems Interconnection

           Subcommittee TC97/SC16 of the International Organization for
Standardization (ISO) has developed a reference model for describing communications between "open" systems [ISOD-82]. This model is known as the ISO Reference Model for Open Systems Interconnection (OSI). It divides communications protocols into seven layers, ranging from physical interconnection at the lowest
      layer to data exchange by application programs at the top.
      
           This message format specification deals with data used by an
application within a system. Thus, the message format being specified here is not a protocol. Since it is not a protocol, it lies outside of the model for open systems interconnection. User Agents are application layer entities (layer 7), however, and the protocols used by a message transfer system are above the session
      layer (layer 5).
      
      
      
      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.)
      
      
      
      
                                     14

                                                      Section 2.3
      
           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.
      
      
      
      2.4  Message Originators and Recipients
      
      
           This message format specification refers to  message  origi-
nators and recipients. These terms were defined functionally in Figure 1. When the message format specification refers to the identity of a message originator or recipient, it means "that information which uniquely identifies the message originator or recipient within the domain of the given message system." The syntax and semantics of message addressing are not within the
      scope of the message format specification.
      
           Originators  and  recipients can be people, roles, processes
      or groups.
      
           People.  People as originators and recipients  are  specific
      individuals.
      
           Roles.    Roles  identify  functions within organizations as
opposed to the specific individuals who perform them. For example, consider a newspaper that produces both morning and evening editions and therefore operates with more than one shift. Someone wishing to contact the city desk would send a message to the city desk role rather than trying to determine exactly who was assigned to the city desk at a specific time. (Of course, messages can usually be sent to the individuals directly whether
      or not they are actually performing a role at the time.)
      
           Processes.  A process in a computer could serve as either an
originator or a recipient for messages. A computer system might originate a message to notify a recipient about the status of some task. For example, an archive utility could notify users about files that have been archived; a distributed file system could notify a user that a remote file has been deposited on a local file system. Messages could be used by computer systems to warn about some impending condition or even to monitor the performance of the computer itself. Some computer processes may also be message recipients, taking action based upon message
      contents.
      
           In addition, some CBMSs allow messages to be sent to groups.
      A group is a predefined list of  message  recipients.    Using  a
      
      
      
      
                                     15

                                                      Section 2.4
      
      group   name  as  a  recipient  permits  message  originators  to
designate a potentially large number of recipients using a single recipient identifier. This makes using the CBMS more convenient
      and accurate.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     16

                                                        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 section. 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
of 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
      
      
      
      
                                     17

                                                    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 the message, or summarize
           the message.  (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, mes-
      sage fields have been divided into three categories:
      
      
      REQUIRED  These fields must be present in all messages  and  must
be processed by message receiving programs as defined
                by the message format specification.
      
      BASIC     These fields need not be present in  all  messages  but
when they do appear, they must be processed by message receiving programs as defined by the message format
                specification.
      
      OPTIONAL  These  fields  need  not be present in all messages and
may be ignored by message receiving programs. The exact meaning of "ignored" is not specified by the message format specification. However, a CBMS must recognize the existence of an optional field (that is, optional fields should not cause errors) and must not process the field in a manner contrary to the semantics defined for that field by the message format specifi- cation. It is left to the discretion of a recipient's CBMS what action is to be taken when an instance of a
                locally unimplemented optional field is detected.
      
      
           (Syntactic compliance is defined in Section 4.1.2.)
      
      
      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.)
      
      
      
                                     18

                                                    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 field is discouraged when the contents of the Author
                field and the From field would be completely redundant.
      
      Sender                   (OPTIONAL)
      
                This field identifies the agent who sent  the  message.
It is used either when the sender is not the originator responsible for the message or to indicate who among a group of originators responsible for the message actually sent it. Use of the Sender field is discouraged when the contents of the Sender field and From field would be completely redundant. The sender field may specify only one originator identity and
                appear only once in a message.
      
      
      3.1.4  Recipient fields
      
      
           Message  recipients  may  be  people,  roles,  processes, or
groups. (See Section 2.4). Recipient fields identify who or
      what is to receive the message.
      
      To                       (REQUIRED)
      
                This  field  identifies  the  primary  recipients  of a
                message.
      
      Bcc                      (OPTIONAL)
      
                This  field  identifies  additional  recipients  of   a
message (a "blind carbon copies" list). The contents of this field are not to be included in copies of the message sent to the primary and secondary recipients. See section 3.2.1 for further discussion of the use of
                blind carbon copies lists.
      
      
      
                                     19

                                                    Section 3.1.4
      
      Cc                       (BASIC)
      
                This field identifies secondary recipients of a message
                (a "carbon copies" list).
      
      Circulate-Next           (OPTIONAL)
      
                This field is used in conjunction with the Circulate-To
field. (See Section 3.2.6.1.) It identifies all recipients in a circulation list who have not received
                the message.
      
      Circulate-To             (OPTIONAL)
      
                This   field  identifies  recipients  of  a  circulated
message. (See Section 3.2.6.1.) It is used in
                conjunction with the Circulate-Next field.
      
      
      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)
      
                This field is also called Delivery date.    This  field
may be added to a message by the recipient's message
                receiving program.  It indicates when the message  left
      
      
      
      
                                     20

                                                    Section 3.1.5
      
                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 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 replaces.
      
      Originator-Serial-Number (OPTIONAL)
      
                This field contains one or more serial numbers assigned
by the message's originator. Messages with multiple recipients should have the same value in the
                Originator-Serial-Number field.
      
      
      
      
      
                                     21

                                                    Section 3.1.6
      
      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 system. A message originator, however, can include precedence information in a message. One example of precedence categories are those used by the U.S. Military: "ROUTINE," "PRIORITY," "IMMEDIATE," "FLASH
                OVERRIDE,"  and "EMERGENCY COMMAND PRECEDENCE."
      
      Message-Class            (OPTIONAL)
      
                This  field  indicates  the  purpose of a message.  For
example, it might contain values indicating that the
1
                message is a memorandum or a data-base entry.
      
      Reissue-Type             (OPTIONAL)
      
                This   field   is  used  in  conjunction  with  message
encapsulating (see Section 3.2.2) to differentiate
                between messages being assigned or redistributed.
      
      Received-From            (OPTIONAL)
      
                This  field  contains  a  record  of  a  message's path
through a message transfer system. The recipient's message receiving program could store here any information about the transfer that it obtained
                from a message transfer system.
      _______________
      
        1
The message format specification is not intended to be used as
a specification for exchanging data-base records. Messages,
      however, sometimes contain data from or for a database.
      
      
      
      
                                     22

                                                    Section 3.1.7
      
      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.
      
      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 specifi- cation or any extension or successor to it is a vendor- defined field. Names for vendor-defined fields could be preempted by extensions to this message format
                specification.
      
      
      
      
      
                                     23

                                                    Section 3.1.9
      
      extension-field
Any field that is defined in a document published as a formal extension or replacement to this message format
                specification.
      
      
      
      3.2  Message Processing Functions
      
      
           A  CBMS  provides three basic classes of functions: creating
messages, transmitting messages to their recipient, and post- receipt processing. Although the message format specification does not define the number or nature of user functions in CBMSs, the meanings for the fields clearly assume certain kinds of functions. For example, fields specifying recipients of replies to messages assume some kind of reply function; fields specifying
      message life span assume some kind of date processing functions.
      
           This  section  provides  more  detail on the processing that
might be done by these kinds of functions, discussing the message fields that would be used and how they would be used. (See
      summary in Table 1.)
      
      
      
      Processing Function    Fields Involved
      
      Message creation       Author, From, Sender, To,
        and posting          Cc, Bcc
      Message reissuing      Reissue-Type
Reply generation Reply-To Cross-referencing Message-ID, In-Reply-To, References,
Obsoletes, Originator-Serial-Number
Life span functions Start-Date, End-Date,
Warning-Date
      Recipient processing   Circulate-To, Circulate-Next
      
      
      
      TABLE 1.  FIELDS USED IN MESSAGE PROCESSING FUNCTIONS
      
      
      3.2.1  Message creation and posting
      
      
           Messages  can  be  created  either  by reissuing an existing
message to a new recipient (see Section 3.2.2) or by creating a new message. The process of message creation might mean that some fields of a new message are filled in from the contents of some other message. Reply functions (Section 3.2.3) provide an
      example of this.
      
      
      
                                     24

                                                    Section 3.2.1
      
           Different  individuals could be involved in different phases
of originating a message: creating it, taking responsibility for it, and explicitly interacting with a CBMS to send it to its recipient. One or more individuals may create a message (that is, write, but not necessarily enter it into the CBMS); they are said to be the message's authors, identified by the Author field. One or more individuals may take responsibility for its contents and the decision to post it; they are identified by the From field. One individual explicitly posts a given message; this person is called the message's sender (identified by the Sender
      field).
      
           The sender and author(s) are often, but not always,  respon-
sible for the message. A common case in which the sender is not responsible for the message is when a secretary enters and posts messages for someone else. An example of a situation in which a message's author is not responsible for the message itself is when an administrative assistant prepares a report that is sent
      under a manager's signature.
      
           The use of the Cc field is  identical  to  current  business
practice. This field contains the formal secondary recipients of
      the message.
      
           Messages  containing  Bcc  fields  are  treated specially by
CBMSs. The contents of this field are not included in copies of the message sent to the recipients other than the originator who are not included in the Bcc field itself. Some systems include the contents of the Bcc field only in the originator's copy; others include all or part of the Bcc field in the copies sent to the recipients indicated in the Bcc field. This specification
      does not indicate exactly how the Bcc field is to be treated.
      
      
      3.2.2  Message reissuing and forwarding
      
      
           Reissuing and forwarding both serve the general user goal of
passing a message on to a new set of recipients. Forwarding is the term used for an informal mechanism, which CBMSs implement by copying some or all of the original message into the contents of a field in the new message. Reissuing is the term used for a formal mechanism to ensure that the message being passed on never loses its integrity as a previously sent message. CBMSs use reissuing to implement several different functions, depending on
      the purposes being served:
      
      
        o  Redistribution.  Making others aware of the complete and
           unaltered contents of the message.
      
      
      
      
      
                                     25

                                                    Section 3.2.2
      
        o  Assignment.  Delegating the responsibility for a message
           to somebody else.
      
      
      These purposes are exemplified in Figure 2.
      
           When  a  CBMS examines a forwarded message, it cannot always
distinguish the old message from what was added when the forwarding took place. In addition, the forwarded information might no longer have the form of a message. This is usually because the format of the message has been changed (for example, to pure unformatted text). (See Figure 2 for an example of how a CBMS might forward a message.) In contrast, a reissued message can always be separated from its enclosing message and never
      loses its identity as a correctly formed message.
      
           This  specification  provides  the  Reissue-Type  field  for
supporting reissuing. Forwarding, since it is an informal means of serving the purpose of passing on information, has no
      supporting fields in the specification.
      
           This  specification  provides  for  reissuing of messages by
encapsulating. This method embeds the entire original message
      inside  a  new  message.  Encapsulating adds structure around the
      
             2
      message .  This allows any part of it to be easily extracted.
      
           This  procedure for passing on previously sent messages is a
matter of organizational policy and has authentication as an associated issue. Each organization must decide if the CBMS it
      acquires should support reissuing or simply supply forwarding.
      
      
      3.2.2.1  Redistribution
      
           Redistribution is a CBMS function for sending  the  original
contents of a message intact and unchanged to new recipients. A redistributed message is identical to the original message with the exception of added information about the reissuing. For reissuing with this purpose, the Reissue-Type field contains the ASCII string "Redistribution." The original message has been
      included directly in a new message.  (See Figure 2.)
      
      
      _______________
      
        2
A message can contain another message, and that message can
contain another message, and so on to any depth of encapsulating.
      This can occur by reissuing a message repeatedly.
      
      
      
      
                                     26

                                                  Section 3.2.2.2
      
      
                            The Original Message
John Doe wishes Jane Jones to get a copy of the following message:
Message:
Field: From "Jean Smith" Field: Posted-Date "27 January 1983" Field: To "John Doe" Field: Subject "Next Project Meeting"
                        Field: Text "The agenda for ..."
      
                               Redistribution
Message:
Field: From "John Doe" John Doe is responsible Field: Posted-Date "28 January 1983" for the redistribution. Field: To "Jane Jones" Field: Reissue-Type "Redistribution" This message directly Message: incorporates a Field: From "Jean Smith" redistributed message. Field: Posted-Date "27 January 1983" Field: To "John Doe" Field: Subject "Next Project Meeting"
          Field: Text "The agenda for ..."
      
                                 Forwarding
Message:
Field: From "John Doe" Field: Posted-Date "28 January 1983" Field: To "Jane Jones" Field: Text A realization of the
"From Jean Smith original message is
To John Doe copied into the Text field. Sent on 27 January 1983 Note that John's CBMS Subject Next Project Meeting has chosen to represent
it as a text string.
           The agenda for ..."
      
      
      
      FIG. 2.  MESSAGE FORWARDING AND REDISTRIBUTION
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     27

                                                  Section 3.2.2.2
      
      3.2.2.2  Assignment
      
           Assignment is the process of designating responsibility.  In
some organizations, formal message traffic is distributed to one or more parts of the organization (called offices) where it is directed to the appropriate individuals or other offices for final disposition. Assignment is done by reissuing a message with the Reissue-Type field containing the ASCII string "Assigned." A message which contains this field is to be interpreted as meaning that the addressees in the "To" field have had the reissued message assigned to them for some action. Any addressee in the "Cc" field has had the message assigned for information. The "From" field records who assigned the message and the "Posted-Date" field records when the message was
      assigned.
      
      
      3.2.3  Reply generation
      
      
           Reply  generation  involves creating a new message in direct
reply to some other message by drawing on the contents of fields in the other message to fill fields in the new message. Many CBMSs provide reply facilities that determine the intended recip-
      ients of a reply.
      
           A Reply-To field is defined by this message format  specifi-
cation. When a message contains a Reply-To field, the CBMS should send replies to the recipients designated in the Reply-To field instead of to the recipients designated in the From field. This statement applies to original messages only, not to reissued messages. The message format specification makes no
      recommendations concerning replies to reissued messages.
      
           Reply-To has several possible applications:
      
      
        o  The  individual(s) responsible for the message might not
have regular access to a CBMS and would indicate an
           alternate recipient, for example, a secretary.
      
        o  The people responsible for receiving responses might not
be the people who were responsible for creating the
           message.
      
        o  Discussion and conference groups could use this  feature
to ensure correct distribution of any submission by having the conference group itself designated in the
           Reply-To field.
      
      
      
      
      
      
                                     28

                                                    Section 3.2.3
      
           When  the  message  does  not  contain a Reply-To field, the
recipient should reply to the originators enumerated in the From field. The sender and authors should not be added automatically
      to the list of those receiving the reply.
      
           Replies could also be sent to the other  recipients  of  the
original message. Vendors might offer additional reply facil- ities, depending on their view of users' organizational require-
      ments.
      
      
      3.2.4  Cross-referencing
      
      
           A  CBMS  message  may  include  designator(s) which identify
other message(s). The designators are used to refer to related messages so that all information in a chain of correspondence can be determined by a CBMS user. The designator used to identify and cross-reference messages can take either of two forms, unique
      identifiers or serial numbers.
      
      
      3.2.4.1  Unique identifiers
      
           Unique identifiers are machine-generated  and  are  intended
primarily for processing by computers. While they could be examined by a human user, unique identifiers are not necessarily
      useful or convenient for people.
      
           Unique  identifiers  occur  in  several  contexts.  They are
often used to identify the contents of idual messages unambiguously. When unique identifiers are used this way, they are called message identifiers. Different versions of a message receive new message identifiers; an example of this is reissuing
      a message with comments.
      
           When a CBMS generates a message identifier, it must be  able
to guarantee that it is unique, both within the domain of the individual CBMS and globally, across all connected CBMSs. CBMSs could generate globally unique identifiers in several ways, all of which require prior agreement on behalf of the connected CBMSs. One method is to assign each connected CBMS a unique code. A CBMS then generates unique identifiers by using its code as a prefix to some other value that it can guarantee to be unique within its domain. (This second value could be a counter
      or a timestamp/user-id combination.)
      
           A CBMS can provide functions for tracing  chains  of  corre-
spondence by using unique identifiers. The message format specification defines fields for which a CBMS provides unique identifiers as values. They are Message-ID, References,
      Obsoletes, and In-Reply-To.  (See Section 3.1.6.)
      
      
      
                                     29

                                                  Section 3.2.4.1
      
      3.2.4.2  Serial numbering
      
           Serial  numbers  are  for  users to maintain a personal num-
bering system for messages. The numbers are composed of both letters and digits so that users could maintain several sets of sequences concurrently (for example, A1, A2, A3... and B1, B2,
      B3...).
      
           Serial  numbers  are  assigned  at  a  defined  point in the
history of a message. Serial numbers are not unique identifiers; they differ from unique identifiers in that they are not neces- sarily generated or processed by a CBMS. They are designed to be entered and read by CBMS users. They can be as simple or complex as the user requires. Serial numbers are intended to be used to designate messages about a specific topic, or messages a given user has sent. Serial numbers are intended to be a permanent
      part of the message, just as unique identifiers are.
      
           A CBMS can provide functions  allowing  originators  to  add
serial numbers to messages. Originator-Serial-Number is the field provided for an originator to add a serial number to a
      message before sending it.
      
      
      3.2.5  Life span functions
      
      
           Messages  have life spans, usually delimited by the creation
date and the time when the last copy of the message is destroyed. Messages could be meaningless before a certain time or irrelevant after a certain time. For example, a reminder to attend a meeting on 5 June loses most of its value on the sixth; a reminder to attend that same meeting may be of little use on 5
      May (although not for the same reason).
      
           A CBMS can define a message's life span explicitly using the
Start-Date and End-Date fields. A third field, Warning-Date, when used in conjunction with the End-Date, may be used to signal the approach of the End-Date. Warning-Date may also stand alone
      and be used by a periodic warning (alarm clock) mechanism.
      
           A  CBMS  could  use  these fields to help users manage their
message stores. For example, a message whose start date has not yet passed could be bypassed by a retrieval command unless the user requested such messages explicitly. A CBMS could use the end date to help with message store housekeeping either by archiving or deleting the expired messages automatically or by asking the user for some action to be taken on them. The warning date could be used to remind the user automatically of an
      impending end date, such as a meeting reminder.
      
      
      
      
      
                                     30

                                                    Section 3.2.6
      
      3.2.6  Requests for recipient processing
      
      
           Recipients  have  a  wide variety of needs for examining and
processing a message, ranging from automatic output on some specified device to the execution of a program embedded in the message itself. Because many of these needs are highly specialized, and support for them not widely implemented, this message format specification does not constrain the requests for
      processing that may be included in a message.
      
           The  message  format  specification  does provide two fields
that permit an originator to request circulation list processing from the recipient. These fields are Circulate-To and Circulate-
      Next.
      
      
      3.2.6.1  Message circulation
      
           Message  circulation  involves serial distribution of a mes-
sage to its recipients, based on a distribution list that is part of the message. The message is delivered first to the first recipient on the distribution list. This recipient, or someone the recipient delegates, sends the message on to the second recipient on the list, perhaps after commenting on or adding to the message. This continues until all recipients on the
      distribution list have received the message.
      
           This  message  format  specification  provides two fields to
support message circulation. The Circulate-To field contains the complete distribution list, indicating the full set of recip- ients, and the Circulate-Next field indicates which recipients have not seen the message. See Figure 3 for an example of
      message circulation using these two fields.
      
      
      
      3.3  Multiple Occurrences and Ordering of Fields
      
      
           Most  message  fields may occur more than once in a message;
the exceptions are the Posted-Date, Sender, and Message-ID fields, which may occur once, at most. What this means is that a received message may contain any number of instances of a particular field (such as the "To" field). If a message contains more than one instance of a particular field, that field "occurs multiply" and that message has "multiple occurrences" of that
      field.
      
           A particular instance of a message field is  not  superseded
by later instances of the same field. The To field is an example
      of this.
      
      
      
                                     31

                                                      Section 3.3
      
      -----------------------------------------------------------------
      
      
           A  message  originator wishes to circulate a message to
recipients A, B and C. The originator includes the
           following fields in the message:
      
                     To:              A
Circulate-To: A, B, C
                     Circulate-Next:  B, C
      
      
           When  recipient  A  or  someone  A delegates causes the
message to be further circulated, the message is sent to the first address in the Circulate-Next field, and
           that name is removed from that field:
      
                     To:              B
Circulate-To: A, B, C
                     Circulate-Next:  C
      
      
           B now sends the message on to its final recipient:
      
                     To:              C
                     Circulate-To:    A, B, C
      
      
      FIG. 3.  EXAMPLE OF MESSAGE CIRCULATION
      
      
      -----------------------------------------------------------------
      
      
           Multiple occurrences of a field are not  necessarily  equiv-
alent to a single field containing the concatenated contents of the several instances of the given field. For example, with the Text field, concatenating the contents of several instances might lose important distinctions between the contents. A single message could be used to send three different documents, each one in a different Text field. However, putting the three documents into a single Text field would make it much more difficult to
      extract any individual document.
      
           Encapsulated  messages  are  exceptions  to   the   multiple
occurrences rule. For example, the To field in an encapsulated message is not a multiple occurrence of the To field in the
      enclosing message.
      
           The fields found in a single message may occur in any order.
      The  order  in  which they occur does not necessarily reflect the
      
      
      
      
                                     32

                                                      Section 3.3
      
      order  in  which  they  were  created.  Nor does it constrain the
order in which the message recipient examines, processes, or
      displays them.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     33

                                                        Section 4
      
      4.  SYNTAX
      
      
           This section begins with an introduction to the concepts and
elements that constitute the syntax for messages. The second section presents an overview of the encoding scheme. The third
      section describes in detail the elements of the message syntax.
      
      
      
      4.1  Introduction
      
      
           This  specification  defines syntactic requirements for mes-
sages when they are passed from one CBMS to another. The
      specification is designed to meet the following goals.
      
      
        o  Provide a concise, flexible representation scheme.
      
        o  Simplify message parsing.
      
        o  Support non-textual components in messages (for example,
3
           facsimile, graphics, or speech ).
      
      
      4.1.1  Message structure
      
      
           Messages   have   two  classes  of  components,  fields  and
messages. A field corresponds to one of the semantic components defined in this message format specification. A message is
      simply another message.
      
           The type of a field in a message determines both its meaning
      and the form for its contents.  (See Section 4.3.2.)
      
           Fields in a  message  are  composed  of  syntactic  elements
called data elements. A Message data element is used to represent messages; a Field data element is used to represent fields. (The term "field" is simply a semantic construct,
      distinct  from  "Field  Data  Element,"  which  is  a   syntactic
      
      _______________
      
        3
While this message format specification is not intended to be
used as a basis for the interchange of all facsimile information, it does recognize that CBMS messages may contain facsimile
      components.
      
      
      
      
                                     34

                                                    Section 4.1.1
      
      construct.)    Many  of the fields defined in this message format
specification are restricted to containing only one kind of data
      element.  (See Section 4.3.2.)
      
           Each  field defined in this message format specification has
been assigned a unique numeric identifier that is used in conjunction with the Field data element. Separate identifiers are provided for vendor-defined fields and for extending the identifier encoding space. A list of fields and identifiers
      appears in Section 4.3.2 and in Appendix C.
      
           Throughout the  message  format  specification,  fields  are
referred to by label name rather than by their numeric identi- fiers. Field labels are names like "Sender," "Warning-Date," or "Circulate-To." The field labels chosen for the specification are names that are in common use in current CBMSs. The specification does not require a CBMS to use these field labels
      in displaying fields to the user.
      
      
      4.1.2  Data elements
      
      
           For the purpose of determining compliance  with  the  syntax
defined in this specification, data elements are divided into two
      groups:
      
      
      BASIC     All   message  receiving  systems  must  process  these
syntactic elements, interpreting their values according
                to the message format specification.
      
      OPTIONAL  Message  receiving  systems  need  not  process   these
                syntactic elements in order to be in compliance.
      
      
           In   addition,   complying   CBMSs  must  meet  requirements
regarding their ability to process the components found inside data elements. These requirements are discussed in Section
      4.2.2.
      
           This message format specification  classifies  data  element
types as either primitives or constructors. Primitive data elements, such as ASCII-String, are basic building blocks. Constructor data elements, such as Message or Sequence, contain one or more primitive or constructor data elements. Some constructors, such as Sequence, may be composed of any other data element. Some, such as Message, may contain only certain data elements. Two data elements, Extension and Vendor-Defined, may be classified as either primitives or constructors, depending on how they are used to extend this specification. The general
      syntactic form for data elements is discussed in section 4.3.1.
      
      
      
                                     35

                                                    Section 4.1.2
      
      4.1.2.1  Primitive data elements
      
           A   primitive   data   element  contains  a  basic  item  of
information; it is not composed of other data elements. In current CBMSs, the most commonly used primitive data element is
4
ASCII-String, a series of ASCII characters. Other primitive data elements are Integer, 2's complement integers; Bit-String, a
      series of bits; and Boolean, either True or False.
      
           One primitive data element, End-Of-Constructor, is used only
as a structural element within constructor data elements and has no meaning by itself. End-of-Constructor is used to provide an end marker for constructor data elements that do not have an
      explicit length; any other use is not valid syntactically.
      
      
      4.1.2.2  Constructor data elements
      
           The Data  Element  Contents  of  constructor  data  elements
contain one or more data elements. The most general form of a constructor is a Sequence or a Set, since both Sequences and Sets may contain any data element. Other constructors are specialized
      forms of sequences.
      
           A Message data element is a constructor.    It  may  contain
only Field data elements, other Message data elements, or encrypted or data compressed forms of these elements. A Field data element can contain any data element. It also indicates which specific field is being represented. The contents of some fields are restricted to a single type of data element, such as
      ASCII-String or Date.
      
      
      4.1.3  Properties
      
      
           Any data element may have associated  with  it  a  Property-
List, which contains properties such as a Printing-Name or one or more Comments. Comment A mechanism to support vendor-defined properties has been supplied by this specification, as well as a
      mechanism to extend the list of property identifiers.
      
      
      _______________
      
        4
An ASCII-String is not limited to ASCII characters however.
The ASCII code table can be extended through standardized techniques as described in FIPS Pub 35, Code Extension Techniques
      in 7 or 8 Bits [NatB-75].
      
      
      
      
                                     36

                                                  Section 4.1.3.1
      
      4.1.3.1  Printing-names
      
           Printing-Names  are  used  to  provide  labels  that  can be
displayed along with their respective data elements. For example, a message originator may use a Printing-Name property to request that the To field of a message be labeled "Distribution:"
      when it is printed by its recipients.
      
      
      4.1.3.2  Comments
      
           The  Comment  property  is  used  to  allow  comments  to be
associated with any data element without affecting its actual contents. For example, someone reviewing the text of a message could add the comment "This looks good" to the Text field without either altering the body itself or adding a separate comment
      field.
      
      
      4.1.4  Data compression and encryption
      
      
           Two  constructor  data  elements,  Compressed and Encrypted,
have been provided for use by a CBMS that supports data compression or encryption. They may be used to hold the compressed or encrypted contents of any data element, including Messages and Fields, and may occur wherever their compressed or encrypted contents may appear. A mechanism is included to allow the user to identify the encryption or compression algorithm used
      (Sections 4.3.4 and 4.3.5).
      
      
      
      4.2  Overview of Syntax Encoding
      
      
           This  section  provides  an  overview  of  the  notation and
terminology used to represent the syntactic elements (data
      elements) defined in this message format specification.
      
           All  data  elements consist of a series of components.  Each
of the components is composed of a series of 8-bit groups called octets. In this document, the bits are numbered starting from the low-order bit. That is, the low-order (or least significant) bit is called "bit 0" and the high-order (or most significant)
      bit is called "bit 7."
      
           Five different components may appear in a data element.
      
      
        o  Identifier  octet  (identifying  particular type of data
           element)
      
      
      
                                     37

                                                      Section 4.2
      
        o  Length  Code  (specifying  number  of octets that appear
           following it in a data element)
      
        o  Qualifier (supplying additional identifying information)
      
        o  Property-List component (a  Property-List  data  element
           containing Property data elements)
      
        o  Data  Element  Contents  (containing  actual data of the
           data element)
      
      
      These components always appear in this order.  Not all components
are present in all data elements, but the components that are
      present maintain this relative order.
      
      
      4.2.1  Identifier Octets
      
      
           The  identifier  octet  is  a numeric code containing infor-
mation that identifies a data element. It is always the first component in a data element. The Identifier octet contains a one-bit flag, indicating whether or not the data element contains a Property-List, and a 7-bit unique identifier for the data element. The value of the data element identifier also indicates
      whether the data element has a Qualifier.
      
           The  most significant bit (Bit 7) of the identifier octet is
set to 1 if there are properties associated with the data element; it is set to 0 if there are none. This bit is independent of the remaining seven bits in the identifier octet, which are called the identifier, and provide unique identifi- cation for data elements. The associated properties are
      specified in a Property-List component.
      
           The  second  most  significant bit (Bit 6) of the identifier
octet (the most significant bit of the identifier itself) signifies whether or not the data element has a Qualifier. If the bit is set to 1, then the data element has a Qualifier; if it is a 0, the data element does not have a Qualifier. The seven
      bits of the identifier uniquely identify the data element.
      
           Table  2  shows  the  settings of the high-order bits of the
identifier octet and their associated meaning. Figure 4 demonstrates the bit-level structure of the identifier octet. In
      this figure, bit 7 is indiciated with P to show its special use.
      
      
      
      
      
      
      
      
                                     38

                                                    Section 4.2.1
      
      -----------------------------------------------------------------
      
      
           bit 7 6 5 4 3 2 1 0
              +---------------+
              |P 0 x x x x x x|     0xxxxxx uniquely identifies a
              +---------------+     data element without a Qualifier.
      
              +---------------+
              |P 1 x x x x x x|     1xxxxxx uniquely identifies a
              +---------------+     data element with a Qualifier.
      
      
      
      FIG. 4.  STRUCTURE OF IDENTIFIER OCTETS
      
      
      -----------------------------------------------------------------
      
      
      
      
      
          Bit Value     Meaning
      
           7    0   The data element does not have properties asso-
ciated.
                1   The data element has properties associated.
      
           6    0   The data element does not have a Qualifier.
                1   The data element has a Qualifier.
      
      
      
          TABLE 2.  HIGH-ORDER BITS IN THE IDENTIFIER OCTET
      
      
      
      
      
      4.2.2  Length code and Qualifier components
      
      
           The Length Code and the Qualifier are both usually one octet
in length. They use an encoding scheme that permits extending the component to the size necessary to represent the length of
      the data element or the value of the Qualifier component.
      
           The  most  significant  bit  of the Length Code or Qualifier
components determines whether it is one or several octets in
      length.  When the most significant bit is 0, the component is one
      
      
      
      
                                     39

                                                    Section 4.2.2
      
      octet  in  length.  When the most significant bit is 1, the other
seven bits of the first octet encode the number of octets in the rest of the component. The actual value begins in the next octet
      and is interpreted as an unsigned integer.
      
           A  single  octet  is  sufficient  for  most  Length Code and
Qualifier components. For those cases where the value of the Length Code or the Qualifier must be greater than 127, extra octets can be added, up to a maximum of 127 octets. Figure 5 shows the encoding scheme, as well as an example of a value less
      than 127 and one greater than 127.
      
      
      -----------------------------------------------------------------
      
      
           bit 7 6 5 4 3 2 1 0
              +---------------+
              |0 x x x x x x x|                   xxxxxxx is the value.
              +---------------+
      
              +---------------+------//-------+
              |1 n n n n n n n|y y y y y y y y|          nnnnnnn is the
              +---------------+------//-------+        number of octets
                                                       that contain the
                                                        value yyyyyyyy.
      
              +---------------+
              |0 0 0 0 1 0 0 1|               This is an example with a
              +---------------+                   value of 9 (decimal).
      
              +---------------+---------------+
              |1 0 0 0 0 0 0 1|1 0 0 0 0 0 1 0|      This example has a
              +---------------+---------------+ value of 130 (decimal).
      
      
              +---------------+---------------+
              |1 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|
              +---------------+---------------+
      
                              +---------------+
                              |0 0 1 0 1 1 0 0|      This example has a
                              +---------------+ value of 300 (decimal).
      
      
      
      FIG. 5.  ENCODING MECHANISM FOR QUALIFIERS AND LENGTH CODES
      
      
      -----------------------------------------------------------------
      
      
      
      
      
                                     40

                                                    Section 4.2.2
      
           In  order  to comply with this message format specification,
CBMSs must be able to determine the value of any length code or
      qualifier  that  is  expressed  in  three  octets  or less.  (The
      
       16
      2  -1).    This message format specification places no limitation
on the value of a length code or qualifier generated by a CBMS (except for the absolute limitation inherent in the represen- tation scheme). However, the use of length codes and qualifiers
32
with larger values (particularly values in excess of 2 -1) should be avoided unless it is known that the receiving system
      can handle them.
      
           Both  Length  Codes and Qualifiers have a special convention
for dealing with special situations. Length Codes can specify that a data element has indeterminate length; a Qualifier can specify that a data element is implementation defined. These
      cases are explained further in the next two sections.
      
      
      4.2.2.1  Length Codes
      
           The length code component immediately follows the identifier
octet. It is present in every data element. The Length Code indicates the number of octets following it in a data element (that is, excluding the identifier octet and the length code itself). Length Codes appear in one of three formats: short,
      long, and indefinite.
      
           A short Length Code is one octet long.  Its most significant
bit (Bit 7) is set to 0 and its value is in the range 0 through
      127.
      
           A long Length Code is at least two octets long.   The  first
octet always has its most significant bit (Bit 7) set to 1. The other seven bits of this octet contain the number of octets
      making  up  the rest of the Length Code, and these octets contain
      
        1016
      (2     - 1) (that is, 127 octets to represent the value).
      
           An  indefinite  Length  Code  is  one  octet long.  Its most
significant bit (Bit 7) is set to 1 and its other bits are all 0. (See Figure 6.) An indefinite Length Code may appear only as
      part  of  a  constructor  data  element;  it  may  not occur in a
      
      
      
      
      
      
      
      
      
                                     41

                                                  Section 4.2.2.1
      
      -----------------------------------------------------------------
      
      
           bit 7 6 5 4 3 2 1 0
              +---------------+
              |0 x x x x x x x|             xxxxxxx is the value of the
              +---------------+                            length code.
      
              +---------------+------//-------+
              |1 n n n n n n n|y y y y y y y y|   nnnnnnn is the number
              +---------------+------//-------+  of octets that contain
                                                the value of the length
code; these are represented
                                                            as yyyyyyy.
              +---------------+
              |1 0 0 0 0 0 0 0|            The "indefinite" length code
              +---------------+
      
      
      FIG. 6.  REPRESENTATION OF LENGTH CODES
      
      
      -----------------------------------------------------------------
      
      
                              5
primitive data element . A constructor data element with an indefinite length code has an End-Of-Constructor data element as the last data element in its Data Element Contents. (The length of such a constructor data element is unrestricted, although it must contain at least one data element -- the End-of-Constructor
      that terminates it -- in its Data Element Contents.)
      
      
      4.2.2.2  Qualifier
      
           If present,the Qualifier component immediately  follows  the
code component. It is used to provide information essential to the interpretation of the data element contents that is beyond that encoded in the identifier octet or length code. For example, the identifier octet could contain the code for a field,
      and the Qualifier component would specify what kind of field.
      
           The Qualifier component appears in only a few data elements.
      
      _______________
      
        5
This is the result of most primitive elements being able to
contain any bit pattern (including the identifier for End-Of-
      Constructor).
      
      
      
      
                                     42

                                                  Section 4.2.2.2
      
      In the Bit-String data element, it indicates the number of unused
bits in the final octet of the Data Element Contents. In the Field and Property data elements, it indicates which field or property the data element represents. In the Compressed and Encrypted data elements, it indicates which compression or encryption algorithm has been used. In the Message data element,
      it indicates the type of message.
      
           The  length  of  the  Qualifier  component  depends  on  the
encoding of the Qualifier. (See Figure 7.) A short Qualifier is one octet long. Its most significant bit is 0 and its value is in the range 0 through 127. A long Qualifier is at least two octets in length. The most significant bit is always 1 and the other 7 bits indicate the number of octets in the value of the
      Qualifier.
      
      
      -----------------------------------------------------------------
      
      
      
      
               +--------+--------+--------+
               |10000010|00000001 00001010|        Qualifier with value
               +--------+--------+--------+              266 (decimal).
      
               +--------+--------+--------+--------+
               |10000011|00000000|00000001 00001010|     Vendor-Defined
               +--------+--------+--------+--------+     Qualifier with
                                                             value 266.
      
               +--------+
               |10000000|              Undefined value for a Qualifier.
               +--------+
      
      
      
      FIG. 7.  EXAMPLES OF QUALIFIER VALUES
      
      
      -----------------------------------------------------------------
      
      
           This message format specification allows implementations  to
define their own values for Qualifiers. A vendor-defined Qual- ifier is any long Qualifier in which the first octet in the value is 0. The value used to identify this Qualifier is not guaranteed to be unique and the same value may be used by
      different implementations to define different Qualifiers.
      
      
      
      
      
      
                                     43

                                                    Section 4.2.3
      
      4.2.3  Property-List
      
      
           A  Property  is  an attribute being associated with, but not
essential to the interpretation of, a data element. The properties currently defined by this message format specification are Printing-Name and Comment. A Property-List component of a data element is represented by a Property-List data element that
      in turn contains Property data elements.
      
           A data element contains at most one Property-List.  The most
significant bit in the identifier octet of the data element
      indicates whether a Property-List is present.
      
      
      4.2.4  Data Element Contents
      
      
           The Data Element Contents component of a data element is the
actual data or information represented by a data element. (The other components provide the information necessary to identify
      and interpret the Data Element Contents.)
      
           In a primitive data element, the Data Element Contents is  a
series of octets interpreted according to the identifier octet
      and any qualifier.
      
           In a constructor data element, the Data Element Contents  is
a series of data elements. When the Length Code component of a constructor data element is "indefinite," the last data element
      in the constructor's Data Element Contents is End-of-Constructor.
      
           The  length  of the Data Element Contents (in octets) is the
difference between the value of the Length Code and the sum of
      the following:
      
      
        o  the  length  of  the Qualifier component (depends on the
           data element)
      
        o  the length of the Property-List component.
      
      
      
      4.3  Data Element Syntax
      
      
           This message  format  specification  defines  nineteen  (19)
different data elements. Section 4.3.1 defines the encoding form for data elements in general and the syntax for each data
      element.  Section  4.3.2  describes  the  use  of  specific  data
      
      
      
      
                                     44

                                                      Section 4.3
      
      elements  as  part  of  the Data Element Contents of a Field data
element. A summary of the syntactic form appears in Appendix F;
      summaries of the data element syntax appear in Appendix G.
      
      
      4.3.1  Data elements
      
      
           This  section  presents  the  general syntactic form for all
data elements defined by this message format specification and the detailed syntax for each data element. The data elements are presented by syntactic class: primitive data elements (Section 4.3.1.1), constructors (Section 4.3.1.2), and data elements which
      can be either (Section 4.3.1.3).
      
           For convenience, the following terminology is used  in  this
      section.
      
      
                  Term            Meaning
      
              Primitive       a Primitive Data Element
      
              Constructor     a Constructor Data Element
      
              Element         any Data Element
      
      
           The  syntax  of  each  Element is presented in graphic form.
The following conventions apply in the diagrams. A single octet
      is represented as follows.
      
      
          +--------+
          |        |
          +--------+
      
      
           Components that vary in length are represented as follows.
      
      
          +---//---+
          |        |
          +---//---+
      
      
           Each  Element  has  up to five components:  an Identifier, a
Length Code, a Qualifier, a Property-List, and the Data Element
      Contents.
      
               In the diagrams, the contents of the identifier octet is
      
      
      
      
                                     45

                                                    Section 4.3.1
      
      shown  as  a "P" followed by an identifier represented in binary.
      (See Figure 4.)
      
      A length code is always represented in the following manner:
      
      
          +---//---+
          |Lxxxxxxx|
          +---//---+
      
      
      A qualifier is always represented in the following manner:
      
      
          +---//---+
          |Qxxxxxxx|
          +---//---+
      
      
      A Property-List (if  present)  always  immediately  precedes  any
      occurrence of Data Element Contents.
      
      The  Data  Element  Contents  appears  in  diagrams as one of the
      following:
      
      
        o  "element(s)", which may be any data element(s)
      
        o  "anything," which is undefined and  may  be  any  combi-
           nation of bits
      
        o  a specific data element
      
        o  the  interpretation to be applied to the bits within the
octets that constitute the element (such as ASCII or
           Integer)
      
      
           Two  data  elements have been reserved for special purposes.
The Extension data element is provided to allow for future expansion of the possible data elements. The Vendor-Defined data element allows CBMS vendors to define their own data elements. Vendor-Defined data elements are not guaranteed to be unique, since two implementations could define different data elements using the same identifier. Vendor-Defined data elements should
      be used and interpreted by prior agreement.
      
           In  the  following  sections, each element is presented with
its name, compliance classification (BASIC or OPTIONAL), its identifier (both in hexadecimal and in octal), a brief description of its use, and a graphic representation. Each data
      element description has the following form.
      
      
      
                                     46

                                                    Section 4.3.1
      
      
      
      
      -----------------------------------------------------------------
      
      
      Data Element             (Compliance)   identifier   identifier
Name ( Category ) octet octet
                                                    16            8
      
                     Description of the syntax of the data element.
      
      
      
                 +---//---+
                 |        |     Diagram representing data element
                 +---//---+
      
      
      
      
      
      
      -----------------------------------------------------------------
      
      
      4.3.1.1  Primitives
      
           The   data   elements   in  this  section  are  arranged  in
alphabetical order by name. (Appendix C presents the identifiers
      in numeric order.)
      
      ASCII-String             (BASIC)        02        002
16 8
This data element contains a series of ASCII
characters [NatB-80], each character right-justified in one octet. For 7-bit ASCII characters, the most
                significant bit of each octet must be 0.
      
           Note: The ASCII code  table  can  be  extended  through
standardized techniques [NatB-75] to introduce addi- tional 7-bit or 8-bit characters or additional code
                tables.
      
      
                 +--------+---//---+----//-----+
                 |P0000010|Lxxxxxxx|ASCII chars|
                 +--------+---//---+----//-----+
      
      
      
      
      
      
      
                                     47

                                                  Section 4.3.1.1
      
      Bit-String               (OPTIONAL)     43        103
16 8
This data element contains a series of bits. It uses the Qualifier data element component to record the number of bits of padding (as an eight bit unsigned integer) needed to fill the final octet of the Data Element Contents to an even octet boundary. These padding bits have no meaning and occur in the low order bits of the final octet. The valid values for the Qualifier component are 0 through 7. The number of bits in the Data Element Contents is calculated from
                the following formula.
      
      
                8   *   number of octets   -   value of
in the Data Qualifier component
                        Element Contents
      
      
                 +--------+---//---+---//---+---//---+
                 |P1000011|Lxxxxxxx|Qxxxxxxx|  bits  |
                 +--------+---//---+---//---+---//---+
      
      Boolean                  (OPTIONAL)     08        010
16 8
This data element contains one octet whose value is either true or false. False is represented by all bits being 0; true is represented by all bits being 1 (although any non-zero value should be interpreted as
                true).
      
      
                 +--------+---//---+--------+
                 |P0001000|Lxxxxxxx| T or F |
                 +--------+---//---+--------+
      
      End-of-Constructor       (BASIC)        01        001
16 8
This data element terminates the Data Element Contents in a constructor data element that has indefinite length. This data element has no Contents component.
                (Use of this element is described in Section 4.2.2.1.)
      
      
                 +--------+---//---+
                 |P0000001|Lxxxxxxx|
                 +--------+---//---+
      
      
      
      
      
      
      
      
                                     48

                                                  Section 4.3.1.1
      
      Integer                  (OPTIONAL)     20        040
16 8
This data element contains a 2's complement integer of variable length, high order octet first. It is recommended that the data element contents be either 2
                or 4 octets long whenever possible.
      
      
                 +--------+---//---+---//---+
                 |P0100000|Lxxxxxxx| Integer|
                 +--------+---//---+---//---+
      
      No-Op                    (OPTIONAL)     00        000
16 8
This data element does nothing. No-Op is used whenever it is necessary to include a data element that means
                "no operation."  It is a short placeholder.
      
      
                 +--------+---//---+
                 |P0000000|Lxxxxxxx|
                 +--------+---//---+
      
      Padding                  (OPTIONAL)     21        041
16 8
This data element is used to fill any number of octets. The contents of a Padding element are undefined and
                convey no information.
      
      
                 +--------+---//---+---//---+
                 |P0100001|Lxxxxxxx|anything|
                 +--------+---//---+---//---+
      
      
      4.3.1.2  Constructors
      
           The data elements in this section  are  arranged  in  alpha-
      betical order.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     49

                                                  Section 4.3.1.2
      
      Compressed               (OPTIONAL)     46        106
16 8
This data element must contain a Bit-String data element. It is used to represent any data that has been compressed; it may be used wherever its uncompressed contents may appear. A Qualifier data component appears in each Compressed data element; it contains a compression identifier (CID) to identify the compression algorithm used. (See Section 4.3.5.) The Data Element Contents contains the product of the
                compression process.
      
      
                 +--------+---//---+---//---+--------//--------+
                 |P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
                 +--------+---//---+---//---+--------//--------+
      
      
      Date                     (BASIC)        28        050
16 8
This data element contains an ASCII-String data element, which is a representation of a date and time formatted in accordance with PUBS 4 [NatB-68], 58 [NatB-79a] and 59 [NatB-79b]. The use of time and time zone is optional. It is recommended that numeric offsets be used to indicate time zone rather than
                alphabetic abbreviations.
      
      
                 +--------+---//---+------//------+
                 |P0101000|Lxxxxxxx| ASCII-String |
                 +--------+---//---+------//------+
      
      
      Encrypted                (OPTIONAL)     47        107
16 8
This data element must contain a Bit-String. It is used to represent any data that has been encrypted; it may be used wherever its unencrypted contents may appear. A Qualifier data component appears in each Encrypted data element; it contains an encryption identifier (EID) identifying the encryption algorithm used. The Data Element Contents is the product of the
                encryption process.
      
      
                 +--------+---//---+---//---+--------//--------+
                 |P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
                 +--------+---//---+---//---+--------//--------+
      
      
      
      
      
      
                                     50

                                                  Section 4.3.1.2
      
      Field                    (BASIC)        4C        114
16 8
This data element uses a Qualifier data element component. The Qualifier component contains a Field Identifier (FID) indicating which specific field is
                being represented.
      
      
                 +--------+---//---+---//---+---//---+
                 |P1001100|Lxxxxxxx|Qxxxxxxx|elements|
                 +--------+---//---+---//---+---//---+
      
      Message                  (BASIC)        4D        115
16 8
This data element may contain Field or Message data elements. Its Qualifier component contains a Message type (MID) indicating the type of the message. (The MID is completely different from the message identifier in the Message-ID field and should not be confused with
                it.)
      
      
                 +--------+---//---+---//---+
                 |P1001101|Lxxxxxxx|Qxxxxxxx|
                 +--------+---//---+---//---+
      
                 +--------//---------//---------//---------//--------+
                 | Field, Message, Encrypted, or Compressed Elements |
                 +--------//---------//---------//---------//--------+
      
      Property-List            (OPTIONAL)     24        044
16 8
This data element contains a series of Property data
                elements to be associated with another data element.
      
      
                 +--------+---//---+-------//--------+
                 |P0100100|Lxxxxxxx|Property Elements|
                 +--------+---//---+-------//--------+
      
      Property                 (OPTIONAL)     45        105
16 8
This data element uses a Qualifier data element component. The Qualifier component contains a Property-Identifier (PID) to indicate which specific
                property is being represented.
      
      
                 +--------+---//---+---//---+---//---+
                 |P1000101|Lxxxxxxx|Qxxxxxxx|elements|
                 +--------+---//---+---//---+---//---+
      
      
      
      
                                     51

                                                  Section 4.3.1.2
      
      Sequence                 (OPTIONAL)     0A        012
16 8
This data element contains any series of data elements. Sequence differs from Set in that the data elements making up the Data Element Contents must be considered as an ordered sequence (according to their order of
                appearance in the sequence.)
      
      
                 +--------+---//---+---//---+
                 |P0001010|Lxxxxxxx|elements|
                 +--------+---//---+---//---+
      
      Set                      (OPTIONAL)     0B        013
16 8
This data element contains any series of data elements with no ordering of the elements implied. (Sequence provides an ordered series.) Although the data elements contained in a Set must be stored sequentially, the order in which they are stored is not
                defined and not processed.
      
      
                 +--------+---//---+---//---+
                 |P0001011|Lxxxxxxx|elements|
                 +--------+---//---+---//---+
      
      Unique-ID                (OPTIONAL)     09        011
16 8
This data element is a unique identifier. It need not be human-readable. The Data Element Contents may be an
                ASCII-String, a Bit-String, or an Integer.
      
      
                 +--------+---//---+---//---+
                 |P0001001|Lxxxxxxx| element|
                 +--------+---//---+---//---+
      
      
      4.3.1.3  Data Elements that Extend this Specification
      
           There  are  two  data  elements that are used to extend this
specification. They can be classified as either primitive or
      constructor data elements, depending on the extension.
      
      
      
      
      
      
      
      
      
      
      
                                     52

                                                  Section 4.3.1.3
      
      Extension                (OPTIONAL)     7E        176
16 8
This data element is used to extend the number of available data elements beyond the 128 that are possible using a 7-bit identifier. A Qualifier component extends the encoding space for identifiers.
                (Extension and Vendor-Defined have the same syntax.)
      
      
                 +--------+---//---+---//---+---//---+
                 |P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
                 +--------+---//---+---//---+---//---+
      
      Vendor-Defined           (OPTIONAL)     7F        177
16 8
This data element is used to represent vendor- and user-defined data elements. A Qualifier component extends the encoding space for identifiers. The Qualifier component is not guaranteed to be unique among all interconnected systems. This data element is interpreted according to prior agreement between systems. (Extension and Vendor-Defined data elements
                have the same syntax.)
      
      
                 +--------+---//---+---//---+---//---+
                 |P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
                 +--------+---//---+---//---+---//---+
      
      
      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) defines which data
      elements are valid as the Contents for each of the fields.
      
           Some fields have  a  Data  Element  Contents  that  contains
"originators" or "recipients." No data element represents the identities of originators or recipients (because that encoding is not within the scope of this message format specification.) These descriptions simply list "originators" or "recipients", implying no restrictions on how the identifiers for originators
      or recipients are represented.
      
      
      
      
      
      
      
      
                                     53

                                                    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.
      
      FIPS-Standard                           01        001
16 8
Use of this encryption identifier as part of the Encrypted data element indicates that the Federal Information Processing Standard method for data
                encryption was [NatB-77].
      
      
      4.3.5  Compression identifiers
      
      
           This message format specification  defines  one  compression
      identification code for use with the Compressed data element.
      
      Unspecified                             00        000
16 8
Use of this compression identifier as part of the Compressed data element indicates that the compression method being used was not specified for inclusion as
                part of the data element.
      
      
      
      
      
                                     54

                                                    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.
      
      FIPS-Standard                           01        01
16 8
This message type marks messages defined by this
                message format specification.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     55

                      SUMMARY OF APPENDIXES
      
      
      
      
      Appendix A  Defines  the  fields  in  the message format specifi-
cation. 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 consol-
                  idates information from Section 4.3.
      
      Appendix C  Provides a reference table listing the data  elements
                  in numerical order by their identifier octets.
      
      Appendix D  Provides a reference table summarizing the components
of messages according to whether they are required or
                  optional for CBMSs implementing the specification.
      
      Appendix E  Provides  a  reference  table  organizing the message
components according to the functional class of the
                  components.
      
      Appendix F  Provides   an  overview  of  the  syntactic  elements
                  defined by this message format specification.
      
      Appendix G  Summarizes syntactic elements  according  to  whether
they are required or optional for a CBMS implementing
                  the message format specification.
      
      Appendix H  Examples  of  each syntactic element displaying their
                  syntax and describing their associated semantics.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     56

                                                       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.
      
      
      
      
      
      
      
      
      
                                     57

                                                       Appendix A
      
      Bcc                      OPTIONAL       0D        015
16 8
This field identifies additional recipients for a message (a "blind carbon copies list"). The contents of this field are not to be included in copies of the message sent to the primary and secondary recipients. See section 3.2.1 for further discussion of the use of blind carbon copies lists. This field contains one or
                more recipient identities.
      
      Cc                       BASIC          06        006
                                                16         8
This field identifies secondary recipients for a message (a "carbon copies" list). This field contains
                one or more recipient identities.
      
      Circulate-Next           OPTIONAL       0E        016
16 8
This field is used in conjunction with the Circulate-To field. (See Section 3.2.6.1 for further discussion.) It identifies all recipients in a circulation list who have not yet received the message. This field contains
                one or more recipient identities.
      
      Circulate-To             OPTIONAL       0F        017
16 8
This field identifies recipients for a circulated message. (See Section 3.2.6.1 for further discussion.) It is used in conjunction with the Circulate-Next field. This field contains one or more recipient
                identities.
      
      Comments                 OPTIONAL       10        020
16 8
This field permits adding comments onto the message without disturbing the original contents of the message. While the Comments field will usually contain one or more ASCII-Strings, there are no restrictions on
                its contents.
      
      Date                     OPTIONAL       11        021
16 8
This field contains a date that the message's originator wishes to associate with a message. The Date field is to the Posted-Date field as the date on a letter is to the postmark added by the post office.
                This field contains one Date.
      
      
      
      
      
      
      
      
                                     58

                                                       Appendix A
      
      End-Date                 OPTIONAL       12        022
16 8
This field contains the date on which a message loses effect. (See also Section 3.2.5 for further
                discussion.)  This field contains one Date.
      
      From                     REQUIRED       01        001
16 8
This field contains the identity of the originators taking formal responsibility for this message. The contents of the From field is to be used for replies when no Reply-to field appears in a message. This
                field contains one or more originator identities.
      
      In-Reply-To              OPTIONAL       13        023
16 8
This field designates previous correspondence to which this message is a reply. The usual contents of this field would be the contents of the Message-ID field of the message(s) being replied to. This field contains
                one or more Unique-IDs or ASCII-Strings.
      
      Keywords                 OPTIONAL       14        024
16 8
This field contains keywords or phrases for use in retrieving a message. This field contains one or more ASCII-Strings. (Each keyword or phrase is represented
                by a separate ASCII-String.)
      
      Message-Class            OPTIONAL       15        025
16 8
This field indicates the purpose of a message. For example, it might contain values indicating that the message is a memorandum or a data-base entry. This
                field contains one data element, an ASCII-String.
      
      Message-ID               OPTIONAL       16        026
16 8
This field contains a unique identifier for a message. This identifier is intended for machine generation and

processing. Further definition appears in Section
3.2.4.1. Only one Message-ID field is permitted in a
message. This field contains one data element, a
                Unique-ID.
      
      Obsoletes                OPTIONAL       26        046
16 8
This field identifies one or more messages that this one supplants. This field contains at least one
                Unique-ID and may contain more than one.
      
      
      
      
      
                                     59

                                                       Appendix A
      
      Originator-Serial-Number OPTIONAL       17        027
16 8
This field contains one or more serial numbers assigned by the message's originator. (Messages with multiple recipients should all have the same value in the Originator-Serial-Number field. This field contains one or more ASCII-Strings. (One ASCII-String is used
                for each serial number.)
      
      Posted-Date              REQUIRED       02        002
16 8
This field contains the posting date, which is the point in time when the message passes through the posting slot into a message transfer system. Only one Posted-Date field is permitted in a message. This
                field contains one Date.
      
      Precedence               OPTIONAL       18        030
16 8
Ordinarily, message precedence or priority is a service request to a message transfer system. A message originator, however, can include precedence information in a message. This field indicates the precedence at which the message was posted. One example of a precedence scheme is the US Military categories "ROUTINE", "PRIORITY", "IMMEDIATE", "FLASH OVERRIDE", and "EMERGENCY COMMAND PRECEDENCE". This field
                contains one ASCII-String.
      
      Received-Date            OPTIONAL       19        031
16 8
This field is also called Delivery date. It may be added to a message by the recipient's message receiving program. It indicates when the message left the delivery system and entered the recipient's message
                processing domain.  This field contains one Date.
      
      Received-From            OPTIONAL       1A        032
16 8
This field contains a record of a message's path through a message transfer system. The recipient's message receiving program may store any such information that it obtains from a message transfer system in this field. The contents of this
                field are unrestricted.
      
      
      
      
      
      
      
      
      
      
                                     60

                                                       Appendix A
      
      References               OPTIONAL       20        040
16 8
This field identifies other correspondence that this message references. If the other correspondence contains a Message-ID field, the contents of the References field must be the message identifier. This
                field contains one or more Unique-IDs or ASCII-Strings.
      
      Reissue-Type             OPTIONAL       25        045
16 8
This field is used in conjunction with message encapsulating (see Section 3.2.2) to differentiate between messages being assigned or redistributed. This field contains one data element, usually an ASCII-
                String.
      
      Reply-To                 BASIC          03        003
                                                16         8
This field identifies any recipients for replies to the message. This field contains one or more recipient
                identities.
      
      Sender                   OPTIONAL       22        042
16 8
This field identifies the agent who sent the message. It is intended either for when the sender is not the originator responsible for the message or to indicate who among a group of originators responsible for the message actually sent it. Use of the Sender field is discouraged when the contents of the Sender field and From field would be completely redundant. Only one Sender field is permitted in a message. This field
                contains one originator identity.
      
      Start-Date               OPTIONAL       23        043
16 8
This field contains the date on which a message takes effect. (See Section 3.2.5 for further discussion.)
                This field contains one Date.
      
      Subject                  BASIC          07        007
                                                16         8
This field contains whatever information the originator provided to summarize or indicate the nature of the message. This field contains one or more ASCII-
                Strings.
      
      Text                     BASIC          04        004
                                                16         8
This field contains the primary content of the message.
                Contents of this field are unrestricted.
      
      
      
      
                                     61

                                                       Appendix A
      
      To                       REQUIRED       05        005
16 8
This field identifies primary recipients for a message.
                This field contains one or more recipient identities.
      
      Warning-Date             OPTIONAL       24        044
16 8
This field is used either alone or in conjunction with an End-Date field. It contains one or more dates. These dates could be used by a message processing program as warnings of an impending end-date or other event. (See Section 3.2.5 for further discussion.)
                This field contains one or more Dates.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     62

                                                       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
                +---//---+
      
      
      
      
      
      -----------------------------------------------------------------
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     63

                                                       Appendix B
      
      ASCII-String             (BASIC)        02        002
16 8
                primitive
      
                This data element contains a series of ASCII characters
[NatB-80], each character right-justified in one
octet. For 7-bit ASCII characters, the most
                significant bit of each octet must be 0.
      
                Note:  The  ASCII  code  table  can be extended through
standardized techniques [NatB-75] to introduce addi- tional 7-bit or 8-bit characters or additional code
                tables.
      
      
                 +--------+---//---+----//-----+
                 |P0000010|Lxxxxxxx|ASCII chars|
                 +--------+---//---+----//-----+
      
      Bit-String               (OPTIONAL)     43        103
16 8
                primitive
      
                This data element contains a series of bits.   It  uses
the Qualifier data element component to record the number of bits of padding (as an 8-bit unsigned integer) needed to fill the final octet of the Data Element Contents to an even octet boundary. These padding bits have no meaning and occur in the low order bits of the final octet. The valid values for the Qualifier component are 0 through 7. The number of bits in the Data Element Contents is calculated from
                the following formula.
      
      
                8   *   number of octets   -   value of
in the Data Qualifier component
                        Element Contents
      
      
                 +--------+---//---+---//---+---//---+
                 |P1000011|Lxxxxxxx|Qxxxxxxx|  bits  |
                 +--------+---//---+---//---+---//---+
      
      
      
      
      
      
      
      
      
      
      
      
                                     64

                                                       Appendix B
      
      Boolean                  (OPTIONAL)     08        010
16 8
                primitive
      
                This  data  element  contains  one octet whose value is
either true or false. False is represented by all bits being 0; true is represented by all bits being 1 (although any non-zero value should be interpreted as
                true).
      
      
                 +--------+---//---+--------+
                 |P0001000|Lxxxxxxx| T or F |
                 +--------+---//---+--------+
      
      Compressed               (OPTIONAL)     46        106
16 8
                constructor
      
                This  data  element  must  contain  a  Bit-String  data
element. It is used to represent any data that has been compressed; it may be used wherever its uncompressed contents may appear. A Qualifier data component appears in each Compressed data element; it contains a compression identifier (CID) to identify the compression algorithm used. (See Section 4.3.5.) The Data Element Contents contains the product of the
                compression process.
      
      
                 +--------+---//---+---//---+--------//--------+
                 |P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
                 +--------+---//---+---//---+--------//--------+
      
      
      Date                     (BASIC)        28        050
16 8
                constructor
      
                This   data   element  contains  an  ASCII-String  data
element, which is a representation of a date and time formatted in accordance with FIPS PUBS 4 [NatB-68], 58 [NatB-79a], and 59 [NatB-79b]. The use of time and time zone is optional. It is recommended that numeric offsets be used to indicate time zone rather than
                alphabetic abbreviations.
      
      
                 +--------+---//---+------//------+
                 |P0101000|Lxxxxxxx| ASCII-String |
                 +--------+---//---+------//------+
      
      
      
      
                                     65

                                                       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 for further discussion.) The Data Element Contents is the product of the encryption
                process.
      
      
                 +--------+---//---+---//---+--------//--------+
                 |P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
                 +--------+---//---+---//---+--------//--------+
      
      End-of-Constructor       (BASIC)        01        001
16 8
                primitive
      
                This data element terminates the Data Element  Contents
in a constructor data element that has indefinite length. This data element has no Contents component.
                (Use of this element is described in Section 4.2.2.1.)
      
      
                 +--------+---//---+
                 |P0000001|Lxxxxxxx|
                 +--------+---//---+
      
      Extension                (OPTIONAL)     7E        176
16 8
                either
      
                This  data  element  is  used  to  extend the number of
available data elements beyond the 128 that are possible using a 7-bit identifier. A Qualifier component extends the encoding space for identifiers.
                (Extension and Vendor-Defined have the same syntax.)
      
      
                 +--------+---//---+---//---+---//---+
                 |P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
                 +--------+---//---+---//---+---//---+
      
      
      
      
      
      
      
      
                                     66

                                                       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 for further
                discussion.)
      
      
                 +--------+---//---+---//---+---//---+
                 |P1001100|Lxxxxxxx|Qxxxxxxx|elements|
                 +--------+---//---+---//---+---//---+
      
      Integer                  (OPTIONAL)     20        040
16 8
                primitive
      
                This  data element contains a 2's complement integer of
variable length, high-order octet first. It is recommended that the data element contents be either 2
                or 4 octets long whenever possible.
      
      
                 +--------+---//---+---//---+
                 |P0100000|Lxxxxxxx| Integer|
                 +--------+---//---+---//---+
      
      Message                  (BASIC)        4D        115
16 8
                constructor
      
                This data element may contain  Field  or  Message  data
elements. Its Qualifier component contains a Message type (MID) indicating the type of the message. (See Section 4.3.6 for further discussion.) (The MID is completely different from the message identifier in the
                Message-ID field and should not be confused with it.)
      
      
                 +--------+---//---+---//---+
                 |P1001101|Lxxxxxxx|Qxxxxxxx|
                 +--------+---//---+---//---+
      
                 +--------//---------//---------//---------//--------+
                 | Field, Message, Encrypted, or Compressed Elements |
                 +--------//---------//---------//---------//--------+
      
      
      
      
      
      
      
                                     67

                                                       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|
                 +--------+---//---+-------//--------+
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     68

                                                       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 for
                further discussion.)
      
      
                 +--------+---//---+---//---+---//---+
                 |P1000101|Lxxxxxxx|Qxxxxxxx|elements|
                 +--------+---//---+---//---+---//---+
      
      Sequence                 (OPTIONAL)     0A        012
16 8
                constructor
      
                This data element contains any series of data elements.
Sequence differs from Set in that the data elements making up the Data Element Contents must be considered as an ordered sequence (according to their order of
                appearance in the sequence.)
      
      
                 +--------+---//---+---//---+
                 |P0001010|Lxxxxxxx|elements|
                 +--------+---//---+---//---+
      
      Set                      (OPTIONAL)     0B        013
16 8
                constructor
      
                This  data element contains any series of data elements
with no ordering of the elements implied. (Sequence provides an ordered series.) Although the data elements contained in a Set must be stored sequentially, the order in which they are stored is not
                defined and not processed.
      
      
                 +--------+---//---+---//---+
                 |P0001011|Lxxxxxxx|elements|
                 +--------+---//---+---//---+
      
      
      
      
      
      
      
      
      
      
                                     69

                                                       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
                either
      
                This data element is used to  represent  vendor-defined
data elements. A Qualifier component extends the encoding space for identifiers. The Qualifier component is not guaranteed to be unique among all interconnected systems. This data element is interpreted according to prior agreement between systems. (Extension and Vendor-Defined data elements
                have the same syntax.)
      
      
                 +--------+---//---+---//---+---//---+
                 |P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
                 +--------+---//---+---//---+---//---+
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     70

                                                       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
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     71

                                                       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 CBMS systems. Optional fields need not be supported by a CBMS but, if supported, must be processed according to the meanings defined by the message format
      specification.
      
      
      
      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
      
      
      
      
                                     72

                                                       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
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     73

                                                       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. (Appendix D 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
      
      
      
      
      
                                     74

                                                       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
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     75

                                                       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.
      
      
      
      
      
      
      
      
                                     76

                                                       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.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     77

                                                       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 (either) 7E 176
16 8
Integer (primitive) 20 040
16 8
No-Op (primitive) 00 000
16 8
Padding (primitive) 21 041
                                                16         8
      
      
      
      
      
                                     78

                                                       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 (either) 7F 377
                                                16         8
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     79

                                                       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 represen- tation. Although this message format specification does not define the syntax of names and addresses, message originators and recipients are identified by their names. This does not imply anything about how naming and addressing can or should be done; it is simply a convenient way to identify message originators and
      recipients in these examples.
      
      
      
      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|
           +--------+--------+
      
      
      
      
      
      
      
      
      
      
      
                                     80

                                                       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.|
           +--------+--------+---- ----+
      
      
      
      
      
      
      
      
      
                                     81

                                                       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|
                    +--------+--------+----    ----+
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     82

                                                       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 unspecified data compression algorithm. The compressed data
      is in a bit-string that is 56 bits long, fully filling 7 octets:
      
      
           Compressed  Length   CID   Bit-String  Length
           +--------+--------+--------+--------+--------+
           |01000110|  0   B |  0   0 |01000011|  0   8 |
           +--------+--------+--------+--------+--------+
      
                       Spare
                    +--------+--------+--------+--------+
                    |  0   0 |  1   C    5   F    2   D
                    +--------+--------+--------+--------+
      
                    +--------+--------+--------+--------+
                       7   7    B   A    F   6    2   9 |
                    +--------+--------+--------+--------+
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     83

                                                       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 |
           +--------+--------+--------+--------+--------+--------+
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     84

                                                       Appendix H
      
           Sequence  data element containing two ASCII-String data ele-
ments. 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 values have no ordering
      because they belong to a set.)
      
      
              Set     Length   Integer  Length
           +--------+--------+--------+--------+--------+--------+
           |00001011|  0   8 |00100000|  0   2 |  0   2    0   7 |
           +--------+--------+--------+--------+--------+--------+
      
                      Integer  Length
                    +--------+--------+--------+--------+
                    |00100000|  0   2 |  0   0    4   7 |
                    +--------+--------+--------+--------+
      
      
      
      
      
           Field  data  element.   The specific field shown is the Text
      field with the contents "I will see you at lunch.":
      
      
             Field    Length    FID      ASCII   Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   B |  0   4 |00000010|  1   8 |
           +--------+--------+--------+--------+--------+
      
                    +----                ----+
                    |I will see you at lunch.|
                    +----                ----+
      
      
      
      
                                     85

                                                       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   A |  0   1 |01001100|  1   9 |
           +--------+--------+--------+--------+--------+
      
                       FID      Date    Length   ASCII
                    +--------+--------+--------+--------+
                    |  0   2 |00101000|  1   6 |00000010|
                    +--------+--------+--------+--------+
      
                      Length
                    +--------+----            ----+
                    |  1   4 |19800704-180000-0400|
                    +--------+----            ----+
      
      
                      Field    Length    FID     ASCII
                    +--------+--------+--------+--------+
                    |01001100|  0   8 |  0   1 |00000010|
                    +--------+--------+--------+--------+
      
                      Length
                    +--------+-- --+
                    |  0   5 |Smith|
                    +--------+-- --+
      
                       Field   Length    FID     ASCII
                    +--------+--------+--------+--------+
                    |01001100|  2   8 |  0   4 |00000010|
                    +--------+--------+--------+--------+
      
                      Length
                    +--------+
                    |  2   5 |
                    +--------+
      
                    +----                             ----+
                    |Are you going to watch the fireworks?|
                    +----                             ----+
      
                      Field    Length    FID     ASCII
                    +--------+--------+--------+--------+
                    |01001100|  0   8 |  0   5 |00000010|
                    +--------+--------+--------+--------+
      
      
      
      
                                     86

                                                       Appendix H
      
      
                      Length
                    +--------+-- --+
                    |  0   5 |Jones|
                    +--------+-- --+
      
      
      
      
      
      H.3  Data Elements that Extend this Specification
      
      
           This  section  contains  examples  of  data elements used to
extend this specification. These data elements can be either primitives or constructors, depending on the extension.
Extension data element containing a length code and 3
octets. The octet immediately following the length code iden- tifies it as Extension Data Element 7. The Data Element Contents is the final two octets. The interpretation of the Data Element Contents would be defined in an extension or successor to this message format specification. [Note: this is an example. Any actual extension data element 7 (if it were ever used) would be
      completely different from anything done here.]:
      
      
           Extension  Length
           +--------+--------+--------+--------+--------+
           |01111110|  0   3 |  0   7 |  4   A    E   9 |
           +--------+--------+--------+--------+--------+
      
      
      
      
      
           Vendor-Defined  data  element containing a length code and 3
octets. The first octet identifies this as vendor-defined data element number 114 (decimal), which this particular vendor has defined to contain three printable ASCII characters in two octets. (Data element 114 (decimal) for another user would be completely different. For example, it might contain a floating
      point number.):
      
      
              User    Length
           +--------+--------+--------+--------+--------+
           |01111111|  0   3 |  7   2 |   P    O    E   |
           +--------+--------+--------+--------+--------+
      
      
      
      
      
      
      
                                     87

                                                       Appendix H
      
      H.4  Fields
      
      
           This  section  contains  examples of Field data element con-
structors for each of several different fields (Keywords, Text, Subject, Vendor-Defined).
Field data element for keywords . The field contains two
keywords, Message and Computer, each represented in a separate
      ASCII-string data element.
      
      
              Field   Length  Keywords   ASCII   Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   4 |  1   4 |00000010|  0   7 |
           +--------+--------+--------+--------+--------+
      
                    +--- ---+
                    |Message|
                    +--- ---+
      
                      ASCII    Length
                    +--------+--------+---  ---+
                    |00000010|  0   8 |Computer|
                    +--------+--------+---  ---+
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     88

                                                       Appendix H
      
           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?|
                    +--------+--------+----          ----+
      
      
      
      
      
           Field data element for Subject  containing  an  ASCII-String
data element ("Good restaurants in Detroit" followed by a carriage return and a line feed). (A recipient would expect the message to contain some information about restaurants in the
      Detroit area.):
      
      
             Field    Length   Subject   ASCII   Length
           +--------+--------+--------+--------+--------+
           |01001100|  2   1 |  0   7 |00000010|  1   E |
           +--------+--------+--------+--------+--------+
      
                    +----                            ----+
                    |Good restaurants in Detroit.<cr><lf>|
                    +----                            ----+
      
      
      
      
      
      
      
      
      
                                     89

                                                       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.5  Messages
      
      
           This  section contains several examples of complete messages
and shows the results of reissuing a message. (See Section
      3.2.2.)
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     90

                                                       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 a.m. EDT.  The subject  of  the  message  is  "Project
Deadline" and the message is a reminder that the deadline is the next day and that the section of the report for the project being done by Johnson should be turned in to Stevens by 3 p.m. that
      day.
      
      
            Message       Length         Type
           +--------+--------+--------+--------+
           |01001101|  8   1 |  B   6 |  0   1 |
           +--------+--------+--------+--------+
      
              Field   Length    FID     ASCII
           +--------+--------+--------+--------+
           |01001100|  0   A |  0   5 |00000010|
           +--------+--------+--------+--------+
      
                      Length
                    +--------+--- ---+
                    |  0   7 |Johnson|
                    +--------+--- ---+
      
             Field    Length    FID      ASCII
           +--------+--------+--------+--------+
           |01001100|  0   A |  0   1 |00000010|
           +--------+--------+--------+--------+
      
                      Length
                    +--------+--- ---+
                    |  0   7 |Stevens|
                    +--------+--- ---+
      
             Field    Length    FID     ASCII    Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   3 |  0   7 |00000010|  1   0 |
           +--------+--------+--------+--------+--------+
      
                    +----        ----+
                    |Project Deadline|
                    +----        ----+
      
             Field    Length    FID      Date    Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   7 |  0   2 |00101000|  1   4 |
           +--------+--------+--------+--------+--------+
      
      
      
      
      
      
      
      
                                     91

                                                       Appendix H
      
      
                      ASCII    Length
                    +--------+--------+----          ----+
                    |00000010|  1   2 |19800814-1000-0400|
                    +--------+--------+----          ----+
      
             Field    Length    FID      ASCII   Length
           +--------+--------+--------+--------+--------+
           |01001100|  6   D |  0   4 |00000010|  6   A |
           +--------+--------+--------+--------+--------+
      
                    +----
                    |Don't forget the project report is
                    +----
      
                     due tomorrow.  Please have<CrLf>
      
                     your section to me by three this
      
                           ----+
                     afternoon.|
                           ----+
      
      
      
      
      
           The  following  example illustrates the results of reissuing
the first message in this section. This message contains the original message (as a Message data element), To, From, and Posted-Date fields, and a Reissue-Type field with Redistributed
      as its value:
      
      
            Message       Length         Type
           +--------+--------+--------+--------+
           |01001101|  8   1 |  F   C |  0   1 |
           +--------+--------+--------+--------+
      
              Field   Length    FID      ASCII
           +--------+--------+--------+--------+
           |01001100|  0   9 |  0   5 |00000010|
           +--------+--------+--------+--------+
      
                      Length
                    +--------+--  --+
                    |  0   6 |Cooper|
                    +--------+--  --+
      
      
      
      
      
      
      
                                     92

                                                       Appendix H
      
      
             Field    Length    FID      ASCII
           +--------+--------+--------+--------+
           |01001100|  0   A |  0   1 |00000010|
           +--------+--------+--------+--------+
      
                      Length
                    +--------+--- ---+
                    |  0   7 |Johnson|
                    +--------+--- ---+
      
             Field    Length    FID      Date    Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   7 |  0   2 |00101000|  1   4 |
           +--------+--------+--------+--------+--------+
      
                       ASCII   Length
                    +--------+--------+----          ----+
                    |00000010|  1   2 |19800814-1030-0400|
                    +--------+--------+----          ----+
      
             Field    Length    FID      ASCII   Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   0 |  2   5 |00000010|  0   D |
           +--------+--------+--------+--------+--------+
      
                    +----     ----+
                    |Redistributed|
                    +----     ----+
      
            Message       Length         Type
           +--------+--------+--------+--------+
           |01001101|  8   1 |  B   6 |  0   1 |
           +--------+--------+--------+--------+
      
              Field   Length    FID      ASCII
           +--------+--------+--------+--------+
           |01001100|  0   A |  0   5 |00000010|
           +--------+--------+--------+--------+
      
                      Length
                    +--------+--- ---+
                    |  0   7 |Johnson|
                    +--------+--- ---+
      
             Field    Length    FID      ASCII
           +--------+--------+--------+--------+
           |01001100|  0   A |  0   1 |00000010|
           +--------+--------+--------+--------+
      
      
      
      
      
      
                                     93

                                                       Appendix H
      
      
                      Length
                    +--------+--- ---+
                    |  0   7 |Stevens|
                    +--------+--- ---+
      
             Field    Length    FID     ASCII    Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   3 |  0   7 |00000010|  1   0 |
           +--------+--------+--------+--------+--------+
      
                    +----        ----+
                    |Project Deadline|
                    +----        ----+
      
             Field    Length    FID      Date    Length
           +--------+--------+--------+--------+--------+
           |01001100|  1   7 |  0   2 |00101000|  1   4 |
           +--------+--------+--------+--------+--------+
      
                      ASCII    Length
                    +--------+--------+----          ----+
                    |00000010|  1   2 |19800814-1000-0400|
                    +--------+--------+----          ----+
      
             Field    Length    FID      ASCII   Length
           +--------+--------+--------+--------+--------+
           |01001100|  6   D |  0   4 |00000010|  6   A |
           +--------+--------+--------+--------+--------+
      
                    +----
                    |Don't forget the project report is
                    +----
      
                     due tomorrow.  Please have<CrLf>
      
                     your section to me by three this
      
                           ----+
                     afternoon.|
                           ----+
      
      
      
      H.6  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.5, but with a known rather than an unknown length.
      
      
      
      
      
                                     94

                                                       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 values 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 a.m. EDT. The subject of the message is "Project Deadline" and the message is a reminder that the deadline is the next day and that the section of the report for the project being done by Johnson should be
      turned in to Stevens by 3 p.m. that day.
      
      
            Message   Length    Type
           +--------+--------+--------+
           |01001101|  8   0 |  0   1 |
           +--------+--------+--------+
      
              Field   Length    FID     ASCII
           +--------+--------+--------+--------+
           |01001100|  0   A |  0   5 |00000010|
           +--------+--------+--------+--------+
      
                      Length
                    +--------+--- ---+
                    |  0   7 |Johnson|
                    +--------+--- ---+
      
      
      
      
      
      
                                     95

                                                       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   7 |  0   2 |00101000|  1   4 |
           +--------+--------+--------+--------+--------+
      
                      ASCII    Length
                    +--------+--------+----          ----+
                    |00000010|  1   2 |19800814-1000-0400|
                    +--------+--------+----          ----+
      
             Field    Length    FID      ASCII   Length
           +--------+--------+--------+--------+--------+
           |01001100|  6   D |  0   4 |00000010|  6   A |
           +--------+--------+--------+--------+--------+
      
                    +----
                    |Don't forget the project report is
                    +----
      
                     due tomorrow.  Please have<CrLf>
      
                     your section to me by three this
      
                           ----+
                     afternoon.|
                           ----+
      
                    End-of-Con Length
                    +--------+--------+
                    |00000000|00000000|
                    +--------+--------+
      
      
      
      
                                     96

                                                       Appendix H
      
      
      
      
      
      
      
      H.7  Message Encoding Using Vendor-Defined Fields
      
      
           This  example is provided to illustrate the encoding of non-
FIPS format messages in the FIPS format. It is the intent of the standard to deal with computer based message systems which are primarily intended for person-to-person use. This example deals with the definition and use of vendor-defined fields to extend the use of the standard to station-to-station messaging. The context is a military message using the military standard JANAP-
      128 format.
      
      
      H.7.1  Example of a JANAP-128 Message
      
      
          JANAP-128
RTTUZYUW RUABCDE0010 0330930-UUUU--RUXABYE. ZNR UUUUU R 020830Z FEB 82 FM Commander,Atlantic Fleet TO USS SHIPA BT
          UNCLAS
      
           MESSAGE        BODY
      
          BT
#0010
          NNNN
      
      
      H.7.2  Encoding of Example using the FIPS Message Format
      
      
            Message   Length             Type
           +--------+--------+--------+--------+
           |01001101|  8   1 |  D   0 |  0   1 |
           +--------+--------+--------+--------+
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  0   4 |  1   8 |
                    +--------+--------+--------+
      
      
      
      
      
                                     97

                                                       Appendix H
      
      
                               ASCII    Length
                             +--------+--------+--------+
                             |00000010|  0   1 |    R   |
                             +--------+--------+--------+
      
                      Field    Length    FID
                    +--------+--------+--------+--------+--------+
                    |01001100|  0   7 |  8   2 |  0   0 |  0   1 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+--------+--------+
                             |00000010|  0   2 |    T   |    T   |
                             +--------+--------+--------+--------+
      
                      Field    Length    FID
                    +--------+--------+--------+--------+--------+
                    |01001100|  0   6 |  8   2 |  0   0 |  0   2 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+--------+
                             |00000010|  0   1 |    U   |
                             +--------+--------+--------+
      
                      Field    Length    FID
                    +--------+--------+--------+--------+--------+
                    |01001100|  0   9 |  8   2 |  0   0 |  0   3 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----  ----+
                             |00000010|  0   4 |   ZYUW   |
                             +--------+--------+----  ----+
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  0   A |  2   2 |
                    +--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----   ----+
                             |00000010|  0   7 |  RUABCDE  |
                             +--------+--------+----   ----+
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  0   7 |  1   7 |
                    +--------+--------+--------+
      
      
      
      
      
                                     98

                                                       Appendix H
      
      
                               ASCII    Length
                             +--------+--------+----  ----+
                             |00000010|  0   4 |   0010   |
                             +--------+--------+----  ----+
      
                      Field    Length    FID      Date    Length
                    +--------+--------+--------+--------+--------+
                    |01001100|  1   8 |  0   2 |00101000|  1   5 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----           ----+
                             |00000010|  1   3 |19820202093000-0000|
                             +--------+--------+----           ----+
      
                      Field    Length    FID
                    +--------+--------+--------+--------+--------+
                    |01001100|  0   9 |  8   2 |  0   0 |  0   2 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----  ----+
                             |00000010|  0   4 |   UUUU   |
                             +--------+--------+----  ----+
      
                      Field    Length    FID
                    +--------+--------+--------+--------+--------+
                    |01001100|  0   C |  8   2 |  0   0 |  0   4 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----  ----+
                             |00000010|  0   7 |  RUXABYE |
                             +--------+--------+----  ----+
      
                      Field    Length    FID
                    +--------+--------+--------+--------+--------+
                    |01001100|  0   A |  8   2 |  0   0 |  0   2 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----   ----+
                             |00000010|  0   5 |   UUUUU   |
                             +--------+--------+----   ----+
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  0   4 |  1   8 |
                    +--------+--------+--------+
      
      
      
      
      
                                     99

                                                       Appendix H
      
      
                               ASCII    Length
                             +--------+--------+--------+
                             |00000010|  0   1 |    R   |
                             +--------+--------+--------+
      
                      Field    Length    FID      Date    Length
                    +--------+--------+--------+--------+--------+
                    |01001100|  1   4 |  1   1 |00101000|  1   1 |
                    +--------+--------+--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----       ----+
                             |00000010|  0   F |8202020830-0000|
                             +--------+--------+----       ----+
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  1   B |  0   1 |
                    +--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+
                             |00000010|  1   8 |
                             +--------+--------+
      
                                      +----                ----+
                                      |Commander,Atlantic Fleet|
                                      +----                ----+
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  0   C |  0   5 |
                    +--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----   ----+
                             |00000010|  0   9 | USS SHIPA |
                             +--------+--------+----   ----+
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  0   7 |  0   4 |
                    +--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----  ----+
                             |00000010|  0   4 |   BODY   |
                             +--------+--------+----  ----+
      
      
      
      
      
      
                                     100

                                                       Appendix H
      
      
                      Field    Length    FID
                    +--------+--------+--------+
                    |01001100|  0   7 |  1   7 |
                    +--------+--------+--------+
      
                               ASCII    Length
                             +--------+--------+----  ----+
                             |00000010|  0   4 |   0010   |
                             +--------+--------+----  ----+
      
      
      H.7.3  Field Mappings of JANAP-128 to FIPS Format
      
      
          JANAP-128 Field              FIPS Format Field
      
          Precedence                   Precedence (Appendix A)
Language Media Format Vendor-Defined Security Vendor-Defined
          Content Indicator Code       Vendor-Defined
          Origination Station          Sender (Appendix A)
            Routing Indication
Station Serial Number Originator-Serial-Number
(Appendix A)
Time of File Posted-Date (Appendix A)
          Security                     Vendor-Defined
          Destination Station          Vendor-Defined
            Routing Indicator
Security Vendor-Defined Precedence Precedence (Appendix A) Date/Time Group Date (Appendix A) FM From (Appendix A) TO To (Appendix A) Body of Message Text (Appendix A) Station Serial Number Originator-Serial-Number
                                         (Appendix A)
      
      
      H.7.4  Vendor-Defined Fields
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     101

-----------------------------------------------------------------
      
      
           Field Name                                Identifier Value
                                                                     8
      
                                 Description
      
      
      -----------------------------------------------------------------
      
      
           Language Media Format                                    01
8
This field contains two ASCII characters; the first
      indicates the input media and the second the output media.
      
           Security                                                 02
8
This field contains a variable length ASCII character
      indicator of the security classification of the messages.
      
           Content Indicator Code                                   03
8
This field contains four ASCII characters and provides
information describing the message content and message handling
      actions to be performed.
      
           Destination Station Routing Indicator                    04
8
This field contains four ASCII characters indicating the CPU
      and terminal device to which the message should be sent.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     102

                           REFERENCES
      
      
      
      
      [BlaR-80]
R. P. Blanc and J. F. Heafner. The NBS Program in Computer
           Network Protocol Standards. In Proceedings, ICCC 80.  1980.
      
      [CCIT-82]
CCITT Study Group VII/5. Draft recommendation X.MHS1: Message Handling Systems: System Model - Service Elements (Version 2). Technical Report, International Telegraph and
           Telephone Consultative Committee (CCITT), December, 1982.
      
      [CroD-77]
David H. Crocker, John J. Vittal, Kenneth T. Pogran, D. Austin Henderson, Jr. Standard for the Format of ARPA Network Text Messages. RFC 733, The Rand Corporation, Bolt Beranek and Newman Inc, Massachussets Institute of
           Technology, Bolt Beranek and Newman Inc., November, 1977.
      
      [FeiE-79]
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-82]
ISO/TC97/SC16. Information Processing Systems - Open Systems Interconnection - Basic Reference Model. ISO/DIS 7498, ISO International Organization for Standardization Organization
           Internationale de Normalisation, December, 1982.
      
      [NatB-68]
National Bureau of Standards. Calendar Date. Federal Information Processing Standards Publication 4, U.S. Department of Commerce / National Bureau of Standards,
           November, 1968.
      
      [NatB-75]
National Bureau of Standards. Code Extension Techniques in 7 or 8 Bits. Federal Information Processing Standards Publication 35, U.S. Department of Commerce / National
           Bureau of Standards, June, 1975.
      
      
      
      
                                     103

[NatB-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.
      
      [NatB-79b]
National Bureau of Standards. Representations of Universal Time, Local Time Differentials, and United States Time Zone References for Information Interchange. Federal Information Processing Standards Publication 59, U.S. Department of
           Commerce / National Bureau of Standards, February, 1979.
      
      [NatB-80]
National Bureau of Standards. Code for Information Interchange. Federal Information Processing Standards Publication 1-1, U.S. Department of Commerce / National
           Bureau of Standards, December, 1980.
      
      [PosJ-79]
Jonathan B. Postel. INTERNET MESSAGE PROTOCOL. RFC 753,
           Information Sciences Institute, March, 1979.
      
      [TasG-80]
Task Group X3S33 on Data Communications Formats, ANSI Subcommittee X3S3 on Data Communications. Third Draft Proposed American National Standard for Heading Format Structure for Code Independent Communication Headings. ANSI document X3S37/80-01, Computer and Business Equipment
           Manufacturers Association, 1980.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     104

                              INDEX
      
      
      
      
      
                ASCII-String   35, 36, 47, 50, 52, 54, 58, 59, 60, 61,
63, 65, 69
Assignment 22, 28, 61 Attachments 23, 57
                Author   19, 57
      
                BASIC   18
BASIC Data Elements
ASCII-String 47, 63 Date 50, 65 End-of-Constructor 48, 66 Field 50, 66 Message 51, 67
BASIC fields
Cc 20 Reply-To 19 Subject 23 Text 23 BASIC syntactic elements 35 Bcc 19, 25, 57 Bit numbering in octets 37 Bit-String 36, 42, 47, 49, 50, 52, 64, 65, 69
                Boolean   36, 48, 64
      
                Cc   20, 58
Chains of correspondence 29 Circulate-Next 20, 31, 58 Circulate-To 20, 31, 58 Circulation 31 Comment 36, 37, 44, 54 Comments 23, 58 Compliance requirements 41 Compressed 37, 43, 49, 54, 65 Compression identifier 49, 65 Compression Identifiers
Unspecified 54
Constructor data element 35, 36 Contents 38, 76
                Cross Referencing   29
      
                Data Element Contents   43, 44, 87, 42, 44, 52, 69, 42,
44, 46, 47, 51, 64, 69, 87
Data Elements
ASCII-String (BASIC) 47, 63
                   Bit-String (OPTIONAL)   47, 64
      
      
      
      
                                     105

             Boolean (OPTIONAL)   48, 64
Compressed (OPTIONAL) 49, 65 Date (BASIC) 50, 65 Encrypted (OPTIONAL) 50, 65 End-of-Constructor (BASIC) 48, 66 Extension (OPTIONAL) 52, 66 Field (BASIC) 50, 66 Integer (OPTIONAL) 48, 67 Message (BASIC) 51, 67 No-Op (OPTIONAL) 49, 67 Padding (OPTIONAL) 49, 68 Property (OPTIONAL) 51, 68 Property-List (OPTIONAL) 51, 68 Sequence (OPTIONAL) 51, 69 Set (OPTIONAL) 52, 69 Unique-ID (OPTIONAL) 52, 69 Vendor-Defined (OPTIONAL) 53, 70 Date 20, 50, 58, 60, 61, 62, 65 Dating 30 Delivery 13, 20, 60 Delivery Protocol 13
                Delivery Slot   13
      
                Encapsulating   26
Encrypted 37, 43, 50, 54, 65 Encryption identifier 50, 65 Encryption Identifiers FIPS-Standard 54 Unspecified 54 End-Date 20, 21, 30, 58, 62 End-Of-Constructor 36, 42, 44, 48, 66
                Extension   35, 46, 52, 66
      
                Field   14, 31, 35, 36, 37, 43, 50, 51, 66, 67, 72
Field Identifier 50, 66 Field label presentation 35 Fields Attachments (OPTIONAL) 57, 23 Author (OPTIONAL) 57, 19 Bcc (OPTIONAL) 57, 19 Cc (BASIC) 58, 20 Circulate-Next (OPTIONAL) 58, 20 Circulate-To (OPTIONAL) 58, 20 Comments (OPTIONAL) 58, 23 Date (OPTIONAL) 58, 20 End-Date (OPTIONAL) 58, 20 From (REQUIRED) 59, 19 In-Reply-To (OPTIONAL) 59, 21 Keywords (OPTIONAL) 59, 23 Message-Class (OPTIONAL) 59, 22
                   Message-ID (OPTIONAL)   59, 21
      
      
      
      
                                     106

             Obsoletes (OPTIONAL)   59, 21
Originator-Serial-Number (OPTIONAL) 59, 21 Posted-Date (REQUIRED) 60, 20 Precedence (OPTIONAL) 60, 22 Received-Date (OPTIONAL) 60, 20 Received-From (OPTIONAL) 60, 22 References (OPTIONAL) 60, 22 Reissue-Type (OPTIONAL) 61, 22 Reply-To (BASIC) 61, 19 Sender (OPTIONAL) 61, 19 Start-Date (OPTIONAL) 61, 21 Subject (BASIC) 61, 23 Text (BASIC) 61, 23 To (REQUIRED) 61, 19 Warning-Date (OPTIONAL) 62, 21
FIPS-Standard 54, 55
                From   17, 19, 29, 57, 59, 61
      
                Globally unique identifiers   29
      
                Identifier octet   38, 41, 37, 38, 42, 44, 76
Identifiers
globally unique 29
In-Reply-To 21, 29, 59 Indefinite length code 41
                Integer   36, 48, 52, 67, 69
      
                Keywords   23, 59, 88
      
                Length Code   40, 41, 42, 38, 39, 40, 41, 42, 44, 46,
76, 77, 87
                Long length code   41
      
                Message Transfer System   13, 22, 60
Message 14, 17, 35, 36, 37, 43, 51, 67 Message content 13 Message envelope 13 Message stores 30 Message Transfer System 13, 22, 60, 12, 13, 14, 17,
20, 22, 60
Message Types
FIPS-Standard 55
Message-Class 22, 59
                Message-ID   21, 22, 29, 31, 59, 60
      
                No-Op   49, 67
                Numbering bits in octets   37
      
                Obsoletes   21, 29, 59
Octets
                   bit numbering in   37
      
      
      
      
                                     107

          OPTIONAL   18
                OPTIONAL Data Elements
Bit-String 47, 64 Boolean 48, 64 Compressed 49, 65 Encrypted 50, 65 Extension 52, 66 Integer 48, 67 No-Op 49, 67 Padding 49, 68 Property 51, 68 Property-List 51, 68 Sequence 51, 69 Set 52, 69 Unique-ID 52, 69 Vendor-Defined 53, 70
OPTIONAL fields
Attachments 23 Author 19 Bcc 19 Circulate-Next 20 Circulate-To 20 Comments 23 Date 20 End-Date 20 In-Reply-To 21 Keywords 23 Message-Class 22 Message-ID 21 Obsoletes 21 Originator-Serial-Number 21 Precedence 22 Received-Date 20 Received-From 22 References 22 Reissue-Type 22 Sender 19 Start-Date 21 Warning-Date 21 OPTIONAL syntactic elements 35 Originator 15, 18, 20, 30, 57, 58, 59, 61
                Originator-Serial-Number   21, 30, 59
      
                Padding   49, 68
Person 18 Posted-Date 17, 20, 31, 58, 60 Posting 13 Posting Protocol 13 Posting Slot 13 Precedence 22, 60
                Precedence categories   22
      
      
      
      
                                     108

          Precedence scheme   60
                Presentation
field label 35
Primitive data element 36, 35, 36 Printing-Name 36, 37, 44, 54, 82 Process 18 Properties Comment 54 Printing-Name 54 Property 38, 43, 51, 68 Property-Identifier 51, 68
                Property-List   36, 38, 44, 46, 51, 68, 76
      
                Qualifier   38, 39, 40, 41, 42, 43, 44, 46, 47, 49, 50,
51, 52, 53, 64, 65, 66, 68, 70, 76
                Qualifiers   43
      
                Received-Date   20, 60
Received-From 22, 60 Recipient 15, 19, 20, 22, 57, 58, 60, 61 Redistribution 22, 26, 61 References 22, 29, 60 Reissue-Type 22, 61 Reply 18, 28 Reply-to 19, 28, 59, 61 REQUIRED 18 REQUIRED fields From 19 Posted-Date 20 To 19
Requirements
compliance 41
                Role   18
      
                Sender   19, 31, 61
Sequence 35, 36, 51, 69 Sequences 36 Serial Numbers 21, 30, 59 Set 36, 51, 52, 69 Short length code 41 Slot 13 Start-Date 21, 30, 61 Subject 23, 61
                Syntactic reissuing   26
      
                Text   23, 32, 61
                To   17, 19, 31, 37, 61
      
                Unique identifiers   29
Unique-ID 52, 59, 60, 69
                Unspecified   54
      
      
      
      
                                     109

          User Agent   12, 13, 14
                User interface   35
      
                Vendor-Defined   35, 46, 53, 70
      
                Warning-Date   21, 30, 62
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
                                     110



Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.
inserted by FC2 system