summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc238.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc238.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc238.txt')
-rw-r--r--doc/rfc/rfc238.txt114
1 files changed, 114 insertions, 0 deletions
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]
+