home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- 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]
-
-