section 2.1 however.
In order to allow reliable inter-operation between users of system dependent facts, the IANA will maintain a registry of system dependent fact names, their syntax, and the interpretation to be given to their values. Registrations of system dependent facts are to be accomplished according to the procedures of section 10. section 2.1). The value of a local fact can be anything at all, provided it can be encoded as a "token".
and server, not formats that would normally ever be reported to the user of the client.
Not much can be said here about the OS dependent file types, as none of the information shown there should be treated as any more than possibilities. It can be seen that the OS type of the server is "unix" though, which is one of the OS types in the IANA registry of Operating System names. Of the three directories listed, "no-exec" has no permission granted to this user to access at all. From the "Unique" fact values, it can be determined that "promiscuous" and "incoming" in fact represent the same directory. Its permissions show that the connected user has permission to do essentially anything other than to delete the directory. That directory was later listed. It happens that the directory can not be deleted because it is not empty. Of the normal files listed, two contain spaces in their names. The file called " leading space" actually contains two spaces in its name, one before the "l" and one between the "g" and the "s". The two spaces that separate the facts from the visible part of the pathname make that clear. The file "writable" has the "a" and "w" permission bits set, and consequently the connected user should be able to STOR or APPE to that file. The other four file names, "file1", "file2", "file3", and "file4" all represent the same underlying file, as can be seen from the values of the "unique" facts of each. It happens that "file1" and "file2" are Unix "hard" links, and that "file3" and "file4" are "soft" or "symbolic" links to the first two. None of that information is available via standard MLST facts, it is sufficient for the purposes of FTP to note that all represent the same file, and that the same data would be fetched no matter which of them was retrieved, and that all would be simultaneously modified were data stored in any. Finally, the sub-directory "incoming" is listed. Since "promiscuous" is the same directory there would be no point listing it as well. In that directory, the files "file5" and "file6" represent still more names for the "file1" file we have seen before. Notice the entry between that for "bar" and "file5". Though it is not possible to easily represent it in this document, that shows a file with a name comprising exactly three spaces (" "). A client will have no difficulty determining that name from the output presented to it however. The directory "empty" is, as its name implies, empty, though that is not shown here. It can, however, be deleted, as can file "bar" and the file whose name is three spaces. All the files that reside in this directory can be renamed. This is a consequence of the UNIX semantics of the directory that contains them being modifiable.
S> 226 Listing completed. Note that this server returns its "unique" fact value in quite a different format. It also returns fully qualified pathnames for the "pdir" entry.
D> Type=file;Size=699;Modify=19950911140000; no-bok S> 226 MLSD completed C> PWD S> 257 "/iana/assignments" is current directory. This example shows some of the IANA maintained files that are relevant for this specification in MLSD format. Note that these listings have been edited by deleting many entries, the actual listings are much longer.
Lastly, notice that the value of the "unique" fact is case dependent. In the example shown, "file1", "File1", and "file2" all have the same "unique" fact value "keVO1+bD8", and thus all represent the same underlying file. On the other hand, "FILE1" has a different "unique" fact value ("keVO1+bd8") and hence represents a different file. Similarly, "FILE2" and "File2" are two names for the same underlying file, whereas "file3", "File3" and "FILE3" all represent different underlying files. That the approximate sizes ("size" fact) and last modification times ("modify" fact) are the same in all cases might be no more than a coincidence. It is not suggested that the operators of server-FTPs create an NVFS that stresses the protocols to this extent; however, both user and server implementations must be prepared to deal with such extreme examples.
... D> type=file;modify=19990419052351;perm=r;size=54264; URLMETHO.O D> type=file;modify=19980218161629;perm=r;size=993; WINDOWS.C D> type=file;modify=19970912154859;perm=r;size=146; WINDOWS.H D> type=file;modify=19990413153731;perm=r;size=16812; WINDOWS.O D> type=file;modify=19990322174959;perm=r;size=129; _CVSIGNO D> type=file;modify=19990413153640;perm=r;size=82536; _DEPEND S> 226 Transfer finished successfully. C> MLst src/install/windows.c S> 250-Listing src/install/windows.c S> type=file;perm=r;size=993; /misc/src/install/windows.c S> 250 End S> ftp> mlst SRC/INSTALL/WINDOWS.C C> MLst SRC/INSTALL/WINDOWS.C S> 250-Listing SRC/INSTALL/WINDOWS.C S> type=file;perm=r;size=993; /misc/SRC/INSTALL/WINDOWS.C S> 250 End Note that this server gives fully qualified pathnames for the "pdir" and "cdir" entries in MLSD listings. Also notice that this server does, though it is not required to, sort its directory listing outputs. That may be an artifact of the underlying file system access mechanisms of course. Finally notice that the NVFS supported by this server, in contrast to the earlier ones, implements its pathnames in a case independent manner. The server seems to return files using the case in which they were requested, when the name was sent by the client, and otherwise uses an algorithm known only to itself to select the case of the names it returns.
D> Type=file;Size=2294;Unique=AAD/AAAABIg; pathnames.h D> Type=file;Size=7605;Unique=AAD/AAAABIk; popen.c D> Type=file;Size=9951;Unique=AAD/AAAABIo; ftpd.conf.5 D> Type=file;Size=5023;Unique=AAD/AAAABIs; ftpusers.5 D> Type=file;Size=3547;Unique=AAD/AAAABIw; logutmp.c D> Type=file;Size=2064;Unique=AAD/AAAABI0; version.h D> Type=file;Size=20420;Unique=AAD/AAAAAAM; cmds.c D> Type=file;Size=15864;Unique=AAD/AAAAAAg; ls.c D> Type=file;Size=2898;Unique=AAD/AAAAAAk; ls.h D> Type=file;Size=2769;Unique=AAD/AAAAAAo; lsextern.h D> Type=file;Size=2042;Unique=AAD/AAAAAAs; stat_flags.h D> Type=file;Size=5708;Unique=AAD/AAAAAAw; cmp.c D> Type=file;Size=9280;Unique=AAD/AAAAAA0; print.c D> Type=file;Size=4657;Unique=AAD/AAAAAA4; stat_flags.c D> Type=file;Size=2664;Unique=AAD/AAAAAA8; util.c D> Type=file;Size=10383;Unique=AAD/AAAABJ0; ftpd.conf.cat5 D> Type=file;Size=3631;Unique=AAD/AAAABJ4; ftpusers.cat5 D> Type=file;Size=17729;Unique=AAD/AAAABJ8; ftpd.cat8 S> 226 MLSD complete. This examples shows yet another server implementation, showing a listing of its own source code. Note that this implementation does not include the fully qualified path name in its "cdir" and "pdir" entries, nor in the output from "MLST". Also note that the facts requested were modified between the "MLST" and "MLSD" commands, though that exchange has not been shown here.
C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabceUYqaaa;Perm=elf; dir D> Type=file;Unique=aaabcbUYqaaa;Perm=rf;Size=0; y1 D> Type=file;Unique=aaabccUYqaaa;Perm=rf;Size=0; y2 D> Type=file;Unique=aaabcdUYqaaa;Perm=rf;Size=0; y3 D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=cdir;Unique=aaabcaUYqaaa;Perm=el; /sub S> 226 That's all folks... C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,42) C> MLSD dir S> 150 I tink I tee a trisector tree D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; /sub D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=r;Size=15039; mlst.c D> Type=dir;Unique=aaabcfUYqaaa;Perm=el; ect D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; dir D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=dir;Unique=aaabchUYqaaa;Perm=el; misc D> Type=file;Unique=aaab8bUYqaaa;Perm=r;Size=34589; ftpd.c S> 226 That's all folks... C> CWD dir/ect S> 250 CWD command successful. C> PWD S> 257 "/sub/dir/ect" is current directory. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,40) C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabcgUYqaaa;Perm=el; ory D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; .. D> Type=cdir;Unique=aaabcfUYqaaa;Perm=el; /sub/dir/ect S> 226 That's all folks... C> CWD /files S> 250 CWD command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,36) C> MLSD S> 150 I tink I tee a trisector tree D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; mlst.c D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c S> 226 That's all folks...
C> RNFR mlst.c S> 350 File exists, ready for destination name C> RNTO list.c S> 250 RNTO command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,34) C> MLSD S> 150 I tink I tee a trisector tree D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; list.c D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files S> 226 That's all folks... The server shown here returns its directory listings in seemingly random order, and even seems to modify the order of the directory as its contents change -- perhaps the underlying directory structure is based upon hashing of some kind. Note that the "pdir" and "cdir" entries are interspersed with other entries in the directory. Note also that this server does not show a "pdir" entry when listing the contents of the root directory of the virtual filestore; however, it does however include multiple "cdir" and "pdir" entries when it feels inclined. The server also uses obnoxiously "cute" messages.
commands will return the asterisk to show the facts selected by the most recent "OPTS MLST". Note that there is no distinct FEAT output for MLSD. The presence of the MLST feature indicates that both MLST and MLSD are supported.
C> FEAT S> 211-Features supported S> MDTM S> MLST Type*;Size*;Modify*;Perm;Unique*; S> REST STREAM S> SIZE S> TVFS S> 211 End This server has wisely chosen not to implement any OS dependent facts. At the time of writing this document, no such facts have been defined (using the mechanisms of section 10.1) so rational support for them would be difficult at best. All but one of the facts supported by this server are enabled by default.
there is a particular operational requirement for that particular information, which ought be more significant than perhaps simply improving the information displayed to an end user. Note, there is no "OPTS MLSD" command, the fact names set with the "OPTS MLST" command apply to both MLST and MLSD commands. Servers are not required to accept "OPTS MLST" commands before authentication of the user-PI, but may choose to permit them. 6] to a successful OPTS MLST command has the following syntax. mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ] This defines the "response-message" as used in the "opts-good" message in RFC 2389 . The facts named in the response are those that the server will now include in MLST (and MLSD) response, after the processing of the "OPTS MLST" command. Any facts from the request not supported by the server will be omitted from this response message. If no facts will be included, the list of facts will be empty. Note that the list of facts returned will be the same as those marked by a trailing asterisk ("*") in a subsequent FEAT command response. There is no requirement that the order of the facts returned be the same as that in which they were requested, or that in which they will be listed in a FEAT command response, or that in which facts are returned in MLST responses. The fixed string "MLST OPTS" in the response may be returned in any case, or mixture of cases.
S> 211- Features supported S> MLST Type*;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> OPTS mlst size;frogs; S> 200 MLST OPTS Size; C> Feat S> 211- Features supported S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> opts MLst unique type; S> 501 Invalid MLST options C> Feat S> 211- Features supported S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End For the purposes of this example, features other than MLST have been deleted from the output to avoid clutter. The example shows the initial default feature output for MLST. The facts requested are then changed by the client. The first change shows facts that are available from the server being selected. Subsequent FEAT output shows the altered features as being returned. The client then attempts to select some standard features that the server does not support. This is not an error, however the server simply ignores the requests for unsupported features, as the FEAT output that follows shows. Then, the client attempts to request a non-standard, and unsupported, feature. The server ignores that, and selects only the supported features requested. Lastly, the client sends a request containing a syntax error (spaces cannot appear in the factlist.) The server-FTP sends an error response and completely ignores the request, leaving the fact set selected as it had been previously. Note that in all cases, except the error response, the response lists the facts that have been selected. C> Feat S> 211- Features supported S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> Opts MLST S> 200 MLST OPTS C> Feat S> 211- Features supported S> MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> MLst tmp S> 250- Listing tmp S> /tmp
S> 250 End C> OPTS mlst unique;size; S> 200 MLST OPTS Size;Unique; C> MLst tmp S> 250- Listing tmp S> Unique=keVO1+YZ5; /tmp S> 250 End C> OPTS mlst unique;type;modify; S> 200 MLST OPTS Type;Modify;Unique; C> MLst tmp S> 250- Listing tmp S> Type=dir;Modify=19990930152225;Unique=keVO1+YZ5; /tmp S> 250 End C> OPTS mlst fish;cakes; S> 200 MLST OPTS C> MLst tmp S> 250- Listing tmp S> /tmp S> 250 End C> OptS Mlst Modify;Unique; S> 200 MLST OPTS Modify;Unique; C> MLst tmp S> 250- Listing tmp S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp S> 250 End C> opts MLst fish cakes; S> 501 Invalid MLST options C> MLst tmp S> 250- Listing tmp S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp S> 250 End This example shows the effect of changing the facts requested upon subsequent MLST commands. Notice that a syntax error leaves the set of selected facts unchanged. Also notice exactly two spaces preceding the pathname when no facts were selected, either deliberately, or because none of the facts requested were available. 1] or EBCDIC character sets. In general, the support of MLST requires support for arbitrary character sets wherever file names and directory names are allowed. This applies equally to both arguments given to the following commands and to the replies from them, as appropriate.
APPE RMD CWD RNFR DELE RNTO MKD STAT PWD STOR RETR STOU The arguments to all of these commands should be processed the same way that MLST commands and responses are processed with respect to handling embedded spaces, CRs and NULs. See section 2.2. 7]) in that language and representation. Pathnames are expected to be encoded in UTF-8 allowing essentially any character to be represented in a pathname. Meaningful pathnames are defined by the server NVFS. No restrictions at all are placed upon the contents of files transferred using the FTP protocols. Unless the "media-type" fact is provided in a MLSx response nor is any advice given here that would allow determining the content type. That information is assumed to be obtained via other means.
6]. This allows unauthenticated clients to determine which of the features defined here are supported, and to negotiate the fact list for MLSx output. No actual MLSx commands may be issued however, and no problems with permitting the selection of the format prior to authentication are foreseen. A general discussion of issues related to the security of FTP can be found in .
 Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.  Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.  Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.  Postel, J. and J. Reynolds, "Telnet protocol Specification", STD 8, RFC 854, May 1983.  Braden, R,. "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.  ISO/IEC 10646-1:1993 "Universal multiple-octet coded character set (UCS) -- Part 1: Architecture and basic multilingual plane", International Standard -- Information Technology, 1993.  Internet Assigned Numbers Authority. http://www.iana.org Email: firstname.lastname@example.org.  Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.  Allman, M. and S. Ostermann, "FTP Security Considerations" RFC 2577, May 1999.
STD 9, RFC 959 by Rick Adams in 1989. A document containing just those commands, edited by David Borman, has been merged with this document. Mike Gleason, Alun Jones and Luke Mewburn provided access to FTP servers used in some of the examples. All of the examples in this document are taken from actual client/server exchanges, though some have been edited for brevity, or to meet document formatting requirements.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.