Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc238.txt.pdf Дата изменения: Wed Mar 27 23:28:07 2002 Дата индексирования: Tue Oct 2 16:21:18 2012 Кодировка:

Network Working Group Request for Comments #238 NIC #7663 Category: Updates: RFC #171, RFC #172 COMMENTS ON DTP AND FTP PROPOSALS Data Transfer Protocol ---------------------1. In the Descriptor/Count have a transaction sequence cannot be sure he received This requires that there be for Descriptor/Count mode, 2. no the he in of

R. T. Braden UCLA-CCN September 29, 1971

mode, the Information Separators should number field. Otherwise, the receiver all transactions before the separation. two forms of information separators, one the other for the DLE mode.

The modes-available handshake should not be mandatory, as it makes sense in the simplex case. The receiver doesn't care what modes transmitter _might_ use; he only cares what mode _is_ used, which discovers when the first data or control transaction arrives. Even the duplex case, it is not clear what use the receiver should make 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.

[Page 1]


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 ]

[Page 2]