[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

Tweet
This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC224
Ad

UNKNOWN
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 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.
                                                                [Page 1]

RFC #224
Page 2
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]


Ad
Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.
inserted by FC2 system