RFC 753
Internet Message Protocol
INTERNET MESSAGE PROTOCOL 💌
okay bestie, this is RFC 753 🎀 It's the IEN 85 / RFC 753 doc, dated March 1979, and it's by Jonathan B. Postel at the Information Sciences Institute (ISI) at the University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291, (213) 822-1511. It's the first edition of this spec, and the author literally asks people to send comments, advice, and suggestions 🫶 It's a proposal, not a finished standard, so the vibe is "help me make this better, babe." The title page doesn't list anything it obsoletes or updates, so there's nothing to tag there ✨
The original's document stamp, for the record:
< INC-PROJECT, MAIL-MAR-79.NLS.38, >, 31-Mar-79 19:50 JBP ;;;;Here's the table of contents, verbatim because the numbers matter 📋
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1. Motivation ................................................... 1
1.2. Scope ........................................................ 1
1.3. The Internetwork Environment ................................. 2
1.4. Operation .................................................... 2
1.5. Interfaces ................................................... 3
2. FUNCTIONAL DESCRIPTION ........................................... 5
2.1. Relation to Other Protocols .................................. 5
2.2. Terminology ................................................. 5
2.3. Assumptions .................................................. 6
2.4. General Specification ........................................ 7
2.5. Mechanisms .................................................. 11
3. DETAILED SPECIFICATION .......................................... 13
3.1. Overview of Message Structure ............................... 13
3.2. Data Elements ............................................... 13
3.3. Message Objects ............................................. 16
3.4. Command ..................................................... 23
3.5. Document .................................................... 31
3.6. Message Structure ........................................... 33
3.7. MPM Organization ............................................ 36
3.8. Interfaces .................................................. 39
4. EXAMPLES & SCENARIOS ............................................ 41
Example 1: Message Format ........................................ 41
Example 2: Delivery and Acknowledgment ........................... 43
GLOSSARY ............................................................ 49
REFERENCES .......................................................... 51
APPENDICES .......................................................... 53PREFACE 🌸
this is the first edition, so treat it as a request for comments, advice, and suggestions 💜 The author says a ton of earlier work exists on computer-aided message systems, and some of it is listed in the reference section. The spec was shaped by lots of conversations with folks in the ARPA research community and others who care about computer-aided message systems. It was written as part of the ARPA-sponsored Internetwork Concepts Research Project at ISI, with help from Greg Finn, Alan Katz, Paul Mockapetris, and Mamie Chew. Hugs to all of them 🫶
Signed: Jon Postel (USC-ISI, March 1979)
1. INTRODUCTION ✨
okay so this doc describes an internetwork message system 📨 It's built to move messages between message processing modules, following the formats and procedures in this spec. The message processing modules are processes running in host computers. They live in different networks, and together they make up one internetwork message delivery system. Main character energy 👑
The doc is meant to have everything you need to build a compatible, cooperating module for this system. Literally everything 💅
1.1. Motivation
as computer-supported message processing grows on single hosts and across networks of computers, people naturally want these systems to connect and work together 🦋 This spec defines the formats and procedures for a general-purpose internetwork message system. It can be a standard for hooking individual message systems together, or it can be a message system all on its own.
It also goes beyond what regular message systems handle. Messages can carry typed segments, like drawings, facsimile images, or digitized speech 🎧 Picture message stations with speakers and microphones (or telephone handsets), where the body of a message, or part of it, is recorded digitized speech. The output terminal could have a graphics display, and the message could draw something on it while the speaker describes the features out loud. So the spec gives you basic data elements for sending structured binary data, plus text 🌈
1.2. Scope
The Internet Message Protocol is meant for sending messages between networks 🌐 It can also be used for the local message system of a network or host. The spec was developed for the ARPA work on interconnecting networks, but the author expects it to have a broader scope too 🦋
The focus is on the internal mechanisms for moving messages, not the external interface users see 💅 The assumption is that a bunch of user interface programs will exist. Some will be brand-new programs built for this system, and some will be older programs built for earlier systems.
1.3. The Internetwork Environment
here's the setup 🧚 The internetwork message environment is made of processes running in hosts. Those hosts are connected to networks, and those networks are linked together by gateways. Each network has lots of different hosts. Gateways are basically hosts sitting on two (or more) networks. They aren't assumed to have much storage, and they don't "know" which hosts are on the networks they're attached to [5] 💀 Gateways are doing a lot with very little, honestly iconic.
1.4. Operation
the way this works is that the protocol runs inside a process, and that process is called a Message Processing Module, or MPM 🎀 MPMs trade messages by setting up full duplex communication and sending messages in a fixed format described in this document. An MPM can also share other information through the commands described here 💬
A user writes a message through a User Interface Program, or UIP ✍️ The user can run several commands to build different fields of the message, and can call an editor to fix up or format some or all of it. Once they're happy, they "send" it by putting it in a data structure that's shared with the MPM 📤
The MPM finds unprocessed input data, either because it was specifically asked to or through a general background search 🔍 It looks at the data, and it uses routing tables to figure out which outgoing link to take. The destination can be one of three things: another user on this same host, a user on another host in the same network, or a user in another network. Each case goes a little differently:
- Another user on this host. The MPM puts the message in a data structure shared with the destination user, and that user's UIP looks there for incoming messages 📬
- A user on another host in this network. The MPM sends the message to the MPM on that host. That MPM repeats the routing decision, sees that the destination is local to it, and puts the message in the data structure shared with the destination user 🏠
- A user on a host in another network. The MPM sends the message to an MPM in that network if it knows how to connect to it directly. Otherwise, it sends the message to an MPM that's "closer" to the destination 🛣️ An MPM might not know about direct connections to MPMs in every other network, but it must be able to pick a next MPM for every possible destination network. (See, lowercase "must" here, the spec's own wording 🤓)
An MPM might know how to connect directly to a few MPMs in nearby networks, and it can send everything else to a particular "big brother" MPM with a wider view of the internet environment 🧠
A single network's message system might be really different from the internet message system 😬 In that case, messages within the network get delivered using that network's own message system. If a message is addressed outside the network, it goes to an MPM, which sends it out through the right gateways using internet procedures and format, to (or toward) the MPM in the destination network. Eventually the message reaches an MPM on the recipient's network, and the local message system carries it to that host 💌
When local message protocols are involved, special conversion programs are needed to change local messages into internet format on the way out, and to change internet messages into local format on the way in 🔄 Those conversions can lose information 😭 The internet message format tries to include features that capture everything any local message system might use. But a particular local system probably won't have features matching all of the internet message system's features. So converting an internet message to a local one sometimes means throwing some information away. For example, if an internet message has mixed text and speech in the body, and it's going to a local system that only handles text, the speech might get swapped out for the text string "There was some speech here" 🎙️ Discarding info should be avoided whenever possible, and put off for as long as possible. Still, there may be cases where it's the only reasonable thing to do 💔
1.5. Interfaces
the MPM depends on a reliable communication procedure to talk to other MPMs 🤝 This is a Transport Level protocol, like TCP [20]. The interface to a procedure like that normally gives you calls to open and close connections, to send and receive data on a connection, and a way to signal and get notified about special conditions (interrupts, i.e., the ones you'd expect) ⚡
The MPM takes in input and produces output through data structures. Those structures are produced and consumed by user interface programs (or other programs) 🫧
2. FUNCTIONAL DESCRIPTION 🦋
ohhh we're at the next big section, and the rest of it comes in the next part 💜
2.1. Terminology ✨
okay so bestie, the basic unit that gets sent between networks is called a message 💌. A message has three parts: a transaction identifier (a number that uniquely identifies the message 🔢), a command list (all the info needed to deliver it 🚚), and the document list. The document list is a header plus a body, and the body holds the actual data 💖.
think of a personal letter 💌. The document body is the contents of the letter, and the document header is the address and return address on the envelope.
an inter-office memo works the same way 🗂️. The document body is the text, and the document header is the memo's header block.
the commands are like what the Post Office or the mail room uses to route your letter or memo 📮. they're the stuff that gets it where it's going.
messages get routed by a process called the message processing module, or MPM 🛣️. messages get created and consumed by User Interface Programs (UIPs), working together with users 🫶.
wanna see a fuller list of terms? check the Glossary section 📚.
2.2. Assumptions 🧠
these are the assumptions made about the internetwork environment 🌐:
it's generally not known what format intranet addresses will take 🤷♀️. 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 had to know about the formats on many networks, you'd need constant software updates across all internet MPMs 😭. so each MPM that handles internet messages only needs to know the minimum necessary to deliver them 📦.
each MPM has to know completely only the addressing format of its own network 🏠. on top of that, the MPM must be able to pick an output link for every message addressed to another network or host 🛤️. an MPM is totally allowed to be smarter than this 🧠✨, but this bare minimum is still necessary 💅.
every network has a unique name and number 🏷️.
each MPM gets its own unique internet address 🪪. this lets every MPM stamp a unique "handling-stamp" on any message that passes through it on the way to delivery 🖋️. main character energy for every single hop 💜.
2.3. General Specification 🎀
there are a few parts to a distributed service that needs specifying 🧩. first is the service being provided, meaning what it looks like to its users 👀. second is the service it uses, meaning the stuff it assumes some lower-level service is already providing 🧱. third is the protocol the modules of the distributed service use to talk to each other 🗣️.
User User
\ /
\ /
\ /
--+----------------------------------------+-- Service
! \ / ! Interface
! +--------+ +--------+ !
! ! Module ! <--Protocol--> ! Module ! !
! +--------+ +--------+ !
! \ / !
! +-----------------------+ !
! ! Communication Service ! !
! +-----------------------+ !
! !
+----------------------------------------+
Message Service
Figure 1.The User/Message Service Interface 💌
the message delivery system's service is to accept messages in a specified format 📨, try to deliver them 🚀, and report back on whether the delivery attempt worked or failed ✅❌. this all happens inside an interconnected system of networks 🕸️, and it might mean relaying a message through several intermediate MPMs, each using a different communication service 🔁.
The Message/Communication Service Interface 📡
the message delivery system calls on a communication service to move info from one MPM to another 🚚. different pairs of MPMs can use different communication services 🔀, but every communication service has to meet the following service characteristics 📋.
it's assumed the communication service gives you a reliable two-way data stream 🪢. you can usually get that in computer networks from a transport-level protocol, like the Transmission Control Protocol (TCP) [20] 🔐. either way, the properties the communication service has to provide are:
- Logical connections for two-way simultaneous data flow of arbitrary data (i.e., no forbidden codes) 🌊. data arrives in the order it was sent, with no gaps 🧩.
- Simple commands to open and close the connections, and to send and receive data on them 🔓.
- A way to signal and be notified "out-of-band" (like TCP's urgent flag 🚨) so some messages can be labeled "more important" than others 💅.
- Controlled flow of data, so data isn't sent faster than the receiver chooses to consume it (on average) 🚦.
- Transmission errors get corrected without the user being notified or involved 🙌. only a complete breakdown in communication gets reported to the user 💀.
The Message-Message Protocol 🗣️
the protocol between the distributed modules of the message delivery system (aka the MPMs) is a small set of commands that carry requests and replies 📬. these commands are encoded in a highly structured, rigidly specified format 🧾. very organized, very iconic 👑.
2.4. Mechanisms ⚙️
MPMs are processes that use some communication service 🖥️. a pair of MPMs that can communicate lives in a common interprocess communication environment 🏘️. one MPM can exist in two (or more) interprocess communication environments 🌈, and that kind of MPM might act to relay messages between MPMs in those environments 🔁.
User User
\ /
\ /
\ /
+---------------------------------------------------------+
! \ / !
! +-----+ +-----+ +-----+ !
! ! MPM ! <--Protocol--> ! MPM ! <--Protocol--> ! MPM ! !
! +-----+ +-----+ +-----+ !
! ! / \ ! !
! +-----------------------+ +-----------------------+ !
! !Communication Service A! !Communication Service B! !
! +-----------------------+ +-----------------------+ !
! !
+---------------------------------------------------------+
Message Service with Internal Relaying
Figure 2.the transfer of data between UIPs and MPMs is thought of as trading data structures that encode messages 🎁. the transfer of data between MPMs also happens as transmitted structured data 📦.
+-----+ DATA +-----+
USER-->! UIP !-->STRUCTURES-->! MPM !-->other
+-----+ +-----+ +-----+ MPMs
! !
! +-----+
+--! !
! +-----+
+--! !
! !
+-----+
+-----+ DATA +-----+
other-->! MPM !-->STRUCTURES-->! UIP !-->USER
MPMs +-----+ +-----+ +-----+
! !
! +-----+
+--! !
! +-----+
+--! !
! !
+-----+
Message Flow
Figure 3.from here on, a message is described as a structured data object, represented using a particular kind of typed data element 🧸. this is 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 any convenient way 🛠️. as the figure below shows, when a message is ready to go, it moves from the processing routines into typed data elements, then into a data compression routine, and finally gets transmitted 🚀. on the receiving side, the message gets decompressed first, then decoded from the data element representation into the local representation the processing routines use 🔄.
+------------------------------------------------+
! !
! processing DATA DATA !
! routines ---> ENCODER ---> COMPRESSOR ---> !
! !
+------------------------------------------------+
Send MPM
+------------------------------------------------+
! !
! DATA DATA processing !
! ---> DECOMPRESSOR ---> DECODER ---> routines !
! !
+------------------------------------------------+
Receive MPM
Detailed View
Figure 4.2.5. Relation to Other Protocols 🧚
here's a diagram showing where the message protocol sits in the protocol hierarchy 🪜:
+------+ +-----+ +-------+ +-----+ +-----+
!Telnet! ! FTP ! !Message! !Voice! ... ! ! Application Level
+------+ +-----+ +-------+ +-----+ +-----+
\ ! / ! !
+-----+ +-----+ +-----+
! TCP ! ! RTP ! ... ! ! Host Level
+-----+ +-----+ +-----+
! ! !
+-------------------------------+
! Internet Protocol ! Gateway Level
+-------------------------------+
!
+---------------------------+
! Local Network Protocol ! Network Level
+---------------------------+
!
Protocol Relationships
Figure 5.the message protocol talks on one side to user interface programs 🖥️, and on the other side to a reliable transport protocol like TCP 🔐. bestie, it's literally sandwiched in the middle 🥪✨.
3. DETAILED SPECIFICATION 💅
the info in this section is tricky to present 😵💫, because everything depends on everything 🔁, and since a document is linear, it has to come out in some order 📜. so here's the plan: a super-brief overview of the message structure first 👀, then a radical switch to defining the basic building blocks 🧱, and finally using those building blocks to get back to the overall structure 🏁.
3.1. Overview of Message Structure
okay so bestie, a message is basically three big chunks: the identification, the command, and the document. Each chunk is built out of message objects 💅
The identification part is a transaction number picked by the originating MPM, plus the internet host number of that same MPM 🎀
The command part is the main character 👑 and it holds an operation type, an operation code, an argument list, an error list, the destination mailbox, and a stamp. The stamp is a list of the MPMs that have handled this message 🦋
The document part is a header plus a body. The message delivery system doesn't care what's inside the document part 🙈, but this spec does have some recommendations for the document header 💖
The next sections define a message as a structured object made of other objects, and those objects are represented with a set of basic data elements ✨
3.2. Data Elements
the data elements here are giving NSW [18] vibes, since they use a similar data structure and encoding 🧚
Each diagram below shows a sequence of octets. Field boundaries are marked with "!", octet boundaries with "+", and everything reads left to right. Every element starts with a one octet code 🍓
Code Type Representation
---- ---- --------------
+------+
0 No Operation ! 1 !
+------+
+------+------+------+------+------
1 Padding ! 0 ! octet count ! Data ...
+------+------+------+------+------
+------+------+
2 Boolean ! 2 ! 1/0 !
+------+------+
+------+------+------+
3 Index ! 3 ! Data !
+------+------+------+
+------+------+------+------+------+
4 Integer ! 4 ! Data !
+------+------+------+------+------+
+------+------+------+------+------
5 Bit String ! 5 ! bit count ! Data ...
+------+------+------+------+------
+------+------+------+------+------
6 Text String ! 6 ! octet count ! Data ...
+------+------+------+------+------
+------+------+------+------+------+------+-----
7 List ! 7 ! octet count ! item count ! Data
+------+------+------+------+------+------+-----
+------+------+------+------+------
8 Proplist ! 8 ! octet count ! Data ...
+------+------+------+------+------Here's the element lineup, and yes, every one of them has its own personality 🌈
- Element code 0 (NOP) is an empty data element used for padding when it's needed. It gets ignored, so it's basically a little nothing burger 🫧
- Element code 1 (PAD) is for sending large amounts of data along with a message, for testing or padding. Nothing is done with this data, but the count of dummy octets has to be exactly right so the next element code shows up where it should 😭
- Element code 2 (BOOLEAN) is a boolean where 1 means True and 0 means False. Iconic, simple, no drama ✅
- Element code 3 (INDEX) is a 16-bit unsigned integer. It takes up only 3 octets, which is so efficient 🦋
- Element code 4 (INTEGER) is a signed 32-bit integer and it always takes up five octets. The representation is two's complement 🔥
- Element code 5 (BITSTR) is a bit string 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. This type has to put its bit count in the two octet count field, not a count of octets. Main character behavior 💅
- Element code 6 (TEXT) is for text. It uses seven bit ASCII characters, right justified in the octet, and the high order bit of the octet is zero 🎀
- Element code 7 (LIST) lets you build structures out of other elements. The item count tells you how many elements follow, and any element can go in there, including another List 🌸 The octet count is how many octets the whole list takes up. A null or empty List, one with no elements, has an item count of zero (0) 🫶
- Element code 8 (PROPLIST) is the Property-List element, and it looks like this:
+------+------+------+------+------+
! 8 ! octet ! pair !
! ! count ! count!
+------+------+------+------+------+
+------+------+------+---------+---------+
! name ! value ! name ! value !
repeated ! count! count ! ...! ...!
+------+------+------+---------+---------+The Property-List is a set of unordered name/value pairs, and it's so cute 🧚 Each pair is a one octet name count and a two octet value count, followed by the name and value strings. The counts give the length in octets of those strings, and each string's length has to agree with its own count. The number of octets until the next pair in the property list is 1 + 2 + name count + value count. The whole Property-List is equal in length to the octet count of the element itself. Right after that octet count is a one octet pair count field, which holds the total number of name/value pairs in the Proplist 💖
3.3. Message Objects
okay so bestie, now we get to the message objects 🎀✨ these are the little building blocks we use to put messages together, things like an address or a date 💅 and they're all made out of the basic data elements from the last part, so it's like Lego but make it networking 🧚
one lowkey important detail: data elements are typed, but message objects are NOT typed 🙈 why? because messages are structured enough that only ONE kind of message object can ever show up in any given spot in a message structure. so no mix-ups, iykyk 💜
here's the list of some of the objects you'll see, grouped by the part of the message where they usually live 🌸
Identification
Internet Host Number (ihn)
this one identifies a host in the internetwork environment 🖥️ when it's part of a tid, it tells you the originating host of a message. the ihn 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. it's giving bit-level precision, obsessed 😭
INTEGERTransaction Identifier (tid)
this is the transaction identifier tied to a particular command 🦋 it's a list of the transaction number and the internet host number of the originating host.
LIST ( tn , ihn )Transaction Number (tn)
this is a number that's uniquely associated with this transaction by the originating host 🌈 it identifies the transaction. (a transaction is a message and acknowledgment, we'll get into that more in later sections ✨) and a tn MUST be unique for the time which the message (a request or reply) containing it could be active in the network. 💀 that MUST is serious, bestie, no skipping it 🫶
INDEXCommand
Address
this is very similar to Mailbox because it's also the "address" of a user 💌 but Address is meant to hold the MINIMUM info needed for delivery, and no more. just the essentials, no extra fluff 💅
PROPLIST ( --- )Answer
a yes (true) or no (false) answer to a question 🍓
BOOLEANArguments
this is the argument to many of the operations 🧚 it consists of a List of different data types. the List will have form and data relevant to the particular operation 🌸
LIST ( --- )Command-Type
gives the type of a command, like request, reply, or alarm 🔥
INDEXError-List
the error list holds information about an error that has occurred 💔 it's a List made of two objects: error-class and error-string 💜
LIST ( error class, error string )Error-Class
a code for the class of the error 🌸
INDEXError-String
a text string explaining the error ✨
TEXTHow-Delivered
a comment on how a message got delivered 🦋 like, a message could be delivered, forwarded, or turned over to general delivery 🚚
LIST ( TEXT )Mailbox
this is the "address" of a user of the internetwork mail system 📬 Mailbox holds stuff like net, host, location, and the local user-id of the recipient. some of that info might not even be needed for delivery, ngl 🙈
as an example, say someone sends a message to a person for the first time. they might include a bunch of things that aren't strictly needed just to make sure it gets delivered 💌 but once they get a reply, that reply can contain an Address (not a Mailbox) which the user will use from then on 💖 so Mailbox is the big extra-detailed version and Address is the streamlined one ✨
a mailbox is a PROPLIST 🎀 a mailbox might contain these name-value pairs:
name element description
---- ------- -----------
IA INTEGER internet address
NET TEXT network name
HOST TEXT host name
USER TEXT user name
CITY TEXT city
COUNTRY TEXT country
STATE TEXT state
ZIP TEXT zip code
PHONE TEXT phone numberPROPLIST ( --- )Operation
this names the operation or procedure to be performed 🎬
TEXTOptions
REGULAR for normal delivery, FORWARD for message forwarding, GENDEL for general delivery, or other options that may be defined later 🌈
LIST ( TEXT, ... )Reasons
these could be things like "mailbox does not exist" or "mailbox full", etc. 🙃
LIST ( TEXT )Stamp
each MPM that handles the message MUST add a unique identifier (an ihn, see above) to the list 🫶 this is what stops messages from getting bounced back and forth through the internet mail system forever. they'll eventually either get delivered or sent back to the sender, no endless loops, periodt 🔁✨
LIST ( ihn, ihn, ... )Trail
when a message is sent through the internetwork environment, it picks up a list of the MPMs that have handled it in "Stamp" 👣 this list then gets carried as "Trail" when the reply or acknowledgment comes back 💫 more simply: requests and replies always have a "Stamp", and each MPM adds its ihn to that "Stamp" 💅 replies also have a "Trail", which is the complete "Stamp" of the original message 🦋
LIST ( ihn, ihn, ... )Type
the command type, like request or reply 💜
INDEXDocument
in this section we define some objects that are useful in message document headers 📄 the ones we use are taken from the current ARPANET message syntax standard [6,8] 🌸
CC
when copies of a message are sent to others on top of the addresses in the To object, those recipients get their addresses recorded here 💌 CC will be a single TEXT element 🎀
TEXTDate
the date and time are represented according to the International Standards Organization (ISO) recommendations [13,14,15] 🌍 taken together, ISO recommendations 2014, 3307, and 4031 give us this representation of the date and time ⏰
yyyy-mm-dd-hh:mm:ss,fff+hh:mmwhere yyyy is the 4 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, and fff is the decimal fraction of the second 🕰️ then the offset from Greenwich gets appended as plus or minus hh hours and mm minutes 🌏
TEXTDocument-Body
the document body is the part of the message people usually think of as the text portion 📖 it's made up of a list of elements 💖 this lets us send data other than plain text if we ever need to 🔊 like digital voice through a BITSTR element, or graphic data, etc. 🎨 info about controlling those features could go in the header for cooperating sites, or in the body itself, but those protocols would depend on agreement between the sites involved 🤝 it's expected, of course, that most messages will have body portions made of TEXT elements 💜
LIST ( --- )Document-Header
the document header holds the memo header shown to the user 📝 in principle it can be any style or structure 🌈 in this specification it is recommended that a PROPLIST be used, and that the name-value pairs correspond to the header fields of RFC 733 [6] ✨
PROPLIST ( --- )From
From is meant to be the name of the author of a document 🖋️ it'll be one TEXT element 💅
TEXTReply-To
sometimes you'll want replies to a message to go to some address other than the From or the Sender 📮 in that case, the Reply-To object can be used 💌
TEXTSender
the Sender holds the address of the individual who sent the message 📤 in some cases this is NOT the same as the author of the message 🙅 when that happens, the author should be specified in the From object 💖 the Sender is a single TEXT element 🎀
TEXTSubject
the subject of the message 🌸
TEXTTo
To identifies the addressees of the message 📬 the To object is one TEXT element 💜
TEXT3.4. Command ✨
okay bestie, this is where the processes actually talk to each other 🗣️💖 Several parts of the command structure are borrowed from the NSW Transaction Protocol [19], and the commands come in pairs, so every request gets its own reply. it's giving well-organized conversation 💅
A command is a list:
LIST ( mailbox, stamp, type, operation, arguments, error-list )the arguments get the general treatment here, and then each command gets its own specific rules if it needs them 🎀
mailbox: PROPLIST
this is the "to" part of the message 📬 it's a property list with general info. some of it is the essential stuff needed for delivery, and some of it is just extra helpful info. the difference from an address is that an address is a very specific list with no extra info at all 🦋
stamp: LIST ( INTEGER, ... )
this is the list of MPMs that have handled the message 🧚 every MPM must add its 32 bit Internet Host Number (ihn) to the list. no skipping, periodt 💜
type: INDEXtype=1: a REQUEST operation.type=2: a REPLY operation.type=3: an ALARM operation. (a high priority message, so it's the main character 🚨)type=4: a RESPONSE to an alarm operation.
operation: TEXT
this is the name of the operation or procedure to be performed 🍓 the string must be interpreted in an upper/lower case independent manner, so deliver and DELIVER are the same bestie 🙈
arguments: LIST
a list of arguments for the operation above ✨
error-list: LIST
if the message is type 1 or 3 (a request or an alarm), the error-list is just an empty list:
LIST ( ) (a zero length list)if the message is type 2 or 4 (a response or response to alarm), it's:
LIST ( error-class, error-string )which tells you what error occured, if any 😭
error-class: INDEX=0: success, no error 🎉=1: partial results returned. this one is for when an operation does several steps and some of them fail 🌗=2: failure, resources unavailable. 🫠=3: failure, user error.=4: failure, MPM error. Recoverable.=5: failure, MPM error. Fatal. 💀=6: User abort requested 🛑
error-string: TEXT
a human readable string describing the error. the chaos is in the details 📝
Here's the table of possible errors, all lined up for you 💅
error-string error-class
No errors 0
Command not implemented 2
Syntax error, command unrecognized 3
Syntax error, in arguments 3
Server error, try again later 4
No service available 5
User requested abort 6command: DELIVER
okay so DELIVER is the one that sends a message to a mailbox 📨 it's a type 1 request, and its reply is ACKNOWLEDGE. the arguments are a LIST of options, and you can use one or more of these:
"REGULAR": regular delivery ✨"FORWARD": message forwarding 🦋"GENDEL": general delivery 🌸- other options which may be defined later 👀
the argument structure looks like this:
LIST ( LIST ( TEXT, ... ))command: ACKNOWLEDGE
ACKNOWLEDGE is the reply to DELIVER. it's type 2, and its arguments are a LIST of tid, trail, answer, reasons, and how-delivered 🫶
tid: the tid of the originating messagetrail: the stamp from the DELIVER commandanswer:yesif delivered successfully,noif there was an error in deliveryreasons: if the answer is yes, the reason is"ok". if the answer is no, the reason could be"no such user","no such host","no such network","address ambiguous", or a similar response 💔how-delivered: one or more of these:"FORWARD": message was accepted for forwarding 🚀"GENDEL": message was accepted for general delivery"ACCEPT": message was accepted for normal delivery ✅- other types of delivery may be defined later 🔮
the argument structure:
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
LIST ( TEXT ),
LIST ( TEXT ))command: PROBE
PROBE is a type 1 request that checks whether the mailbox (the one in the command's mailbox) exists at a host 🔍 its reply is RESPONSE. it takes no arguments, so the arguments are just LIST ( --none-- ), and the argument structure is:
LIST ( )command: RESPONSE
RESPONSE is the type 2 reply to PROBE 🎀 its arguments are tid, trail, answer, and then either address OR reasons:
tid: the tid which came from the originating PROBEtrail: the stamp which came from the originating PROBEanswer: yes if the mailbox was found, no for an invalid mailbox- if the answer is yes, the fourth argument is
address - if the answer is no, it's
reasons address: a specific address in the network 📍reasons: why the mailbox is invalid. possible reasons include:"Mailbox doesn't exist"👻"Mailbox full"📦"Mailbox has moved, try this new location", address, where the address is the new address to try 🏠
the argument structure depends on the answer:
if answer is yes
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
PROPLIST )
if answer is no
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
LIST ( TEXT ))command: CANCEL
CANCEL is a type 3 command that aborts a request for a specified transaction 🛑 its reply is CANCELED, and its arguments are just LIST ( tid ), where tid is the transaction to be cancelled. the argument structure:
LIST ( LIST ( INDEX, INTEGER ))command: CANCELED
CANCELED is the type 4 reply to CANCEL 🫠 its arguments are tid, trail, and answer:
tid: the tid of the transaction to be cancelledtrail: the stamp of the CANCEL commandanswer: yes if the command was canceled, no if not
the argument structure:
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN )so to summarize again, a command is a LIST of these objects 💜
name element
---- -------
mailbox PROPLIST
stamp LIST ( INTEGER, ... )
type INDEX
operation TEXT
arguments LIST ( --- )
error LIST ( INDEX, TEXT )3.5. Document 📄
the actual document comes right after the command list 💌 it has a header, which usually holds things like From, To, Date, CC, and so on, and then the body of the message. the message delivery system doesn't depend on the document at all. the section below is a recommendation for common practice, not a requirement, so nobody's getting in trouble 🫶
Document Header
ngl the header is where things get personal 🎀 it's impossible to predict every form that intranet addresses will take, so standardizing document headers would be a mistake too. the approach here is to lay the groundwork for a set of basic header functions and leave enough room for networks to add whatever features they want. features added that way might not be understood by other networks, though, so it's suggested that the subset defined here be implemented by all networks 🌈
this subset is taken from the current ARPANET standard for message headers in the text oriented computer message system [6,8] ✨
the document header comes before the body and is a proplist data element. individual networks use it to tailor the header to their own needs. for example, on the ARPA network the receiver's name is usually taken to be their network address, so it often prints in the header in exactly that form: Frank@SITEX. that's not okay for more formal communication 😬 so a network might put a name-value pair like ("SALUTATION:", "Mr. Frank Hacker") into the header proplist. when the message arrives, the document handling program can scan the header proplist for that pair and address the recipient by name instead of by network address 💅 but other networks, or sites within a network, may not understand that specific info. in that case it should be ignored 🙈
the minimum header is a PROPLIST of these name-value pairs:
Name Value
---- -----
DATE TEXT
FROM TEXTa normal header is a PROPLIST containing these name-value pairs:
Name Value
---- -----
DATE TEXT
SENDER TEXT
FROM TEXT
TO TEXT
CC TEXT
SUBJECT TEXTDocument Body
the body is just a sequence of data elements that holds the actual document 📝 most of the time it's a single TEXT element, but some applications might use other data elements too 🦋
LIST ( --- )3.6. Message Structure 🎀
Okay bestie, so an internet message is made of three parts 💅. First up is the tid, which identifies the transaction. Second is the Command List. Third is the Document List, which is its own little team made of a Document-Header and a Document-Body 🧚.
When a message is getting shipped between two MPMs, it looks like a LIST:
Message is:
LIST ( tid, Command-List, Document-List )Batching is so convenient 🧺. You can ship several messages together as one unit from one MPM to another, and that group is called a message-bag. A message-bag is a LIST of Messages, and each Message is shaped like we just saw.
Thus, a message-bag is:
LIST ( Message1, Message2, ... )Message Sharing 🔁
Okay, so when messages get batched for delivery, the same Document is often going to a bunch of different recipients 😩. The Document is usually the biggest chunk of the message, so if every recipient got their own copy of the Mail in the message-bag, you'd be sending the same data over and over. Not it.
So instead, the message-bag is assembled so the actual data shows up first, and references to it show up later 🦋. Every message has a unique tid, so a reference just points at the tid of the real data. Basically, every copied bit of data points back to something earlier in the message-bag. The data you're looking for is indexed by tid, and the semantics require that references only point at data you've already seen.
A portion is Shared based on its position inside a Message. So if the Command list is Shared, its spot in the Message holds the tid of an earlier message whose Command list was identical. Same goes for the Document Header and the Document Body. Only a complete Command, Header, or Body can be Shared. Never a partial one, no exceptions 🙅♀️.
If an encryption scheme is used, the encrypted portion of the message can't be shared. Why? The encrypting keys are specific to two individuals, so it's just not gonna work 🔐.
Internal Message Organization 🧩
The tid
This is the transaction identifier, and it's assigned by the originating MPM 🆔.
The Command List
The command-list is a LIST with two elements, content and command 📋.
Content is one item of element type INDEX. If content=0, the item is not shared, and the next element of the LIST is the command. If content=1, the item is shared. In that case, the second element holds the tid of the command to share from. That tid has to belong to a prior message in the current message-bag. Other values of content may be defined later for different data structures ✨.
Thus, command-list is:
LIST ( content, tid ) if content=1
Or,
LIST ( content, command ) if content=0
content is:
INDEX which is 0 if there is no sharing
and is 1 if sharing occurs
tid is:
the tid of the message to be shared from
command is:
LIST ( mailbox, stamp, type, operation, arguments, error-list )The document-list
The document portion of an internet message is optional. When it's there, it's a LIST with two elements 📄:
document-list is:
LIST ( header-list, body-list )Here's the tea 🫖: either the header-list or the body-list can be shared, but both elements must appear in the m.
The document-header
The header-list is always a List with exactly two elements 🎀. The first element is content, saying whether or not the header is shared. The second element is either the tid of the header to copy (if content=1), or the document-header itself (a PROPLIST with the actual header info, if content=0). That tid has to point to a document-header you've already seen in the message-bag 👀.
The header-list is either:
LIST ( content, tid ) if content=1
Or,
LIST ( content, document-header ) if content=0
document-header is:
PROPLIST which contains header informationThe document-body
The body-list is a LIST of two elements too 🫶. The first element is content again, telling you whether the body is shared. If it is, the second element is the tid of the body to copy, and that tid has to belong to a message already seen in the message-bag. If there's no sharing, the second item is a document-body.
body-list is:
LIST ( content, tid ) if content=1
Or,
LIST ( content, document-body ) if content=0
document-body is:
LIST ( items comprising the body ... )Message Fields 💜
Here's the whole structure in one glance, bestie 🌈:
message := ( tid, command-list, document-list )
tid := ( tn, ihn )
command-list := ( content, command )
command := ( mailbox, stamp, type, operation,
arguments, error-list )
document-list := ( header-list, body-list )
header-list := ( content, document-header )
body-list := ( content, document-body )3.7. MPM Organization 🏠
Introduction ✨
The heart of the internet message system is the MPM 💖. It's responsible for routing and delivering messages between the networks. Each network must have at least one MPM. These MPMs are connected to each other, and internet mail is always transferred along the channels between them. The system also interfaces with the already existing local message system 🔌.
Since the local network message system can be super different from the internet system, you might need special programs to convert incoming internet messages into the local format. Same deal in reverse: messages heading out to other networks may get converted into the internet format 🔄.
The MPM 👑
Messages in the internet mail system ship in "bags," and each bag holds one or more messages 🛍️. Every bag is addressed to a specific MPM and contains messages for the hosts on that MPM's network.
Each MPM is expected to implement functions that let it deliver the local messages it receives, and forward the non-local ones to other MPMs that are presumably closer to the message's destination 🗺️.
Loosely speaking, each MPM splits into five components 🧩:
- 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 Net Delivery: Delivers local net and local host messages, and may call on a conversion program.
- 4--Foreign Net Router: Creates new Message-Bags for forwarding to other MPMs, and determines the route.
- 5--Foreign Net Shipper: Activates foreign shipping channels and ships Message-Bags to foreign MPMs. Performs data compression while shipping bags.
All of these components can be thought of as independent 🦄. Of the five, the Acceptor, the Local-Net Delivery, and the Message-Bag Processor are fully self-contained, and they only talk to each other through a queue called the Bag-Input Queue. The Acceptor's job is to wait for incoming Message-Bags and insert them into the Bag-Input Queue 📥.
That queue is the input to the Message-Bag Processor, which separates out suitable portions of the Message-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 decides to forward a message to another MPM, it has to add its own identification (its ihn) to the stamp field of the command 🏷️. That makes the stamp a record of the route the message has taken. An MPM should look at the stamp field to see whether the message is stuck in a routing loop 🔁. Some commands need the stamp to be returned as a trail in the matching reply command.
All of these queues hold complete Message-Bags, although some of those might be portions of the original Bag 📦.
The Local-Host and Local-Net queues are the input to the Local-Net Delivery process. This component is responsible for delivering messages to its local host and to the other hosts on its local net that it's connected to 🏡. It must be able to handle whatever error conditions the local net might throw at it, including retransmitting. It may call on a conversion program to reformat messages into a form the local protocol will accept, which probably involves things like copying shared information 🔧.
The other two processes are more tightly coupled 💞. The Foreign Net Router takes its input Bags from the Foreign Net Queue. Based on the internal information it contains, it figures out which of the MPMs it's connected to should receive the Bag 🧭.
Then it places the Bag, along with the routing information, into the Shippable Mail Queue. The Foreign Net Shipper pulls it from that queue and transmits it across a channel to the intended foreign MPM 🚀.
The Foreign Net Router should be able to take external input into its routing information table. That can come from the Foreign Net Shipper if a channel goes down, which means deciding either to postpone delivery or to find a new route 📉.
The Router is responsible for keeping enough topological information to figure out where to forward any incoming Message-Bag. Decisions about returning undeliverable Bags are made by the Router too 🔙.
Now, this part is important, so listen up 📢: message delivery should be reliable. If delivery is impossible, the message should be returned to the sender, along with information about why it couldn't be delivered 😤.
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 still in the network when another instance of that transaction number gets chosen ⏳.
3.8. 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. This interface also has to pass the delivery address information, which becomes the information in the mailbox field of the command 📬. It's weakly assumed that the information gets passed between the UIP and the MPM through shared files, but that's not the only possible mechanism. The two processes could be more strongly coupled (like by sharing memory), or less strongly coupled (like by communicating over logical channels) 🧵.
Communication Interface 📡
It's assumed here that the MPM uses an underlying communication system, and TCP [20] has been taken as the model 💻. 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 interconnect MPMs, as long as you use suitable protocols to provide reliable communication 📞.
4. EXAMPLES & SCENARIOS ✨
Okay so, the examples are where it all clicks, bestie 🫶 Let's walk through how a real message gets built, one layer at a time.
Example 1: Message Format 💌
Imagine we want to send this message, and it's giving tea ☕:
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIB>
Subject: Meeting Thursday
To: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie
Dave:
Please mark your calendar for our meeting Thursday at 3 pm.
--jon.It gets encoded in the structured format 🎀 The steps below show the top-down build, from the big picture down to the actual bits.
1. message
2. ( tid, command-list, document-list )
3. ( ( tn, ihn ),
( content, command ),
( header-list, body-list ) )
4. ( ( tn, ihn ),
( content,
( mailbox, stamp, type, operation,
arguments, error-list ) ),
( ( content, document-header ),
( content, document-body ) ) )
5. ( ( 37, 167772404 ),
( 0, (
( IA: 167772359, NET: arpa, HOST: rand-unix,
USER: DCrocker ),
( 167772404 ),
1
DELIVER
( ( REGULAR ) ),
( ) ) ),
( ( 0, (
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIB>
Subject: Meeting Thursday
To: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
( 0, ( Dave:
Please mark your calendar for our meeting
Thursday at 3 pm.
--jon. ) ) ) )
6. LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
Please mark your calendar for
our meeting Thursday at 3 pm.
--jon." ) ) ) )Example 2: Delivery and Acknowledgment 🦋
Here's the full journey of the Example 1 message 🚀 We get four views of it: first it leaves the originating MPM, hops through a relay MPM to the destination MPM, and then the acknowledgment comes all the way back the same way.
+-----------------------------------------------------------------+
! 1 2 !
! sending --> originating --> relay --> destination --> receiving !
! user MPM MPM MPM user !
! !
! 4 3 !
! originating <-- relay <-- destination !
! MPM MPM MPM !
+-----------------------------------------------------------------+
Transmission Path
Figure 6.- Between the originating MPM and the relay MPM. 💫
LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
Please mark your calendar for
our meeting Thursday at 3 pm.
--jon." ) ) ) )The originating MPM sends the Example 1 message on to a relay MPM 📮
- Between the relay MPM and the destination MPM. 🌸
LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404,
INTEGER=167772246 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
Please mark your calendar for
our meeting Thursday at 3 pm.
--jon." ) ) ) )The relay MPM tacks its ihn onto the stamp, and that's the only change. Everything else stays exactly the same ✨
- Between the destination MPM and the relay MPM. 🧚
LIST( LIST( INDEX=1993, INTEGER=167772359 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772404,
mailbox USER: *MPM* ),
stamp LIST( INTEGER=167772359 ),
type INDEX=2
operation TEXT="ACKNOWLEDGE"
arguments LIST( LIST( INDEX=37,
tid INTEGER=167772404 ),
LIST( INTEGER=167772404,
trail INTEGER=167772246,
INTEGER=167772359 ),
answer BOOLEAN=TRUE,
reason LIST( TEXT="OK" ),
how-delivered LIST( TEXT="ACCEPT" ) ),
error-list LIST( INDEX=0,
TEXT="No Errors") ),
document LIST( ) )The destination MPM hands the message over to the user's UIP and writes up an acknowledgment, addressed to the originating MPM 🎀 Notice that the trail is the incoming stamp plus the destination MPM's own ihn. Main character energy, fr 👑
- Between the relay MPM and the originating MPM. 🦋
LIST( LIST( INDEX=1993, INTEGER=167772359 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772404,
mailbox USER: *MPM* ),
stamp LIST( INTEGER=167772359
INTEGER=167772246),
type INDEX=2
operation TEXT="ACKNOWLEDGE"
arguments LIST( LIST( INDEX=37,
tid INTEGER=167772404 ),
LIST( INTEGER=167772404,
trail INTEGER=167772246,
INTEGER=167772359 ),
answer BOOLEAN=TRUE,
reason LIST( TEXT="OK" ),
how-delivered LIST( TEXT="ACCEPT" ) ),
error-list LIST( INDEX=0,
TEXT="No Errors") ),
document LIST( ) )The relay MPM adds its ihn to the stamp and sends the acknowledgment along to the originating MPM 💜
GLOSSARY 📖
1822 🌷 BBN Report 1822, "The Specification of the Interconnection of a Host and an IMP". This is the spec for the interface between a host and the ARPANET.
Command List 💅 The part of a message the MPMs look at to decide what processing action to take.
datagram 🫧 A logical unit of data. An internet datagram, specifically, is the unit of data passed between the internet module and a higher level module.
Destination 📍 The destination address, which is a field in the internet header datagram protocol.
Document List 📄 The part of the message that gets created by, or delivered to, a user.
header 🎀 Control information at the very start of a message, segment, datagram, packet, or block of data.
IMP 🛰️ The Interface Message Processor, which is the packet switch of the ARPANET.
Internet Address 🌍 A four octet (32 bit) source or destination address made up of a Network field and a Local Address field.
internet datagram 🌈 The unit of data exchanged between a pair of internet modules. It includes the internet header.
Local Address 🏠 The address of a host within a network. How an internet local address actually maps onto host addresses in a network is quite general, and it allows for many-to-one mappings.
message 💌 The unit of information sent between users of message systems. Between MPMs, a message consists of a Transaction Identifier, a Command List, and a Document List.
module 🧩 An implementation, usually in software, of a protocol or some other procedure.
MPM 🦄 A Message Processing Module, meaning the process that implements this internet message protocol.
octet 🍓 An eight bit byte.
Rest 🧁 The 3 octet (24 bit) local address portion of an Internet Address.
RTP ⏱️ Real Time Protocol: a host-to-host protocol for communicating time critical information.
Source 📤 The source address, which is a field in the internet header.
TCP 🔐 Transmission Control Protocol: a host-to-host protocol for reliable communication in internetwork environments.
Transaction Identifier 🪪 The unique identifier of a message.
Type of Service 🏷️ An internet datagram protocol header field that indicates the type (or quality) of service for this internet packet.
UIP 🖥️ A User Interface Program: a program that presents message data to a user and accepts message data from a user. It's the program that interacts with the user while messages are being composed and examined.
XNET 🐞 A cross-net debugging protocol.
References 📚✨
okay bestie, here's the bibliography, the whole reading list 🤓💖 every source is kept exactly as written:
- [1] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192, February 1979.
- [2] Bhushan, A., K. Progran, R. Tomlinson, and J. White, "Standardizing Network Mail Headers," RFC 561, NIC 18516, 5 September 1973.
- [3] Bolt Beranek and Newman, "Specification for the Interconnection of a Host and an IMP," BBN Technical Report 1822, May 1978 (Revised).
- [4] Braaten, O., "Introduction to a Mail Protocol," Norwegian Computing Center, INWG 180, August 1978.
- [5] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
- [6] 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.
- [7] Crocker, D., E. Szurkowski, and D. Farber, "Components of a Channel-independent Memo Transmission System," Department of Electrical Engineering, University of Delaware,, February 1979.
- [8] 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.
- [9] Harrenstien, K., "Field Addressing," ARPANET Message, SRI International, October 1977.
- [10] Haverty, J., "MSDTP -- Message Services Data Transmission Protocol," RFC 713, NIC 34739, April 1976.
- [11] Haverty, J., "Thoughts on Interactions in Distributed Services," RFC 722, NIC 36806, 16 September 1976.
- [12] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed Specification of an Inter-site Message Protocol," 8 July 1975.
- [13] ISO-2014, "Writing of calendar dates in all-numeric form," Recommendation 2014, International Organization for Standardization, 1975.
- [14] ISO-3307, "Information Interchange -- Representations of time of the day," Recommendation 3307, International Organization for Standardization, 1975.
- [15] ISO-4031, "Information Interchange -- Representation of local time differentials," Recommendation 4031, International Organization for Standardization, 1978.
- [16] Myer, T., and D. Henderson, "Message Transmission Protocol," RFC 680, NIC 32116, 30 April 1975.
- [17] Postel, J. "Internetwork Datagram Protocol, Version 4," USC Information Sciences Institute, IEN 80, February 1979.
- [18] Postel, J. "NSW Data Representation (NSWB8)," IEN 39, May 1978.
- [19] Postel, J. "NSW Transaction Protocol (NSWTP)," IEN 38, May 1978.
- [20] Postel, J. "Transmission Control Protocol, TCP, Version 4," USC Information Sciences Institute, IEN 81, February 1979.
- [21] Postel, J., "Assigned Numbers," RFC 750, NIC 45500, 26 September 1978.
- [22] Postel, J., "Message System Transition Plan," JBP 64, USC-Information Sciences Institute, February 1979.
- [23] Rivest, R. L. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" Communications of the ACM, Vol. 21, Number 2, February 1978.
- [24] Shoch, J., "A Note On Inter-Network Naming, Addressing, and Routing," Xerox Palo Alto Research Center, IEN 19, January 1978.
- [25] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW Working Note 24, Bolt Beranek and Newman, October 1978.
- [26] White, J., "A Proposed Mail Protocol," RFC 524, NIC 17140, 13 June 1973.
- [27] White, J., "Description of a Multi-Host Journal," NIC 23144, 30 May 1974.
- [28] White, J., "Journal Subscription Service," NIC 23143, 28 May 1974.
Appendices 🎀
A. Encryption 🔐
okay so this one is giving future feature energy 🔮 it would be totally doable to let the document part of a message be encrypted, either all of it or just some of it 💅 the plan is to add a brand new basic data element just for carrying encrypted stuff. whatever's inside it could be made of other elements too, but you can only see that structure once it's been decrypted 👀
+------+------+------+------+-------
9 Encrypt ! 9 ! octet count ! Data ...
+------+------+------+------+--------Element code 9 (ENCRYPT) is Encrypt. The format is one octet type code, the three octet type count, and count octets of data. Using this element means the data inside it is encrypted. The encryption scheme isn't locked in yet, but it'll probably be the Public Key Encryption technique [23], because it can do coded signatures and that's so iconic 🫶
here's how it'd work: the first time an encryption block shows up for a given message, the user gets asked for the right key 🔑 then the encrypted data gets decrypted. what comes out is complete data type fields. encryption can't happen over a partial field, so it's all or nothing per field 🙅♀️ after that, the revealed data just gets processed like normal ✨
ngl there's no reason you couldn't encrypt every single field in a document, including all the header stuff like From, Date, and so on 🫣
B. Data Compression 🗜️
when message-bags get shipped between MPMs, the data should be compressed using the scheme below 💜
shipping-unit := compression-type message-bag
compression-type := A one octet compression type indicator.
compression-type value description
---------------------- -----------
0 no compression used
1 basic compressionBasic Compression 🧩
this basic compression procedure is the exact same one used with the ARPANET FTP [8] (iconic callback 💅). there are three kinds of compression-units: sequence-units, replication-units, and filler-units. the data gets chopped into a series of compression-units that doesn't care about the structure or object and element boundaries, so it just flows straight through 🌊
sequence-unit 🌸
a sequence-unit is one octet flag and count, followed by that many data octets.
+-+-------+--------+--------+----
!0! n ! n data octets ...
+-+-------+--------+--------+----the flag and count octet has its high order bit set to zero, and the remaining bits tell you the count (in the range 0 to 127) of data octets that follow 🔢
replication-unit 🦋
a replication-unit is one octet flag and count, followed by one data octet that gets replicated count times 🪞
+--+------+--------+
!10! n ! data !
+--+------+--------+the flag and count octet has its high order two bits equal to one-zero, and the remaining six bits give the count (in the range 0 to 63) of number of time to replicate the data octet 🙈
filler-unit 🧁
a filler-unit is one octet flag and count, which says a filler octet should be inserted count times 🍓
+--+------+
!11! n !
+--+------+the flag and count octet has its high order two bits equal to one-one, and the remaining six bits give the count (in the range 0 to 63) of number of time to insert the filler octet 💫
the filler octet is zero, the octet with all bits zero 🌈 and that's the whole thing, bestie, we made it 🥹👑
📦 where this page comes from
- ietf: rfc753 1979-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms