From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc224.txt | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 doc/rfc/rfc224.txt (limited to 'doc/rfc/rfc224.txt') diff --git a/doc/rfc/rfc224.txt b/doc/rfc/rfc224.txt new file mode 100644 index 0000000..827d536 --- /dev/null +++ b/doc/rfc/rfc224.txt @@ -0,0 +1,112 @@ + + + + + + +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 + + + + + + + [Page 1] + +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 ] + + + + + + + + + + + + + [Page 2] + -- cgit v1.2.3