RFC 759
Internet Message Protocol
INTERNET MESSAGE PROTOCOL 💌
Okay bestie, here are the deets 📜 This is RFC 759, also known as IEN 113, called Internet Message Protocol, and it was written by Jonathan B. Postel at the Information Sciences Institute, University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291, (213) 822-1511. It's dated August 1980. The title block doesn't list a category or status, and it doesn't say what it obsoletes or updates, so there's nothing to report on that front 🙈
TABLE OF CONTENTS 📚
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1. Motivation ................................................... 1
1.2. Scope ........................................................ 1
1.3. The Internetwork Environment ................................. 2
1.4. Model of Operation ........................................... 2
1.5. Interfaces ................................................... 4
2. FUNCTIONAL DESCRIPTION ........................................... 5
2.1. Terminology .................................................. 5
2.2. Assumptions ................................................. 5
2.3. General Specification ........................................ 6
2.4. Mechanisms ................................................... 7
2.5. Relation to Other Protocols ................................. 10
3. DETAILED SPECIFICATION .......................................... 13
3.1. Overview of Message Structure ............................... 13
3.2. Message Structure ........................................... 14
3.3. Identification .............................................. 15
3.4. Command ..................................................... 15
3.5. Document .................................................... 19
3.6. Message Objects ............................................. 20
3.7. Data Elements ............................................... 27
4. OTHER ISSUES .................................................... 35
4.1. Accounting and Billing ...................................... 35
4.2. Addressing and Routing ...................................... 36
4.3. Encryption .................................................. 37
5. The MPM: A Possible Architecture ............................... 39
5.1. Interfaces .................................................. 39
5.2. MPM Organization ............................................ 40
6. EXAMPLES & SCENARIOS ............................................ 45
Example 1: Message Format ........................................ 45
Example 2: Delivery and Acknowledgment ........................... 47
7. SPECIFICATION SUMMARY ........................................... 55
7.1. Message Fields .............................................. 55
7.2. Deliver Message ............................................. 58
7.3. Acknowledge Message ......................................... 59
7.4. Probe Message ............................................... 61
7.5. Response Message ............................................ 62
7.6. Cancel Message .............................................. 64
7.7. Canceled Message ............................................ 66
7.8. Data Element Summary ........................................ 68
REFERENCES .......................................................... 69PREFACE 🎀
Okay so this is the second edition of this spec, and it's meant to be treated as a request for comments, advice, and suggestions 💖 A ton of prior work has been done on computer aided message systems, and some of it is listed in the reference section. This spec was shaped by lots of discussions with members of the ARPA research community, plus other people who are into developing computer aided message systems ✨ It was prepared as part of the ARPA sponsored Internetwork Concepts Research Project at ISI, with help from Greg Finn, Suzanne Sluizer, Alan Katz, Paul Mockapetris, and Linda Sato 🫶
Jon Postel
1. INTRODUCTION ✨
This document describes an internetwork message system 🦋 The system is designed to transmit messages between message processing modules, following the formats and procedures specified in this document. The message processing modules are processes in host computers. They're located in different networks, and together they make up an internetwork message delivery system.
This document is meant to give you all the info you need to build a compatible cooperating module of this internetwork message delivery system 💅
1.1. Motivation 🌸
As computer supported message processing activities grow on individual host computers and in networks of computers, there's a natural desire to connect these systems and get them working together 🍓 This spec describes the formats and procedures of a general purpose internetwork message system. It can be used as a standard for connecting individual message systems, or as a message delivery system in its own right.
This system also handles data items beyond what contemporary message systems cover, and that's the iconic part 🤩 Messages can include data objects that could represent drawings, facsimile images, or digitized speech. Picture message stations equipped with speakers and microphones (or telephone hand sets), where the body of a message, or a portion of it, is recorded digitized speech. The output terminal could include a graphics display, so the message might show a drawing on the display and verbally (via the speaker) describe certain features of the drawing. This spec provides for composing complex data objects and encoding them in machine independent basic data elements. Main character energy, literally 👑
1.2. Scope 🧚
The Internet Message Protocol is meant to be used for transmitting messages between networks. It may also be used for the local message system of a network or host. This spec was developed in the context of the ARPA work on interconnecting networks, but it's thought to have a more general scope 💜
The focus here is on the internal mechanisms for transmitting messages, not the external interface to users. It's assumed that a number of user interface programs will exist. These will be both new programs designed to work with this system and old programs designed to work with earlier systems ✨
1.3. The Internetwork Environment 🌈
The internetwork message environment is made up of processes that run in hosts. Those hosts are connected to networks, and those networks are interconnected by gateways 🔥 Each network consists of many different hosts, and the networks are tied together through gateways. Gateways are basically hosts on two (or more) networks, and they aren't assumed to have much storage capacity or to "know" which hosts are on the networks they're attached to [1,2] 💀
1.4. Model of Operation 🦋
This protocol is implemented in a process called a Message Processing Module, or MPM. MPMs exchange messages by establishing full duplex communication and sending the messages in a fixed format described in this document. The MPM may also communicate other information through the commands described here 💌
A message is formed by a user interacting with a User Interface Program, or UIP. The user can use several commands to create various fields of the message, and may invoke an editor program to correct or format some or all of it. Once the user is happy with the message, it's submitted for transmission by placing it in a data structure read by the MPM 💅
The MPM finds the unprocessed input data (either through a specific request or a general background search), examines it, and, using routing tables (or some other method), decides which outgoing link to use. The destination might be another user on the same host, one on another host in a network shared with the same host, or a user in another network 🫶
In the first case, where the destination is another user on this host, the MPM places the message in a data structure read by that destination user, where that user's UIP will look for incoming messages 🎀
In the second case, where the user is on another host in this network, the MPM transmits the message to the MPM on that host. That MPM then repeats the routing decision. Once it finds the destination is local to it, it places the message in the data structure shared with the destination user ✨
In the third case, where the user is on a host in another network, the MPM transmits the message to an MPM in that network if it knows how to establish a connection directly to it. Otherwise, the MPM transmits the message to an MPM that is "closer" to the destination 🌸 An MPM might not know of direct connections to MPMs in all other networks, but it must be able to select a next MPM to handle the message for each possible destination network. ⭐
An MPM might know a way to establish direct connections to a few MPMs in other nearby networks, and send all other messages to a particular big brother MPM that has a wider knowledge of the internet environment 👑
An individual network's message system may be quite different from the internet message system. In that case, intranet messages are delivered using the network's own message system. If a message is addressed outside the network, it's given to an MPM, which then sends it through the appropriate gateways to (or towards) the MPM in the destination network. Eventually the message reaches an MPM on the network of the recipient, and it's then sent via the local message system to that host 🧚
When local message protocols are used, special conversion programs are required to transform local messages into internet format when they're going out, and to transform internet messages into local format when they come into the local environment. Those transformations can potentially lead to information loss 😭 The internet message format tries to provide features that capture all the information any local message system might use. However, a particular local message system is unlikely to have features equivalent to all the possible features of the internet message system. So in some cases, transforming an internet message into a local message discards some of the information. For example, if an internet message carrying mixed text and speech data in the body is going to be delivered to a local system that only carries text, the speech data may be replaced by the text string "There was some speech here" 🙈
Discarding information is to be avoided when at all possible, and deferred as long as possible. Still, the possibility remains that in some cases it's the only reasonable thing to do 🥺
1.5. Interfaces 💜
The MPM calls on a reliable communication procedure to talk to other MPMs. This is a Transport Level protocol, such as the Transmission Control Protocol (TCP) [3] ✨ The interface to such a procedure conventionally provides calls to open and close connections, send and receive data on a connection, and some means to signal and be notified of special conditions (i.e., interrupts) 🔥
The MPM receives input and produces output through data structures that are produced and consumed, respectively, by user interface (or other) programs 💅
2. FUNCTIONAL DESCRIPTION ✨
Okay bestie, this section is the tour of the whole Internet Message System and the world it lives in 🌍✨
2.1. Terminology 💌
So messages get routed by a process called the Message Processing Module (or MPM) 🚚. The messages themselves are created and consumed by User Interface Programs (UIPs), working together with actual users 🫶
The basic unit that gets passed between MPMs is called a message 💖. A message is made up of a transaction identifier (which uniquely identifies the message), a command (which holds the info needed for delivery), and a document. The document can have a header and a body.
Think of a personal letter 💌: the document body is the actual contents of the letter, and the document header is the date line, greeting, and signature. For an inter-office memo 📎, the body is the text and the header is the memo's header.
The commands are basically the same info the Post Office or the mail room uses to route a letter or memo 📮. Some of that command info is filled in by the UIP.
2.2. Assumptions 🧠
Okay, so here's what we're assuming about the internetwork environment 👀
It's not known what format intranet addresses will end up taking. No single standard addressing scheme would suit every network, so it's safe to assume there will be several, and that they'll change over time 🔄. If every MPM that handles internet messages had to know about the formats on many networks, the software in all of the internet MPMs would need frequent updates 😩. So each MPM that handles internet messages is required to know only the minimum necessary to deliver them 🎯.
Each MPM is required to know completely only the addressing format of its own network(s). On top of that, the MPM must be able to select an output link for each message addressed to another network or host 🛣️. This doesn't stop a given MPM from being more intelligent, but that minimum is the bare necessity. Each network has a unique name and numeric address, and those names and addresses are registered with a naming authority and may be listed in documents such as Assigned Numbers [4] 📚.
Each MPM will have a unique internet address 🏠. That lets every MPM slap a unique "handling-stamp" on a message as it passes through on the way to delivery 🏷️✨
2.3. General Specification 📝
There are several aspects to a distributed service that needs specifying. First, there's the service being provided, meaning the characteristics of the service as seen by its users 👩💻. Second, there's the service it uses, meaning the characteristics it assumes some lower level service provides 🧱. And third, there's the protocol used between the modules of the distributed service 🤝
User User
\ /
UIP UIP
\ /
--+----------------------------------------+-- Service
| \ / | Interface
| +--------+ +--------+ |
| | Module | <--Protocol--> | Module | |
| +--------+ +--------+ |
| \ / |
| +-----------------------+ |
| | Communication Service | |
| +-----------------------+ |
| |
+----------------------------------------+
Message Service
Figure 1.The User/Message Service Interface 🎀
The message delivery system's job is to accept messages in a specified format, try to deliver them, and report whether the delivery attempt worked or failed 📬. This service happens inside an interconnected system of networks, and it may relay a message through several intermediate MPMs using different communication services 🔀
The Message/Communication Service Interface 🔌
The message delivery system relies on a communication service to move information from one MPM to another 🚀. Different pairs of MPMs can use different communication services, but every communication service has to meet the service characteristics described below 👑
It's assumed the communication service provides a reliable two-way data stream 🌊. In computer networks, you can usually get one of those from the transport level protocol, for example the Transmission Control Protocol (TCP) [3]. Either way, here's what the communication service must provide 💅:
- Logical connections for two way simultaneous data flow of arbitrary data (i.e., no forbidden codes). All data sent is delivered in order.
- Simple commands to open and close the connections, and to send and receive data on the connections.
- Controlled flow of data so that data is not transmitted faster than the receiver chooses to consume it (on the average).
- Transmission errors are corrected without user notification or involvement of the sender or receiver. Complete breakdown on communication is reported to the sender or receiver.
The Message-Message Protocol 🗣️
The protocol used between the distributed modules of the message delivery system, meaning the MPMs, is a small set of commands that convey requests and replies 💬. These commands are encoded in a highly structured and rigidly specified format 🔒
2.4. Mechanisms ⚙️
MPMs are processes that use some communication service 🧩. A pair of MPMs that can communicate live in a common interprocess communication environment. An MPM might exist in two (or more) interprocess communication environments, and an MPM like that might act to relay messages between MPMs 🌉. Messages can be held for a while in an MPM, so the whole path needed for delivery doesn't have to be available all at once ⏳
From the moment an MPM accepts a message from a UIP, until an MPM delivers it to a UIP and an acknowledgment comes back to the originating UIP, the message is considered active in the message system 🏃♀️💨
User User
\ /
UIP UIP
\ /
+---------------------------------------------------------+
| \ / |
| +-----+ +-----+ +-----+ |
| | MPM | <--Protocol--> | MPM | <--Protocol--> | MPM | |
| +-----+ +-----+ +-----+ |
| | / \ | |
| +-----------------------+ +-----------------------+ |
| |Communication Service A| |Communication Service B| |
| +-----------------------+ +-----------------------+ |
| |
+---------------------------------------------------------+
Message Service with Internal Relaying
Figure 2.So there are two roles an MPM can play 🎭: an end-point MPM or a relay MPM. Most MPMs play both roles 💫. A relay MPM relays messages from one communication environment to another 🔁. An end-point MPM is the source or destination of messages 📍
The data moving between UIPs and MPMs is seen as the exchange of data structures that encode messages 📦. The data moving between MPMs is also sent as structured data 🧾
+-----+ DATA +-----+
USER-->| UIP |-->STRUCTURES-->| MPM |-->other
+-----+ +-----+ +-----+ MPMs
| |
| +-----+
+--| |
| +-----+
+--| |
| |
+-----+
+-----+ DATA +-----+
other-->| MPM |-->STRUCTURES-->| UIP |-->USER
MPMs +-----+ +-----+ +-----+
| |
| +-----+
+--| |
| +-----+
+--| |
| |
+-----+
Message Flow
Figure 3.In what follows, a message is described as a structured data object, represented in a particular kind of typed data elements 🧸. That's how a message looks when it's sent between MPMs or swapped between an MPM and a UIP. Inside an MPM (or a UIP), a message can be represented in any convenient form 🛠️
2.5. Relation to Other Protocols 🌐
This protocol benefited from the earlier work on message protocols in the ARPA Network [5,6,7,8,9], and from the ideas of others about the design of computer message systems [10,11,12,13,14,15,16,17,18,19,20,21] 🙌
Figure 4 shows where the message protocol sits in the ARPA internet protocol hierarchy 🗺️
+------+ +-----+ +-------+ +-----+ +-----+
|Telnet| | FTP | |Message| |Voice| ... | | Application Level
+------+ +-----+ +-------+ +-----+ +-----+
\ | / | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
|
Protocol Relationships
Figure 4.Quick note: "local network" means an individual or specific network 🏡. For example, the ARPANET is a local network 🛰️
The message protocol connects on one side to user interface programs and on the other side to a reliable transport protocol such as TCP 🔗. In this internet message system, the MPMs talk directly to each other using the lower level transport protocol 💬. In the old ARPANET system, message transmission was part of the file transfer protocol 📂
+------+ +-----+ +-------+
|Telnet| | FTP |---|Message| Application Level
+------+ +-----+ +-------+
\ /
+-----+ +-----+
|Voice|---| NCP | Host Level
+-----+ +-----+
|
|
| Gateway Level
|
|
+----------------+
| ARPA NET | Network Level
+----------------+
Old ARPANET Protocols
Figure 5.Last thing, and it's kind of a big deal 😭: in the old ARPANET protocols, you couldn't send messages (or communicate in any way) to other networks, since there was no gateway level or internet protocol [5] 🚫
3. DETAILED SPECIFICATION ✨
The tricky bit about this part is that everything depends on everything 😭, but since this is a linear medium we have to go in some order 💅. So here's the plan 🦋: a quick overview of the message structure, then the details as data objects 🎀, then the data objects themselves ✨, and finally how the basic data elements get represented 👑. Several parts of the message structure are based on the NSW Transaction Protocol [22], plus some similar (but more general) proposals [23,24] 🫶
3.1. Overview of Message Structure
Okay, a message is normally made up of three parts 🌸: the identification, the command, and the document. Each of those parts is itself made of data objects 🧚
The identification part is a transaction number assigned by the originating MPM, plus the MPM identifier 🍓
The command part is made of an operation type, an operation code, the arguments to the operation, error information, the destination mailbox, and a trace 💜. The trace is a list of the MPMs that have handled this message, so it's like the message's little travel diary 🦋
The document part is a data structure ✨. The message delivery system doesn't depend on what's in the document part, so it's not looking inside 🙈. A standard for the document part is defined in reference [25] 📚
The following sections define how a message is represented as a structured object made up of other objects 🎀. Those objects are then built out of a set of basic data elements 🧩
The basic data elements are defined in section 3.7 💖. In short, they're exact forms for representing integers, strings, booleans, et cetera 🌈. There are also two elements for building data structures: list and property list 👑. A list is a simple list of elements, and lists can contain lists too 🫶. A property list is a list of pairs of elements, where the first element of each pair names the pair. So basically a property list is a list of <name,value> pairs 💅. In general, when an object is made up of multiple instances of a simpler object, it's represented as a list of those simpler objects ✨. When an object is made up of a variety of simpler objects, it's represented as a property list of them 🦋. And in most uses of the property list representation, extra <name,value> pairs are allowed on top of the ones that are specifically required 🎀
3.2. Message Structure
An internet message is made of two or three parts 💖. The first is the Identification, which identifies the transaction. The second is the Command. The third part, the Document, is optional 🌸
When a message is shipped between two MPMs, it takes the form of a property list, with the <name,value> pairs in this order 🦋
MESSAGE is:
( Identification, Command [, Document ] )It's convenient to batch several messages together and ship them as a unit from one MPM to another 📦 Such a group of messages is called a message-bag 🧺
A message-bag is a list of Messages, and each Message is of the form described above 💜
MESSAGE-BAG is:
( Message, Message, ... )The Identification
This is the transaction identifier 🆔 It's assigned by the originating MPM. The identification is made up of the MPM identifier and a transaction number that's unique in that context for this message ✨
The Command
The command is made up of a mailbox, an operation code, the arguments to that operation, some error information, and a trace of the route this message took 🛤️ The command is implemented as a property list containing <name,value> pairs, where the names are used to identify the associated argument values 💅
The Document
The document portion of an internet message is optional 🫶 and when it's there, it's a data structure as defined in [25] 📚
3.3. Identification
Each message must have a unique identifier while it exists in the message delivery system 🔒 This is provided by combining the unique identifier of the MPM with a unique transaction number chosen for the message by that MPM 💖
IDENTIFICATION is:
( mpm-identifier, transaction-number )The mpm-identifier is based on the host address of the computer the MPM lives on 🖥️ If there's more than one MPM in a host, the mpm-identifier must be extended so it can tell the co-resident MPMs apart 🧚
3.4. Command
This section describes the commands MPMs use to talk to each other 💬 The commands come in pairs, and every request has a matching reply 👯♀️
COMMAND is:
( mailbox, operation, [arguments,]
[error-class, error-string,] trace )The mailbox is the "To" specification of the message 💌 It's a property list of general information. Some of it is essential for delivery, and some of it is extra info that might help with delivery 🌈 A mailbox is different from an address, because an address is a very specific property list with no extra information 🎯 The mailbox includes a specification of the user. When a command is addressed to the MPM itself, rather than a user it serves, the special user name "*MPM*" is specified 🤖
The operation is the name of the operation or procedure to be performed 🛠️
The arguments to the operation vary from operation to operation 🎀
The error information is made up of an error class code and a character string, and it shows what error occurred, if any 🚨 The error information is normally present only in replies, and not present in requests 💅
The trace is a list of the MPMs that have handled the message 🦋 Each MPM must add its handling-stamp to the list 📝
3.4.1. Command: DELIVER
Function: Sends a document to a mailbox 📬
Reply: The reply is ACKNOWLEDGE 💌
Arguments:
- type-of-service: one or more of the following:
"REGULAR" regular delivery
"FORWARD" message forwarding
"GENDEL" general delivery
"PRIORITY" priority delivery3.4.2. Command: ACKNOWLEDGE
Function: Reply to DELIVER 💖
Arguments:
- reference: the identifier of the originating message 🆔
- address: The address is the final mailbox the message was delivered to 📍 This would be different from the original mailbox if the message was forwarded, and it's limited to the essential information needed for delivery 🎯
- type-of-service: one of the following:
"GENDEL" message was accepted for general delivery
"REGULAR" message was accepted for normal delivery
"PRIORITY" message was accepted for priority delivery- error-class and error-string: If the document was delivered successfully, the error information has class 0 and the string "ok" 🎉 Otherwise, the error information has a non-zero class, and the string would be one of "no such user", "no such host", "no such network", "address ambiguous", or a similar response 😬
- trail: the trace from the DELIVER command 🦋
3.4.3. Command: PROBE
Function: Finds out if the specified mailbox (specified in mailbox of the command) exists at a host 🔎
Reply: The reply is RESPONSE 💌
Arguments: none 🫧
3.4.4. Command: RESPONSE
Function: Reply to PROBE 💬
Arguments:
- reference: the identification of the originating PROBE 🆔
- address: a specific address 📍
- error-class and error-string: If the mailbox was found, the error class is 0 and the error string is "OK" ✨ If the mailbox has moved and a forwarding address in known, the error class is 1 and the error string is "Mailbox moved, see address" 📮 Otherwise the error class is greater than 1, and the error string may be one of the following: "Mailbox doesn't exist", "Mailbox full", "Mailbox has moved, try the new location indicated in the address" 😭
- trail: the trace which came from the originating PROBE 🦋
3.4.5. Command: CANCEL
Function: Abort request for the specified transaction 🛑
Reply: The reply is CANCELED 💌
Arguments:
- reference: identification of the transaction to be canceled 🆔
3.4.6. Command: CANCELED
Function: Reply to CANCEL 💅
Arguments:
- reference: identification of the canceled transaction 🆔
- error-class and error-string: If the command was canceled, the error class is 0 and the error string is "OK" 🎉 Otherwise the error class is positive, and the error string may be one of the following: "No such transaction", or any error for an unreachable mailbox 🙃
- trail: the trace of the CANCEL command 🦋
To summarize again, a command generally consists of a property list of the following objects 💜
name value
---- -----
mailbox property list of address information
operation name of operation
arguments ---
error-class numeric class of the error
error-string text description of the error
trace list ( handling-stamp, ... )3.5. Document
The actual document follows the command 📄 The message delivery system doesn't depend on the document, doesn't examine it, and doesn't use it in any way 🙅♀️ The standard for the contents of the document is reference [25] 📚 The document must be the last <name,value> pair in the message property list 🫶
3.6. Message Objects 💅✨
okay so when we build messages, we keep using a set of objects like mailbox or date 🎀 these objects get encoded into basic data elements. some are simple stuff like integers or character strings, and others are more complex, built out of lists or property lists 🧚
the objects are listed below in alphabetical order, bestie 💖
Action 🦋
the type of handling action the MPM takes when it processes a message. it's one of ORIGIN, RELAY, FORWARD, or DESTINATION 👑
Address 🌸
an address holds the minimum info needed to deliver a message, and nothing extra. (compare that with mailbox, it's giving main character energy 💅)
an address is a property list. it contains these <name,value> pairs:
name description
---- -----------
NET network name
HOST host name
USER user nameor these:
name description
---- -----------
MPM mpm-identifier
USER user nameAnswer 💜
a yes (true) or no (false) answer to a question 🙈
Arguments 🍓
lots of operations need arguments, and they're different for each command. this "object" is just a placeholder for the actual arguments when we describe commands in a general way 🧚
City 🌈
the character string name of a city 🏙️
Command 🔥
(mailbox, operation [ ,arguments ]
[ ,error-class, error-string ], trace)Country 🌍
the character string name of a country 🌎
Date ⭐
the date and time follow the International Standards Organization (ISO) recommendations [26,27,28]. put together, the ISO recommendations 2014, 3307, and 4031 give us this representation of date and time:
yyyy-mm-dd-hh:mm:ss,fff+hh:mmhere's the breakdown 🫶
- yyyy is the four-digit year
- mm is the two-digit month
- dd is the two-digit day
- hh is the two-digit hour in 24 hour time
- mm is the two-digit minute
- ss is the two-digit second
- fff is the decimal fraction of the second
then we tack on the offset from Greenwich as plus or minus hh hours and mm minutes ✨
the time is local time, and the offset is the difference between local time and Coordinated Universal Time (UTC). to go from local time to UTC, you subtract the offset from the local time. (math bestie moment 🤓)
for example, when it's
Los Angeles is 14:25:00-08:00
the UTC is 22:25:00or when it's
Paris is 11:43:00+01:00
the UTC is 10:43:00Document 📝
the document is the user's composition. the message delivery system doesn't use it in any way 🙅♀️
Error-Class 🚨
a numeric code for the class of error. the error classes are coded like this:
= 0: success, no error. this is the normal case, periodt 💖= 1: failure, address changed. this one shows up when forwarding is possible but the type of service you picked doesn't allow it 🦋= 2: failure, resources unavailable. these are temporary, so the command might work if you try again later ⏰= 3: failure, user error. for example, an unknown operation or bad arguments 🙈= 4: failure, MPM error. recoverable. these are temporary too, so the command might work if you try again later 🌸= 5: failure, MPM error. permanent. these are permanent, so there's no point in trying the same command again 💀= 6: aborted as requested by the user. this is the response to a successfully canceled command 🫶
Error-String 💬
this is a character string describing the error. here are the possible errors 💅
error-string error-class
No errors 0
Ok 0
Mailbox Moved, see address 1
Mailbox Full, try again later 2
Syntax error, operation unrecognized 3
Syntax error, in arguments 3
No Such User 3
No Such Host 3
No Such Network 3
No Such Transaction 3
Mailbox Does Not Exist 3
Ambiguous Address 3
Server error, try again later 4
No service available 5
Command not implemented 5
Aborted as requested by user 6Handling-Stamp 🔥
the handling-stamp tells you which MPM handled the message, the date (time included) it was processed, and the type of handling action taken 🕰️
( mpm-identifier, date, action )Host 🖥️
the character string name of a host 💻
Identification 🆔
this is the transaction identifier for a particular message. it's made of the transaction number and the MPM identifier of the originating MPM 🎀
( mpm-identifier, transaction-number )Internet Address 🌐
this identifies a host in the ARPA internetwork environment. when it's part of identification, it identifies the originating host of a message. the internet address is a 32 bit number. the higher order 8 bits identify the network, and the lower order 24 bits identify the host on that network [2] 🧠
for use in the MPMs, the internet address gets split into eight bit fields, and each field's value is written in decimal digits. for example, the ARPANET address of ISIE is 167837748 and it's written as 10,1,0,52 ✨
this representation can also be extended to include an address within a host, like the TCP port of the MPM. for example: 10,1,0,52,0,45 🦋
Mailbox 📬
this is the destination address of a user of the internetwork mail system. a mailbox has info like network, host, location, and the local user identifier of the message's recipient. some of the info in a mailbox isn't needed for delivery 🙃
here's a relatable example 💖 when you message someone for the first time, you might include lots of stuff that isn't strictly needed just to make sure it gets there. but once they reply, that reply will contain an Address (not a Mailbox), and you can use that from then on 💌
a mailbox is a property list. it might contain these <name,value> pairs:
name description
---- -----------
MPM mpm-identifier
NET network name
HOST host name
PORT address of MPM within the host
USER user name
ORG organization name
CITY city
STATE state
COUNTRY country
ZIP zip code
PHONE phone numberthe minimum mailbox is an Address 🌷
MPM-Identifier 🛰️
the internetwork address of the MPM. this can be the ARPA Internet Address or an X.121 Public Data Network Address [29]. the mpm-identifier is a property list with one <name,value> pair. this unusual structure is on purpose, so it's easy to tell what type of address you're looking at 🧐
Network 🛜
the character string name of a network 📡
Operation ⚙️
this names the operation or procedure to be performed. it's a character string name 🛠️
Organization 🏢
the character string name of an organization 🎓
Phone ☎️
this is the character string representation of a phone number. for example, the phone number of ISI is 1 (international region) + 213 (area code) + 822 (central office) + 1511 (station number) = 12138221511 📞
Port 🚪
this names the port or subaddress within a host of the MPM. the default port for the MPM is 45 (55 octal) [4] 🔢
Reference 🔗
a reference is an identification from an earlier message 🕵️♀️
State 🗺️
the character string name of a state 🌵
Trace 🧵
each MPM that handles the message has to add its handling-stamp to this list. that lets us catch messages that are being sent in a loop within the internet mail system, and it helps with fault isolation 🔍
Trail 🛤️
when a message travels through the internetwork environment, it picks up this trace, which is a list of the MPMs that have handled it. this list then gets carried as the trail in a reply or acknowledgment of that message. requests and replies always have a trace, and each MPM adds its handling-stamp to that trace. replies also have a trail, which is the complete trace of the original message 💫
Transaction Number 🎟️
this is a number that the originating MPM uniquely associates with this transaction. it identifies the transaction. (a transaction is a message and its acknowledgment 💌) a transaction number must be unique for as long as the message (a request or reply) containing it could still be active in the network ⏳
Type-of-Service 🚀
a service parameter for delivering a message. for instance, a message could be delivered (REGULAR), forwarded (FORWARD), turned over to general delivery (GENDEL) (which means letting a person decide how to keep trying to deliver the message), or given priority handling (PRIORITY) 🏃♀️
User 🙋♀️
the character string name of a user 🧑
X121 Address 🇺🇳
this identifies a host in the Public Data Network environment. when it's part of an identifier, it identifies the originating host of a message. the X121 address is a sequence of up to 14 digits [29]. for use in the MPMs, the X121 address is written in decimal digits 🔟
Zip Code 📮
the character string representation of a postal zip code. the zip code of ISI is 90291 🌴
3.7. Data Elements 🎀💖
the data elements defined here are similar to the data structure and encoding used in NSW [30] 🧩
each of the diagrams below represents a sequence of octets. field boundaries are marked with the "|" character, and octet boundaries with the "+" character. each element begins with a one-octet code. the information in each element goes left-to-right. in fields with numeric values, the high-order (most significant) bit is the left-most bit. for transmission, the leftmost octet is sent first. (cohen has written about some of the headaches of mapping memory order to transmission order 🤯 [31])
Code Type Representation
---- ---- --------------
+------+
0 No Operation | 0 |
+------+
+------+------+------+------+------
1 Padding | 1 | octet count | Data ...
+------+------+------+------+------
+------+------+
2 Boolean | 2 | 1/0 |
+------+------+
+------+------+------+
3 Index | 3 | Data |
+------+------+------+
+------+------+------+------+------+
4 Integer | 4 | Data |
+------+------+------+------+------+
Extended +------+------+------+------+------
5 Precision | 5 | octet count | Data ...
Integer +------+------+------+------+------
+------+------+------+------+------
6 Bit String | 6 | bit count | Data ...
+------+------+------+------+------
+------+------+------
7 Name String | 7 | count| Data ...
+------+------+------ +------+------+------+------+------
8 Text String | 8 | octet count | Data ...
+------+------+------+------+------
+------+------+------+------+-----
9 List | 9 | octet count | Data ...
+------+------+------+------+-----
+------+------+------+------+------
10 Proplist | 10 | octet count | Data ...
+------+------+------+------+------
+------+
11 End of List | 11 |
+------+okay so Element code 0 (NOP) is the empty data element 🧚 used for padding whenever it's needed. It gets ignored, so it's basically the invisible one of the bunch ✨
Element code 1 (PAD) is for when you need to send a huge chunk of data with a message, either for testing or just for padding 🎀 The type-octet is followed by a three-octet count of how many octets come next. Nothing is done with this data, but the count of dummy octets must be correct, because that's how you find the next element code. Lowkey the most important part of PAD is the counting 💀
Element code 2 (BOOLEAN) is the boolean one 🦋 The octet right after the type-octet is 1 for True and 0 for False. Simple, iconic, no notes.
Element code 3 (INDEX) is a 16-bit unsigned integer datum 🌸 It only takes up 3 octets, so it's super compact. Small but mighty.
Element code 4 (INTEGER) is a signed 32-bit integer datum 💜 It will always occupy five octets, no exceptions. The representation is two's complement, which is giving very organized energy 💅
Element code 5 (EPI) is the extended precision integer 👑 The type octet is followed by a three-octet count of the number of data octets to follow. Representation is two's complement, same as INTEGER, so it's a whole family of two's complement vibes 🫶
Element code 6 (BITSTR) is a bit string element for binary data 🍓 If the bit string doesn't end on an octet boundary, it gets padded on the right with zeros to fill out the last octet. Also, this data type has to put the bit-count in the three-octet count field instead of the number of octets. Not the octets, the bits, bestie. Please pay attention 🙈
Element code 7 (NAME) is for character string names, or other short strings 🌈 The type octet is followed by a one-octet count of the number of characters (one per octet) to follow. Seven bit ASCII characters are used, right justified in the octet, and the high order bit in the octet is zero. Clean and tidy ✨
Element code 8 (TEXT) is for representing text 🎀 It's basically NAME's bigger sibling. The type octet is followed by a three-octet count of the number of characters (one per octet) to follow. Seven bit ASCII characters, right justified, high order bit is zero. Same rules, just more room to talk 💖
Element code 9 (LIST) is how you build structures out of other elements 🧚 The three-octet octet count tells you how many octets are in the whole list. That means the octets following this count field, all the way to the end of the list, not including the ENDLIST octet. The two-octet item count tells you how many elements follow. Any element can go in a list, and yes, that includes another list. Lists within lists within lists, it's giving Russian nesting doll 🪆
+------+------+------+------+------+------+
| 9 | octet count | item count |
+------+------+------+------+------+------+
+------+------/---+
repeated | element |
+------+------/---+
+-------+
|ENDLIST|
+-------+Sometimes you can't know how long a list is until you've already started sending its head 😭 For that situation there's a special ENDLIST element. A list of undetermined length gets sent with the octet count cleared to zero, and the item count cleared to zero too. A null or empty List, one with no elements, has an octet count of two (2) and an item count of zero (0). The ENDLIST element always follows a LIST, even when the length is already known. No skipping it, periodt 💅
Element code 10 (PROPLIST) is the Property List element 👑 It's a special case of the list element where the elements come in pairs, and the first element of each pair is a name. Here's the vibe:
+------+------+------+------+------+
| 10 | octet count | pair |
+------+------+------+------+------+
+------+------/---+------+------/---+
repeated | name element | value element |
+------+------/---+------+------/---+
+-------+
|ENDLIST|
+-------+The Property List is a set of unordered <name,value> pairs 🦋 Each pair has a name, which must be a NAME element, and a value, which can be any kind of element at all. After the type code comes a three-octet octet count of the octets that follow. After that is a one-octet pair count, which tells you how many <name,value> pairs are in the property list.
Every name in a <name,value> pair has to be unique within its property list. In other words, there shall be at most one occurrence of any particular name in one property list. No duplicate names allowed, bestie, that's a whole no-no 🙅♀️
Same deal as LIST for undetermined lengths 💜 A property list of undetermined length gets sent with the octet count cleared to zero, and the pair count cleared to zero. A null or empty property list, one with no elements, has an octet count of one (1) and a pair count of zero (0). The ENDLIST element always follows a property list, even when its length is already determined.
Element code 11 (ENDLIST) is the end of list element 🌸 It marks the end of the corresponding list or property list. Its whole job is to say "we're done here" 🫶
Structure Sharing
okay so picture this 🎀 When messages get batched together in message-bags for transmission, it's super common for the same document to go to more than one recipient. And since the document is usually the biggest part of the message, you'd end up sending a ton of repeated data if every recipient got their own copy in the message-bag. Not it 🙅♀️
So to avoid all that redundancy, messages can be put together in the message-bag so that the actual data shows up on its first occurrence, and later occurrences only have references to it 🧚 When data is shared, the first occurrence gets tagged, and any later spot where that data belongs just points back at the earlier tagged location. All references to copied data point to earlier locations in the message-bag. The data you want is found by its tag ✨
This is a very general sharing mechanism, but PLEASE NOTE THAT THE MPM WILL NOT SUPPORT THE FULL USE OF THIS MECHANISM. THE MPM WILL ONLY SUPPORT SHARING OF WHOLE DOCUMENTS. No other level of sharing will be supported by the MPMs. So the MPMs are really only doing whole-document sharing, bestie, don't get it twisted 🙈
Sharing can be used inside a document, as long as every reference points to a tag within that same document 💖
Here's how it works: you put a share-tag on the first occurrence of the data to be shared, and you put a share-reference at each location where copies of that data would have gone 🦋
+------+------+------+
12 Share Tag | 12 | share-index |
+------+------+------+
+------+------+------+
13 Share Reference | 13 | share-index |
+------+------+------+Element code 12 (S-TAG) is the share tag element 🌈 The two octets after the type-octet specify the shared data identification code for the data element that comes next. Note that s-tag is not a DATA element, because DATA elements encode higher level objects, and an s-tag isn't one of those 💅
Element code 13 (S-REF) is the share reference element 👑 The two octets after the type-octet specify the referenced shared data identification code. So it's the pointer, and the tag is the thing being pointed at 🫶
Here's an example of the mechanism. Say you have this structure, where we want to share <b>:
( ( <a>, <b> ) ( <c>, <b> ) )It can be coded like this instead:
( ( <a>, <s-tag-1><b> ) ( <c>, <s-ref-1> ) )To make it easier to work with structures that might contain shared data, the two high-order bits of the list and property list element codes are reserved 🧚 They tell you whether the structure contains data to be shared, or contains a reference to shared data. So if the high-order bit of the list or property list element code octet is set to one, then the property list contains a share-reference to shared data. And if the second high-order bit is set to one, the structure contains a share-tag for data to be shared. Bit tricks, but make it aesthetic 💜
Here's the same example again, this time showing exactly how those high-order bits get used:
+------+------+------+------+------+------+------+------+
|11 - 9|01 - 9| <a> | 12 | 0 | 1 | <b> | 11 |
+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+
|10 - 9| <c> | 13 | 0 | 1 | 11 | 11 |
+------+------+------+------+------+------+------+It's not considered an error for an element to be tagged but never referenced 🙌 Totally valid, just a little lonely 🥺
A substructure can have internal sharing too 🍓 If that substructure is closed with respect to sharing, meaning all references to its tagged elements are inside the substructure, then the knowledge of the sharing doesn't need to go up the hierarchy of lists. For example, if the substructure is:
00-LIST ( a b c b )then with sharing it becomes:
11-LIST ( a T1:b c R1 )When this substructure gets included in a bigger structure, the high order bits can be reset, because the substructure is closed with respect to sharing. For example:
00-LIST ( x 11-LIST ( a T1:b c R1 ) y )Note: While sharing saves transmission and memory, it's costly in processing to separate shared elements. That's the main reason the MPM restricts the sharing it supports. At some later time these restrictions may be eased 🔥
It is possible to create loops, "strange loops" and "tangled hierarchies" using this mechanism [32] 🌀 The MPM won't check for these improper structures within documents, and it won't deliver messages involved in such structures between documents. Chaotic energy, and not the good kind 💀
If an encryption scheme is used to keep communication private, it's unlikely that any parts of the message can be shared 🔐 That's because the encryption keys are usually specific to two individuals. There may be a few cases where encrypted data can be shared, though. For example, all the members of a committee might use a common key when acting on committee business. Or, in a public key scheme, a document may be "signed" using the sender's private key, and then anyone with the sender's public key can inspect it 🫶
4. OTHER ISSUES ✨
This section talks about a bunch of other issues that need to be dealt with in a computer message system 💻 Not the most glamorous bit, but you need it 💅
4.1. Accounting and Billing 💸
Okay bestie, let's talk money 💅 Accounting and billing has to be handled by the MPM. The charge the user gets from the delivery system needs to be predictable, so it can't depend on what sending one specific message actually cost, since that cost is all over the place with random delays, handling, and temporary storage charges 🙈 Instead, those costs get pooled and charged back to users on an average-cost basis. The user can be charged based on destination or distance, message length, type of service, or other parameters picked as the message goes into the delivery system, but it must not depend on the essentially random handling of that particular message. Not random billing, periodt ✨
This means it's pointless for each message to carry an accumulated charge (or a list of charges) 🙅♀️ The MPM just keeps a log of messages handled and periodically bills the people who originated them.
It seems the most reasonable scheme is to copy what the international telephone authorities do 📞 In those schemes, the authority where the message starts bills the user for the total charge. The authorities help each other out with international message transfer, and they periodically settle any differences in their accounts caused by uneven international traffic. It's giving teamwork 🫶
So the MPMs keep logs of the messages they handle and periodically charge their neighboring MPM for the messages they handled on that neighbor's behalf. This settlement procedure is outside the message system and happens between the administrators of the MPMs, so it's not something the message system itself does 💜
As traffic grows, logging every message individually gets impractical 😭 So the plan is to set up categories of messages (e.g., short, medium, large) and only count how many fall into each category. Iconic efficiency.
The MPM at the source of a message needs a local way to identify the user to charge for the delivery service. The relay and destination MPMs will know which neighbor MPMs to charge (or settle with) for delivering their messages 🎀
4.2. Addressing and Routing 🗺️
The mailbox can hold lots of different types of address information 🌸 The MPMs in the ARPA internet can use the internet address most effectively [2]. How to use the other address info isn't very clear yet, ngl. If you want some addressing brain food, check out the references [33,34,35] 📚
An MPM sometimes has to make a routing decision when it's acting as a relay-MPM (or a source MPM). It needs to be able to use the information from the mailbox to figure out which of its neighbor MPMs to send the message to. One way to do this is a table of destination networks, each paired with the neighbor MPM identifiers used to route toward that network 🧚
These routing tables aren't expected to be very dynamic 🦋 They'd only change when new MPMs come into existence or when MPMs go out of service for periods of days.
Even with routing information that changes slowly, the MPMs still need an automatic way to adjust their routing tables. This routing problem is pretty similar to routing in a network of packet switches, like the ARPANET IMPs or a set of internet gateways. A ton of work has been done on these problems, and many simple schemes have turned out to be faulty 💀 Some details of these procedures could get troublesome once the number of nodes grows past a certain point or the update exchanges happen really often.
A basic routing scheme is a table of <network-name, mpm-identifier> pairs. The MPM can look up the network name found in the mailbox of the message and figure out the internet mpm-identifier of the next MPM to route the message to. To allow automatic routing updates, another column gets added to show the distance to the destination. The distance could be measured in several ways, for example, the number of relay MPMs (or hops) to the final destination. So with that, each entry in the table becomes a triple of <network-name, mpm-identifier, distance> 👑
To update routing info when things change, an MPM updates its table. Then it sends each next MPM in its table a table of <network-name, distance> pairs, which basically say "I can get a message to each of these networks with "cost" distance." 📣 When an MPM gets one of these updates, it adds the distance to the MPM that sent the update (e.g., one hop) to all the distances, then compares that with its own table.
If the update shows that the distance to a destination network is now smaller via the MPM that sent it, the MPM changes its own table to reflect the better route and the new distance ✨ And if the MPM made any changes to its table, it sends update info to all the MPMs listed as next-MPMs in its table.
One more feature: when a new network comes into existence, an entry has to be added to the table in each MPM. So MPMs should expect that update info might include entries for new networks, and if that happens, they add those entries to their own tables 🌈
When a brand-new MPM comes into existence, it starts with an initial table saying it's a good route (short distance) to the network it's in, plus entries for a few neighbor networks. It sends an initial "update" to those neighbor MPMs, and they respond with more complete tables, which tell the new MPM about routes to lots of networks 🥹
This routing update mechanism is a pretty simple-minded scheme, and it may have to be replaced as the MPM system grows 🙈 It also ignores the chance for MPMs to use other information (besides the destination network name) for routing. MPMs might have tables that indicate next-MPMs based on city, telephone number, organization, or other categories of information 💅
4.3. Encryption 🔐
It's totally straightforward to add the ability to have the document portion of messages wholly or partially encrypted 🫧 An additional basic data element is defined to carry the encrypted data. The data inside this element can be made up of other elements, but that can only be seen after the data is decrypted.
+------+------+------+------+
14 Encrypt | 14 | octet count |
+------+------+------+------+
+------+------+------+-------
|alg id| key id | Data ...
+------+------+------+--------Element code 14 (ENCRYPT) is used to wrap up encrypted data 🎁 The format is a one-octet type code, a three-octet octet count, a one-octet algorithm identifier, a two-octet key identifier, and then count octets of data. Using this element means the data inside it is encrypted. The encryption scheme is shown by the algorithm identifier, and the key that was used is shown by the key identifier (this is not the key itself, so don't panic 😭). The NBS Data Encryption Standard (DES) [36], public key encryption [37,38,39], or other schemes may be used.
To process this data element, the user is asked for the right key, and then the data can be decrypted 🔑 The data revealed this way will be in the form of complete data element fields. Encryption can't happen over a partial field, so that's a no-go. Once revealed, the data gets processed normally.
Also, there's no reason all the fields of a document couldn't be encrypted, including all the document header info like From, Date, etc. Full encryption mode, activated 🔥
5. THE MPM: A POSSIBLE ARCHITECTURE 🏛️✨
The heart of the internet message system is the MPM, which is responsible for routing and delivering messages 💖 Each network must have at least one MPM. These MPMs are logically connected to each other, and internet mail is always transferred along logical channels between them. The MPMs interface with existing local message systems 🫶
Since a local message system can be very different from the internet system, special programs may be needed to convert incoming internet messages to the local format 🔄 Likewise, messages heading out to other networks may get converted to the internet format and sent via the MPMs.
5.1. Interfaces 🔌
User Interface
It's assumed that the interface between the MPM and the UIP passes data structures that represent the document portion of the message 📄 On top of that, this interface must also pass the delivery address info (which becomes the info in the mailbox field of the command). It's assumed the info gets passed between the UIP and the MPM through shared files, but that's not the only option. These two processes could be more strongly coupled (e.g., by sharing memory), or less strongly coupled (e.g., by communicating via logical channels) 🦋
When a UIP passes a document and a destination address to the MPM, the MPM assigns a transaction-number and forms a message to send 🧾 The MPM must record the relationship between the transaction-number, the document, and the UIP, so that it can tell the UIP about the outcome of the delivery attempt when the acknowledgment message comes in at some later time. Main character memory skills 🧠
If the UIP and MPM are communicating by file passing, sending and receiving mail might go like this:
- A user has an interactive session with a UIP to compose a document to send to a destination (or a list of destinations). When the user tells the UIP the document is ready to go, the UIP puts the info into a file for the MPM. Then the UIP can move on to the user's next request 💌
- The MPM finds the file and pulls out the info. It creates a message, assigns a transaction-number, and forms a deliver command. The MPM records the UIP associated with this message, then sends the message toward the destination 🚀
- When the MPM gets a deliver message from another MPM addressed to a user in its domain, it pulls out the document and puts it into a file for the UIP associated with the destination user. The MPM also sends an acknowledge message back to the originating MPM 💜
- When the MPM receives an acknowledgment for a message it sent, it creates a notification for the associated UIP and places it in a file for that UIP 🌸
The format of these files is up to each UIP/MPM interface pair 🎀 One reasonable choice is to use the same data structures used in the MPM-MPM communication.
Communication Interface
It's assumed here that the MPMs use an underlying communication system, and TCP [3] is the model 🧚 Specifically, the MPM is assumed to be listening for a TCP connection on a TCP port, which means it's a server process 🖥️ The port is either given explicitly in the mpm-identifier or takes the default value 45 (55 octal) [4]. Again, this isn't meant to limit implementation choices 🌈 Other forms of interprocess communication are allowed, and other types of physical interconnection are permitted too. You could even use dial telephone calls to connect MPMs (using suitable protocols to provide reliable communication) [12,19,20,21] 📞✨
5.2. The MPM Organization 💌
Okay bestie, let's talk about how the MPM is actually organized 🫶 Messages in the internet mail system travel in lists called message-bags (or just bags), and every bag holds one or more messages. Each MPM is expected to be able to deliver the local messages it gets, and to forward the non-local ones to other MPMs that are presumably closer to where the message is headed ✨
Loosely speaking, each MPM splits into six components, and they're giving very clean separation of duties 💅
1--Acceptor
Receives incoming message-bags from other MPMs, from UIPs, or from conversion programs.
2--Message-Bag Processor
Splits a bag into these three portions:
a. Local Host Messages b. Local Net Messages c. Foreign Net Messages
3--Local Host Delivery
Delivers local host messages, and may call on a conversion program.
4--Local Net Delivery
Delivers local net messages, and may call on a conversion program.
5--Foreign Net Router
Forms message-bags for transmission to other MPMs and determines the first step in the route.
6--Foreign Net Sender
Activates transmission channels to other MPMs and sends message-bags to foreign MPMs.
If the local net message system uses the protocol of the MPMs, then there need be no distinction between local net and foreign net delivery procedures. That's a lowkey relief 🌸
All of these components can be thought of as independent 🦋 The Acceptor's whole job is to wait for incoming message-bags and insert them into the Bag-Input Queue.
The Bag-Input queue gets read by the message-bag Processor, which separates suitable portions of the bags it pulls from the queue and delivers them to one of three queues:
a. Local Host Queue b. Local Net Queue c. Foreign Net Queue
When an MPM has a message to send to another MPM, it must add its own handling-stamp to the trace field of the command. The trace then becomes a record of the route the message has taken 🗺️ An MPM should examine the trace field to see if the message is in a routing loop. All commands require the return of the trace as a trail in the matching reply command 🧚
All of these queues hold complete message-bags, made by selecting messages from the input message-bags 🍓
The Local Host queue is the input to the Local Host Delivery process. This component is responsible for delivering messages to its local host. It may call on a conversion program to reformat the messages into a form the local protocol will accept. This will probably involve things like copying shared information 💖
The Local Net queue is the input to the Local Net Delivery process. This component is responsible for delivering messages to other hosts on its local net. It must be capable of handling whatever error conditions the local net might return, and should include the ability to retransmit. It may call on a conversion program to reformat the messages into a form the local protocol will accept. This will probably involve things like copying shared information 🔥
The other two processes are more closely coupled 👯 The Foreign Net Router takes its input bags from the Foreign Net Queue. From the internal information it contains, it determines which of the MPMs it is connected to should receive the bag.
It then places the bag, along with the routing information, into the Send Mail Queue. The Foreign Net Sender retrieves it from that queue and transmits it across a channel to the intended foreign MPM. The Sender aggregates messages going to the same next MPM into a bag 📦
The Foreign Net Router should be capable of receiving external input to its routing information table. This may come from the Foreign Net Sender if a channel goes down, which means a decision is needed: either postpone delivery or work out a new route. The Router is responsible for maintaining enough information to determine where to send any incoming message-bag 👑
Forwarding
An MPM may have information about the correct mailboxes of users who aren't at its location 🌈 This information, called a forwarding data base, may be used to return the correct address in response to a probe command, or to actually forward a deliver command (if the type of service allows it).
Here's the tea: forwarding can make a message's route pass through an MPM that's already on the trace of that message. So only the portion of the trace back to the most recent forward action should be used for loop detection by a relay relaying MPM, and only the forward action entries in the trace should be checked by a forwarding MPM 🙈
Implementation Recommendations
Transaction numbers can be assigned sequentially, wrapping around when the highest value is reached. This should ensure that no message with a particular transaction number from this source is in the network when another instance of this transaction number is chosen 🎀
Separating shared elements when the routes of those elements diverge, while still preserving as much sharing as possible, appears to be an O(N*M**2) operation, where N is the number of distinct objects in a message which may be shared across message boundaries and M is the number of messages in the bag. Lowkey a lot of math, but it's giving real computer science 🤓
Also note that share-tags may be copied into separate message bags which aren't referenced. These could be removed with another pass over the message bag 🧹
6. EXAMPLES & SCENARIOS 🎬
Example 1: Message Format
Suppose we want to send the following message. Iconic 💅
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIE>
Subject: Meeting Thursday
To: Danny Cohen <Cohen@USC-ISIB>
CC: Linda
Danny:
Please mark your calendar for our meeting Thursday at 3 pm.
--jon.It will be encoded in the structured format. The following shows successive steps in the top-down generation of this message. The actual document above won't be shown in the coded form 🧚
1. message
2. (identification, command, document)
3. (ID:(mpm-identifier, transaction-number),
CMD:(MAILBOX:mailbox, OPERATION:operation,
arguments, TRACE:trace),
DOC:<<document>>)
4. (ID:(mpm-identifier, transaction-number),
CMD:(MAILBOX:mailbox, OPERATION:operation,
TYPE-OF-SERVICE:regular, TRACE:trace),
DOC:<<document>>)
5. (ID:(MPM:(IA:12,1,0,52,0,45), TRANSACTION:37),
CMD:(MAILBOX:(MPM:(IA:12,3,0,52,0,45),
NET:ARPA,
HOST:ISIB,
PORT:45,
USER:Cohen),
OPERATION:DELIVER,
TYPE-OF-SERVICE:REGULAR,
TRACE:(MPM:(IA:12,1,0,52,0,45)
DATE:1979-03-29-11:46-08:00,
ACTION:ORIGIN)),
DOC:<<document>>)
6. PROPLIST:(
ID:PROPLIST:(
MPM:PROPLIST:(
IA:12,1,0,52,0,45),
ENDLIST
TRANSACTION:37)
ENDLIST,
CMD:PROPLIST(
MAILBOX:(PROPLIST:(
MPM:PROPLIST(
IA:12,3,0,52,0,45),
ENDLIST
NET:ARPA,
HOST:ISIB,
PORT:45,
USER:Cohen ),
ENDLIST
OPERATION:DELIVER,
TYPE-OF-SERVICE:REGULAR,
TRACE:(PROPLIST:MPM:
(PROPLIST:
IA:12,1,0,52,0,45)
ENDLIST
DATE:1979-03-29-11:46-08:00,
ACTION:ORIGIN)),
ENDLIST
ENDLIST
DOC:<<document>>)
ENDLIST7. SPECIFICATION SUMMARY 💅
7.1. Message Fields 🎀
okay so bestie, this is the cheat sheet 🫶 every keyword in this protocol gets recognized no matter what case you type it in, so "ORIGIN" and "origin" are the same vibe 💖
All keywords used in this protocol are to be recognized independent of
case.
action: NAME (one of)
"ORIGIN" | "RELAY" | "FORWARD" | "DESTINATION"
address: PROPLIST (one of)
NAME: "MPM", <mpm-identifier>
NAME: "USER", <user>
or
NAME: "NET", <net>
NAME: "HOST", <host>
NAME: "PORT", <port>
NAME: "USER", <user>
answer: BOOLEAN
city: NAME
command: PROPLIST
NAME: "MAILBOX", <mailbox>
NAME: "OPERATION", <operation>
<<arguments>>
NAME: "ERROR-CLASS", <error-class> (only in replies)
NAME: "ERROR-STRING", <error-string> (only in replies)
NAME: "TRACE", <trace>
country: NAME
document: <<document>>
error-class: INDEX
error-string: NAME
host: NAME
handling-stamp: PROPLIST
NAME: "MPM", <mpm-identifier>
NAME: "DATE", <date>
NAME: "ACTION", <action>
identification: LIST
NAME: "MPM", <mpm-identifier>
NAME: "TRANSACTION", <transaction-number>
internet-address: NAME
mailbox: PROPLIST (some of)
NAME: "MPM", <mpm-identifier>
NAME: "NET", <net>
NAME: "HOST", <host>
NAME: "PORT", <port>
NAME: "USER", <user>
NAME: "ORG", <organization>
NAME: "CITY", <city>
NAME: "STATE", <state>
NAME: "COUNTRY", <country>
NAME: "ZIP", <zip-code>
NAME: "PHONE", <phone-number>
<<other-items>>
message: PROPLIST
NAME: "ID", <identification>
NAME: "CMD", <command>
NAME: "DOC", <document> (only in deliver)
mpm-identifier: PROPLIST (one of)
NAME: "IA", <internet-address>
or
NAME: "X121", <x121-address>
net: NAME
operation: NAME (one of)
"DELIVER" | "ACKNOWLEDGE
| "PROBE" | "RESPONSE
| "CANCEL" | "CANCELED"
organization: NAME
phone-number: NAME
port: NAME
state: NAME
trace: LIST
<handling-stamp>
...
trail: LIST
<handling-stamp>
...
transaction-number: INTEGER
type-of-service: NAME (one or more of)
"REGULAR" | "FORWARD" | "GENDEL" | "PRIORITY"
user: NAME
x121-address: NAME
zip-code: NAME7.2. Deliver Message ✨
okay bestie, this one is the Deliver Message layout 💌 here's the whole thing, copied exactly:
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"DELIVER"
NAME:"TYPE-OF-SERVICE", NAME:<type-of-service>
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
NAME:"DOC", <<document>>
ENDLIST7.3. Acknowledge Message 🦋
this one's the Acknowledge Message, and it's giving tidy ✨
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:"*MPM*"
NAME:"NET", NAME:<net>
NAME:"PORT", NAME:<port>
NAME:"HOST", NAME:<host>
ENDLIST
NAME:"OPERATION", NAME:"ACKNOWLEDGE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"TYPE-OF-SERVICE", NAME:<type-of-service>
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST7.4. Probe Message 🔍
next up is the Probe Message, bestie 💜
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"PROBE"
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST7.5. Response Message 💅
the Response Message is up now, and the layout is giving main character energy 👑
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"RESPONSE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST7.6. Cancel Message 🚫
the Cancel Message is next, and I'm not gonna lie, it's lowkey a lot 💀
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"CANCEL"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST7.7. Canceled Message 🥀
and then there's the Canceled Message, which is the other side of that drama 🙈
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"CANCELED"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST7.8. Data Element Summary 🧚
last but not least, the Data Element Summary table, which is literally the cheat sheet for every code and its length 📋✨
CODE NAME STRUCTURE LENGTH
---- ---- --------- ------
0 NOP CODE(1) 1
1 PAD CODE(1),COUNT(3),DATA(C) C+4
2 BOOLEAN CODE(1),TRUE-FALSE(1) 2
3 INDEX CODE(1),INDEX(2) 3
4 INTEGER CODE(1),INTEGER(4) 5
5 EPI CODE(1),COUNT(3),INTEGER(C) C+4
6 BITSTR CODE(1),COUNT(3),BITS(C/8) C/8+4
7 NAME CODE(1),COUNT(1),NAME(C) C+2
8 TEXT CODE(1),COUNT(3),TEXT(C) C+4
9 LIST CODE(1),COUNT(3),ITEMS(2),DATA(C-2) C+4
10 PROPLIST CODE(1),COUNT(3),PAIRS(1),DATA(C-1) C+4
11 ENDLIST CODE(1) 1
12 S-TAG CODE(1),INDEX(2) 3
13 S-REF CODE(1),INDEX(2) 3
14 ENCRYPT CODE(1),COUNT(3),ALG-ID(1),
KEY-ID(2),DATA(C-3) C+4
The numbers in parentheses are the number of octets in the field.REFERENCES 📚✨
okay bestie, this is the reading list 🧚 every source the spec leans on, lowkey the bibliography that built the whole internet 💅
[1] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
[2] Postel, J., "DOD Standard Internet Protocol," USC/Information Sciences Institute, IEN 128, NTIS number AD A079730, January 1980.
[3] Postel, J., "DOD Standard Transmission Control Protocol," USC/Information Sciences Institute, IEN 129, NTIS number AD A082609, January 1980.
[4] Postel, J., "Assigned Numbers," RFC 762, USC/Information Sciences Institute, January 1980.
[5] Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook," NIC 7104, for the Defense Communications Agency by the Network Information Center of SRI International, Menlo Park, California, Revised January 1978.
[6] Neigus, N., "File Transfer Protocol for the ARPA Network," RFC 542, NIC 17759, SRI International, August 1973.
[7] Bhushan, A., K. Progran, R. Tomlinson, and J. White, "Standardizing Network Mail Headers," RFC 561, NIC 18516, September 1973.
[8] Myer, T., and D. Henderson, "Message Transmission Protocol," RFC 680, NIC 32116, 30 April 1975.
[9] Crocker, D., J. Vittal, K. Progran, and D. Henderson, "Standard for the Format of ARPA Network Text Messages," RFC 733, NIC 41952, 21 November 1977.
[10] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192, February 1979.
[11] Braaten, O., "Introduction to a Mail Protocol," Norwegian Computing Center, INWG 180, August 1978.
[12] Crocker, D., E. Szurkowski, and D. Farber, "An Internetwork Memo Distribution Capability - MMDF," Sixth Data Communications Symposium, ACM/IEEE, November 1979.
[13] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed Specification of an Inter-site Message Protocol," 8 July 1975.
[14] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW Working Note 24, Bolt Beranek and Newman, October 1978.
[15] White, J., "A Proposed Mail Protocol," RFC 524, NIC 17140, SRI International, 13 June 1973.
[16] White, J., "Description of a Multi-Host Journal," NIC 23144, SRI International, 30 May 1974.
[17] White, J., "Journal Subscription Service," NIC 23143, SRI International, 28 May 1974.
[18] Levin, R., and M. Schroeder, "Transport of Electronic Messages Through a Network," Teleinformatics 79, Boutmy & Danthine (eds.) North Holland Publishing Co., 1979.
[19] Earnest, L., and J. McCarthy, "DIALNET: A Computer Communications Study," Computer Science Department, Stanford University, August 1978.
[20] Crispin M., "DIALNET: A Telephone Network Data Communications Protocol," DECUS Proceedings, Fall 1979.
[21] Caulkins, D., "The Personal Computer Network (PCNET) Project: A Status Report," Dr. Dobbs Journal of Computer Calisthenics and Orthodontia, v.5, n.6, June 1980.
[22] Postel, J., "NSW Transaction Protocol (NSWTP)," USC/Information Sciences Institute, IEN 38, May 1978.
[23] Haverty, J., "MSDTP -- Message Services Data Transmission Protocol," RFC 713, NIC 34739, April 1976.
[24] Haverty, J., "Thoughts on Interactions in Distributed Services," RFC 722, NIC 36806, 16 September 1976.
[25] Postel, J., "A Structured Format for Transmission of Multi-Media Documents," RFC 767, USC/Information Sciences Institute, August 1980.
[26] ISO-2014, "Writing of calendar dates in all-numeric form," Recommendation 2014, International Organization for Standardization, 1975.
[27] ISO-3307, "Information Interchange -- Representations of time of the day," Recommendation 3307, International Organization for Standardization, 1975.
[28] ISO-4031, "Information Interchange -- Representation of local time differentials," Recommendation 4031, International Organization for Standardization, 1978.
[29] CCITT-X.121, "International Numbering Plan for Public Data Networks," Recommendation X.121, CCITT, Geneva, 1978.
[30] Postel, J., "NSW Data Representation (NSWB8)," USC/Information Sciences Institute, IEN 39, May 1978.
[31] Cohen, D., "On Holy Wars and a Plea for Peace," IEN 137, USC/Information Sciences Institute, 1 April 1980.
[32] Hofstadter, D., "Godel, Escher, Bach: An Eternal Golden Braid," Basic Books, New York, 1979..
[33] Harrenstien, K., "Field Addressing," ARPANET Message, SRI International, October 1977.
[34] Postel, J., "Out-of-Net Host Address for Mail," RFC 754, USC/Information Sciences Institute, April 1979.
[35] Shoch, J., "On Inter-Network Naming, Addressing, and Routing," IEEE Computer Society, COMPCON, Fall 1978.
[36] National Bureau of Standards, "Data Encryption Standard," Federal Information Processing Standards Publication 46, January 1977.
[37] Diffie, W., and M. Hellman, "New Directions in Cryptology," IEEE Transactions on Information Theory, IT-22, 6, November 1976.
[38] Rivest, R., A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" Communications of the ACM, Vol. 21, Number 2, February 1978.
[39] Merkle, R., and M. Hellman, "Hiding Information and Signatures in Trapdoor Knapsacks," IEEE Transactions of Information Theory, IT-24,5, September 1978.
📦 where this page comes from
- ietf: rfc759 1980-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms