home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 200s / rfc250.txt < prev    next >
Text File  |  1997-03-04  |  2KB  |  60 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                             H. Brodie
  8. Request for Comments #250                         UCLA-NMC
  9. NIC #7691                                         Computer Science
  10. Categories:  D5, D7                               7 October 71
  11. Updates:  None
  12. Obsoletes:  None
  13.  
  14.                      Some Thoughts on File Transfer
  15.  
  16.    There are several aspects of the proposed Data Transfer Protocol (RFC
  17.    #171) and File Transfer Protocol (RFC #172) which we believe could
  18.    use further clarification and perhaps revision.  Interest in
  19.    transferring larger amounts of data than is typically sent via the
  20.    usual TELNET connection is increasing, and at least at UCLA-NMC
  21.    implementation attempts have pointed out several difficulties with
  22.    the proposed protocols.
  23.  
  24.    First, and probably most easily decided, is the ambiguity in RFC #171
  25.    with regards to the sequence number field of the descriptor and count
  26.    transaction.  The description provided for the transaction header
  27.    provides for 16 bit sequence number.  However, the sequence number
  28.    field in the error codes transaction only provides for 8 bits.  We
  29.    are of the opinion that 8 bits is sufficient for a sequence number
  30.    field.  If the sequence number is reduced to 8 bits, and the two NUL
  31.    bytes are deleted from the descriptor and count header, then its size
  32.    is reduced to 48 bits, which would seem to be as convenient to handle
  33.    as the proposed 72 bit transaction header.
  34.  
  35.    Another source of difficulty lies in the implementation of the (the
  36.    SEX time-sharing system) the 'end' of a file (which presumably would
  37.    be the begin point of an Append transaction) is almost com- pletely
  38.    context-defined--i.e., the program reading the file determines when
  39.    it has reached the end of the file.  Therefore, the meaning of
  40.    'Append' is somewhat hazy, and since the proposed Mail Box Protocol
  41.    uses the Append feature, not implementing this command in a File
  42.    Transfer service is costly in terms of lost useability.
  43.  
  44.    We believe that resolution of these ambiguities will lead to a
  45.    greatly accelerated implementation schedule, at least here at UCLA-
  46.    NMC.
  47.  
  48.        [ This RFC was put into machine readable form for entry ]
  49.        [ into the online RFC archives by BBN Corp. under the   ]
  50.        [ direction of Alex McKenzie.                   12/96   ]
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60.