Comments on Mailbox Protocol
Why small machines cannot run the mailbox protocol.
McKenzie, A.M., "Comments on Mailbox Protocol", RFC 224, DOI 10.17487/RFC0224, September 1971, <https://www.rfc-editor.org/info/rfc224>.
@misc{rfc224,
series = {Request for Comments},
number = 224,
howpublished = {RFC 224},
publisher = {RFC Editor},
doi = {10.17487/RFC0224},
url = {https://www.rfc-editor.org/info/rfc224},
author = {A.M. McKenzie},
title = {{Comments on Mailbox Protocol}},
pagetotal = 2,
year = 1971,
month = sep,
} RFC text
Network Working Group Alex McKenzie
Request for Comments #224 BBN
NIC #7623 14 September 1971
Categories: D.7
Updates: none
Obsoletes: none
Reference: RFC #215, #221
Comments on Mailbox Protocol
It should be noted that the Terminal IMP will be unable to
directly implement the currently-proposed mailbox protocol for
the following reasons:
a) The Terminal IMP is completely incapable of storing
incoming messages for later printing or display.
b) The Terminal IMP is not expected to be able to perform
as the "server" portion of any connection.
c) The Terminal IMP cannot provide programs for the
processing of a variety of types of input streams.
It currently supports the TELNET protocol, and is
expected to support at least one mode of Data
Transfer Protocol in the future. It is _not_ likely
to support the File Transfer Protocol. Furthermore,
when using the Data Transfer Protocol it will not
perform any transformations on the data stream
(e.g., interpretation of line printer form-control
"characters," translation from one character set to
another, etc.). It will be up to the "other end"
of the connection to set up and decode messages based
on the terminal type.
Although these limitations preclude Terminal IMPs from
participating in the currently-proposed mailbox protocol, this
should not be considered an objection to implementation of the
protocol, provided that Terminal IMP installations will be
guaranteed the right to "rent" mailboxes at some larger Host
site [the NIC is probably a good candidate]. With this capability,
a message destined for a Terminal IMP user would be shipped to the
site of the "rented" mailbox according to protocol and stored
there. A terminal IMP user could then periodically log in to that
RFC #224
Page 2
site (under TELNET protocol) and examine the contents of the
mailbox; since the "examination" would be carried out over a
TELNET connection the Host containing the mailbox would _automatically_
perform the necessary transformation of the data before transmitting
it to the Terminal IMP.
A technically unattractive alternative to this scheme would
be to _require_ each Terminal IMP site to have a printer dedicated
to the mailbox function. If the mail were then transferred in
TELNET format, we could probably provide a socket connected to
the dedicated printer for receipt of mail. Obviously, if this
scheme were chosen, a Terminal IMP could accept mail from only
one sender at a time, and the transmission rate would be limited
to the speed of the printer. Furthermore, a single central
mailbox printer is likely to provide poor service to Terminal
IMPs with widely scattered terminals (e.g., dial-in terminals
distributed over an area with a 10-mile radius).
We feel that, in addition to other arguments, it would be
more cost-effective to provide storage for rented mailboxes at
one site than to provide a _special_ mailbox printer at each
Terminal IMP site.
AMcK:jm
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
AI ELI5
On this page
§1Terminal IMP Limitations
RFC 224 is a comment from BBN on the proposed mailbox protocol. The Terminal IMP is a small machine designed for basic network access, particularly for terminals and dial-in users. However, it has three critical limitations:
It cannot store incoming messages for later printing or display. It cannot perform as the server portion of any connection. It cannot provide programs to process varied input streams—it supports Telnet and may support parts of the Data Transfer Protocol, but not File Transfer Protocol, and it will not perform transformations on the data stream.
A small machine is designed for visitors to connect in and use, not to receive and store mail or to work as a store itself.
§2Rented Mailbox Solution
BBN proposes that Terminal IMP installations be guaranteed the right to rent mailboxes at a larger host site—the Network Information Center is suggested as a candidate. Messages destined for a Terminal IMP user would be shipped to the renting site and stored there according to protocol.
A Terminal IMP user could then periodically log in via Telnet and examine the mailbox. Since examination happens over Telnet, the host containing the mailbox would automatically perform necessary data transformations before sending to the Terminal IMP. This elegantly solves the storage and transformation problems.
Instead of the small machine keeping the mail, a bigger computer nearby stores it. The user logs in to read their mail, and the bigger computer takes care of putting it in the right format.
§3Why Not Other Approaches
An alternative would be to require each Terminal IMP site to have a dedicated printer for mail. Mail would be transferred in Telnet format to this printer. However, this approach is technically unattractive: a Terminal IMP could accept mail from only one sender at a time, and the transmission rate would be limited to printer speed. A single printer is poor service for Terminal IMPs with widely scattered terminals (such as dial-in terminals distributed over a 10-mile radius).
BBN concludes that renting mailbox storage at one site is more cost-effective and technically superior to providing a dedicated printer at each Terminal IMP site.
You could put a printer at each small machine, but then only one letter can arrive at a time and it prints at printer speed. Storing mail at a big computer instead is faster and cheaper.