From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc269.txt | 165 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 165 insertions(+) create mode 100644 doc/rfc/rfc269.txt (limited to 'doc/rfc/rfc269.txt') diff --git a/doc/rfc/rfc269.txt b/doc/rfc/rfc269.txt new file mode 100644 index 0000000..86fc8ac --- /dev/null +++ b/doc/rfc/rfc269.txt @@ -0,0 +1,165 @@ + + + + + + +Network Working Group H. Brodie +Request for Comments #269 UCLA-NMC +NIC # 7817 6 December 71 +Categories: File Transfer +Updates: 122, 238, 172 +Obsoletes: None + + + Some Experience with File Transfer + +At UCLA-NMC we have recently completed implementation of a program which +utilizes UCSB's storage capability via their Simple Minded File System +(See RFC #122 by Jim White for a description of SMFS). The use of the +program is detailed in Appendix A. + +We learned a number of things in the implementation effort and +subsequent usage. We think a number of these apply towards the +development of a net- word-wide File Transfer Protocol, and we hope to +stimulate further dis- cussion of these issues. We discovered some +things in the UCSB protocol that we would like to see included in the +network-wide protocol, and we see some things that are in the currently +proposed net protocol and are unfortunately absent from the UCSB +protocol. + +In the first category, is the UCSB file retrieval procedure. The user +specifies among other things, a bit count of the number of bits to be +retrieved in the current request. + +Successive RTF commands yield successive pieces of the file. Portions +of the file can be spaced over by use of the SPF command. We think that +the ability of the user to specify the size of the "chunks" of the file +he is about to receive, along with the ability to access any part of the +file without having to get the entire file, is definitely an advantage. +It makes the user programs easier to write since the problem of parsing +the input stream virtually disappears, as the user program knows exactly +what to expect at all times. In addition, the one request, one response +nature of the protocol avoids the problem of sending a request and then +receiving pieces of data of unpredictable size at unknown intervals. +The response to each RTF gives the comforting knowledge that "they're +still listening". This leads us to believe that there is much to be +gained by the adoption of a one request, one response type of protocol. +We might point out that for any significant file transfer, this does not +seriously cut down on the overall data transfer rate, since a +"defaulting" type of approach, as SMFS uses can be used to keep the +request messages very small. We also have found the mandatory password +scheme of UCSB quite easily used, and any server site, (i.e. a site +specifically advertising file storage) can reasonably be expected, in +our opinion, to require passwords (see also RFC #238 by R. Braden). + + + + [Page 1] + +Network Working Group H. Brodie +Request for Comments #269 UCLA-NMC +NIC #7817 6 December 71 + +Almost immediately after starting to use SMFS we found a serious lack in +one area. There is no way for a user to ask "what files do I have +there?" As a matter of fact, the author suspects that there are already +several files there which he has "forgotten" about! It is reasonable, +perhaps even necessary, for any server to supply a nicely formatted +character string describing the files stored there for this password, or +user, or whatever division is used. The listing should also contain +other pertinent information, such as date created, size etc. + +In the meantime, UCSB is providing the SEX system with valuable "out-of- +line on-line" storage, and we look forward to the development of a +widely accepted file transfer protocol, implemented on a large number of +server sites, hopefully equipped with low cost bulk storage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 2] + +SEX Notebook Appendix A H. Brodie +Section 23.29 3 December 71 + + FXFER + +FXFER is a re-entrant program written in Symbol which is used to send a +receive file from UCSB, using their Simple Minded File System. For the +description of the Network interface to SMFS, see RFC #122 by Jim White. + +Files are stored there in a paged format identical to the paged format +that the tape process uses:
... Thus a +file which Master lists as having n pages will take 2048 n bytes of +storage at UCSB. The user's sign-on initials are used as both the +access and modification passwords, so that if a file is sent under on +user's sign-on, they can only be retrieved or deleted by him. + +Commands + +PA - Increments "print All" counter. Different settings of this + counter yield different levels of program trace output on + the console. + +NP - No print. This sets the "Print All" counter to zero. + +DF FOO - This deletes the file "FOO" located at UCSB. + +PF FOO - This sends the file "FOO", pointed to by the user's root + directory, to UCSB. Only read access is needed to "FOO". + +GF FOO - The file "FOO" located at UCSB is retrieved and put in the + user's root (with write access). Note that it must have been + sent by the user to have the right password. + +RN FOO BAR - Rename the file "FOO" at UCSB to "BAR". The same password + restrictions as with PF and GF apply. (Not yet implemented) + +ST - Status. Tells what program is doing and how much its done. + +X - Exit Program. + +If the system and/or UCSB is particularly slow, then UCSBFIL may type a +time-out message. At this point the user has the option of continuing, +or exiting the program. The message is self-explanatory, as are most of +the program's messages. + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Nick Christenson 10/97] + + + + + [Page 3] + -- cgit v1.2.3