summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc775.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc775.txt')
-rw-r--r--doc/rfc/rfc775.txt311
1 files changed, 311 insertions, 0 deletions
diff --git a/doc/rfc/rfc775.txt b/doc/rfc/rfc775.txt
new file mode 100644
index 0000000..6bcf85e
--- /dev/null
+++ b/doc/rfc/rfc775.txt
@@ -0,0 +1,311 @@
+
+
+
+
+
+ RFC 775 Directory oriented FTP commands Page 1
+
+
+
+ DIRECTORY ORIENTED FTP COMMANDS
+
+ David Mankins (dm@bbn-unix)
+ Dan Franklin (dan@bbn-unix)
+ A. D. Owen (ADOwen@bbnd)
+
+
+ As a part of the Remote Site Maintenance (RSM) project for ARPA,
+ BBN has installed and maintains the software of several DEC PDP-
+ 11s running the Unix operating system. Since Unix has a tree-
+ like directory structure, in which directories are as easy to
+ manipulate as ordinary files, we have found it convenient to
+ expand the FTP servers on these machines to include commands
+ which deal with the creation of directories. Since there are
+ other hosts on the ARPA net which have tree-like directories,
+ including Tops-20 and Multics, we have tried to make these
+ commands as general as possible.
+
+ We have added four commands to our server:
+
+
+
+ XMKD child
+ Make a directory with the name "child".
+
+ XRMD child
+ Remove the directory with the name "child".
+
+ XPWD
+ Print the current working directory.
+
+ XCUP
+ Change to the parent of the current working
+ directory.
+
+
+
+ The "child" argument should be created (removed) as a
+ subdirectory of the current working directory, unless the "child"
+ string contains sufficient information to specify otherwise to
+ the server, e.g., "child" is an absolute pathname (in Multics and
+ Unix), or child is something like "<abso.lute.path>" to Tops-20.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RFC 775 Directory oriented FTP commands Page 2
+
+
+
+ REPLY CODES
+
+ The XCUP command is a special case of XCWD, and is included to
+ simplify the implementation of programs for transferring
+ directory trees between operating systems having different
+ syntaxes for naming the parent directory. Therefore we recommend
+ that the reply codes for XCUP be identical to the reply codes of
+ XCWD.
+
+ Similarly, we recommend that the reply codes for XRMD be
+ identical to the reply codes for its file analogue, DELE.
+
+ The reply codes for XMKD, however, are a bit more complicated. A
+ freshly created directory will probably be the object of a future
+ XCWD command. Unfortunately, the argument to XMKD may not always
+ be a suitable argument for XCWD. This is the case, for example,
+ when a Tops-20 subdirectory is created by giving just the
+ subdirectory name. That is, with a Tops-20 server FTP, the
+ command sequence
+
+ XMKD MYDIR
+ XCWD MYDIR
+
+ will fail. The new directory may only be referred to by its
+ "absolute" name; e.g., if the XMKD command above were issued
+ while connected to the directory <DFRANKLIN>, the new
+ subdirectory could only be referred to by the name
+ <DFRANKLIN.MYDIR>.
+
+ Even on Unix and Multics, however, the argument given to XMKD may
+ not be suitable. If it is a "relative" pathname (that is, a
+ pathname which is interpreted relative to the current directory),
+ the user would need to be in the same current directory in order
+ to reach the subdirectory. Depending on the application, this
+ may be inconvenient. It is not very robust in any case.
+
+ To solve these problems, upon successful completion of an XMKD
+ command, the server should return a line of the form:
+
+ 257<space>"<directory-name>"<space><commentary>
+
+ That is, the server will tell the user what string to use when
+ referring to the created directory. The directory name can
+ contain any character; embedded double-quotes should be escaped
+
+
+
+
+
+
+
+
+
+
+
+ RFC 775 Directory oriented FTP commands Page 3
+
+
+
+ by double-quotes (the "quote-doubling" convention).
+
+ For example, a user connects to the directory /usr/dm, and
+ creates a subdirectory, named child:
+
+ XCWD /usr/dm
+ 200 directory changed to /usr/dm
+ XMKD child
+ 257 "/usr/dm/child" directory created
+
+ An example with an embedded double quote:
+
+ XMKD foo"bar
+ 257 "/usr/dm/foo""bar" directory created
+ XCWD /usr/dm/foo"bar
+ 200 directory changed to /usr/dm/foo"bar
+
+ We feel that the prior existence of a subdirectory with the same
+ name should be interpreted as an error, and have implemented our
+ server to give an "access denied" error reply in that case.
+
+ CWD /usr/dm
+ 200 directory changed to /usr/dm
+ XMKD child
+ 521-"/usr/dm/child" directory already exists;
+ 521 taking no action.
+
+ We recommend that failure replies for XMKD be analogous to its
+ file creating cousin, STOR. Also, we recommend that an "access
+ denied" return be given if a file name with the same name as the
+ subdirectory will conflict with the creation of the subdirectory
+ (this is a problem on Unix, but shouldn't be one on Tops-20).
+
+ Essentially because the XPWD command returns the same type of
+ information as the successful XMKD command, we have implemented
+ the successful XPWD command to use the 257 reply code as well.
+
+ We present here a summary of the proposed reply codes for the
+ experimental commands. The codes given outside parentheses are
+ consistent with RFC 691; i.e., are for the old protocol, as
+ updated by the suggestions in that RFC. The server and user
+ programs at BBN-Unix currently implement these codes. Reply 257
+ is the only new code. Reply codes shown within parentheses are
+ for the "new" ftp protocol, most recently documented in RFC 765.
+
+
+
+
+
+
+
+
+
+
+
+ RFC 775 Directory oriented FTP commands Page 4
+
+
+
+ The invented code for the RFC 765 Protocol is 251.
+
+ Command:
+
+ reply code explanation
+
+
+ XMKD create directory
+
+ 257 (251) "pathname" created
+ 521 (450) "pathname" already exists
+ 506 (502) action not implemented
+ 521 (450) access denied
+ 550 (501) bad pathname syntax or ambiguous
+ 425 (451) random file system error
+
+ XCUP change directory to
+ superior of current one
+
+ 200 (200) working directory changed
+ 506 (502) action not implemented
+ 507 (551) no superior directory
+ 521 (450) access denied
+ 425 (451) random file system error
+
+ XRMD remove directory
+
+ 224 (250) deleted ok
+ 506 (502) action not implemented
+ 521 (450) access denied
+ 550 (501) bad pathname syntax or ambiguous
+ 425 (451) random file system error
+
+ XPWD print current working
+ directory
+
+ 257 (251) "pathname"
+ 425 (451) random file system error
+ 506 (502) action not implemented
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RFC 775 Directory oriented FTP commands Page 5
+
+
+ SUBTLETIES
+
+ Because these commands will be most useful in transferring
+ subtrees from one machine to another, we must stress the fact
+ that the argument to XMKD is to be interpreted as a sub-directory
+ of the current working directory, unless it contains enough
+ information for the destination host to tell otherwise. A
+ hypothetical example of its use in the Tops-20 world:
+
+ XCWD <some.where>
+ 200 Working directory changed
+ XMKD overrainbow
+ 257 "<some.where.overrainbow>" directory created
+ XCWD overrainbow
+ 431 No such directory
+ XCWD <some.where.overrainbow>
+ 200 Working directory changed
+
+ XCWD <some.where>
+ 200 Working directory changed to <some.where>
+ XMKD <unambiguous>
+ 257 "<unambiguous>" directory created
+ XCWD <unambiguous>
+
+ Note that the first example results in a subdirectory of the
+ connected directory. In contrast, the argument in the second
+ example contains enough information for Tops-20 to tell that the
+ <unambiguous> directory is a top-level directory. Note also that
+ in the first example the user "violated" the protocol by
+ attempting to access the freshly created directory with a name
+ other than the one returned by Tops-20. Problems could have
+ resulted in this case had there been an <overrainbow> directory;
+ this is an ambiguity inherent in some Tops-20 implementations.
+ Similar considerations apply to the XRMD command. The point is
+ this: except where to do so would violate a host's conventions
+ for denoting relative versus absolute pathnames, the host should
+ treat the operands of the XMKD and XRMD commands as
+ subdirectories. The 257 reply to the XMKD command must always
+ contain the absolute pathname of the created directory.
+
+
+
+ References
+
+ File Transfer Protocol (RFC 765), Postel, J., June 1980
+
+
+
+
+
+
+
+
+
+
+ RFC 775 Directory oriented FTP commands Page 6
+
+
+
+ CWD Command of FTP (RFC 697), Lieb, J., NIC 32963, 14 July 1975
+ One More Try on the FTP (RFC 691), Harvey, B., NIC 32700, 28 May
+ 1975
+ Revised FTP Reply Codes (RFC 640), Postel, J., N. Neigus, K.
+ Pogran, NIC 30843, 5 June 1974
+ File Transfer Protocol (RFC 542), Neigus, N., NIC 17759, 12 July
+ 1977
+