1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc250.txt b/doc/rfc/rfc250.txt
new file mode 100644
index 0000000..a95845d
--- /dev/null
+++ b/doc/rfc/rfc250.txt
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+Network Working Group                             H. Brodie
+Request for Comments #250                         UCLA-NMC
+NIC #7691                                         Computer Science
+Categories:  D5, D7                               7 October 71
+Updates:  None
+Obsoletes:  None
+
+                     Some Thoughts on File Transfer
+
+   There are several aspects of the proposed Data Transfer Protocol (RFC
+   #171) and File Transfer Protocol (RFC #172) which we believe could
+   use further clarification and perhaps revision.  Interest in
+   transferring larger amounts of data than is typically sent via the
+   usual TELNET connection is increasing, and at least at UCLA-NMC
+   implementation attempts have pointed out several difficulties with
+   the proposed protocols.
+
+   First, and probably most easily decided, is the ambiguity in RFC #171
+   with regards to the sequence number field of the descriptor and count
+   transaction.  The description provided for the transaction header
+   provides for 16 bit sequence number.  However, the sequence number
+   field in the error codes transaction only provides for 8 bits.  We
+   are of the opinion that 8 bits is sufficient for a sequence number
+   field.  If the sequence number is reduced to 8 bits, and the two NUL
+   bytes are deleted from the descriptor and count header, then its size
+   is reduced to 48 bits, which would seem to be as convenient to handle
+   as the proposed 72 bit transaction header.
+
+   Another source of difficulty lies in the implementation of the (the
+   SEX time-sharing system) the 'end' of a file (which presumably would
+   be the begin point of an Append transaction) is almost com- pletely
+   context-defined--i.e., the program reading the file determines when
+   it has reached the end of the file.  Therefore, the meaning of
+   'Append' is somewhat hazy, and since the proposed Mail Box Protocol
+   uses the Append feature, not implementing this command in a File
+   Transfer service is costly in terms of lost useability.
+
+   We believe that resolution of these ambiguities will lead to a
+   greatly accelerated implementation schedule, at least here at UCLA-
+   NMC.
+
+       [ 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 1]
+