RFC 806
Proposed Federal Information Processing Standard: Specification for message format for computer based message systems
RFC 806: Specification for Message Format for Computer Based Message Systems 💌
Part 1 of 18 🎀
okay bestie, let's start with the title block because it tells us everything about this doc 👀 This is a Proposed Federal Information Processing Standard (so it's a government standard proposal, not a regular internet RFC), and it's from the National Bureau of Standards, specifically their Institute for Computer Sciences and Technology. It's dated September 1981 and filed under the Network Working Group. The title block doesn't name any individual authors, and it doesn't say that this doc obsoletes or updates anything. It's all about the message format for computer based message systems (CBMSs) 💅
Table of Contents 🗂️
Page
EXECUTIVE SUMMARY 1
1. INTRODUCTION 3
1.1 Guide to Reading This Document 3
1.2 Vendor-Defined Extensions to the Specification 4
1.3 The Scope of the Message Format Specification 4
1.4 Issues Not Within the Scope of the Message Format 4
Specification
1.5 Relationship to Other Efforts 5
2. A SIMPLE MODEL OF A CBMS ENVIRONMENT 6
2.1 Logical Model of a CBMS 8
2.2 Relationship to the ISO Reference Model for Open 10
Systems Interconnection
2.3 Messages and Fields 10
2.4 Message Originators and Recipients 11
3. SEMANTICS 12
3.1 Semantics of Message Fields 12
3.1.1 Types of fields 12
3.1.2 Semantic Compliance Categories 13
3.1.3 Originator fields 13
3.1.4 Recipient fields 14
3.1.5 Date fields 15
3.1.6 Cross-reference fields 16
3.1.7 Message-handling fields 16
3.1.8 Message-content fields 17
3.1.9 Extensions 18
i
3.2 Message Processing Functions 18
3.2.1 Message creation and posting 19
3.2.2 Message reissuing and forwarding 20
3.2.2.1 Redistribution 22
3.2.2.2 Assignment 22
3.2.3 Reply generation 23
3.2.4 Cross referencing 24
3.2.4.1 Unique identifiers 24
3.2.4.2 Serial numbering 24
3.2.5 Life span functions 25
3.2.6 Requests for recipient processing 25
3.2.6.1 Message circulation 26
3.3 Multiple Occurrences and Ordering of Fields 26
4. SYNTAX 28
4.1 Introduction 28
4.1.1 Message structure 28
4.1.2 Data elements 29
4.1.2.1 Primitive data elements 30
4.1.2.2 Constructor data elements 30
4.1.3 Properties 30
4.1.3.1 Printing-names 30
4.1.3.2 Comments 31
4.1.4 Data compression and encryption 31
4.1.5 Data sharing 31
4.2 Overview of Syntax Encoding 32
4.2.1 Identifier Octets 32
4.2.2 Length code and Qualifier components 33
4.2.2.1 Length Codes 35
4.2.2.2 Qualifier 36
4.2.3 Property-List 38
4.2.4 Data Element Contents 38
4.3 Data Element Syntax 39
4.3.1 Data elements 39
4.3.1.1 Primitives 42
4.3.1.2 Constructors 44
4.3.2 Using data elements within message fields 48
4.3.3 Properties and associated elements 49
4.3.4 Encryption identifiers 49
4.3.5 Compression identifiers 49
4.3.6 Message types 50
SUMMARY OF APPENDIXES 51
ii
APPENDIX A. FIELDS -- IMPLEMENTORS' MASTER REFERENCE 52
APPENDIX B. DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE 57
APPENDIX C. DATA ELEMENT IDENTIFIER OCTETS 65
APPENDIX D. SUMMARY OF MESSAGE FIELDS BY COMPLIANCE 66
CATEGORY
D.1 REQUIRED Fields 66
D.2 BASIC Fields 66
D.3 OPTIONAL Fields 66
APPENDIX E. SUMMARY OF MESSAGE SEMANTICS BY FUNCTION 68
E.1 Circulation 68
E.2 Cross Referencing 68
E.3 Life spans 68
E.4 Delivery System 68
E.5 Miscellaneous Fields Used Generally 69
E.6 Reply Generation 69
E.7 Reissuing 69
E.8 Sending (Normal Transmission) 69
APPENDIX F. SUMMARY OF DATA ELEMENT SYNTAX 70
APPENDIX G. SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY 72
G.1 BASIC Data Elements 72
G.2 OPTIONAL Data Elements 72
APPENDIX H. EXAMPLES 74
iii
H.1 Primitive Data Elements 74
H.2 Constructor Data Elements 76
H.3 Fields 81
H.4 Messages 84
H.5 Unknown Lengths 88
REFERENCES 92
INDEX 94
ivList of Figures 🖼️
FIG. 1. LOGICAL MODEL OF A COMPUTER BASED MESSAGE SYSTEM 8
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION 21
FIG. 3. EXAMPLE OF MESSAGE CIRCULATION 27
FIG. 4. STRUCTURE OF IDENTIFIER OCTETS 34
FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH 35
CODES
FIG. 6. REPRESENTATION OF LENGTH CODES 36
FIG. 7. EXAMPLES OF LENGTH CODES 37
FIG. 8. EXAMPLES OF QUALIFIER VALUES 38List of Tables 📋
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS 19
TABLE 2. TYPE BITS IN THE IDENTIFIER OCTET 33EXECUTIVE SUMMARY ✨
okay so this spec is all about the message format for computer based message systems (CBMSs). Basically, it's how different CBMSs can swap messages and still understand each other, no cap 💌
Interchange can be tackled at a bunch of different levels. One level handles the physical connections. Another handles how information actually travels between CBMSs. Another covers the form and meaning of the messages being exchanged, and the highest level covers operations on a message. Each of these levels would get its own standard 🔥
This particular spec only deals with form and meaning at the moment a message leaves one CBMS and arrives at another. Messages are built out of fields, and each field holds a different kind of info: who sent it, who it's going to, the subject, precedence and security, references to earlier messages, and the actual text. The syntax (the standard format) means one CBMS can process what another one generated. The semantics (the standard meanings) mean everyone who gets a message reads it the way its sender meant it 🫶
Any CBMS that implements this spec is compatible with any other CBMS that implements it too. So a message posted by one system can be received and interpreted by a totally different system, which is honestly iconic 👑
This spec wasn't made in a vacuum. It came out of looking at CBMSs that were already in use in commercial and research environments. Three major design perspectives shaped it:
- Viability. The spec uses concepts that already work. It was designed with implementation concerns in mind 🦋
- Compatibility. The spec contains concepts from existing CBMSs. Because of that, lots of CBMSs already have functions and components similar to the ones needed to implement this spec 🌸
- Extensibility. This spec defines a broad range of message content components but only requires an elementary subset of them. That means even a super simple CBMS can implement it. It also has a rich set of optional components, plus mechanisms for user extensions and future extensions to the spec 🧚
The spec defines the form and meaning of message contents and their components as they pass from one CBMS to another through a message transfer system. It does not address any of the following major issues. 💀
- 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. 💅
- 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. 🎀
- 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. 🚚
- 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. ✉️
- 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. 🫶
1. INTRODUCTION ✨
A computer-based message system (CBMS) allows communication between "entities" (usually people) using computers. Computers serve both to mediate the actual communications between systems and to provide users with facilities for creating and reading the messages. 💻
CBMSs have been developing for over ten years. More recently, CBMSs have been one of the bases in industry for the introduction of office automation. A growing number of organizations use either their own or a commercially available CBMS. The design and complexity of these systems vary widely. This message format specification provides a basis for interaction between different CBMSs by defining the format of messages passed between them. 🌈
1.1. Guide to Reading This Document
The method of presenting the material in this specification is to combine the technical specification with tutorial information. This approach has been taken to place the specification in context and improve its readability. 📖
The core of the technical information in the document is in Section 2 "A Simple Model of a CBMS Environment", Section 3.1 "Semantics of Message Fields", Section 4.2 "Overview of Syntax Encoding", and Section 4.3 "Data Element Syntax". Appendixes A and B consolidate the technical informations. These appendices are designed for ease of reference and should be read in conjunction with the body of the report for a complete understanding of the message format presented in the specification. 🔥
Section 2 presents a simple model of operation of a CBMS. Section 3 discusses the components of messages and their meaning (semantics). This includes discussions of the recommended relationship between message components and CBMS user functions. (See Section 3.2.) Section 4 presents details of the form (syntax) required for components of a message. 🦋
Appendix D summarizes the components of messages according to whether they are required or optional for CBMSs implementing the message format specification. Appendix E organizes the message components according to the functional class of the components. Appendix F provides an overview of the syntactic elements defined by this message format specification; Appendix G summarizes those elements according to whether they are required or optional for a CBMS implementing the message format specification. Examples of each syntactic element appear in Appendix H, displaying syntax and describing the associated semantics. 🧚
1.2. Vendor-Defined Extensions to the Specification
This specification provides the capability of extending the range of functionality by the use of vendor-defined qualifiers and vendor-defined data elements. Any vendor who uses this capability to provide services which are essentially equivalent to those already designated as required, basic, or optional does not comply with the specification. 🚫
Heads up bestie: a vendor who builds "basically the same thing" as the required, basic, or optional stuff using these extensions is not complying. Don't be that vendor. 🙈
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. 🎯
- The meaning and form of standard fields to be used in messages.
- Which fields must be present in all messages.
- Which fields complying CBMSs must be able to process.
- How messages, fields, and the data contained in fields are represented.
1.4. Issues Not Within the Scope of the Message Format Specification
The message format specification does not address the following issues, some of which are being covered by other NBS standards developments. (See [BlaR-80] for a description of the NBS protocols program.) 🙅♀️
- The nature of a message transfer system, except to state the assumption that it transfers messages transparently.
- The form or nature of the protocols used to transfer messages (posting, relay, and delivery protocols).
- The content and representation of message envelopes.
- Representations for unique identifiers (in particular, message identifiers).
- Network and internetwork addressing.
- Representations for identities of message originators and recipients.
- Functions that CBMSs provide for users.
- Presentation of messages to users.
- Representations for multi-media objects.
- Data representation for messages within CBMSs.
- Data sharing or any storage management within CBMSs.
- Representations for fixed or floating point numbers.
1.5. Relationship to Other Efforts
The message format specification is based on several documents and the current state of many CBMSs available both in industry and the research community. These documents include the standardization efforts in the ARPANet [CroD-77, PosJ-79] and the CCITT, proposed ISO and ANSI header format standards [TasG-80, ISOD-79], the work of IFIPS Working Group 6.5, and various papers about the general nature of mail systems, addressing, and mail delivery. (See [FeiE-79] for references.) 📚
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: 💌
- Message Creation: The facilities used by a message originator to create messages and specify to whom they are to be sent.
- Message Transfer: The facilities used to convey a message to its recipient(s).
- 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. 🌸
- 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. 🏃♀️
- Transmission of CBMS messages is asynchronous. The recipient's system need not be available when the message leaves the originator's system. That is, CBMS message transfer facilities are store-and-forward. ⏳
- 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 of data that an originator wishes to send to a recipient. By contrast, Teletex systems and communicating word processors handle the transfer of final form documents; compatible communicating word processors can exchange documents in editable form; Telex and TWX deal in unformatted text. 🍓
- CBMSs offer message creation facilities as an important part of the system. CBMSs assist users in the preparation of messages by having text editing facilities available and allowing users to include data stored on-line in messages. Some CBMSs also interface to other office automation facilities, such as formatters and spelling correctors. This is not true of Telex, TWX, or similar services. 🎀
Okay so CBMSs are lowkey iconic because they give you recipient processing facilities, and that's a big deal 💅✨ Most other electronic communications don't do this. Telex and TWX machines just print your message on paper when it arrives and don't keep a copy in the system 🖨️ (Teletex is similar, but some Teletex systems can keep a copy of the document in local storage 🗄️). Communicating word processors might tell their operators that a document arrived and is stored on-line, but they don't really offer much else in the way of recipient processing 🥺. Most CBMSs give you at least these recipient processing facilities:
- The ability to keep a copy of a message on-line after it has been read 📚
- The ability to examine or delete stored messages one at a time 🗑️
- The ability to organize messages using some kind of electronic "file folder" 📁
- The ability to tell if a message is recent (it arrived since the last time the recipient used the CBMS) or unseen (the recipient has never looked at it) 👀
- The ability to summarize stored messages. A summary usually includes things like whether the message is recent or unseen, when it was received, its length, who it's from, and its subject 📝
- The ability to retrieve a stored message based on one or more of its attributes (for example, when it was received, whether or not it has been seen or deleted, and the values in its fields) 🔍
- A forward facility that lets users include all or part of a message in a new outgoing message 💌
- A reply facility that lets users answer messages without having to type in a brand new list of recipients 🫶
2.1 Logical Model of a CBMS 🧠
Okay this part is so structured and I'm obsessed. The CBMS facilities for message creation, transfer, and recipient processing are reflected in a logical model of a CBMS developed by IFIP Working Group 6.5 [SchP-79]. (An essentially identical model is being used by CCITT Study Group VII, Question 5, regarding Message Handling Facilities.) The model has two main pieces: a Message Transfer System and a number of User Agents. Check out Figure 1 below 👇
| |
| ************* |
********* ------> * Message * -------> *********
* User * Posting * Transfer * Delivery * User *
* Agent * Protocol * System * Protocol * Agent *
********* <------- ************* <------- *********
| |
| |
Posting Delivery
Slot Slot
Message Flow
Originator --------------------------------> RecipientFIG. 1. LOGICAL MODEL OF A COMPUTER BASED MESSAGE SYSTEM 🎀
A User Agent is a functional entity that acts on behalf of a user. It helps with creating and processing messages and talks to the Message Transfer System 🤖💬.
The Message Transfer System is an entity that accepts a message from its originator's User Agent and eventually passes it to each of its recipients' User Agents. It may do routing and storage functions (among other things) to get the job done 🚚📦.
Transferring a message from an originator's User Agent to the Message Transfer System is called Posting. The originator's User Agent and the Message Transfer System engage in a Posting Protocol to make Posting happen. Transferring a message from the Message Transfer System to a recipient's User Agent is called Delivery, and the recipient's User Agent and the Message Transfer System engage in a Delivery Protocol to make Delivery happen 🔄.
The point where responsibility for a message gets handed off is called a Slot. The Posting Slot is the point where responsibility passes from an originator's User Agent to the Message Transfer System. The Delivery Slot is the point where responsibility passes from the Message Transfer System to a recipient's User Agent 🫱🫲.
The model splits messages into two parts: the message content and the message envelope. The message content is the information the originator wants to send to the recipient. This message format specification deals solely with the message content 🎯. The message envelope has all the information the Message Transfer System needs to do its job, and this message format specification does not specify the message envelope. Some of the data on the message envelope could be redundant with some data in the message content. The Message Transfer System isn't expected to look at the message content unless the originator's or recipient's User Agent tells it to 🙈.
This message format specification doesn't put any restrictions on the Message Transfer System itself, except that it has to be transparent to the contents of messages. It also doesn't dictate the form or nature of any protocol the Message Transfer System uses. And finally, it doesn't specify the content or form of the message envelope. Basically, the message format specification defines the format for the contents of messages, not the way they're transmitted 📐.
Lots of today's commercially available CBMSs include all of the facilities in the logical model 💻. Their architectures may reflect the savings you can get when systems are self-contained. For example, stand-alone systems that store messages in a single central database don't need a Message Transfer System at all. An implementation can integrate the User Agent and Message Transfer System software, which gets rid of the Posting and Delivery Protocols 🧩.
2.2 Relationship to the ISO Reference Model for Open Systems Interconnection 🌐
Subcommittee TC97/SC16 of the International Standards Organization (ISO) developed a reference model for describing communications between "open" systems [ISOD-81]. It's known as the ISO Reference Model for Open Systems Interconnection (OSI). It splits communications protocols into seven layers, from physical interconnection at the bottom all the way up to data exchange by application programs at the top 🪜.
This message format specification deals with data used by an application within a system. So the message format being specified here is not a protocol 🙅♀️. Since it isn't a protocol, it sits outside the model for open systems interconnection. User Agents are application layer entities (layer 7), though, 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 is made up of a series of components called fields. Fields can be described by their meaning in a message (semantics) and by the format required for them in a message (syntax) 🔍.
Semantically, a field is just a component of a message, and this message format specification defines the meanings of particular fields. Syntactically, a field is a unit of data whose form is defined by this message format specification. Users or vendors can define additional fields too, as long as those fields follow the syntactic and semantic rules this message format specification sets for additional fields 🧁.
(A quick note on terminology, bestie: a message is made of components called fields. The words "message" and "field" get used both in the casual sense from the previous sentence and in a more restricted sense as names of particular syntactic elements. As syntactic element names, Message and Field are always capitalized. ✨)
Some CBMS functions depend on the contents of particular fields, while other functions (like being able to read a message) may have little to do with the fields themselves. Section 3.2 talks about some of the specific functions a CBMS might give users, and the fields that have to be used to support those functions 📋.
2.4 Message Originators and Recipients 🧑🤝🧑
This message format specification talks about message originators and recipients. These terms were defined functionally in Figure 1. When the message format specification refers to the identity of a message originator or recipient, it means "that information which uniquely identifies the message originator or recipient within the domain of the given message system." 🪪 The syntax and semantics of message addressing are outside the scope of the message format specification.
Originators and Recipients can be people, roles, or processes. Let's break it down 🦋.
People. People as originators and recipients are specific individuals. Obviously 🙄💕.
Roles. Roles identify functions within organizations, as opposed to the specific individuals who perform them. For example, imagine a newspaper that produces both morning and evening editions, so it runs more than one shift. Someone who wants to contact the city desk would send a message to the city desk role, instead of trying to figure out 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're actually performing a role at the time 💁♀️.)
Processes. A process in a computer can be either an originator or a recipient for messages. A computer system might send a message to notify a recipient about the status of some task. For example, an archive utility could tell users about files that have been archived, and a distributed file system could tell a user that a remote file has been deposited on a local file system 🗂️. Messages can also 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 on message contents 🤖✨.
3. SEMANTICS ✨
okay so, some CBMSs let you send messages to groups 🫶 A group is basically a predefined list of recipients. Instead of typing out a bunch of names, the sender puts in one group name as the recipient and the message goes to everyone on that list. It's giving convenience AND accuracy, which is honestly iconic 💅
This section is all about two big topics: how message processing functions work, and what the message fields actually mean 🧠 Section 3.1 breaks down the six functional groups of message fields: Origination, Dates, Recipients, Cross-referencing, Message-handling, and Message-contents. Section 3.1.1 goes deeper into each group and walks through the semantics of every field in it. Section 3.2 then covers the processing functions that depend on what particular fields mean 🦋
3.1. Semantics of Message Fields 💌
okay so the general definition of a message is covered in Sections 1 and 2 🎀 A semantically valid message must contain one From field, one To field, and one Posted-Date field. Beyond that, it can have any number of other fields, depending on the processing and functions supplied by the originating or receiving CBMS. (Section 3.2 describes the classes of functions CBMSs supply.)
3.1.1. Types of fields 🌸
message receiving programs are required to interpret fields according to the semantics described in the rest of this se. The message fields defined in this document are sorted into these functional categories:
- Originator fields tell you who or what took part in creating the message, and where replies should go 👑 (See Section 3.1.3.)
- Date fields record when events happen, like message creation or expiration ⏰ (See Section 3.1.5.)
- Recipient fields tell you who or what is supposed to receive the message 💖 (See Section 3.1.4.)
- Cross-reference fields label a message or point to other messages 🔗 (See Section 3.1.6.)
- Message-handling fields record what type of service the sender asked the message transfer system for, or how recipients should treat the message 🧚 (See Section 3.1.7.)
- Message-content fields either hold the main content of a message or index or summarize it ✨ (See Section 3.1.8.)
- Extension fields give you ways to extend the message format specification 🌈 (See Section 3.1.9.)
3.1.2. Semantic Compliance Categories 🎀
okay this part is about checking whether a CBMS follows the semantic requirements of this message format spec. Every message field gets sorted into one of three categories 📋
REQUIRED — these fields must be in every message, and receiving programs must process them the way the message format spec defines 😤
BASIC — these fields don't have to show up in every message, but when they do show up, receiving programs must process them the way the message format spec defines 🫶
OPTIONAL — these fields don't have to show up in every message, and receiving programs may ignore them. The exact meaning of "ignored" isn't specified by the message format spec. In general, a CBMS must recognize that an optional field exists (so optional fields shouldn't cause errors), and it must not process the field in a way that goes against the semantics the message format spec defines for that field 💅
(Syntactic compliance is defined in Section 4.1.2. 📐)
3.1.3. Originator fields 👑
a message originator can be a person, a role, or a process 🧑💻 Originator fields are how you find out who the author is, who's responsible for the message, who or what actually sent it, and where replies should be directed. (See Section 2.4.)
From (REQUIRED) 💅 This field has the identity of the originator(s) who take formal responsibility for the message. If there's no Reply-To field in a message, replies go to whatever's in the From field.
Reply-To (BASIC) 💌 This field tells you who gets replies to the message.
Author (OPTIONAL) ✍️ This field names the individual(s) who wrote the main contents of the message. Using Author is discouraged when its contents and the From field's contents would be totally redundant 🙄
Sender (OPTIONAL) 📮 This field names the agent that sent the message. It's used either when the sender isn't the originator responsible for the message, or to show which person in a group of responsible originators actually sent it. Using Sender is discouraged when its contents and the From field's contents would be totally redundant. Only one Sender field is allowed in a message 🔒
3.1.4. Recipient fields 🎯
message recipients can be people, roles, or processes. (See Section 2.4.) Recipient fields identify who or what is meant to receive the message 💖
To (REQUIRED) 🫶 This field names the primary recipients of a message.
Bcc (OPTIONAL) 🙈 This field names 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 more on how blind carbon copies lists get used.
Cc (BASIC) 📝 This field names the secondary recipients of a message (a "carbon copies" list).
Circulate-Next (OPTIONAL) 🔁 This field goes along with the Circulate-To field. (See Section 3.2.6.1.) It names all the recipients in a circulation list who haven't received the message yet 🧾
Circulate-To (OPTIONAL) 🔄 This field names the recipients of a circulated message. (See Section 3.2.6.1.) It's used together with the Circulate-Next field 💫
3.1.5. Date fields ⏰
there are date fields for two kinds of uses 🗓️ Dates can be tied to some event in the history of a message, and dates can also mark the span of time during which the message is meaningful (its life span) 🦋
Posted-Date (REQUIRED) 📬 This field has 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 allowed in a message 🔒
Date (OPTIONAL) 💭 This field has a date the message's originator wants to associate with the message. The Date field is to the Posted-Date field what the date on a letter is to the postmark the post office adds 📮💅
End-Date (OPTIONAL) 🌙 This field has the date on which a message stops having effect. (See also Section 3.2.5.)
Received-Date (OPTIONAL) 📥 Delivery date. This field can be added to a message by the recipient's message receiving program. It shows when the message left the delivery system and entered the recipient's message processing domain 🏁
Start-Date (OPTIONAL) 🌅 This field has the date on which a message takes effect. (See also Section 3.2.5.)
Warning-Date (OPTIONAL) ⚠️ This field is used either alone or together with an End-Date field. It has one or more dates. Those dates could be used by a message processing program as warnings about an upcoming end date or other event. (See also Section 3.2.5.) 🚨
3.1.6. Cross-reference fields 🔗
cross-reference fields can identify a message and point to other messages. (See Section 3.2.4.) 🧵
In-Reply-To (OPTIONAL) 💬 This field marks earlier correspondence that this message is replying to. The usual contents of this field are the contents of the Message-ID field of the message(s) being replied to 🫶
Message-ID (OPTIONAL) 🪪 This field has a unique identifier for a message. The identifier is meant for machines to generate and process 🤖 More details are in Section 3.2.4.1. Only one Message-ID field is allowed in a message 🔒
Obsoletes (OPTIONAL) 🗑️ This field names one or more messages that this one replaces 👋
Originator-Serial-Number (OPTIONAL) 🔢 This field has one or more serial numbers assigned by the message's originator. Messages with multiple recipients should have the same value in the Originator-Serial-Number field 🎟️
References (OPTIONAL) 📚 This field names other correspondence that this message references. If that other correspondence has 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 how a message should be handled or categorized, main character energy 👑
Precedence (OPTIONAL) 🚀 This field shows 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 tells you the purpose of a message. For example, it might contain values saying the message is a memorandum or a data-base entry. 🗂️
Reissue-Type (OPTIONAL)
This field gets used together with message encapsulating (see Section 2.4.1) to tell apart messages that are being assigned from messages that are being redistributed. 🦋
Received-From (OPTIONAL)
This field holds a record of a message's path through a message transfer system. The recipient's message receiving program could store any information about the transfer that it got from a message transfer system here. 🛣️
3.1.8 Message-content fields
The whole point of most messages is to pass some particular information from the originator to the recipient, and a few fields are built specifically to hold that info. 💖
Subject (BASIC)
This field holds any information the originator provided to summarize or indicate the nature of the message. ✨
Text (BASIC)
This field holds the primary content of the message. 📝
Attachments (OPTIONAL)
This field holds additional data that comes along with a message. It's kind of like enclosures in a conventional mail system. 📎
¹ 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.
Comments (OPTIONAL)
This field lets you add comments to the message without disturbing the original contents of the message. 🙈
Keywords (OPTIONAL)
This field holds keywords or phrases for use in retrieving a message. 🔍
3.1.9 Extensions
This message format specification allows for two extra types of fields: vendor-defined fields, and as-yet-undefined (extension) fields that will be introduced by extensions to this message format specification. ext era, bestie 🌈
vendor-defined-field
Any field not defined in this message format specification or any extension or successor to it is a vendor-defined field. Names for vendor-defined fields could be preempted by extensions to this message format specification. 🏷️
extension-field
Any field that is defined in a document published as a formal extension or replacement to this message format specification. 🧩
3.2 Message Processing Functions
A CBMS provides three basic classes of functions: creating messages, transmitting messages to their recipient, and post-receipt processing. ✨ The message format specification doesn't define how many user functions a CBMS has or what they are, but the meanings of the fields clearly assume certain kinds of functions. For example, fields that specify recipients of replies to messages assume some kind of reply function, and fields that specify message life span assume some kind of date processing functions. 🗓️
This section gives more detail on the processing that might be done by these kinds of functions, and it covers which message fields would be used and how. (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-NextTABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS
3.2.1 Message creation and posting
Messages can be created either by reissuing an existing message to a new recipient (see Section 2.4.1) or by creating a brand new message. 🎀 Making a new message might mean that some fields get filled in from the contents of some other message. Reply functions (Section 3.2.3) are a great example of this. 💌
Different individuals could be involved in different phases of originating a message: creating it, taking responsibility for it, and explicitly interacting with a CBMS to send it to its recipient. 👯 One or more individuals may create a message (that is, write it, but not necessarily enter it into the CBMS), and they're called 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, and they're identified by the From field. One individual explicitly posts a given message, and this person is called the message's sender (identified by the Sender field). 🫶
The sender and author(s) are often, but not always, responsible for the message. A common case where the sender isn't responsible for the message is when a secretary enters and posts messages for someone else. 💼 Another example of an author not being responsible for the message itself is when an administrative assistant prepares a report that's sent under a manager's signature. 👑
Messages containing Bcc fields get treated specially by CBMSs. The contents of this field are not included in copies of the message sent to the recipients designated in the To and Cc fields. Some systems include the contents of the Bcc field only in the originator's copy, while 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 mandate how the Bcc field is to be treated. 🤫
Audit trail entries (such as the posting time and sender identity) are automatically appended to a message by the CBMS each time the message passes through a posting slot to a message transfer system. A message transfer system could also provide timestamps at each transfer between user agent and the transfer system. 🕰️ A message identifier (Sections 3.2.4 and 3.1.6), placed in the message by the original sender's User Agent, is preserved throughout this message flow. That means that when the same message is sent twice to the same recipients by the same Sender, the audit trail information for the two messages is different. 🔁
3.2.2 Message reissuing and forwarding
Reissuing and forwarding both serve the general user goal of passing a message on to a new set of recipients. 🦋 Forwarding is the term for an informal mechanism, where a CBMS copies some or all of the original message into the contents of a field in the new message. Reissuing is the term for a formal mechanism that makes sure 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. 🧠
- Redistribution. Make others aware of the complete and unaltered contents of the message. 📣
- Assignment. Delegate the responsibility for a message to somebody else. 🤝
These purposes are shown in Figure 2. 📊
When a CBMS examines a forwarded message, it can't always tell the old message apart from what was added when the forwarding took place. On top of that, 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 re-issuing. Forwarding, since it's an informal way 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 message². This allows any part of it to be easily extracted. ✨
The Original Message
John Doe wishes Jane Jones to get a copy of the following
message:
Message:
Field: From "Jean Smith"
Field: Posted-Date "15 June 1980"
Field: To "John Doe"
Field: Subject "Next sales meeting"
Field: Text "The agenda for ..."
Redistribution
Message:
Field: From "John Doe" John Doe is responsible
Field: Posted-Date "16 June 1980" for the redistribution.
Field: To "Jane Jones"
Field: Reissue-Type "Redistribution" This message directly
Message: incorporates a
Field: From "Jean Smith" redistributed message.
Field: Posted-Date "15 June 1980"
Field: To "John Doe"
Field: Subject "Next Sales Meeting"
Field: Text "The agenda for ..."
Forwarding
Message:
Field: From "John Doe"
Field: Posted-Date "16 June 1980"
Field: To "Jane Jones"
Field: Text A realization of the
"From Jean Smith original message is
To John Doe copied into the Text field.
Sent on 15 June 1980 Note that John's CBMS
Subject Next Sales Meeting has chosen to represent
it as a text string.
The agenda for ..."
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTIONOkay so authentication is totally an organizational policy issue 💅 It's about passing on messages that were already sent. Every organization has to decide if the CBMS it picks should support reissuing or just 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 basically identical to the original, except it has extra info about the reissuing 🧚 For reissuing with this purpose, the Reissue-Type field contains the ASCII string "Redistribution". The original message gets included directly in a new message. (See Figure 2.) 🌸
3.2.2.2 Assignment 💜
Assignment is the process of designating responsibility 👑 In some organizations, formal message traffic gets funneled through one or more parts of the organization (called offices), where it's directed to the right 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 with this field is meant to be read as: the addressees in the "To" field have had the reissued message assigned to them for some action 🔥 Any addressee in the "Cc" field has had the message assigned for information. The From field records who assigned the message, and the "Posted-Date" field records when the message was assigned 🫶
2 A message can contain another message, and that message can contain another message, and so on to any depth of encapsulating. This can occur by reissuing a message repeatedly. 🙈
— page 22 —
3.2.3 Reply generation 🍓
Reply generation is when you create a new message in direct reply to some other message, using the contents of fields in the other message to fill fields in the new one ✨ Lots of CBMSs have reply facilities that figure out who the intended recipients of a reply are 💅
- A
Reply-Tofield is defined by this message format specification. When a message contains aReply-Tofield, the CBMS should send replies to the recipients designated in theReply-Tofield instead of to the recipients designated in theFromfield. 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, and they're lowkey iconic 👑
- 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 💖
- The people responsible for receiving responses might not be the people who were responsible for creating the message 🧚
- 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-Tofield 🌈
- When the message does not contain a
Reply-Tofield, the recipient should reply to the originators enumerated in theFromfield. The sender and authors should not be added automatically to the list of those receiving the reply. 🙅♀️
Replies could also be sent to the other recipients of the original message. Vendors might offer additional reply facilities, depending on their view of users' organizational requirements 🎀
— page 23 —
3.2.4 Cross referencing 🔗
A CBMS message may include designator(s) that identify other message(s) 🦋 The designators are used to refer to related messages so that all info in a chain of correspondence can be determined by a CBMS user. The designator used to identify and cross-reference messages can take either of two forms: unique identifiers or serial numbers 💅
3.2.4.1 Unique identifiers 🤖
Unique identifiers are machine-generated quantities that are mainly meant for processing by computers. They could be examined by a human user, but they're not necessarily useful or convenient for people 💀
Unique identifiers show up in several contexts. They're often used to identify the contents of individual messages unambiguously. When unique identifiers are used this way, they're called message identifiers. Different versions of a message (for example, the message when it's reissued with comments) get new message identifiers 🌸
When a CBMS generates a message identifier, it must be able to guarantee that it's unique, both within the domain of the individual CBMS and globally, across all connected CBMSs 😭 CBMSs could generate globally unique identifiers in several ways, and all of them require prior agreement on behalf of the connected CBMSs. One method is to assign each connected CBMS a unique code. A CBMS then generates unique identifiers by using its code as a prefix to some other quantity that it can guarantee to be unique within its domain. (This second quantity could be a counter or a timestamp/user-id combination.) 🧚
A CBMS can provide functions for tracing chains of correspondence by using unique 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.)
3.2.4.2 Serial numbering 🎀
Serial numbers are for users to maintain a personal numbering system for messages 💖 They're made of both letters and digits, so users can keep several sets of sequences going at once (for example, A1, A2, A3... and B1, B2, B3...) 🌈
— page 24 —
Serial numbers get assigned at a defined point in the history of a message. They are not unique identifiers. They differ from unique identifiers (Section 3.2.4.1) in that they're not necessarily either generated or processed by a CBMS 🦋 They're designed to be typed and read by CBMS users, and they can be as simple or complex as the user requires ✨ Serial numbers are meant to designate messages about a specific topic, or messages a given user has sent. They're intended to be a permanent part of the message, just like unique identifiers are 👑
A CBMS can provide functions that let originators add serial numbers to messages. A field has been provided to permit this. Originator-Serial-Number is for an originator to add a serial number to a message before sending it 💅
3.2.5 Life span functions ⏳
Messages have life spans, usually delimited by the creation date and the time when the last copy of the message is destroyed 🥹 Messages could be meaningless before a certain time, or irrelevant after a certain time. For example, a reminder to attend a meeting on 5 June loses most of its value on the sixth; a reminder to attend that same meeting is likely to be of little use on 5 May (although not for the same reason) 💀
A CBMS can define a message's life span explicitly using the Start-Date and End-Date fields. A third field, Warning-Date, when used in conjunction with the End-Date, may be used to signal the approach of the End-Date. It may also stand alone and be used by a periodic warning (alarm clock) mechanism 🔔
A CBMS could use these fields to help users manage their message stores. For example, a message whose start date has not yet passed could be bypassed by a retrieval command unless the user explicitly requested such messages. A CBMS could use the end date to help with message store housekeeping, either by archiving or deleting the expired messages automatically, or by asking the user for some action to be taken on them. The warning date could be used to automatically remind the user of an impending end date, such as a meeting reminder 🫶
3.2.6 Requests for recipient processing 📬
Recipients have a wide variety of needs for examining and processing a message, ranging from automatic output on some specified device to the execution of a program embedded in the message itself 😳 Because many of these needs are highly specialized, and support for them isn't 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 let an originator request circulation list processing from the recipient. These fields are Circulate-To and Circulate-Next 🌸
— page 25 —
3.2.6.1 Message circulation 🔁
Message circulation is serial distribution of a message to its recipients, based on a distribution list that's part of the message 💖 The message gets delivered first to the first recipient on the distribution list. That 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 keeps going until all recipients on the distribution list have received the message 🧚
This message format specification provides two fields to support message circulation. The Circulate-To field contains the complete distribution list, indicating the full set of recipients, and the Circulate-Next field indicates which recipients have not seen the message. See Figure 3 for an example of message circulation using these two fields 🦋
3.3 Multiple Occurrences and Ordering of Fields 🎀
Most message fields may occur more than once in a message. The exceptions are the Posted-Date, Sender, and Message-ID fields, which may occur at most once. What this means is that a received message may contain any number of instances of a particular field (such as the "To" field). If a message contains more than one instance of a particular field, that field "occurs multiply" and that message has "multiple occurrences" of that field 💅
A particular instance of a message field is not superseded by later instances of the same field. The To field is an example of this 👑
Multiple occurrences of a field are not necessarily equivalent to a single field containing the concatenated contents of the several instances of the given field. For example, with the Text field, concatenating the contents of several instances
...ok so the big circulation example above is the whole vibe 🦋 Like, one message could carry three different documents, one per Text field 📄 But if you cram all three into a single Text field, pulling out just one of them becomes a total nightmare 💀
To: A
Circulate-To: A, B, C
Circulate-Next: B, C
To: B
Circulate-To: A, B, C
Circulate-Next: C
To: C
Circulate-To: A, B, CFIG. 3. EXAMPLE OF MESSAGE CIRCULATION
Okay the fields in one message can show up in any order 🌸 The order they appear in doesn't have to match the order they were made, and it doesn't limit the order the recipient looks at, processes, or displays them in. Totally up to them, bestie 💅
4. SYNTAX ✨
This section is the big reveal about how messages are built 🔥 It starts with the concepts and elements that make up message syntax. Then it gives you the encoding scheme in a quick overview. The last part breaks down every single piece of the message syntax in detail.
4.1 Introduction
Here's what this spec does: it defines the syntax requirements for messages when they get passed from one CBMS to another 🎀 The goals are pretty iconic:
- Provide a concise flexible representation scheme.
- Simplify message parsing.
- Support non-textual components in messages (for example, facsimile, graphics, or speech [3]).
[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.
4.1.1 Message structure
Messages come in two classes of components: fields and messages 🧚 A field lines up with one of the semantic components defined in this format. A message is just another message, which is kind of iykyk 🙈
The type of a field decides both what it means and what shape its contents have 💖 (See Section 4.3.2.)
Fields are made of syntactic elements called data elements. A Message data element is used to represent messages, and a Field data element is used to represent fields 🦋 Quick note: "field" in this spec is a semantic construct, which is different from "Field Data Element," which is a syntactic construct. Lots of the fields in this format are restricted to containing only one kind of data element 👑 (See Section 4.3.2.)
Every field defined in this spec gets a unique numeric identifier, used together with the Field data element 🔢 Vendor-defined fields get their own separate identifiers, and there's also a separate range for extending the identifier encoding space ✨ A list of fields and identifiers shows up in Section 4.3.2 and Appendix C.
Throughout the spec, fields get referred to by their label name instead of their numeric identifiers 🎀 Labels are names like "Sender", "Warning-Date", or "Circulate-To". These labels were picked because they're already in common use in current CBMSs 💅 The spec doesn't require a CBMS to show these labels when it displays fields to the user, although using them is encouraged for a common user interface 🫶
4.1.2 Data elements
For figuring out compliance with the syntax in this spec, data elements get split into two groups: basic and optional 🌈
BASIC All message receiving systems must process these
syntactic elements, interpreting their values according
to the message format specification.
OPTIONAL Message receiving systems need not process these
syntactic elements in order to be in compliance.Complying CBMSs also have to meet requirements about being able to process the components found inside data elements 🔥 Those requirements are covered in Section 4.2.2. (Semantic compliance is defined in Section 3.1.2.)
This spec sorts data element types into either primitives or constructors. (See Sections 4.1.2.1 and 4.1.2.2.) Primitive data elements, like ASCII-String, are the basic building blocks 🧱 Constructor data elements, like Message or Sequence, hold one or more primitive or constructor data elements. Some constructors, like Sequence, can be made of any other data element. Others, like Message, can only contain certain data elements. (See Section 4.3.1.)
4.1.2.1 Primitive data elements
A primitive data element holds one basic piece of information, and it isn't made of other data elements 💜 In current CBMSs, the most commonly used primitive is ASCII-String, which is a series of ASCII characters ✨ The other primitives are Integer (2's complement integers), Bit-String (a series of bits), and Boolean (True or False).
One primitive, End-Of-Constructor, only shows up as a structural element inside constructor data elements and has no meaning on its own 🙈 It's used as an end marker for constructor data elements that don't have an explicit length. (See Section 4.2.2.1.) Using it any other way is not valid syntactically.
4.1.2.2 Constructor data elements
The Data Element Contents of a constructor contain one or more data elements 🧚 The most general constructors are Sequence and Set, since both can hold any data element. Other constructors are specialized forms of sequences 🌸
A Message data element is a constructor. It can only hold Field data elements, other Message data elements, or encrypted or compressed forms of those 🎀 A Field data element can hold any data element, and it also says which specific field is being represented. Some fields only allow one kind of data element, like ASCII-String or Date 💅
4.1.3 Properties
Any data element can have a Property-List attached to it 🦋 That list holds properties like a Printing-Name (Section 4.1.3.1) or one or more Comments (Section 4.1.3.2). This spec gives you a mechanism for vendor-defined properties, plus a way to extend the list of property identifiers 💖
4.1.3.1 Printing-names
Printing-Names give you labels that can be displayed next to their data elements 🖨️ For example, a message originator can use a Printing-Name property to ask that the To field be labeled "Distribution:" when recipients print it 👑
4.1.3.2 Comments
The Comment property lets you attach comments to any data element without changing its actual contents 💬 Say someone is reviewing a message's text: they can add the comment "This looks good" to the Text field without altering the body and without adding a separate comment field 🫶
4.1.4 Data compression and encryption
Two constructor data elements, Compressed and Encrypted, are there for CBMSs that support data compression or encryption 🔐 They can hold the compressed or encrypted contents of any data element, including Messages and Fields, and they can show up wherever their compressed or encrypted contents could. There's a mechanism that lets the user identify which encryption or compression algorithm was used (Sections 4.3.4 and 4.3.5) 🌈
4.1.5 Data sharing
Data sharing means using a data element multiple times by referencing a single copy 🧩 It's used in two situations:
- For economy when a large object appears more than once in a message. Data sharing can be used here to save on storage and transmission costs.
- For consistency when the same object appears more than once in a message. If one instance of that object gets altered, all instances have to reflect that change. Several copies of the same object won't do the job as well as data sharing does in this case.
There's a clear need for facilities that support data sharing, but this spec doesn't define such a mechanism 😭 There isn't enough experience with data sharing in messages yet to standardize it. The spec is flexible enough, though, to allow syntax extensions for data sharing later on ✨
4.2 Overview of Syntax Encoding
This section gives you an overview of the notation and terminology used to represent the syntactic elements (data elements) defined in this format 📖
All data elements are made of a series of components. Each component is a series of 8-bit groups called octets 🦋 In this document, bits are numbered starting from the low-order bit. So the low-order (or least significant) bit is "bit 0", and the high-order (or most significant) bit is "bit 7" 🔢
A data element can have five different components 💅
- Identifier octet (identifying particular type of data element)
- Length Code (specifying number of octets that appear following it in a data element)
- Qualifier (supplying additional identifying information)
- Property-List component (a Property-List data element containing Property data elements) 💖
- Data Element Contents (containing actual data of the data element) 🫶
okay so these components always show up in this exact order 🎀 Not every data element has every component, but whichever ones are there keep the same relative order. no cap, it's giving organized ✨
4.2.1 Identifier Octets ✨
okay bestie, the identifier octet is a numeric code that tells you what kind of data element you're looking at 🦋 It's always the first component in a data element. It has a one-bit flag that says whether the data element has a Property-List, plus a seven-bit unique identifier for the data element 💅 The value of that identifier also tells you whether the data element has a Qualifier. (See Table 2.)
Bit Value Meaning
7 0 The data element does not have properties
associated.
1 The data element has properties associated.
6 0 The data element does not have a Qualifier.
1 The data element has a Qualifier.TABLE 2. TYPE BITS IN THE IDENTIFIER OCTET 🌸
the most significant bit (Bit 7) of the identifier octet gets set to 1 if the data element has properties associated with it, and to 0 if it doesn't 🔥 This bit is independent of the other seven bits, which are called the identifier and give each data element its unique ID 👑 The associated properties get described in a Property-List component.
the second most significant bit (Bit 6) of the identifier octet is the most significant bit of the identifier itself, and it signals whether the data element has a Qualifier 💜 If it's 1, there's a Qualifier. If it's 0, there isn't. Those seven bits uniquely identify the data element. (See Figure 4.)
Data elements always have a Length Code component right after the identifier octet 🧚 (See 4.2.2.1.)
bit 7 6 5 4 3 2 1 0
+---------------+
|P 0 x x x x x x| P0xxxxxx uniquely identifies a
+---------------+ data element without a Qualifier.
+---------------+
|P 1 x x x x x x| P1xxxxxx uniquely identifies a
+---------------+ data element with a Qualifier.FIG. 4. STRUCTURE OF IDENTIFIER OCTETS 🦋
4.2.2 Length code and Qualifier components 🎀
the Length Code and the Qualifier are both usually one octet long 💖 They use an encoding scheme that lets the component stretch to whatever size is needed, either for the length of the data element or for the value of the Qualifier 🌈
the most significant bit of the Length Code or Qualifier decides whether it's one octet or several 💅 If that bit is 0, the component is one octet long. If it's 1, the other seven bits of the first octet tell you how many octets come after it. The actual value starts in the next octet and gets read as an unsigned integer 🫶
a single octet is enough for most Length Code and Qualifier components 😭 For cases where the Length Code or the Qualifier has to be greater than 127, you can add extra octets, up to a maximum of 127 octets. Figure 5 shows the encoding scheme, plus an example of a value less than 127 and one greater than 127 🔥
the way this works is that, to comply with this message format specification, CBMSs must be able to determine the value of any length code or qualifier that's expressed in three octets or less. (The [...] 2^16 -1). This message format specification places no limitation on the value of a length code or qualifier generated by a CBMS (except for the absolute limitation inherent in the representation scheme). However, the use of length codes and [...] (2^32 -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 weird situations 🙈 A Length Code can say that a data element had indeterminate length, and a Qualifier can say that a data element is implementation defined. These cases are explained further in Sections 4.2.2.1 and 4.2.2.2. ✨
bit 7 6 5 4 3 2 1 0
+---------------+
|0 x x x x x x x| xxxxxxx is the value.
+---------------+
+---------------+------//-------+
|1 n n n n n n n|y y y y y y y y| nnnnnnn is the
+---------------+------//-------+ number of octets
that contain the
value yyyyyyyy.
+---------------+
|0 0 0 0 1 0 0 1| This is an example with a
+---------------+ value of 9 (decimal).
+---------------+---------------+
|1 0 0 0 0 0 0 1|1 0 0 0 0 0 1 0| This example has a
+---------------+---------------+ value of 130 decimal.FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH CODES 🌸
4.2.2.1 Length Codes 🧚
the Length Code tells you how many octets follow it in a data element (so not counting the identifier octet or the length code itself) 💜 Length Codes come in 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 those octets contain [...] (2^1016 - 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 primitive data element. [4] 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.) 💅
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 🦋
Figure 7 shows the Length Codes for three elements, whose values are 38, 201, and 300 ✨
+--------+
|00100110| Length code for 38
+--------+
+--------+--------+
|10000001|11001001| Length code for 201
+--------+--------+
+--------+--------+--------+
|10000010|00000001 00101100| Length code for 300
+--------+--------+--------+FIG. 7. EXAMPLES OF LENGTH CODES 🌈
4.2.2.2 Qualifier 👑
the Qualifier component of a data element is used to give information that's essential for interpreting the data element contents, and that goes beyond what's encoded in the identifier octet or the length code 💖 For example, the identifier octet could contain the code for a field, and the Qualifier would specify what kind of field it is 🫶
the Qualifier only shows up in a few data elements 🍓 In the Bit-String data element, it indicates the number of unused bits in the final octet of the Data Element Contents. In the Field and Property data elements, it indicates which field or property the data element represents. In the Compressed and Encrypted data elements, it indicates which compression or encryption algorithm has been used. In the Message data element, it indicates the type of message. 💅
in the sequence of data element components, the Qualifier sits between the Length Code and the Property-List components 🧚 Its length depends on how the Qualifier is encoded. (See Figure 8.) A short Qualifier is one octet long. Its most significant bit is 0, and its value is in the range 0 through 127. A long Qualifier is at least two octets in length. The most significant bit is always 1, and the other 7 bits indicate the number of octets in the value of the Qualifier. 🌸
this message format specification lets implementations define their own values for Qualifiers 🔥 A vendor-defined Qualifier is any long Qualifier in which the first octet in the value is 0. The value used to identify this Qualifier is not guaranteed to be unique, and the same value may be used by different implementations to define different Qualifiers. 🙈
end of part 8, bestie 💖
Okay bestie, the qualifier examples are literally the cutest little bit-puzzles 🎀
+--------+
|00011011| Qualifier with value 28 (decimal).
+--------+
+--------+--------+--------+
|10000010|00000001 00001010| Qualifier with value
+--------+--------+--------+ 266 (decimal).
+--------+--------+--------+--------+
|10000011|00000000|00000001 00001010| Vendor-Defined
+--------+--------+--------+--------+ Qualifier with
value 266.
+--------+
|10000000| Undefined value for a Qualifier.
+--------+FIG. 8. EXAMPLES OF QUALIFIER VALUES ✨
4.2.3. Property-List 🎀
Okay so a Property is just an attribute that's attached to a data element. Right now this spec only defines two of them, Printing-Name and Comment. 💖 A Property-List component of a data element is shown as a Property-List data element, and that list holds Property data elements inside it.
A data element can have at most one Property-List. The most significant bit in the identifier octet of the data element tells you whether a Property-List is there or not. (See Section 4.2.1.) 🧚
4.2.4. Data Element Contents 🍓
The Data Element Contents is the actual data or info that the data element is carrying. The other components are there to help you identify and interpret those contents. 💅
In a primitive data element, the contents are a series of octets, and you read them based on the identifier octet and any qualifier. 🦋
In a constructor data element, the contents are a series of data elements. If the Length Code of a constructor is "indefinite", then the very last data element in its contents has to be End-of-Constructor. Iykyk 🌸
The length of the Data Element Contents (in octets) is the Length Code value minus the sum of these two things:
- the length of the Qualifier component (this depends on the data element) 💜
- the length of the Property-List component 🫶
4.3. Data Element Syntax 👑
This message format spec defines nineteen (19) different data elements, and honestly, we're about to meet all of them. 😭 Section 4.3.1 is where the general encoding form and the syntax for each element lives. Section 4.3.2 explains how specific data elements get used inside the Data Element Contents of a Field data element. If you want a summary of the syntactic form, check Appendix F, and for the data element syntax summaries, go to Appendix G. ✨
4.3.1. Data elements 🌈
This section lays out the general syntactic form for every data element defined here, plus the detailed syntax for each one. They're organised by syntactic class: primitive data elements (Section 4.3.1.1) and constructors (Section 4.3.1.2). 🦋
For convenience, this section uses the following terminology:
Term Meaning
Primitive a Primitive Data Element
Constructor a Constructor Data Element
Element any Data ElementEach Element's syntax is shown in graphic form. Here's how the diagrams work. A single octet looks like this:
+--------+
| |
+--------+Components that vary in length look like this:
+---//---+
| |
+---//---+Every Element has up to five components: an Identifier, a Length Code, a Qualifier, a Property-List, and the Data Element Contents. (See Section 4.2.) 💖
In the diagrams, the identifier octet is shown as a "P" followed by the identifier written in binary. (See Figure 4.) The identifier itself is a seven bit quantity, right justified in the identifier octet. Full details on identifier octets are in Section 4.2.1. 🎀
A length code is always drawn like this:
+---//---+
|Lxxxxxxx|
+---//---+A qualifier is always drawn like this:
+---//---+
|Qxxxxxxx|
+---//---+A Property-List (if there is one) always sits right before any Data Element Contents. 🍓
In the diagrams, the Data Element Contents shows up as one of these:
- "element(s)", which can be any data element(s) 🧚
- "anything", which is undefined and can be any combination of bits 🌸
- a specific data element 💜
- the interpretation to apply to the bits inside the octets that make up the element (such as ASCII or Integer) 🫶
Two data elements are reserved for special purposes. The Extension data element exists so the set of possible data elements can grow in the future. 🌟 The Vendor-Defined data element lets CBMS vendors define their own data elements. Heads up, though: Vendor-Defined data elements are not guaranteed to be unique, because two implementations could define different data elements using the same identifier. 💀 So Vendor-Defined data elements SHOULD be used and interpreted by prior agreement.
Next up, each element gets presented with its name, its compliance classification (BASIC or OPTIONAL), its identifier (in both hexadecimal and octal), a brief description of its use, and a graphic representation. Every data element description follows this form:
Data Element (Compliance) identifier identifier
Name ( Category ) octet octet
16 8
Description of the syntax of the data element.
+---//---+
| | Diagram representing data element
+---//---+4.3.1.1. Primitives 🦋
The data elements in this section are arranged in alphabetical order by name. (Appendix C lists the identifiers in numeric order.) 💅
ASCII-String (BASIC) 02 002
16 8This data element contains a series of ASCII characters, each character right-justified in one octet. For seven-bit ASCII characters, the most significant bit of each octet MUST be 0. 🩷
+--------+---//---+----//-----+
|P0000010|Lxxxxxxx|ASCII chars|
+--------+---//---+----//-----+Bit-String (OPTIONAL) 43 103
16 8This 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 8This 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 8This data element terminates the Data Element Contents in a constructor data element that has indefinite length. This data element has no Contents component. (Use of this element is described in Section 4.2.2.1.) 🌙
+--------+---//---+
|P0000001|Lxxxxxxx|
+--------+---//---+Integer (OPTIONAL) 20 040
16 8This 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 8This 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 8This data element is used to fill any number of octets. The contents of a Padding element are undefined and convey no information. 🫧
+--------+---//---+---//---+
|P0100001|Lxxxxxxx|anything|
+--------+---//---+---//---+4.3.1.2. Constructors 🌸
The data elements in this section are arranged in alphabetical order.
Compressed (OPTIONAL) 46 106
16 8okay bestie, Compressed is giving packed-up energy 🗜️ It has to contain a Bit-String data element, and it's used for any data that's been compressed. Wherever the uncompressed version could show up, this one can too ✨ Every Compressed element carries a Qualifier data component with a compression identifier (CID) so everyone knows which compression algorithm was used (see Section 4.3.5 💅). The Data Element Contents is just the product of the compression process 🎀
+--------+---//---+---//---+--------//--------+
|P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+ Date (BASIC) 28 050
16 8Date is a BASIC element 🗓️ and it holds an ASCII-String data element. That string is a date and time formatted according to PUBS 4 [NatB-68], 58 [NatB-79a] and 59 [NatB-79b] 💜
+--------+---//---+------//------+
|P0101000|Lxxxxxxx| ASCII-String |
+--------+---//---+------//------+ Encrypted (OPTIONAL) 47 107
16 8Encrypted is the one for anything that's been locked up 🔐 It must contain a Bit-String, and it can be used wherever the unencrypted contents could appear. Every Encrypted element has a Qualifier data component with an encryption identifier (EID) naming the encryption algorithm used (see Section 4.3.4 🫶). The Data Element Contents is the product of the encryption process.
+--------+---//---+---//---+--------//--------+
|P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+ Extension (OPTIONAL) 7E 176
16 8Extension is how you get more room 🚪 It extends 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, so they're literal twins 👯)
+--------+---//---+---//---+---//---+
|P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+ Field (BASIC) 4C 114
16 8Field uses a Qualifier data element component 🎯 That Qualifier holds a Field Identifier (FID) that says which specific field is being represented (see Section 4.3.2 🌸).
+--------+---//---+---//---+---//---+
|P1001100|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+ Message (BASIC) 4D 115
16 8Message is the main character 👑 It may contain Field or Message data elements. Its Qualifier component holds a Message type (MID) that tells you what kind of message it is (see Section 4.3.6 ✨). Bestie, the MID is completely different from the message identifier in the Message-ID field, so don't mix them up 🙈
+--------+---//---+---//---+
|P1001101|Lxxxxxxx|Qxxxxxxx|
+--------+---//---+---//---+
+--------//---------//---------//---------//--------+
| Field, Message, Encrypted, or Compressed Elements |
+--------//---------//---------//---------//--------+ Property-List (OPTIONAL) 24 044
16 8Property-List is a little bundle 🧺 It contains a series of Property data elements that get associated with another data element.
+--------+---//---+-------//--------+
|P0100100|Lxxxxxxx|Property Elements|
+--------+---//---+-------//--------+ Property (OPTIONAL) 45 105
16 8Property uses a Qualifier data element component 🌈 The Qualifier holds a Property-Identifier (PID) that says which specific property is being represented (see Section 4.3.3 💖).
+--------+---//---+---//---+---//---+
|P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+ Sequence (OPTIONAL) 0A 012
16 8Sequence holds any series of data elements, but the order matters 📋 The elements in the Data Element Contents must be considered as an ordered sequence (according to their order of appearance in the sequence.) Sequence and Set are different in exactly this way 💅
+--------+---//---+---//---+
|P0001010|Lxxxxxxx|elements|
+--------+---//---+---//---+ Set (OPTIONAL) 0B 013
16 8Set holds any series of data elements with no ordering implied 🫧 (Sequence is the one that gives you an ordered series.) Although the elements in a Set must be stored sequentially, the order they're stored in is not defined and not processed. Lowkey chaotic, but that's the vibe 🦋
+--------+---//---+---//---+
|P0001011|Lxxxxxxx|elements|
+--------+---//---+---//---+ Unique-ID (OPTIONAL) 09 011
16 8Unique-ID is a unique identifier 🔑 It doesn't need to 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 8Vendor-Defined is for vendor- and user-defined data elements 🧚 A Qualifier component extends the encoding space for identifiers. The Qualifier is not guaranteed to be unique among all interconnected systems, so this element gets 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. Which data elements can show up depends on 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 🌷
4.3.3 Properties and associated elements ✨
This message format specification defines two properties 🍓
Comment 01 001
16 8This property may contain any series of data elements. It most commonly contains one or more ASCII-Strings 💬
Printing-Name 02 002
16 8This 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 8Use of this encryption identifier as part of the Encrypted data element indicates that the encryption method being used was not specified for inclusion as part of the data element 🤷♀️
NBS-Standard 01 001
16 8Use of this encryption identifier as part of the Encrypted data element indicates that the NBS standard method for data encryption [NatB-77] was used 🏛️
4.3.5 Compression identifiers ✨
This message format specification defines two compression identification codes for use with the Compressed data element 🗜️
Unspecified 00 000
16 8Use of this compression identifier as part of the Compressed data element indicates that the compression method being used was not specified for inclusion as part of the data element 🫠
NBS-Standard 01 001
16 8Use of this compression identifier as part of the Compressed data element is reserved at the present time. It will be used in the future to indicate that the NBS standard method for data compression was used once the data compression standard is defined 🔮
4.3.6 Message types ✨
Okay bestie, we're finishing up the MID codes 💅 Here's the table that shows the NBS-Standard message type, with the hex and octal values 🦋
NBS-Standard 01 01
16 8This message type is for messages defined by this message format specification 🌸 And that's the whole MID section. Iykyk 💜
Summary of Appendixes ✨
Okay, the appendixes are where the real reference stuff lives, so here's the quick tour 🧚
- Appendix A defines the fields in the message format specification. It's alphabetical, so it's built for implementors to look stuff up. It has the semantic definitions of the fields from Section 3.1, the Field Identifier values, and which data elements are valid as the Contents for each field. 🎀
- Appendix B defines the data elements in the message format specification. It's also alphabetical and meant for implementors. It pulls together everything from Section 4.3 🍓
- Appendix C is a reference table of the data elements in numerical order by their identifier octets 🔢
- Appendix D is a reference table summarizing the components of messages, based on whether they're required or optional for CBMSs implementing the specification 💖
- Appendix E is a reference table that sorts the message components by their functional class 🌈
- Appendix F gives an overview of the syntactic elements defined by this message format specification ✨
- Appendix G summarizes the syntactic elements based on whether they're required or optional for a CBMS implementing the message format specification 🫶
- Appendix H has examples of each syntactic element, showing their syntax and describing their associated semantics 🦋
Appendix A: Fields -- Implementors' Master Reference 🎀
Appendix A is the big one, bestie 👑 It defines every field in the message format specification so implementors have one place to check. It has the semantics of the fields from Section 3.1, the Field Identifier values, and which data elements are valid as the Contents for each field. The field definitions are alphabetical, so you can scroll right to the one you need 🌸
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.
-----------------------------------------------------------------So every entry has a header row with the compliance level and identifier values, then a description, then the valid data element names 🧠
Attachments
Attachments OPTIONAL 08 010
16 8Attachments are optional 💅 This field holds extra data that comes along with a message. It's kinda like enclosures in regular mail. Its contents are unrestricted, so anything goes 🦋
Author
Author OPTIONAL 0C 014
16 8Author is optional 🌷 This field tells you who wrote the main contents of the message. Using Author is discouraged when its contents and the From field would be totally redundant 🙈 It holds one or more originator identities.
Bcc
Bcc OPTIONAL 0D 015
16 8Bcc is optional 🫣 This field lists extra recipients for a message, which is the "blind carbon copies list." The contents of this field are NOT included in copies of the message sent to the primary and secondary recipients. See section 3.2.1 for more on how blind carbon copies lists are used. It holds one or more recipient identities.
Cc
Cc BASIC 06 006
16 8Cc is BASIC, not optional 💖 This field lists secondary recipients for a message, which is the "carbon copies" list. It holds one or more recipient identities.
Circulate-Next
Circulate-Next OPTIONAL 0E 016
16 8Circulate-Next is optional, and it's the buddy of Circulate-To 🔁 (See Section 3.2.6.1.) It names all the recipients in a circulation list who haven't received the message yet. It holds one or more recipient identities.
Circulate-To
Circulate-To OPTIONAL 0F 017
16 8Circulate-To is optional too 🌈 This field names the recipients of a circulated message. (See Section 3.2.6.1.) It's used together with Circulate-Next and holds one or more recipient identities.
Comments
Comments OPTIONAL 10 020
16 8Comments is optional 💬 This field lets you add comments to the message without messing up its original contents. Comments usually holds one or more ASCII-Strings, but there are no restrictions on what it can contain ✨
Date
Date OPTIONAL 11 021
16 8Date is optional 📅 This field holds a date that the originator wants to link to a message. The Date field is to the Posted-Date field what the date on a letter is to the postmark the post office adds. It holds one Date.
End-Date
End-Date OPTIONAL 12 022
16 8End-Date is optional ⏳ This field holds the date when a message stops having effect. (See also Section 3.2.5.) It holds one Date.
From
From REQUIRED 01 001
16 8From is REQUIRED, so it always has to be there 👑 This field holds the identity of the originators who formally take responsibility for the message. When no Reply-to field shows up in a message, the From contents are what gets used for replies. It holds one or more originator identities.
In-Reply-To
In-Reply-To OPTIONAL 13 023
16 8In-Reply-To is optional 💌 This field points to earlier correspondence that this message is replying to. Usually it holds the contents of the Message-ID field from the message(s) being replied to. It holds one or more Unique-IDs or ASCII-Strings.
Keywords
Keywords OPTIONAL 14 024
16 8Keywords is optional 🔍 This field holds keywords or phrases for finding a message later. It holds one or more ASCII-Strings, and each keyword or phrase gets its own ASCII-String 🏷️
Message-Class
Message-Class OPTIONAL 15 025
16 8Message-Class is optional 🗂️ This field says what the purpose of a message is. For example, it might say the message is a memorandum or a data-base entry. It holds one data element, an ASCII-String.
Message-ID
Message-ID OPTIONAL 16 026
16 8Message-ID is optional 🆔 This field holds a unique identifier for a message. It's meant to be generated and processed by machines. More details are in Section 3.2.4.1. Only one Message-ID field is permitted in a message. It holds one data element, a Unique-ID.
Obsoletes
Obsoletes OPTIONAL 26 046
16 8Obsoletes is optional 🪦 This field names one or more messages that this one replaces. It holds at least one Unique-ID and can hold more than one.
Originator-Serial-Number
Originator-Serial-Number OPTIONAL 17 027
16 8Originator-Serial-Number is optional 🔢 This field holds one or more serial numbers assigned by the message's originator. Messages with multiple recipients should all have the same value in this field. It holds one or more ASCII-Strings, with one ASCII-String for each serial number.
Posted-Date
Posted-Date REQUIRED 02 002
16 8Posted-Date is REQUIRED, no cap 📮 This field holds the posting date, which is the moment the message goes through the posting slot into a message transfer system. Only one Posted-Date field is permitted in a message. It holds one Date.
Precedence
Precedence OPTIONAL 18 030
16 8Precedence is optional, and it's giving priority energy 🚨 Normally, message precedence or priority is a service request made to a message transfer system. But a message originator can also include precedence information in a message. This field shows 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." It holds one ASCII-String.
Received-Date 📬 ✨
Received-Date OPTIONAL 19 031
16 8Okay so Received-Date is OPTIONAL 🎀 It's the delivery date! This field may be added to a message by the recipient's message receiving program. It tells you when the message left the delivery system and entered the recipient's message processing domain. This field contains one Date. 🗓️
Received-From 🛤️
Received-From OPTIONAL 1A 032
16 8This field is literally 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, so no drama here 💅
References 🔗
References OPTIONAL 20 040
16 8This 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. It's giving connected, no cap 🫶
Reissue-Type 🔁
Reissue-Type OPTIONAL 25 045
16 8This field is used in conjunction with message encapsulating (see Section 3.2.2) to differentiate between messages being assigned or redistributed. It's the tiebreaker between "assigned" and "redistributed" 👑 This field contains one data element, usually an ASCII-String.
Reply-To 💌
Reply-To BASIC 03 003
16 8This field identifies any recipients for replies to the message. It's where the replies go, bestie 🌸 This field contains one or more recipient identities.
Sender 🕵️♀️
Sender OPTIONAL 22 042
16 8This field identifies the agent who sent the message. It's 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 🌅
Start-Date OPTIONAL 23 043
16 8This field contains the date on which a message takes effect. (See also Section 3.2.5.) This field contains one Date. Main character energy: the message's glow-up starts here ✨
Subject 🎀
Subject BASIC 07 007
16 8This field contains whatever information the originator provided to summarize or indicate the nature of the message. It's the title, the vibe check, the whole thing 🦋 This field contains one or more ASCII-Strings.
Text 📝
Text BASIC 04 004
16 8This field contains the primary content of the message. This is the main event 🎬 Contents of this field are unrestricted.
To 🫵
To REQUIRED 05 005
16 8This field identifies primary recipients for a message. It's the people the message is really for, so this one is non-negotiable 🔥 This field contains one or more recipient identities.
Warning-Date ⏰
Warning-Date OPTIONAL 24 044
16 8This field is used either alone or in conjunction with an End-Date field. It contains one or more dates. These dates could be used by a message processing program as warnings of an impending end-date or other event. 🚨 (See also Section 3.2.5.) This field contains one or more Dates.
APPENDIX B ✨ DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE 📚
This appendix defines all of the data elements in the message format specification, for reference use by implementors. 🤓 It contains no new information but rather consolidates the syntactic information from Section 4.3.
Each data element description has the following form.
-----------------------------------------------------------------
Data Element (Compliance) identifier identifier
Name ( Category ) octet octet
16 8
Constructive class (primitive or constructor)
Description of the syntax of the data element.
+---//---+
| | Diagram representing data element
+---//---+
-----------------------------------------------------------------ASCII-String 🔤 (BASIC)
ASCII-String (BASIC) 02 002
16 8Constructive class: primitive. 🧩
This data element contains a series of ASCII characters, each character right-justified in one octet. For seven-bit ASCII characters, the most significant bit of each octet must be 0. Bestie, that high bit is a must 🙏
+--------+---//---+----//-----+
|P0000010|Lxxxxxxx|ASCII chars|
+--------+---//---+----//-----+Bit-String 🧃 (OPTIONAL)
Bit-String (OPTIONAL) 43 103
16 8Constructive class: primitive. 💫
This data element contains a series of bits. It uses the Qualifier data element component to record the number of bits of padding (as an eight bit unsigned integer) needed to fill the final octet of the Data Element Contents to an even octet boundary. These padding bits have no meaning and occur in the low order bits of the final octet. The valid values for the Qualifier component are 0 through 7. The number of bits in the Data Element Contents is calculated from the following formula.
8 * number of octets - value of
in the Data Qualifier component
Element Contents +--------+---//---+---//---+---//---+
|P1000011|Lxxxxxxx|Qxxxxxxx| bits |
+--------+---//---+---//---+---//---+Boolean ⚖️ (OPTIONAL)
Boolean (OPTIONAL) 08 010
16 8Constructive class: 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). It's giving binary, honestly 🤖
+--------+---//---+--------+
|P0001000|Lxxxxxxx| T or F |
+--------+---//---+--------+Compressed 🗜️ (OPTIONAL)
Compressed (OPTIONAL) 46 106
16 8Constructive class: 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. Packed small, shown big 📦
+--------+---//---+---//---+--------//--------+
|P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+Date 📅 (BASIC)
Date (BASIC) 28 050
16 8Constructive class: constructor. 🗓️
This data element contains an ASCII-String data element, which is a representation of a date and time formatted in accordance with FIPS Publications 4 [NatB-68], 59 [NatB-79b], and 58 [NatB-79a]. Timestamps with receipts, very organized 🧾
+--------+---//---+------//------+
|P0101000|Lxxxxxxx| ASCII-String |
+--------+---//---+------//------+Encrypted 🔐 (OPTIONAL)
Encrypted (OPTIONAL) 47 107
16 8Constructive class: constructor. 🤫
This data element must contain a Bit-String. It is used to represent any data that has been encrypted; it may be used wherever its unencrypted contents may appear. A Qualifier data component appears in each Encrypted data element; it contains an encryption identifier (EID) identifying the encryption algorithm used. (See Section 4.3.4.) The Data Element Contents is the product of the encryption process. Secret stuff, safe with me 🙊
+--------+---//---+---//---+--------//--------+
|P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+End-of-Constructor 🔚 (BASIC)
End-of-Constructor (BASIC) 01 001
16 8Constructive class: 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.) It's the period at the end of the sentence 💅
+--------+---//---+
|P0000001|Lxxxxxxx|
+--------+---//---+Extension 🧩 (OPTIONAL)
Extension (OPTIONAL) 7E 176
16 8Constructive class: constructor. 🌈
This data element is used to extend the number of available data elements beyond the 128 that are possible using a 7-bit identifier. A Qualifier component extends the encoding space for identifiers. (Extension and Vendor-Defined have the same syntax.) Room to grow, and it's iconic 👑
+--------+---//---+---//---+---//---+
|P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+Okay bestie, this is where the data element types wrap up 💖 Let's go! ✨
Field 🎀 is a BASIC constructor, and it's a pretty iconic one. Here's how its header looks:
Field (BASIC) 4C 114
16 8
constructorIt uses a Qualifier data element component 💅. That Qualifier holds a Field Identifier (FID), which tells you exactly which specific field is being represented (see Section 4.3.2) 🦋.
+--------+---//---+---//---+---//---+
|P1001100|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+Integer 🔢 is OPTIONAL and it's giving simple but powerful ✨. Here's the header:
Integer (OPTIONAL) 20 040
16 8
primitiveIt holds a 2's complement integer of variable length, with the high order octet coming first 💜. It is recommended that the data element contents be either 2 or 4 octets long whenever possible 🌸.
+--------+---//---+---//---+
|P0100000|Lxxxxxxx| Integer|
+--------+---//---+---//---+Message 💌 is BASIC and very main character. Here's the header:
Message (BASIC) 4D 115
16 8
constructorA Message element may contain Field or Message data elements 🧚. Its Qualifier component holds a Message type (MID) that tells you what kind of message it is (see Section 4.3.6) ⭐. Okay, important tea ☕: the MID is completely different from the message identifier in the Message-ID field, so don't mix them up 🙈.
+--------+---//---+---//---+
|P1001101|Lxxxxxxx|Qxxxxxxx|
+--------+---//---+---//---+
+--------//---------//---------//---------//--------+
| Field, Message, Encrypted, or Compressed Elements |
+--------//---------//---------//---------//--------+No-Op 😴 is OPTIONAL and honestly a total cutie. Here's the header:
No-Op (OPTIONAL) 00 000
16 8
primitiveIt does nothing 🫶. No-Op shows up whenever you need a data element that means "no operation", kind of like a little placeholder 🍓.
+--------+---//---+
|P0000000|Lxxxxxxx|
+--------+---//---+Padding 🌈 is OPTIONAL and it's all about filling space. Here's the header:
Padding (OPTIONAL) 21 041
16 8
primitiveIt's used to fill any number of octets 🦋. The contents of a Padding element are undefined and convey no information, so it's basically just vibes 🫧.
+--------+---//---+---//---+
|P0100001|Lxxxxxxx|anything|
+--------+---//---+---//---+Property-List 📋 is OPTIONAL and very organized. Here's the header:
Property-List (OPTIONAL) 24 044
16 8
constructorIt contains a series of Property data elements that get associated with another data element 💜.
+--------+---//---+-------//--------+
|P0100100|Lxxxxxxx|Property Elements|
+--------+---//---+-------//--------+Property 🎀 is OPTIONAL and uses a Qualifier data element component too. Here's the header:
Property (OPTIONAL) 45 105
16 8
constructorThe Qualifier component holds a Property-Identifier (PID) that tells you which specific property is being represented (see Section 4.3.3) 💅.
+--------+---//---+---//---+
|P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+Sequence 🔁 is OPTIONAL and it's giving order. Here's the header:
Sequence (OPTIONAL) 0A 012
16 8
constructorIt contains any series of data elements 🌸. The big difference from Set is that the data elements in the Data Element Contents must be considered as an ordered sequence, going by their order of appearance in the sequence ⭐.
+--------+---//---+---//---+
|P0001010|Lxxxxxxx|elements|
+--------+---//---+---//---+Set 🫧 is OPTIONAL and a little more chill about ordering. Here's the header:
Set (OPTIONAL) 0B 013
16 8
constructorIt contains any series of data elements with no ordering implied 🙃. Sequence is the one that gives you an ordered series. Even though the elements in a Set must be stored sequentially, the order they're stored in is not defined and not processed 🤷♀️.
+--------+---//---+---//---+
|P0001011|Lxxxxxxx|elements|
+--------+---//---+---//---+Unique-ID 🪪 is OPTIONAL and it's the identifier with main character energy. Here's the header:
Unique-ID (OPTIONAL) 09 011
16 8
constructorIt's a unique identifier, and it doesn't need to be human-readable 🤖. The Data Element Contents may be an ASCII-String, a Bit-String, or an Integer 💜.
+--------+---//---+---//---+
|P0001001|Lxxxxxxx| element|
+--------+---//---+---//---+Vendor-Defined 🏷️ is OPTIONAL and very much its own thing. Here's the header:
Vendor-Defined (OPTIONAL) 7F 177
16 8
constructorThis data element represents vendor-defined data elements 🌈. A Qualifier component extends the encoding space for identifiers. The Qualifier component is not guaranteed to be unique among all interconnected ems 👀. This data element is interpreted according to prior agreement between systems. Extension and Vendor-Defined data elements have the same syntax 💅.
+--------+---//---+---//---+---//---+
|P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---+---//---+Appendix C. Data Element Identifier Octets 🧾
Here's the full identifier-to-name lookup, all in one place 💖.
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-DefinedAppendix D. Summary of Message Fields by Compliance Category 📚
This appendix is just for reference 💅. It doesn't add any new information. It simply pulls things together from Section 3.1 🌸.
This appendix lists the message field names in alphabetical order within each compliance category. (Appendix E sorts the same field names by functional category instead.) Full field definitions are in Appendix A 🦋.
Required fields must appear in a message. Basic fields must be recognized and processed by all CBM systems. Optional fields need not be supported by a CBMS, but if they are supported, they must be processed according to the meanings defined by the message format specification 🫶.
D.1. REQUIRED Fields 🚨
FromPosted-DateTo
D.2. BASIC Fields 🎀
CcReply-ToSubjectText
D.3. OPTIONAL Fields 🌈
AttachmentsAuthorBccCirculate-NextCirculate-ToCommentsDateEnd-DateIn-Reply-ToKeywordsMessage-ClassMessage-IDObsoletesOriginator-Serial-NumberPrecedenceReceived-DateReceived-FromReferencesReissue-TypeSenderStart-DateWarning-Date
Appendix E. Summary of Message Semantics by Function 🔍
This appendix is also just for reference 💜. It doesn't add new information either. It pulls from Section 3.1 🧚.
This appendix lists the message field names in alphabetical order within each functional class. (Appendix D sorts them by compliance class instead.) Full field definitions are in Appendix A ✨.
E.1. Circulation 🔄
Circulate-NextCirculate-To
E.2. Cross Referencing 🔗
In-Reply-ToMessage-IDObsoletesOriginator-Serial-NumberReferences
E.3. Life spans ⏳
End-DateStart-DateWarning-Date
E.4. Delivery System 📬
Received-DateReceived-From
E.5. Miscellaneous Fields Used Generally 🧩
AttachmentsCommentsKeywordsMessage-ClassPrecedenceSubjectText
E.6. Reply Generation 💌
Reply-To
E.7. Reissuing ♻️
Reissue-Type
E.8. Sending (Normal Transmission) 📤
AuthorBccCcDateFromPosted-DateSenderTo
Appendix F. Summary of Data Element Syntax 🎀
This appendix gives a quick visual rundown of data element syntax by diagramming the components of each data element 💖. The detailed version lives in Section 4.3.1 🦋.
In these diagrams, required components of a data element are drawn with a double border, which signifies "required" 🫶.
+========+ +===//===+
| | | |
+========+ +===//===+
always one one or more
octet long octets longOptional components of data elements are drawn with a single border instead, which signifies "not required" 🌸.
+--------+ +---//---+
| | | |
+--------+ +---//---+
always one one or more
octet long octets longOkay bestie, let's get into the identifier octet, the P-bit, and the components 💜
The first octet in a data element is the identifier octet 🧚 In diagrams, all eight bits of it are always shown. Fixed bits show their values as 1s and 0s, and variable bits get drawn as x's and y's ✨
The first bit is the P-bit 🦋 It tells you whether the data element has a property list (a P-bit of 1 means yes, there's a property list 🎀). The other seven bits hold the rest of the identifier 💅
Every other octet in a data element falls into one of four classes: Length Code, Qualifier, Property-List, and Contents 🌸 Diagrams of syntax label each component by its class, like this:
Component Class Label
Length code Length
Qualifier Qual
Property-List P-List
Contents ContentsData elements have to follow this shape, no exceptions 🫶
+========+===//===+---//---+---//---+---//---+
|Pxxxxxxx| Length | Qual | P-List |contents|
+========+===//===+---//---+---//---+---//---+The Length component is the total number of octets that come after the length code octet in the data element. Count from there, bestie 🔥
Appendix G. Summary of Data Elements by Compliance Category ✨
Okay so, compliance categories for syntactic elements come in two flavors: basic and optional 💖 Every CBMS is required to recognize and process basic elements 👑 A CBMS doesn't have to process optional elements, although the semantics strongly recommend a lot of them 🙈
This appendix sums up the data elements by sorting them into their compliance category. It's giving organized 💅
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 8G.2. OPTIONAL Data Elements
Bit-String (primitive) 43 103
16 8
Boolean (primitive) 08 010
16 8
Compressed (constructor) 46 106
16 8
Encrypted (constructor) 47 107
16 8
Extension (constructor) 7E 176
16 8
Integer (primitive) 20 040
16 8
No-Op (primitive) 00 000
16 8
Padding (primitive) 21 041
16 8
Property (constructor) 45 105
16 8
Property-List (constructor) 24 044
16 8
Sequence (constructor) 0A 012
16 8
Set (constructor) 0B 013
16 8
Unique-ID (constructor) 09 011
16 8
Vendor-Defined (constructor) 7F 377
16 8Appendix H. Examples 🌈
This appendix gives at least one example for every data element in this message format spec 🎀 In these examples the identifier octets are in binary, and all the other numbers are in hex 🧮 ASCII strings get shown as actual characters instead of their numeric codes 💜
Here's the important bit, though: this spec doesn't define how names and addresses work. Message originators and recipients are just identified by their names in these examples. That doesn't mean anything about how naming and addressing should be done. It's just a handy way to label who's who 🦋
H.1. Primitive Data Elements
This section has one example of each primitive data element. Each example comes with a short explanation and a series of octets 🌸
No-Op data element:
+--------+--------+
|00000000|00000000|
+--------+--------+End-of-Constructor data element:
+--------+--------+
|00000001|00000000|
+--------+--------+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.|
+--------+--------+---- ----+Bit-String data element containing 44 bits of data (((7-1) x 8) - 4). Six octets hold those 44 bits. The last 4 bits in the final octet are padding and get 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 has one example of each constructor data element. Each example gives a short explanation and then an annotated series of the data elements that make 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|
+--------+--------+---- ----+Printing-Name Property. The value of the Printing-Name is "Distribution":
Property Length PID ASCII Length
+--------+--------+--------+--------+--------+
|01000101| 0 F | 0 2 |00000010| 0 C |
+--------+--------+--------+--------+--------+
+---- ----+
|Distribution|
+---- ----+Compressed data element. Its contents were compressed using an as-yet-undefined NBS standard data compression algorithm. The compressed data sits in a bit-string that's 56 bits long, fully filling 7 octets 🗜️
Compressed Length CID Bit-String Length
+--------+--------+--------+--------+--------+
|01000110| 0 B | 0 1 |01000011| 0 8 |
+--------+--------+--------+--------+--------+
Spare
+--------+--------+--------+--------+
| 0 0 | 1 C 5 F 2 D
+--------+--------+--------+--------+
+--------+--------+--------+--------+
7 7 B A F 6 2 9 |
+--------+--------+--------+--------+Encrypted data element. The encryption method used on its contents has been intentionally left unspecified 🔐 This element holds a Bit-String with 22 bits (((4-1) x 8) - 2) of data. Those 22 bits are represented in octets, and the final 2 bits in the final octet are padding and get 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 has a date but no time. The date shown 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 |
+--------+--------+--------+--------+--------+--------+Sequence data element containing two ASCII-String data elements. The first ASCII-String is "This is" while the second string is " a list" 💜
Sequence Length ASCII Length
+--------+--------+--------+--------+--- ---+
|00001010| 1 2 |00000010| 0 7 |This is|
+--------+--------+--------+--------+--- ---+ ASCII Length
+--------+--------+--- ---+
|00000010| 0 7 | a list|
+--------+--------+--- ---+okay so this next example is a Set data element, and it's giving organized 🗂️✨ It holds two Integer data elements: 519 (decimal) and 71 (decimal). Bestie, these two values have no ordering, because they live in a set and sets don't care about order 🙈 So nothing is "first" or "second" in a way that matters.
Set Length Integer Length
+--------+--------+--------+--------+--------+--------+
|00001011| 0 8 |00100000| 0 2 | 0 2 0 7 |
+--------+--------+--------+--------+--------+--------+
Integer Length
+--------+--------+--------+--------+
|00100000| 0 2 | 0 0 4 7 |
+--------+--------+--------+--------+Next up is a Field data element. The field we're looking at is the Text field, and its contents are "I will see you at lunch." Literally so relatable 🍓
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 B | 0 4 |00000010| 1 8 |
+--------+--------+--------+--------+--------+
+---- ----+
|I will see you at lunch.|
+---- ----+79
Now the full Message with four fields: Posted-Date, From, Text, and To 📬 It was sent on July 4, 1980 at 6 p.m. eastern daylight time, it's from a person named Smith, and the text is a question asking the recipient "Are you going to watch the fireworks?" 🎆 The message goes to Jones. The vibes are immaculate 💜
Message Length Type Field Length
+--------+--------+--------+--------+--------+
|01001101| 5 8 | 0 1 |01001100| 1 7 |
+--------+--------+--------+--------+--------+
FID Date Length ASCII
+--------+--------+--------+--------+
| 0 2 |00101000| 1 4 |00000010|
+--------+--------+--------+--------+
Length
+--------+---- ----+
| 1 2 |19800704-180000EDT|
+--------+---- ----+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 8 | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+-- --+
| 0 5 |Smith|
+--------+-- --+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 2 8 | 0 4 |00000010|
+--------+--------+--------+--------+
Length
+--------+
| 2 5 |
+--------+
+---- ----+
|Are you going to watch the fireworks?|
+---- ----+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 8 | 0 5 |00000010|
+--------+--------+--------+--------+
80
Length
+--------+-- --+
| 0 5 |Jones|
+--------+-- --+Okay, next one is an Extension data element 🧚 It has a length code and 3 octets. The octet right after the length code tells you it's Extension Data Element 7, and the Data Element Contents are the final two octets. How those contents get interpreted would be defined in an extension or a successor to this message format spec.
[Note: this is an example. Any actual extension data element 7 (if it were ever used) would be completely different from anything done here.] ⚠️ Don't copy this one, bestie!
Extension Length
+--------+--------+--------+--------+--------+
|01111110| 0 3 | 0 7 | 4 A E 9 |
+--------+--------+--------+--------+--------+Last one in this batch is a Vendor-Defined data element 🌈 It has a length code and 3 octets. The first octet says this is vendor-defined data element number 114 (decimal). That particular vendor defined it to hold three printable ASCII characters in two octets. Element 114 would be totally different for another user, though. For example, it might hold a floating point number 🤯
User Length
+--------+--------+--------+--------+--------+
|01111111| 0 3 | 7 2 | P O E |
+--------+--------+--------+--------+--------+H.3 Fields 💅
This section has examples of Field data element constructors for several different fields: Keywords, Text, Subject, and Vendor-Defined. Iconic 👑
82
Okay, first up is a Field data element for keywords 🔑 This field holds two keywords, Message and Computer, and each one gets its own ASCII-string data element.
Field Length Keywords ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 4 | 1 4 |00000010| 0 7 |
+--------+--------+--------+--------+--------+
+--- ---+
|Message|
+--- ---+
ASCII Length
+--------+--------+--- ---+
|00000010| 0 8 |Computer|
+--------+--------+--- ---+Next, a Field data element for Text, with a Property-List data element that has a comment attached 💭 The text field holds the ASCII-String data element "Do you want lunch?". The Property-List has a comment property, and that property is an ASCII-string data element containing "Now?". The vibe is so casual 🍕
Field Length Text Prop-List Length
+--------+--------+--------+--------+--------+
|11001100| 2 0 | 0 4 |00100100| 0 9 |
+--------+--------+--------+--------+--------+
Property Length PID ASCII
+--------+--------+--------+--------+
|01000101| 0 7 | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+- -+
| 0 4 |Now?|
+--------+- -+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |Do you want lunch?|
+--------+--------+---- ----+82
Now a Field data element for Subject, containing an ASCII-String data element. The string is "Good restaurants in Detroit" followed by a carriage return and a line feed 🥡 A recipient would expect the message to have some info about restaurants in the Detroit area, so it's giving planning energy 🗺️
Field Length Subject ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 2 1 | 0 7 |00000010| 1 E |
+--------+--------+--------+--------+--------+
+---- ----+
|Good restaurants in Detroit.<cr><lf>|
+---- ----+83
Last field example: a Field data element whose form and meaning were defined by a vendor 🏷️ This vendor defined vendor-defined field 12 (decimal) as a field with the printing name "Reply-by", and its contents are a date, January 7, 1981 in this case. The meaning of vendor-defined field 12 is unique to that vendor, so the same field number could mean something totally different for other vendors. Be careful, bestie 😭
Field Length Qualifier User number
+--------+--------+--------+--------+--------+
|11001100| 1 F | 8 2 | 0 0 0 C |
+--------+--------+--------+--------+--------+
Prop-List Length Property Length
+--------+--------+--------+--------+
|00100100| 0 E |01000101| 0 C |
+--------+--------+--------+--------+
PID ASCII Length
+--------+--------+--------+---- ----+
| 0 2 |00000010| 0 9 |Reply-By:|
+--------+--------+--------+---- ----+
Date Length ASCII Length
+--------+--------+--------+--------+
|00101000| 0 A |00000010| 0 8 |
+--------+--------+--------+--------+
+--- ---+
|19810107|
+--- ---+H.4 Messages 🦋
This section has several examples of complete messages, and it shows what happens when you reissue a message. (See Section 3.2.2.) So many examples, I'm obsessed 🤩
84
The following sample message has Stevens as its originator and Johnson as its recipient 💌 It was sent on August 14, 1980 at 10 am EDT. The subject 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 Johnson is working on should be turned in to Stevens by 3 pm that day. Stressful but make it cute 📝
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | B 4 | 0 1 |
+--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 5 | 0 2 |00101000| 1 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 0 |19800814-1000EDT|
+--------+--------+---- ----+
85Pick up right where the last part left off: that little "Don't forget the project report" example is the tail of the Section H.4 message, so keep rolling with the reissue example.
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.|
----+Okay, so now we get to the reissue example, and honestly it's giving paper trail. 🧾✨ It shows what happens when you take the first message from this section and send it again. The reissued version wraps up the original message (as a Message data element) along with the To, From, and Posted-Date fields, plus a Reissue-Type field set to Redistributed. 🦋
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | F 8 | 0 1 |
+--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 9 | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+-- --+
| 0 6 |Cooper|
+--------+-- --+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+86
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 5 | 0 2 |00101000| 1 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 0 |19800814-1030EDT|
+--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 0 | 2 5 |00000010| 0 D |
+--------+--------+--------+--------+--------+
+---- ----+
|Redistributed|
+---- ----+
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | B 4 | 0 1 |
+--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+87
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 5 | 0 2 |00101000| 1 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 0 |19800814-1000EDT|
+--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
due tomorrow. Please have<CrLf>
your section to me by three this
----+
afternoon.|
----+H.5. Unknown Lengths 🌸
This section is all about data elements whose length is unknown, and it has two examples of them. 🙈 Both of these examples already showed up back in Sections H.2 and H.4, except this time the length was known instead of unknown. Plot twist, but make it make sense. 💅
Here's the first one: a Set data element with an unknown length that holds two Integer data elements. The first integer has a value of 519 (decimal), and the second has a value of 71 (decimal). Fun fact: 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 second one is a sample message with an unknown length, and it's giving office drama in the best way. 📬 Stevens is the originator and Johnson is the recipient. It was sent on August 14, 1980, at 10 am EDT. The subject is "Project Deadline," and the message is a friendly reminder that the deadline is the next day, and that Johnson's section of the report for the project should be turned in to Stevens by 3 pm that day. Stevens really said "pls have it in by 3" 😭🎀
Message Length Type
+--------+--------+--------+
|01001101| 8 0 | 0 1 | +--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+------- ---+89
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 5 | 0 2 |00101000| 1 2 |
+--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 0 |19800814-1000EDT|
+--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
due tomorrow. Please have<CrLf>
your section to me by three this
----+
afternoon.|
----+
End-of-Con Length
+--------+--------+
|00000000|00000000|
+--------+--------+90
91
REFERENCES ✨
okay so this is the bibliography bit, and honestly it's giving receipts 💅 every source the RFC leaned on is listed right here, with all the details so nobody has to guess 🧚
[BlaR-80] R. P. Blanc and J. F. Heafner. The NBS Program in Computer Network Protocol Standards. In Proceedings, ICCC 80. 1980.
[CroD-77] David H. Crocker, John J. Vittal, Kenneth T. Pogran, D. Austin Henderson, Jr. Standard for the Format of ARPA Network Text Messages. RFC 733, The Rand Corporation, Bolt Beranek and Newman Inc, Massachussets Institute of Technology, Bolt Beranek and Newman Inc., November, 1977. 📬
[FeiE-79] E. Feinler, J. Pickens, and A. Sjoberg. Computer Message Services Bibliography. Technical Report NIC-BIBLIO-791201, SRI International, December, 1979. 📚
[ISOD-79] ISO/TC97/SC6 Data Communications. Second Draft Proposed Communication Heading Format Standard. ISO/TC97/SC6 N 1948, ISO International Organization for Standardization Organization Internationale de Normalisation, September, 1979. Secretariat: USA (ANSI). 🌸
[ISOD-81] ISO/TC97/SC16. Open Systems Interconnection Basic Reference Model. ISO/TC97/SC16 N, ISO International Ozation for Standardization Organization Internationale de Normalisation, 1981. 🦋
[NatB-68] National Bureau of Standards. Calendar Date. Federal Information Processing Standards Publication 4, U.S. Department of Commerce / National Bureau of Standards, November, 1968. 🗓️
[NatB-77] National Bureau of Standards. Data Encryption Standard. Federal Information Processing Standards Publication 46, U.S. Department of Commerce / National Bureau of Standards, January, 1977. 🔐
[NatB-79a] National Bureau of Standards. Representations of Local Time of the Day for Information Interchange. Federal Information Processing Standards Publication 58, U.S. Department of Commerce / National Bureau of Standards, February, 1979. 🕰️
[NatB-79b] National Bureau of Standards. Representations of Universal Time, Local Time Differentials, and United States Time Zone References for Information Interchange. Federal Information Processing Standards Publication 59, U.S. Department of Commerce / National Bureau of Standards, February, 1979. 🌍
[PosJ-79] Jonathan B. Postel. INTERNET MESSAGE PROTOCOL. RFC 753, Information Sciences Institute, March, 1979. 💌
[SchP-79] Peter Schicker. The Computer Based Mail Environment: An Overview. Technical Report, Bell-Northern Research Ltd., Ottawa, Ontario, Canada, December, 1979. 🍁
[TasG-80] Task Group X3S33 on Data Communications Formats, ANSI Subcommittee X3S3 on Data Communications. Third Draft Proposed American National Standard for Heading Format Structure for Code Independent Communication Headings. ANSI document X3S37/80-01, Computer and Business Equipment Manufacturers Association, 1980. 🎀
INDEX ✨
okay bestie, this is the cheat sheet for the whole spec. every term, field, and data element, with the pages where it shows up 💖
ASCII-String 29, 30, 42, 45, 47, 49, 53, 54, 55, 57,
59, 63
Assignment 17, 22, 55
Attachments 17, 52
Audit trail 20
Author 14, 52
BASIC 13
BASIC Data Elements
ASCII-String 42, 57
Date 45, 59
End-of-Constructor 43, 60
Field 46, 60
Message 46, 61
BASIC fields
Cc 14
Reply-To 14
Subject 17
Text 17
BASIC syntactic elements 29
Bcc 14, 19, 20, 52
Bit numbering in octets 32
Bit-String 30, 37, 42, 44, 45, 47, 57, 58, 59, 63
Boolean 30, 43, 58
Cc 14, 19, 52
Chains of correspondence 24
Circulate-Next 15, 26, 53
Circulate-To 15, 26, 53
Circulation 26
Comment 30, 31, 38, 49
Comments 18, 53
Compliance requirements 34
Compressed 31, 37, 44, 49, 58
Compression identifier 44, 58
Compression Identifiers
NBS-Standard 49
Unspecified 49
Constructor data element 29, 30
Contents 32, 70
Cross Referencing 24
Data Element Contents 37, 38, 39, 81, 36, 39, 47, 63,
36, 38, 39, 41, 42, 47, 57, 63, 81
Data Elements
94
ASCII-String (BASIC) 42, 57
Bit-String (OPTIONAL) 42, 57
Boolean (OPTIONAL) 43, 58
Compressed (OPTIONAL) 44, 58
Date (BASIC) 45, 59
Encrypted (OPTIONAL) 45, 59
End-of-Constructor (BASIC) 43, 60
Extension (OPTIONAL) 45, 60
Field (BASIC) 46, 60
Integer (OPTIONAL) 43, 61
Message (BASIC) 46, 61
No-Op (OPTIONAL) 44, 61
Padding (OPTIONAL) 44, 62
Property (OPTIONAL) 47, 62
Property-List (OPTIONAL) 46, 62
Sequence (OPTIONAL) 47, 63
Set (OPTIONAL) 47, 63
Unique-ID (OPTIONAL) 47, 63
Vendor-Defined (OPTIONAL) 48, 64
Date 15, 45, 53, 54, 55, 56, 59
Dating 25
Delivery 9, 15, 54
Delivery Protocol 9
Delivery Slot 9
Encapsulating 22
Encrypted 31, 37, 45, 49, 59
Encryption identifier 45, 59
Encryption Identifiers
NBS-Standard 49
Unspecified 49
End-Date 15, 25, 53, 56
End-Of-Constructor 30, 36, 39, 43, 60
Extension 41, 45, 60
Field 10, 26, 29, 30, 31, 37, 46, 60, 61, 66
Field Identifier 46, 60
Field label presentation 29
Fields
Attachments (OPTIONAL) 52, 17
Author (OPTIONAL) 52, 14
Bcc (OPTIONAL) 52, 14
Cc (BASIC) 52, 14
Circulate-Next (OPTIONAL) 53, 15
Circulate-To (OPTIONAL) 53, 15
Comments (OPTIONAL) 53, 18
Date (OPTIONAL) 53, 15
End-Date (OPTIONAL) 53, 15
From (REQUIRED) 53, 14
In-Reply-To (OPTIONAL) 53, 16
Keywords (OPTIONAL) 53, 18
95
Message-Class (OPTIONAL) 54, 17
Message-ID (OPTIONAL) 54, 16
Obsoletes (OPTIONAL) 54, 16
Originator-Serial-Number (OPTIONAL) 54, 16
Posted-Date (REQUIRED) 54, 15
Precedence (OPTIONAL) 54, 16
Received-Date (OPTIONAL) 54, 15
Received-From (OPTIONAL) 55, 17
References (OPTIONAL) 55, 16
Reissue-Type (OPTIONAL) 55, 17
Reply-To (BASIC) 55, 14
Sender (OPTIONAL) 55, 14
Start-Date (OPTIONAL) 55, 15
Subject (BASIC) 55, 17
Text (BASIC) 56, 17
To (REQUIRED) 56, 14
Warning-Date (OPTIONAL) 56, 15
From 12, 14, 23, 52, 53, 55
Globally unique identifiers 24
Identifier octet 33, 35, 32, 33, 36, 39, 40, 70
Identifiers
globally unique 24
In-Reply-To 16, 24, 53
Indefinite length code 35
Integer 30, 43, 47, 61, 63
Keywords 18, 53, 81
Length Code 34, 36, 32, 33, 34, 35, 36, 37, 39, 40,
70, 71, 81
Long length code 35
Message Transfer System 8, 9, 17, 54
Message 10, 12, 29, 30, 31, 37, 46, 61
Message content 9
Message envelope 9
Message stores 25
Message Transfer System 9, 17, 20, 55, 8, 9, 10, 12,
15, 16, 20, 54, 55
Message Types
NBS-Standard 50
Message-Class 17, 54
Message-ID 16, 24, 26, 53, 54, 55
NBS-Standard 49, 50
No-Op 44, 61
Numbering bits in octets 32
Obsoletes 16, 24, 54
96
Octets
bit numbering in 32
OPTIONAL 13
OPTIONAL Data Elements
Bit-String 42, 57
Boolean 43, 58
Compressed 44, 58
Encrypted 45, 59
Extension 45, 60
Integer 43, 61
No-Op 44, 61
Padding 44, 62
Property 47, 62
Property-List 46, 62
Sequence 47, 63
Set 47, 63
Unique-ID 47, 63
Vendor-Defined 48, 64
OPTIONAL fields
Attachments 17
Author 14
Bcc 14
Circulate-Next 15
Circulate-To 15
Comments 18
Date 15
End-Date 15
In-Reply-To 16
Keywords 18
Message-Class 17
Message-ID 16
Obsoletes 16
Originator-Serial-Number 16
Precedence 16
Received-Date 15
Received-From 17
References 16
Reissue-Type 17
Sender 14
Start-Date 15
Warning-Date 15
OPTIONAL syntactic elements 29
Originator 11, 13, 15, 25, 52, 53, 55
Originator-Serial-Number 16, 25, 54
Padding 44, 62
Person 13
Posted-Date 12, 15, 26, 53, 54
Posting 9
Posting Protocol 9
Posting Slot 9
97
Precedence 16, 54
Precedence categories 17
Precedence scheme 54
Presentation
field label 29
Primitive data element 30, 29, 30
Printing-Name 30, 38, 49, 76
Process 13
Properties
Comment 49
Printing-Name 49
Property 32, 37, 46, 47, 62
Property-Identifier 47, 62
Property-List 30, 32, 33, 38, 39, 40, 46, 62, 70
Qualifier 32, 33, 34, 36, 37, 39, 40, 42, 44, 45, 46,
47, 48, 57, 58, 59, 60, 62, 64, 70
Qualifiers 37
Received-Date 15, 54
Received-From 17, 55
Recipient 11, 14, 17, 52, 53, 55, 56
Redistribution 17, 22, 55
References 16, 24, 55
Reissue-Type 17, 55
Reply 13, 23
Reply-to 14, 23, 53, 55
REQUIRED 13
REQUIRED fields
From 14
Posted-Date 15
To 14
Requirements
compliance 34
Role 13
Sender 14, 26, 55
Sequence 29, 30, 47, 63
Sequences 30
Serial Numbers 16, 24, 54
Set 30, 47, 63
Short length code 35
Slot 9
Start-Date 15, 25, 55
Subject 17, 55
Syntactic reissuing 22
Text 17, 26, 56
To 12, 14, 19, 26, 30, 56
Unique identifiers 24
98
Unique-ID 47, 53, 54, 55, 63
Unspecified 49
User Agent 8, 9, 20
User interface 29
Vendor-Defined 41, 48, 64
Warning-Date 15, 25, 56
99and that's the whole spec, babe 🦋✨ every single page of it. you did it 🎀💅
📦 where this page comes from
- ietf: rfc806 1981-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms