RFC238 Comments on DTP and FTP proposals

0238 Comments on DTP and FTP proposals. R.T. Braden. September 1971. (Format: TXT=2735 bytes) (Updates RFC0171, RFC0172) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

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.



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

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<MAP> ひとつの画像に複数のリンクを設定する(イメージマップ)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る