RFC 238

Comments on DTP and FTP proposals

πŸ“… published September 1971, from ietf

RFC #238: Comments on DTP and FTP Proposals πŸŽ€

okay bestie, the title block first πŸ’… this is RFC #238 (NIC #7663), written by R. T. Braden of UCLA-CCN and dated September 29, 1971. the category line is left blank in the original. it updates RFC #171 and RFC #172, and no obsoletes are listed.


Data Transfer Protocol πŸ¦‹

  1. ok so in Descriptor/Count mode, the Information Separators should have a transaction sequence number field πŸ”’ otherwise the receiver can't be sure he got every transaction before the separation. that means you need two kinds of information separators: one for Descriptor/Count mode and one for the DLE mode πŸ’œ
  2. the modes-available handshake should not be mandatory πŸ™…β€β™€οΈ because it makes no sense in the simplex case. the receiver doesn't care what modes the transmitter might use, only what mode is used, and he finds that out when the first data or control transaction shows up ✨ even in the duplex case, it's not clear what the receiver should do with the modes-available info from the transmitter πŸ€·β€β™€οΈ

File Transfer Protocol 🌸

  1. the protocol lets an end-of-file be marked by closing the connection 😭 this is the same mistake 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: the receiver has no way to tell whether CLS means 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   ]
πŸ“¦ where this page comes from