Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Comments on DTP and FTP proposals (RFC0238)

IP.com Disclosure Number: IPCOM000002951D
Original Publication Date: 1971-Sep-29
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 3K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.T. Braden: AUTHOR

Abstract

Data Transfer Protocol ----------------------

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 100% of the total text.

Network Working Group R. T. Braden

Request for Comments #238 UCLA-CCN

NIC #7663 September 29, 1971

Category:

Updates: RFC #171, RFC #172

COMMENTS ON DTP AND FTP PROPOSALS

Data Transfer Protocol

----------------------

1. In the Descriptor/Count mode, the Information Separators should

have a transaction sequence number field. Otherwise, the receiver

cannot be sure he received all transactions before the separation.

This requires that there be two forms of information separators, one

for Descriptor/Count mode, the other for the DLE mode.

2. The modes-available handshake should not be mandatory, as it makes

no sense in the simplex case. The receiver doesn't care what modes

the transmitter _might_ use; he only cares what mode _is_ used, which

he discovers when the first data or control transaction arrives. Even

in the duplex case, it is not clear what use the receiver should make

of the modes-available information from the transmitter.

File Transfer Protocol

----------------------

1. The protocol allows an end-of-file to be indicated by closing the

connection. This is the same mistake which we made in an early

version of NETRJS. Closing the connection without a File Separator

transaction should only be used to indicate an error, i.e., to abort

the transmission; it should never be used to indicate normal

completion of file transfer. The reason is obvious: there is no way

for the receiver to tell whether CLS indicates normal completion or an

abnormal condition in the other host (e.g. the file transfer program

died).

2. There should be two forms of the _store_ request, one which fails

if a file of the same name already exists, and one which replaces an

existing file of the same name (as now).

3. A service center host may be expected to require username and

password transactions before any others are accepted.

4. There are no error transactions defined for lost data or lost

synch. It is assumed there are handled at the DTP level?

5. All of the defined error codes should be allowed (and encouraged)

to have explanatory text following them.

RTB:gjm

[ 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 ]