summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1068.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1068.txt')
-rw-r--r--doc/rfc/rfc1068.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc1068.txt b/doc/rfc/rfc1068.txt
new file mode 100644
index 0000000..23df465
--- /dev/null
+++ b/doc/rfc/rfc1068.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group A. DeSchon
+Request for Comments: 1068 R. Braden
+ ISI
+ August 1988
+
+ Background File Transfer Program (BFTP)
+
+
+Status of This Memo
+
+ This memo describes an Internet background file transfer service that
+ is built upon the third-party transfer model of FTP. No new
+ protocols are involved. The purpose of this memo is to stimulate
+ discussion on new Internet service modes. Distribution of this memo
+ is unlimited.
+
+1. Introduction
+
+ For a variety of reasons, file transfer in the Internet has generally
+ been implemented as an interactive or "foreground" service. That is,
+ a user runs the appropriate local FTP user interface program as an
+ interactive command and requests a file transfer to occur in real
+ time. If the transfer should fail to complete for any reason, the
+ user must reissue the transfer request. Foreground file transfer is
+ relatively simple to implement -- no subtleties of queuing or stable
+ storage -- and in the early days of networking it provided excellent
+ service, because the Internet/ARPANET was lightly loaded and
+ reasonably reliable.
+
+ More recently, the Internet has become increasingly subject to
+ congestion and long delays, particularly during times of peak usage.
+ In addition, as more of the world becomes interconnected, planned and
+ unplanned outages of hosts, gateways, and networks sometimes make it
+ difficult for users to successfully transfer files in foreground.
+
+ Performing file transfer asynchronously (i.e., in "background"),
+ provides a solution to some of these problems, by eliminating the
+ requirement for a human user to be directly involved at the time that
+ a file transfer takes place. A background file transfer service
+ requires two components: a user interface program to collect the
+ parameters describing the required transfer(s), and a file transfer
+ control (FTC) daemon to carry them out.
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 1]
+
+RFC 1068 August 1988
+
+
+ Background file transfer has a number of potential advantages for a
+ user:
+
+ o No Waiting
+
+ The user can request a large transfer and ignore it until a
+ notification message arrives through some common channel (e.g.,
+ electronic mail).
+
+ o End-to-end Reliability
+
+ The FTC daemon can try a transfer repeatedly until it either
+ succeeds or fails permanently. This provides reliable end-to-
+ end delivery of a file, in spite of the source or destination
+ host being down or poor Internet connectivity during some time
+ period.
+
+ o Multiple File Delivery
+
+ In order for background file transfer to be accepted in the
+ Internet, it may have to include some "value-added" services.
+ One such service would be an implementation of a multiple file
+ transfer capability for all hosts. Such a facility is suggested
+ in RFC-959 (see the description of "NLST") and implemented in
+ some User-FTP programs.
+
+ o Deferred Delivery
+
+ The user may wish to defer a large transfer until an off-peak
+ period. This may become important when parts of the Internet
+ adopt accounting and traffic-based cost-recovery mechanisms.
+
+
+ There is a serious human-engineering problem with background file
+ transfer: if the user makes a mistake in entering parameters, this
+ mistake may not become apparent until much later. This can be the
+ cause of severe user frustration. To avoid this problem, the user
+ interface program ought to verify the correctness of as many of the
+ parameters as possible when they are entered. Of course, such
+ foreground verification of parameters is not possible if the remote
+ host to which the parameters apply is currently unreachable.
+
+ To explore the usefulness of background file transfer in the present
+ Internet, we have implemented a file-mover service which we call the
+ Background File Transfer Program or BFTP.
+
+ Section 2 describes BFTP and Section 3 presents our experience and
+ conclusions. The appendices contain detailed information about the
+
+
+
+DeSchon & Braden [Page 2]
+
+RFC 1068 August 1988
+
+
+ user interface language for BFTP, a description of the program
+ organization, and sample execution scripts.
+
+2. Background File Transfer Program
+
+ 2.1 General Model
+
+ In the present BFTP design, its user interface program and its FTC
+ daemon program must execute on the same host, which we call the
+ BFTP control host.
+
+ Through the user interface program, a BFTP user will supply all of
+ the parameters needed to transfer a file from source host S to
+ destination host D, where S and D may be different from the BFTP
+ control host. These parameters include:
+
+ o S and D host names,
+
+ o login names and passwords on S and D hosts, and
+
+ o S and D file names (and optionally, directories).
+
+
+ The user may also specify a number of optional control parameters:
+
+ * Source file disposition -- Copy, move (i.e., copy and
+ delete), or simply delete the source file. The default is
+ copy.
+
+ * Destination file operation -- Create/Replace, append to, or
+ create a unique destination file. The default is
+ create/replace ("STOR").
+
+ * FTP Parameters -- Explicitly set any of the FTP type, mode,
+ or structure parameters at S and D hosts.
+
+ * Multiple Transfers -- Enable "wildcard" matching to perform
+ multiple transfers.
+
+ * Start Time -- Set the time of day for the first attempt of
+ the transfer. The default is "now" (i.e., make the first
+ attempt as soon as the request has been queued for the FTC
+ daemon).
+
+
+ Finally, the user specifies a mailbox to which a completion
+ notification message will be sent, and "submits" the request to
+ the FTC daemon queue. The user can then exit the BFTP user
+
+
+
+DeSchon & Braden [Page 3]
+
+RFC 1068 August 1988
+
+
+ interface program.
+
+ If the transfer should fail permanently, the FTC daemon will send
+ a notification message to the user's mailbox. In the event of a
+ temporary failure (e.g., a broken TCP connection), the FTC daemon
+ will log the failure and retry the transfer after some timeout
+ period. The retry cycles will be repeated until the transfer
+ succeeds or until some maximum number of tries specified has been
+ reached. In either case, a notification message will then be sent
+ to the user's mailbox.
+
+ The user can check on the progress of the transfer by reentering
+ the BFTP user interface program, supplying a key that was defined
+ with the request, and displaying the current status of the
+ request. The user may then cancel the request or leave it in the
+ queue.
+
+ The BFTP program includes a server-Telnet module, so it can be
+ executed as a remotely-accessible service that can be reached via
+ a Telnet connection to the BFTP well-known port (152). This
+ allows a user on any Internet host to perform background file
+ transfers without running BFTP locally, but instead opening a
+ Telnet connection to port 152 on a BFTP service host. Of course,
+ a user can also run the local BFTP user interface program directly
+ on any host that supports it and for which the user has login
+ privileges.
+
+ The next section discusses how BFTP uses standard FTP servers to
+ perform the transfers, while the following section covers the user
+ interface of BFTP.
+
+ 2.2 File Transfer Mechanics for BFTP
+
+ The BFTP makes use of the "third party" or "Server-Server" model
+ incorporated in the Internet File Transfer Protocol [RFC-959].
+ Thus, the FTC daemon opens FTP control connections to the existing
+ FTP servers on source host S and destination host D and instructs
+ them to transfer the desired file(s) from S to D. The S and D
+ hosts may be any two Internet hosts supporting FTP servers (but at
+ least one of them must support the FTP "PASV" command). This
+ approach allows the implementation of a background file transfer
+ capability for the entire Internet at a very low cost.
+
+ Figure 1 illustrates the BFTP model of operation. Note that the
+ BFTP control host is not necessarily the same as S or D. Figure 2
+ illustrates the FTP command interchange used in a typical Server-
+ Server file transfer operation; this may be compared with the
+ User-Server FTP scenario illustrated in Section 7 of RFC-959.
+
+
+
+DeSchon & Braden [Page 4]
+
+RFC 1068 August 1988
+
+
+ Since BFTP may be asked to transfer files between any two hosts in
+ the Internet, it must support all the file types and transfer
+ modes that are defined in RFC-959, not just a subset implemented
+ by particular hosts.
+
+ BFTP supports the transfer of a set of files in a single request,
+ using the standard technique:
+
+ (1) Send an NLST command to the source host S, specifying a
+ pathname containing "wildcard" characters. The reply will
+ contain a list of matching source file names.
+
+ (2) Execute a separate transfer operation for each file in this
+ list. The destination file name in each case is assumed to
+ be the same as the source file name; this requires that these
+ names be compatible with the naming conventions of D.
+
+ It will typically be necessary to specify working directories for
+ the transfers at S and D, so the file names will be simple,
+ unstructured names on each system.
+
+ This approach depends upon the wildcard matching capability of the
+ source host S. A more general implementation would acquire a
+ complete list of the file names from the source host and do the
+ matching in the FTC daemon, for example using a regular-expression
+ matcher. Another useful extension would be a general pattern-
+ matching file name transformation capability (e.g., like the one
+ included in the 4.3BSD version of FTP) to generate appropriate
+ destination pathnames for multiple requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 5]
+
+RFC 1068 August 1988
+
+
+ Figure 1 -- BFTP Model of Operation
+
+
+
+
+
+ --------- Remote
+ | BFTP | (telnet) o User
+ Local | Network | <---------------- -|-
+ User o | Server | / \
+ -|- ---------
+ / \ | |
+ | |
+ | |
+ v v
+ ----------- (Submit +---+
+ | BFTP User | request) |---| Request
+ | Interface | ---------> |---| Queue
+ ----------- |---|
+ . +---+
+ . /
+ . /
+ (foreground . / (try/retry
+ request-- . / request)
+ see 2.3) v v
+ -------- +---+
+ | FTC | -------------> | | User
+ | Daemon | Notify | | Mailbox
+ -------- Message +---+
+ / \
+ / FTP \
+ / Control \
+ / Connections \
+ HOST S v v HOST D
+ -------- --------
+ | FTP | ===========> | FTP |
+ | Server | file | Server |
+ -------- transfer --------
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 6]
+
+RFC 1068 August 1988
+
+
+ Figure 2 -- Server-Server File Transfer
+
+
+
+ Server FTP BFTP Daemon Server FTP
+ HOST S HOST C HOST D
+ ---------- ----------- ----------
+
+ <-------- Open TCP Ctrl conn
+ Open TCP Ctrl conn -------->
+
+ <-------- (log in)
+ (login confirm.) -------->
+ (log in) -------->
+ <-------- (login confirm.)
+
+ <-------- TYPE, STRU, MODE, CWD
+ (confirmations) -------->
+ TYPE, STRU, MODE, CWD -------->
+ <-------- (confirmations)
+
+ <-------- PASV command
+ PASV confirm -------->
+ PORT command -------->
+ <-------- PORT confirm
+
+ RETR file -------->
+ <-------- STOR file
+ <------------------------------ Open TCP Data conn
+ <------------------------------ Send file
+ <------------------------------ Close Data conn
+ <-------- RETR confirm
+ STOR confirm -------->
+
+ <-------- QUIT command
+ QUIT command -------->
+ Close Ctrl conn -------->
+
+ <-------- Close Ctrl conn
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 7]
+
+RFC 1068 August 1988
+
+
+ BFTP currently utilizes the following Server-FTP commands [RFC-
+ 959]: USER, PASS, ACCT, PASV, PORT, RETR, STOR, STOU, CWD, NLST,
+ MODE, STRU, TYPE, and QUIT.
+
+ The FTC daemon attempts to work around FTP servers that fail to
+ support certain commands. For example, if a server does not
+ support the optional command "CWD", the FTC daemon will attempt to
+ construct a complete path name using the source directory name and
+ the source file name. However, it is necessary that at least one
+ of the two hosts support the FTP passive (PASV) command. While
+ many FTP server implementations support do this command, some (in
+ particular, the 4.2BSD FTP) do not. The PASV command was
+ officially listed as being optional in RFC-959.
+
+ 2.3 Reliable Delivery
+
+ The reliable delivery function of BFTP is analogous to reliable
+ delivery in a transport protocol like TCP. Both depend upon
+ repeated delivery attempts until success is achieved, and in both
+ cases the choice of the retry interval requires some care to
+ balance overhead against unresponsiveness.
+
+ Humans are impatient, but even their impatience has a limit. If
+ the file cannot be transferred "soon", a human will turn to
+ another project; typically, there is a tendency for the transfer
+ to become less urgent the longer the wait. The FTC daemon of BFTP
+ therefore starts each transfer request with a very short retry
+ interval -- e.g., 10 minutes -- and then doubles this interval for
+ successive retries, until a maximum interval -- e.g., 4 hours --
+ is reached. This is essentially the exponential backoff algorithm
+ of the Ethernet, which is also used by transport protocols such as
+ TCP, although BFTP and TCP have quite different rationales for the
+ algorithm.
+
+ We must also define the meaning of reliable transmission for a
+ multiple-transfer request. For example, the set of files selected
+ by wildcard characters in a pathname is not well defined; the set
+ may change while the request is pending, as files are created and
+ deleted. Furthermore, it is unreasonable to regard the entire
+ multiple transfer as a single atomic operation. Suppose that
+ transferring a set of files fails part way through; for an atomic
+ operation, the files which had been successfully transferred would
+ have to be deleted pending the next retry of the entire set. This
+ would be ridiculously inefficient and may be impossible (since the
+ communication path may be broken when it is time to issue the
+ deletion requests).
+
+
+
+
+
+DeSchon & Braden [Page 8]
+
+RFC 1068 August 1988
+
+
+ BFTP addresses these issues in the following manner:
+
+ * For a multiple file operation, the FTC daemon saves the file
+ name list returned by the first successful NLST command in
+ the request queue entry. This name list determines the set
+ of source files for the transfer; there can be no later
+ additions to the set.
+
+ * The FTC daemon maintains a transfer status pointer. On each
+ retry cycle, it tries to transfer only those files that have
+ not already been successfully transferred.
+
+ * The request is complete when all the individual file
+ transfers have been successful, a permanent failure has
+ occured, or when the retry limit is reached.
+
+ * The notification message to the user lists the status of each
+ of the multiple files.
+
+
+ 2.4 BFTP User Interface
+
+ The purpose of BFTP is to simplify the file transfer process and
+ to place the burden of reliability on the BFTP control host. We
+ have attempted to provide a "user friendly" command interface to
+ BFTP, similar in flavor to the user interface of the TOPS-20
+ operating system. This interface provides extensive prompting,
+ defaulting, and help facilities for every command.
+
+ For a list of all BFTP commands, the user may enter "?<Return>" at
+ the main BFTP prompt ("BFTP>"). Entering "help<Return>" and
+ "explain<Return>" will provide increasing levels of explanatory
+ material. To obtain information on a particular command, "help
+ <command name><Return>" may be entered. The 'quit' or 'exit'
+ command will exit from BFTP. Command and subcommand names may be
+ abbreviated to the shortest unique sequence for that context;
+ alternatively, a partial name can be automatically completed by
+ typing <Return>.
+
+ The normal procedure for a BFTP user is to set up a set of
+ parameters defining the desired transfer and then submit the
+ request to the FTC daemon. To give the user the maximum
+ flexibility, BFTP supports three modes of submission:
+
+ o Background Operation
+
+ To request a reliable background file transfer, the user will
+ issue the BFTP 'submit' command to the FTC daemon.
+
+
+
+DeSchon & Braden [Page 9]
+
+RFC 1068 August 1988
+
+
+ o Foreground Verification, Background Operation
+
+ The BFTP 'verify' command may be used to ascertain that file
+ transfer parameters are valid. It causes BFTP to connect to
+ the FTP servers on both the source and the destination hosts
+ (if possible), log into both, verify the FTP parameters, and
+ verify that the specified source file is present.
+
+ Once the 'verify' command has successfully completed, the
+ user can issue the 'submit' command to schedule the actual
+ file transfer.
+
+
+ o Foreground Operation
+
+ The BFTP 'transfer' command will perform the specified
+ third-party transfer in foreground mode. This is illustrated
+ by the dotted path bypassing the queue in Figure 1.
+
+
+ The easiest way to set up the parameters is to issue the 'prompt'
+ command, which will prompt the user for all of the basic
+ parameters required for most transfers. Certain unusual
+ parameters must be set with the 'set' command (see Appendix B for
+ details).
+
+ When entering any parameter, the following control characters may
+ be used:
+
+ ? will display help text for the parameter, indicating its
+ meaning, the choices, and the default, and then reprompt for
+ the parameter.
+
+ <ESC> will display the default value (or the last value set) for
+ this parameter. The user can accept this default by entering
+ <Return>, or else erase it with Control-W and enter a
+ different value for the parameter, followed by <Return> to
+ accept the entered value.
+
+ <Control-W>
+ will erase the value typed or displayed for current
+ parameter.
+
+ <Return>
+ will accept the value displayed for this parameter, and
+ continue to the next parameter, if any. If the user has not
+ typed a value or used <ESC> to display the default, <Return>
+ will display the default and then accept it.
+
+
+
+DeSchon & Braden [Page 10]
+
+RFC 1068 August 1988
+
+
+ It is important to provide a means for a user to obtain status
+ information about an earlier request or even to cancel an earlier
+ request. However, these functions, especially cancellation, must
+ be controlled by some user authentication. We did not want to
+ build a user authentication database with each BFTP instance or
+ require login to BFTP itself, and there is no Internet-wide user
+ authentication mechanism. We adopted the following weak
+ authentication mechanism as a compromise:
+
+ * When the 'submit' command is issued, it prompts the user for
+ a character string called a "keyword", which recorded with
+ the request.
+
+ * This keyword can be entered later as the argument to a 'find'
+ command, which will display the status of all requests with
+ matching keywords.
+
+ * Similarly, the keyword may be used to cancel the
+ corresponding request.
+
+ If two different users happen to choose the same keywords, of
+ course, this scheme will not protect each other's requests from
+ accidental or malicious cancellation. However, a notification
+ message will be sent at the time that a cancellation occurs.
+
+ To make a series of similar requests, the user needs only to
+ change the individual parameters that differ from the preceding
+ request and then issue a new 'submit' command, for each request.
+ There are commands for individually setting each of the parameters
+ that 'prompt' sets -- and 'time' -- to provide a shortcut for BFTP
+ experts. A simpler but lengthier procedure is to use the 'prompt'
+ command to run through the current set of parameters, reentering
+ the parameters that must change and using the sequence
+ <ESC><return> to retain the previous value for each of the others.
+ The same procedures may be used to correct a mistake made in
+ entering a particular parameter.
+
+ The current settings of all the BFTP parameters can be displayed
+ at any time with the 'status' command, while the 'clear' command
+ will return all parameters to their initial values. Finally, the
+ 'request' command allows the user to save the current set of
+ parameters in a file or to restore the parameters from a
+ previously-saved file.
+
+ There is also a window-based BFTP user interface for use on a Sun
+ Workstation, described in Appendix A. The complete list of BFTP
+ commands is presented in Appendix B.
+
+
+
+
+DeSchon & Braden [Page 11]
+
+RFC 1068 August 1988
+
+
+3. Experience and Conclusions
+
+ BFTP has been available to users at ISI for some months. Users have
+ reported a number of advantages of using BFTP:
+
+ (a) Some users prefer the prompting style of BFTP to the user
+ interface of the foreground FTP they normally use.
+
+ (b) The BFTP "verify" command allows the user to verify that host
+ names, passwords, and filenames are correct without having to
+ wait for the entire transfer to take place.
+
+ (c) Since results are returned through the mail system, a transfer
+ can occur without tying up a terminal line, a phone line, or
+ even a window.
+
+
+ BFTP must be able to communicate with a variety of Server-FTP
+ implementations, and we have observed much variation in the commands
+ supported, error handling, and the timing in these servers. Some of
+ the problems we have encountered are:
+
+ (1) Some systems (e.g., 4.2BSD) do not support the PASV command.
+
+ (2) 4.2/3BSD systems return a non-standard response to the NLST
+ command. Instead of returning a list of complete path-names,
+ they use an ad hoc format consisting of a directory name
+ followed by a list of files.
+
+ (3) 4.2/3BSD systems may return a "permanent negative completion
+ reply" (a 5xx FTP reply code) as a result of a communications
+ failure such as a broken TCP connection. According to RFC-959,
+ the appropriate response is a "transient negative completion
+ reply" (a 4xx FTP reply code), which would inform the BFTP that
+ the transfer should be retried.
+
+ (4) A number of servers return badly formatted responses. An
+ example of this is the 4.2/3BSD response to an NLST command for
+ a non-existent file name: an error string which is not preceded
+ by a numerical response code.
+
+
+ To diagnose problems that do occur, we have found it very useful to
+ have a complete record of the interchange between the FTC daemon and
+ the two FTP servers. This record is saved and is currently always
+ included in the notification message mailed to the user (see Appendix
+ D for an example). As we get more experience with this program, some
+ of the details of the transfer may be omitted from this log.
+
+
+
+DeSchon & Braden [Page 12]
+
+RFC 1068 August 1988
+
+
+ The use of library routines shared between modules makes it
+ relatively easy to implement additional user interface programs. We
+ are currently experimenting with a window version of BFTP, the
+ "bftptool", which runs in the SunView environment, and is described
+ in Appendix A. Some additional interfaces that might be useful are:
+
+ o A command line interface for use in shell scripts and
+ "Makefiles".
+
+ o A more general library interface which would make it easy to
+ invoke BFTP from a variety of programs.
+
+ o Additional full-screen form based interfaces, for example a tool
+ running in X-Window system environment.
+
+
+ Lastly, BFTP would benefit from the resolution of the following open
+ protocol issues:
+
+ o There currently exist no provisions for Internet-wide user
+ authentication. In the BFTP context, this means that passwords
+ required for a file transfer must be present in BFTP request
+ files. The security of these passwords is subject to the
+ limitations of the file system security on the BFTP control
+ host. Anonymous file transfer provides a partial solution, but
+ a more general, long term solution is needed.
+
+ o Better mechanisms are needed to cope with the diversity of real
+ file systems in the Internet.
+
+ For example, an extension could be made to the FTP protocol to
+ allow the daemon to learn the delimiter conventions of each host
+ file system. This could allow a more flexible and powerful
+ multiple-file facility in BFTP. This could include the
+ automatic transfer of directory subtrees, for example.
+
+
+4. References
+
+ [RFC-959] Postel, J., and J. Reynolds, "File Transfer Protocol
+ (FTP)", RFC-959, USC/Information Sciences Institute,
+ October 1985.
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 13]
+
+RFC 1068 August 1988
+
+
+Appendix A -- BFTP Implementation Structure
+
+ BFTP has been implemented on both a Sun workstation running Sun OS
+ 3.4 (based on 4.2BSD) and a VAX running 4.3BSD. The program modules
+ are: the local user interface programs "bftp", the Internet server
+ program "bftpd", and the FTC daemon "fts". BFTP makes use of the
+ "at" command, a UNIX batch job facility, to submit requests and
+ execute the daemon. An additional user interface program, the
+ "bftptool", is available for Sun OS 3.4, and runs in the SunView
+ environment.
+
+ BFTP keeps its state in a set of control files: request files,
+ command files, and message files. These files are stored in the home
+ directory specified for the environment of the process running
+ "bftp". If a user is running "bftp" directly, this will typically be
+ the user's home directory. In the case where a user has made a
+ Telnet connection to the well-known port 152 on a BFTP service host,
+ "bftp" is started by "bftpd" (or "inetd", indirectly). As a result,
+ the control files will be owned by the user-id under which "inetd"
+ was started, normally "root", and stored in the top level directory
+ "/". Note, however, that under BFTP all user files are written by
+ the FTP servers, which are presumed to enforce the operating systems'
+ access control conventions. Hence, BFTP does not constitute a system
+ integrity exposure.
+
+ A.1 User Interface Program
+
+ The BFTP user interface program "bftp" may be run directly via a
+ UNIX shell. Once the program has been started, the prompt "BFTP>"
+ will appear and commands may be entered. These commands are
+ described in detail in Appendix B.
+
+ A.2 Tool-Style User Interface Program
+
+ The BFTP user interface program "bftptool" may be started from a
+ shell window in the SunView environment on a Sun workstation. The
+ BFTP commands may be selected via the left mouse button. The
+ various file transfer parameters appear in a form-style interface;
+ defaults and multiple-choice style parameter values can be filled
+ in via menus. An advantage of this form-style interface program
+ is that it is possible to view all of the file transfer parameters
+ simultaneously, providing the user with a sense for which
+ parameter values might be mutually exclusive.
+
+ Help information can be displayed in a text subwindow by
+ positioning the on-screen mouse pointer over a command or a
+ parameter, and clicking the center mouse button. (No standard
+ mechanism for displaying help information is currently included in
+
+
+
+DeSchon & Braden [Page 14]
+
+RFC 1068 August 1988
+
+
+ the SunView package.)
+
+ The commands used in the "bftptool" are for the most part very
+ similar to the commands described in Appendix B. Request
+ submittal and the execution of the FTC daemon are identical for
+ the "bftp" and the "bftptool" interface programs.
+
+ A.3 Internet Server
+
+ The Internet server program "bftpd" can be invoked by opening a
+ Telnet connection to a well-known port, and does not require
+ login. The "bftpd" program runs under "inetd", the standard
+ BSD4.x well-known port dispatcher. When a SYN arrives for the
+ BFTP well-known port, "bftpd" opens the TCP connection and
+ performs Telnet negotiations. It then passes control to the user
+ interface "bftp" which allows the user to enter file transfer
+ requests.
+
+ A.4 BFTP Server Daemon
+
+ The BFTP file transfer control daemon program is named "fts" (for
+ "File Transfer Service"). This module contains code to actually
+ cause a single file transfer operation using the FTP server-server
+ model as shown in Figures 1 and 2. It is invoked with the command
+ "fts <request-file>". The <request-file> contains the necessary
+ parameters for the file transfer, in ASCII format, separated by
+ linefeeds. Such a request file may be created by the user
+ interface program, "bftp".
+
+ As a byproduct of the development of BFTP, "fts" represents a
+ server-server FTP driver that can be run independent of the "bftp"
+ program. Parameters used in the file transfer are read from a
+ request file, which is created and accessed via library routines
+ which can be shared between modules. This could be used to
+ perform FTP's under program control.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 15]
+
+RFC 1068 August 1988
+
+
+Appendix B: BFTP Command Summary
+
+ B.1 Special Editing Characters
+
+ In the "bftp" program, the special editing characters for command
+ words, subcommands, and parameter fields are as follows:
+
+ <return> Accept current command/field.
+ <escape> Complete current command/field, or display default.
+ <space> Complete and delimit current command.
+ <delete> Erase last character.
+ control-L Refresh screen.
+ control-R Refresh line.
+ control-U Erase line.
+ control-W Erase current token.
+ ? List legal options.
+
+ B.2 BFTP Commands
+
+ The remainder of Appendix B consists of a list of the BFTP
+ commands. Each command should be followed by a carriage-return.
+ In the description of the syntax for each command, square brackets
+ "[]" are used to indicate a ssubcommand, or a list of possible
+ subcommands, which are separated by the "|" character. Angle
+ brackets "<>" are used to indicate a description of a parameter
+ where the choices would be too numerous to list, for example
+ "<host name/number>".
+
+ B.2.1 Clear Command
+
+
+ Return all parameters to their default values.
+
+ clear
+
+ B.2.2 Destination Commands
+
+ Set the destination directory.
+
+ ddir <directory name>
+
+ Set the destination file name.
+
+ dfile <file name>
+
+ Set the destination host, user, and password.
+
+ dhost <host name/number> <login> <password>
+
+
+
+DeSchon & Braden [Page 16]
+
+RFC 1068 August 1988
+
+
+ B.2.3 Explain Command
+
+ Display a short explanation of how to use BFTP.
+
+ explain
+
+ B.2.4 Find Command
+
+ Find and display a previous request.
+
+ find
+
+ BFTP will prompt for the request id, which is printed when the
+ request is first submitted. An example of a request id is
+ "bftp583101774". BFTP also prompts for the request keyword, which
+ was determined by the user when the request was first submitted.
+ If no keyword was specified, a <CR> should be typed. If no
+ request id is entered, BFTP will display all requests which
+ contain a matching keyword.
+
+ RequestID (optional): <bftp-request-id>
+ RequestKeyword: <keyword>
+
+ After BFTP has displayed a summary of a matching request, it asks
+ whether the request is to be changed, or canceled.
+
+ Do you wish to change this request? [yes | no]
+ Do you wish to cancel this request? [yes | no]
+
+ If the user indicates that the request is to be changed, BFTP will
+ read in the parameters and cancel the existing request. At this
+ point the user may make any desired changes and use the "submit"
+ command to requeue the request. At this point a new request id
+ will be assigned and displayed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 17]
+
+RFC 1068 August 1988
+
+
+ Although this may happen extremely rarely, if at all, it is
+ possible that a system crash (or the interruption of the BFTP
+ program) at a particularly inopportune moment may leave a request
+ which is not queued. When the "find" command locates such a
+ request, it displays the warning:
+
+ Your request is NOT currently queued.
+
+ If this happens, the request may be read in and resubmitted using
+ the following procedure:
+
+ Your request is NOT currently queued.
+ Do you wish to change this request? yes
+
+ (BFTP displays the parameters that have been read in.)
+
+ Previous request canceled.
+ Use the 'submit' command to submit a new request.
+
+ B.2.5 Help Command
+
+ Print local help information.
+
+ help
+ help <command>
+
+ B.2.6 Quit Command
+
+ Clear parameters and exit the BFTP program.
+
+ quit
+
+ B.2.7 Prompt Command
+
+ Prompt for commonly-used parameters.
+
+ prompt
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 18]
+
+RFC 1068 August 1988
+
+
+ The following are the parameters that BFTP prompts for:
+
+ copy/move/delete: [copy | move | delete]
+ ascii/ebcdic/image/local:
+ [ascii|ebcdic] [nonprint|telnet|carriage-control]
+ or
+ [image]
+ or
+ [local] <byte size>
+ (see "set type" for additional information)
+
+ Source --
+ Host: <host name/number>
+ User: <login>
+ Password: <password>
+ Dir: <directory including a delimiter, e.g., "/" or ">">
+ (either an absolute path, or relative to the login)
+ File: <file name>
+
+ Destination --
+ Host: <host name/number>
+ User: <login>
+ Password: <password>
+ Dir: <directory>
+ File: <file name>
+
+ Once the prompting has been completed, the current values of all
+ parameters will be displayed. Parameters not mentioned in the
+ prompting will be initialized with default values, and may be
+ changed via the "set" commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 19]
+
+RFC 1068 August 1988
+
+
+ B.2.8 Request Commands
+
+ The request commands enable the user to save a set of BFTP
+ parameters in a "request-file" for future use. Subcommands are
+ provided to to list all available request-files, or to read,
+ write, or delete a request-file. All request-files are stored in
+ the user's home directory. Therefore, this facility is not
+ available when the user is accessing BFTP by telneting to port
+ 152.
+
+ Delete request file "bftp-save.name".
+
+ request delete <name>
+
+ List all bftp-save files.
+
+ request list
+
+ Read a request file in as the current request.
+
+ request load <name>
+
+ Save the current request in a file named "bftp-save.name".
+
+ request store <name>
+
+ B.2.9 Set Commands
+
+ The "set" commands have complex subcommand structures and are used
+ to set many of the less commonly used FTP parameters. The
+ subcommands of "set" are as follows:
+
+ Set the account for the source/destination login.
+
+ set account [source | destination] <account string>
+
+ Set to true to append to destination file.
+
+ set append [true | false]
+
+ The source file will be copied to the destination file name.
+
+ set copy
+
+ The source file will be deleted after the file has been moved or
+ copied.
+
+ set delete
+
+
+
+DeSchon & Braden [Page 20]
+
+RFC 1068 August 1988
+
+
+ Set the mailbox to which the results will be returned. The
+ mailbox should be in standard internet format, for example:
+ "deschon@isi.edu".
+
+ set mailbox <mailbox string>
+
+ Set the FTP transfer mode.
+
+ set mode [stream | block | compress]
+
+ The source file will be deleted after it has been copied.
+
+ set move
+
+ Set to true to transfer multiple files.
+
+ set multiple [true | false]
+
+ Set the port for the source/destination FTP connection.
+
+ set port [source | destination] <port number>
+
+ Set the FTP structure.
+
+ set structure [file | record | page]
+
+ Set the FTP type and format / byte size parameters. Note that a
+ normal text file is usually "ascii", and a "binary" file is often
+ the same as an "image" file.
+
+ set type [ascii|ebcdic] [nonprint|telnet|carriage-control]
+ or
+ set type [image]
+ or
+ set type [local] <byte size>
+
+ Set to true if the STOU command is to be used. If the STOU
+ command is supported by the destination host, the file will be
+ stored into a file having a unique file name.
+
+ set unique [true | false]
+
+ Set to true to display full FTP conversations for "verify" and
+ "transfer" commands.
+
+ set verbose [true | false]
+
+
+
+
+
+DeSchon & Braden [Page 21]
+
+RFC 1068 August 1988
+
+
+ B.2.10 Source Commands
+
+ Set the source directory.
+
+ sdir <directory name>
+
+ Set the source file name.
+
+ sfile <file name>
+
+ Set the source host, user, and password.
+
+ shost <host name/number> <login> <password>
+
+ B.2.11 Status Command
+
+ Display the current parameter values.
+
+ status
+
+ B.2.12 Submit Command
+
+ Submit the current request for background FTP.
+
+ submit
+
+ BFTP prompts for the following information:
+
+ StartTime: <date and/or time>
+ ReturnMailbox: <internet mailbox>
+ RequestKeyword: <made-up keyword>
+
+ B.2.13 Time Command
+
+ Set the start time, the starting retry interval, and the maximum
+ number of tries.
+
+ time <date and/or time> <minutes between tries>
+ <maximum number of tries>
+
+ B.2.14 Transfer Command
+
+ Perform the current request in the foreground.
+
+ transfer
+
+
+
+
+
+
+DeSchon & Braden [Page 22]
+
+RFC 1068 August 1988
+
+
+ B.2.15 Verify Command
+
+ Make the connections now to check parameters.
+
+ verify
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 23]
+
+RFC 1068 August 1988
+
+
+Appendix C: Example BFTP User Script
+
+ deschon.isi.edu 1% telnet hobgoblin.isi.edu 152
+ Trying 128.9.0.42 ...
+ Connected to hobgoblin.isi.edu.
+ Escape character is '^]'.
+
+ BFTP Server (hobgoblin.isi.edu)
+
+ Background File Transfer: For help, type '?', 'help', or 'explain'.
+
+ BFTP> prompt
+
+ Copy/Move/Delete: copy
+
+ Source --
+ Host: deschon.isi.edu
+ User: deschon
+ Password:
+ Dir: ./
+ File: foo*
+
+ Destination --
+ Host: venera.isi.edu
+ User: deschon
+ Password:
+ Dir: ./temp/
+ File: foo*
+
+ StartTime: Tue Oct 6 10:14:43 1987 (interval) 60 (tries) 5
+ ReturnMailbox: deschon@isi.edu
+ RequestPassword:
+
+ BFTP> set multiple true
+ BFTP> status
+ Request type: COPY
+
+ Source --
+ Host: 'deschon.isi.edu'
+ User: 'deschon'
+ Pass: SET
+ Acct: ''
+ Dir: './'
+ File: 'foo*'
+ Port: 21
+
+ Destination --
+ Host: 'venera.isi.edu'
+
+
+
+DeSchon & Braden [Page 24]
+
+RFC 1068 August 1988
+
+
+ User: 'deschon'
+ Pass: SET
+ Acct: ''
+ Dir: './temp/'
+ File:'foo*'
+ Port: 21
+
+ Structure: file, Mode: stream, Type: ascii, Format: nonprint
+ Multiple matching: TRUE
+ Return mailbox: 'deschon@isi.edu', Password: SET
+ Remaining tries: 5, Retry interval: 60 minutes
+
+ Start after Tue Oct 6 10:14:43 1987.
+
+ BFTP> submit
+ Checking parameters...
+
+ Request bftp560538880 submitted to run at 10:14 Oct 6.
+
+ BFTP> quit
+ bye
+ Connection closed by foreign host.
+ deschon.isi.edu 2%
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 25]
+
+RFC 1068 August 1988
+
+
+Appendix D: Sample BFTP Notification Message
+
+ Received-Date: Tue, 6 Oct 87 10:15:52 PDT
+ Date: Tue, 6 Oct 87 10:15:47 PDT
+ From: root (Operator)
+ Posted-Date: Tue, 6 Oct 87 10:15:47 PDT
+ To: deschon
+ Subject: BFTP Results: bftp560538880
+
+ Request bftp560538880 submitted to run at 10:14 Oct 6.
+
+ Tue Oct 6 10:15:22 1987: starting...
+
+ Request type: COPY
+ Source: deschon.isi.edu-deschon-XXX--21-./-foo*
+ Destination: venera.isi.edu-deschon-XXX--21-./temp/-
+ Stru: F, Mode: S, Type: A N, Creation: STOR
+ Multiple matching: TRUE
+ Return mailbox: 'deschon@isi.edu', Password: SET
+ Remaining tries: 5, Retry interval: 60 minutes
+
+ Connect to: deschon.isi.edu, 21
+ deschon.isi.edu ==> 220 deschon.isi.edu FTP server (Version 4.7
+ Sun Sep 14 12:44:57 PDT 1986) ready.
+ Connect to: venera.isi.edu, 21
+ venera.isi.edu ==> 220 venera.isi.edu FTP server (Version 4.107
+ Thu Mar 19 20:54:37 PST 1987) ready.
+ deschon.isi.edu <== USER deschon
+ deschon.isi.edu ==> 331 Password required for deschon.
+ deschon.isi.edu <== PASS XXX
+ deschon.isi.edu ==> 230 User deschon logged in.
+ venera.isi.edu <== USER deschon
+ venera.isi.edu ==> 331 Password required for deschon.
+ venera.isi.edu <== PASS XXX
+ venera.isi.edu ==> 230 User deschon logged in.
+ deschon.isi.edu <== CWD ./
+ deschon.isi.edu ==> 200 CWD command okay.
+ venera.isi.edu <== CWD ./temp/
+ venera.isi.edu ==> 250 CWD command successful.
+ deschon.isi.edu <== PORT 128,9,1,56,4,106
+ deschon.isi.edu ==> 200 PORT command okay.
+ deschon.isi.edu <== NLST foo*
+ deschon.isi.edu ==> 150 Opening data connection for /bin/ls
+ (128.9.1.56,1130) (0 bytes).
+ deschon.isi.edu ==> 226 Transfer complete.
+ deschon.isi.edu <== PASV
+ deschon.isi.edu ==> 502 PASV command not implemented.
+ venera.isi.edu <== PASV
+
+
+
+DeSchon & Braden [Page 26]
+
+RFC 1068 August 1988
+
+
+ venera.isi.edu ==> 227 Entering Passive Mode (128,9,0,32,6,200)
+ deschon.isi.edu <== PORT 128,9,0,32,6,200
+ deschon.isi.edu ==> 200 PORT command okay.
+ deschon.isi.edu <== RETR foo
+ venera.isi.edu <== STOR foo
+ deschon.isi.edu ==> 150 Opening data connection for foo
+ (128.9.0.32,1736) (0 bytes).
+ deschon.isi.edu ==> 226 Transfer complete.
+ venera.isi.edu ==> 150 Openning data connection for foo
+ (128.9.1.56,20).
+ venera.isi.edu ==> 226 Transfer complete.
+ venera.isi.edu <== PASV
+ venera.isi.edu ==> 227 Entering Passive Mode (128,9,0,32,6,201)
+ deschon.isi.edu <== PORT 128,9,0,32,6,201
+ deschon.isi.edu ==> 200 PORT command okay.
+ deschon.isi.edu <== RETR foo1
+ venera.isi.edu <== STOR foo1
+ deschon.isi.edu ==> 150 Opening data connection for foo1
+ (128.9.0.32,1737) (4 bytes).
+ deschon.isi.edu ==> 226 Transfer complete.
+ venera.isi.edu ==> 150 Openning data connection for foo1
+ (128.9.1.56,20).
+ venera.isi.edu ==> 226 Transfer complete.
+ deschon.isi.edu <== QUIT
+ venera.isi.edu <== QUIT
+
+ Tue Oct 6 10:15:39 1987: completed successfully.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeSchon & Braden [Page 27]
+ \ No newline at end of file