home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0238.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  2.7 KB  |  115 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        R. T. Braden
  8. Request for Comments #238                                    UCLA-CCN
  9. NIC #7663                                                    September 29, 1971
  10. Category:
  11. Updates: RFC #171, RFC #172
  12.  
  13.                    COMMENTS ON DTP AND FTP PROPOSALS
  14.  
  15.    Data Transfer Protocol
  16.    ----------------------
  17.  
  18.    1. In the Descriptor/Count mode, the Information Separators should
  19.    have a transaction sequence number field.  Otherwise, the receiver
  20.    cannot be sure he received all transactions before the separation.
  21.    This requires that there be two forms of information separators, one
  22.    for Descriptor/Count mode, the other for the DLE mode.
  23.  
  24.    2. The modes-available handshake should not be mandatory, as it makes
  25.    no sense in the simplex case.  The receiver doesn't care what modes
  26.    the transmitter _might_ use; he only cares what mode _is_ used, which
  27.    he discovers when the first data or control transaction arrives.  Even
  28.    in the duplex case, it is not clear what use the receiver should make
  29.    of the modes-available information from the transmitter.
  30.  
  31.    File Transfer Protocol
  32.    ----------------------
  33.  
  34.    1. The protocol allows an end-of-file to be indicated by closing the
  35.    connection.  This is the same mistake which we made in an early
  36.    version of NETRJS.  Closing the connection without a File Separator
  37.    transaction should only be used to indicate an error, i.e., to abort
  38.    the transmission; it should never be used to indicate normal
  39.    completion of file transfer.  The reason is obvious: there is no way
  40.    for the receiver to tell whether CLS indicates normal completion or an
  41.    abnormal condition in the other host (e.g. the file transfer program
  42.    died).
  43.  
  44.    2. There should be two forms of the _store_ request, one which fails
  45.    if a file of the same name already exists, and one which replaces an
  46.    existing file of the same name (as now).
  47.  
  48.    3. A service center host may be expected to require username and
  49.    password transactions before any others are accepted.
  50.  
  51.    4. There are no error transactions defined for lost data or lost
  52.    synch.  It is assumed there are handled at the DTP level?
  53.  
  54.    5. All of the defined error codes should be allowed (and encouraged)
  55.    to have explanatory text following them.
  56.  
  57.  
  58.  
  59.                                                                 [Page 1]
  60.  
  61. RTB:gjm
  62.        [ This RFC was put into machine readable form for entry ]
  63.        [ into the online RFC archives by BBN Corp. under the   ]
  64.        [ direction of Alex McKenzie.                   12/96   ]
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.                                                                 [Page 2]
  114.  
  115.