1 files changed, 112 insertions, 0 deletions
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]
+