RFC224 - Comments on Mailbox Protocol

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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 RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by BBN Corp. under the ]

[ direction of Alex McKenzie. 12/96 ]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航