RFC 221

A Mail Box Protocol, Version-2 🎀

Okay bestie, let's get into RFC 221 🦋 It's by R. Watson from SRI-ARC, and it's filed under NIC 7612, dated 25 August 1971. It's part of the Network Working Group series. The header doesn't list a category, and it doesn't say it obsoletes or updates anything, so there's nothing to cross-check there 💅

• RFC number: 221
• Title: A Mail Box Protocol, Version-2
• Author: R. Watson, SRI-ARC
• NIC number: 7612
• Date: 25 August 1971
• Obsoletes / Updates: not listed in the header

---

INTRODUCTION ✨

Okay so the first reaction to RFC 196, "A Mail Box Protocol", NIC (7141,), was basically everyone going "yes, we need this" 💖 The conventions in RFC 196 only assumed the Data Transfer Protocol (in NIC 7104), to keep the first implementation simple. The valid argument, we believe, has been made that sites will also implement the File Transfer Protocol and that as much as possible the Mail Box Protocol should be a subset of it. This version is in answer to that suggestion 🫶

The purpose of a mail box protocol is to give each site a standard way to receive sequential files for immediate or deferred printing, or other uses 🖨️ Files for deferred printing would probably be stored in intermediate disk files. How a file is handled, stored, manipulated, or printed at a site is not this protocol's problem 🙈

A mail box, as we see it, is basically a write only (from the Network) sequential file. Messages and documents get appended to it, separated by an appropriate site dependent code 🍓

We also assume there's a program at the sending site that sends the file in the format given below, with the optional control codes when appropriate. This program could probably be accessed as a subcommand of the Telnet program 🧚

The motivation here is the Network Information Center's (NIC) need to deliver messages and documents to remote sites. They also need to receive documents from remote sites for cataloging, redistribution, and other purposes, without having to know the path name conventions and file system commands at each site 🌸 Multiple mail boxes (256) are allowed at each site and are identified as described below. The default is mail box number 0, for use with the standard mail printer defined below ⭐

The only place the Mail Box Protocol could clash with the File Transfer Protocol is file naming conventions. The File Transfer Protocol assumes the using site will use a filename that follows the access and file path name conventions of the serving site, and that the user supplies this info. But with the Mail Box Protocol we'd really like to avoid needing to know the path name conventions at each site 💅

So basically, we need a network virtual pathname convention. We didn't want to solve that problem in general at this time. In RFC 196, NIC 7141, the proposal was a separate socket for mail type delivery, plus an integer 0-127 to specify the address of a specific file (Mail Box) to append to. That was the simplest network-wide standard file name convention for an initial implementation 🦋

To follow the spirit of the File Transfer Protocol more closely, I'd now recommend the Append Request be used specifically, and that the standard socket agreed on for use with the File Transfer Protocol also be used. After the byte indicating an Append request, there would be a standard agreed-upon string of letters followed by a number, which says this is a mail box append request. A suggested name string would be NETMAIL#, where # is a byte interpreted as a mail box number 0-255. If the above suggested Mail Box file naming convention is unsuitable, and some other network-wide standard mail box naming can be agreed on, then that can be used instead. Please let me know how you feel about this naming convention 💜

Given agreement on a standard mail box pathname, the Mail Box Protocol can use a subset of the File Transfer Protocol conventions, given below 🎀

The other problem raised about the Mail Box Protocol was someone accidentally or deliberately flooding a site's printer with garbage, since there are no access or file size controls. Some thinking and discussion has not yielded any simple satisfactory solutions. I'd recommend initial implementations without standard special safeguards in this area. Safeguards would be a site-dependent option. Standard safeguards for this problem can be easily added later if they really prove necessary, and if satisfactory ones can be agreed on 😭

---

MAIL BOX PROTOCOL - VERSION 2 💜

The Mail Box Protocol uses established network conventions. Specifically, it uses the Network Control Program, Initial Connection Protocol, Data Transfer Protocol, and File Transfer Protocol (as described in Current Network Protocols, NIC 7104) 🌈

