From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc238.txt | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 114 insertions(+)
 create mode 100644 doc/rfc/rfc238.txt

(limited to 'doc/rfc/rfc238.txt')

diff --git a/doc/rfc/rfc238.txt b/doc/rfc/rfc238.txt
new file mode 100644
index 0000000..da97b7b
--- /dev/null
+++ b/doc/rfc/rfc238.txt
@@ -0,0 +1,114 @@
+
+
+
+
+
+
+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]
+
-- 
cgit v1.2.3