The normal transmission for Mail Box 0 is Network ASCII. The standard receiving mail printer for mail box number 0 is assumed to have a print line 72 characters wide and a page of 66 lines 📄 The new line convention is carriage return (Hex '0D'), (Octal '015') followed by line feed (Hex '0A') (Octal '012'), as per the Telnet Protocol, RFC 158, NIC 6768. The standard printer will accept form feed (Hex '0C') (Octal '014') as meaning move paper to the top of a new page 🧚

It's the sender's responsibility to control the length of the print line and page. If more than 72 characters per line are sent, or if more than 66 lines are sent without a form feed, then the receiving site can handle those situations however works for them. These conventions can be changed by control codes, described below 🍓

At the head of a message or document sent to mail box number 0, there's an initial address string terminated by a form feed. This address string contains the sender's name and address, and the receiver's name and address, formatted in some reasonable, easy-to-read way so a clerk can read it and distribute the item. Comments can also be included in the address string 🌸

The format of information in mail boxes other than mail box number 0 is not explicitly defined by this protocol 🙈

Initial Connection

Initial Connection goes as per the Official Initial Connection Protocol, Document #2, NIC 7101, to the standard File Transfer socket, which is not yet assigned. A candidate socket number, socket #3, has been suggested 🦋

File Transfer

The mail item (file) gets transferred according to the File Transfer Protocol 💖

As per the File Transfer Protocol, a file (mail item) can be sent in more than one data transaction, as defined in the Data Transfer Protocol. End of file is indicated by the file separator (as defined in the Data Transfer Protocol), or by closing the connection 🫶

Order of Transactions

The only basic operation required is an append ✨

                    Append Request

   (Mailer) User  -------------------->  server (Mail Box)

                     <File - data>

                   ------------------->

                   End of File indication

                   ------------------->

                       Acknowledge

                   <-------------------

The data type default is network ASCII. The standard line printer default is as defined above. Other control transactions can be used 💅

---

CONTROL TRANSACTIONS TO BE USED 🎀

   OP CODE

   Hex     Octal
   00      000     Change data type identifier
   09      011     Error or unsuccessful terminate
   0A      012     Acknowledge or successful terminate
   0B      013     Append request (add to existing file)
   5A      132     Change printer control settings

DATA TYPE CODES 🌈

All data types of the File Transfer Protocol can be used for special applications. For Mail Box 0, the default is 8 bit bytes of Network ASCII characters 🦋

ERROR CODES ⭐

All error codes defined in the File Transfer Protocol could be returned 😭

PRINTER CONTROL CODES 🖨️

     Hex     Octal
     01      321     Meaning:  Set line width to 72 characters
     02      322     Meaning:  Use the full width of your printer
     03      323     Meaning:  Set page size to 66 lines
     04      324     Meaning:  Set page size to infinite

Other virtual printer control codes can be added in the future. Other classes of control codes can be added as the need arises 💜

---

JOURNAL RECORD 📓

This is the machine-generated record that came with the document, kept exactly as it was:

   <JOURNAL>7612.NLS;1, 27-AUG-71 10:41 RWW ; (Expedite) Title:
   Author(s): Richard W. Watson/RWW; Distribution: SDC2 TFL JWM JFH REL
   AOJO JEW AWH DLM PWF RAW HRVZ AAM RLS JMM JMW AKB PMK TNP ASL BMW JAM
   EAF RTB JMP BDW JTM JCL AJB CDS RFH EMA;/NWG; Sub-Collections: NWG
   ARC NIC; RFC# 221; Clerk: RWW;
   Origin: <WATSON>MAIL.NLS;4, 27-AUG-71 9:51 RWW ;

         [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Ryan Kato 6/01 ]

That's the whole thing, bestie! 🌈👑 RFC 221 is a lowkey iconic piece of early networking history.