RFC 3659
Extensions to FTP
7.6. System Dependent and Local Facts
By using an system dependent fact, or a local fact, a server-PI may communicate to the user-PI information about the file named that is peculiar to the underlying file system.7.6.1. System Dependent Facts
System dependent fact names are labeled by prefixing a label identifying the specific information returned by the name of the appropriate operating system from the IANA maintained list of operating system names. The value of an OS dependent fact may be whatever is appropriate to convey the information available. It must be encoded as a "token" as defined in 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.7.6.2. Local Facts
Implementations may also make available other facts of their own choosing. As the method of interpretation of such information will generally not be widely understood, server-PIs should be aware that clients will typically ignore any local facts provided. As there is no registration of locally defined facts, it is entirely possible that different servers will use the same local fact name to provide vastly different information. Hence user-PIs should be hesitant about making any use of any information in a locally defined fact without some other specific assurance that the particular fact is one that they do comprehend. Local fact names all begin with the sequence "X.". The rest of the name is a "token" (see section 2.1). The value of a local fact can be anything at all, provided it can be encoded as a "token".7.7. MLSx Examples
The following examples are all taken from dialogues between existing FTP clients and servers. Because of this, not all possible variations of possible response formats are shown in the examples. This should not be taken as limiting the options of other server implementors. Where the examples show OS dependent information, that is to be treated as being purely for the purposes of demonstration of some possible OS specific information that could be defined. As at the time of the writing of this document, no OS specific facts or file types have been defined, the examples shown here should not be treated as in any way to be preferred over other possible similar definitions. Consult the IANA registries to determine what types and facts have been defined. Finally also beware that as the examples shown are taken from existing implementations, coded before this document was completed, the possibility of variations between the text of this document and the examples exists. In any such case of inconsistency, the example is to be treated as incorrect. In the examples shown, only relevant commands and responses have been included. This is not to imply that other commands (including authentication, directory modification, PORT or PASV commands, or similar) would not be present in an actual connection, or were not, in fact, actually used in the examples before editing. Note also that the formats shown are those that are transmitted between client
and server, not formats that would normally ever be reported to the user of the client.7.7.1. Simple MLST
C> PWD S> 257 "/tmp" is current directory. C> MLst cap60.pl198.tar.gz S> 250- Listing cap60.pl198.tar.gz S> Type=file;Size=1024990;Perm=r; /tmp/cap60.pl198.tar.gz S> 250 End The client first asked to be told the current directory of the server. This was purely for the purposes of clarity of this example. The client then requested facts about a specific file. The server returned the "250-" first control-response line, followed by a single line of facts about the file, followed by the terminating "250 " line. The text on the control-response line and the terminating line can be anything the server decides to send. Notice that the fact line is indented by a single space. Notice also that there are no spaces in the set of facts returned, until the single space before the file name. The file name returned on the fact line is a fully qualified pathname of the file listed. The facts returned show that the line refers to a file, that file contains approximately 1024990 bytes, though more or less than that may be transferred if the file is retrieved, and a different number may be required to store the file at the client's file store, and the connected user has permission to retrieve the file but not to do anything else particularly interesting.7.7.2. MLST of a directory
C> PWD S> 257 "/" is current directory. C> MLst tmp S> 250- Listing tmp S> Type=dir;Modify=19981107085215;Perm=el; /tmp S> 250 End Again the PWD is just for the purposes of demonstration for the example. The MLST fact line this time shows that the file listed is a directory, that it was last modified at 08:52:15 on the 7th of November, 1998 UTC, and that the user has permission to enter the directory, and to list its contents, but not to modify it in any way. Again, the fully qualified pathname of the directory listed is given.
7.7.3. MLSD of a directory
C> MLSD tmp S> 150 BINARY connection open for MLSD tmp D> Type=cdir;Modify=19981107085215;Perm=el; tmp D> Type=cdir;Modify=19981107085215;Perm=el; /tmp D> Type=pdir;Modify=19990112030508;Perm=el; .. D> Type=file;Size=25730;Modify=19940728095854;Perm=; capmux.tar.z D> Type=file;Size=1830;Modify=19940916055648;Perm=r; hatch.c D> Type=file;Size=25624;Modify=19951003165342;Perm=r; MacIP-02.txt D> Type=file;Size=2154;Modify=19950501105033;Perm=r; uar.netbsd.patch D> Type=file;Size=54757;Modify=19951105101754;Perm=r; iptnnladev.1.0.sit.hqx D> Type=file;Size=226546;Modify=19970515023901;Perm=r; melbcs.tif D> Type=file;Size=12927;Modify=19961025135602;Perm=r; tardis.1.6.sit.hqx D> Type=file;Size=17867;Modify=19961025135602;Perm=r; timelord.1.4.sit.hqx D> Type=file;Size=224907;Modify=19980615100045;Perm=r; uar.1.2.3.sit.hqx D> Type=file;Size=1024990;Modify=19980130010322;Perm=r; cap60.pl198.tar.gz S> 226 MLSD completed In this example notice that there is no leading space on the fact lines returned over the data connection. Also notice that two lines of "type=cdir" have been given. These show two alternate names for the directory listed, one a fully qualified pathname, and the other a local name relative to the servers current directory when the MLSD was performed. Note that all other file names in the output are relative to the directory listed, though the server could, if it chose, give a fully qualified pathname for the "type=pdir" line. This server has chosen not to. The other files listed present a fairly boring set of files that are present in the listed directory. Note that there is no particular order in which they are listed. They are not sorted by file name, by size, or by modify time. Note also that the "perm" fact has an empty value for the file "capmux.tar.z" indicating that the connected user has no permissions at all for that file. This server has chosen to present the "cdir" and "pdir" lines before the lines showing the content of the directory, it is not required to do so. The "size" fact does not provide any meaningful information for a directory, so is not included in the fact lines for the directory types shown.
7.7.4. A More Complex Example
C> MLst test S> 250- Listing test S> Type=dir;Perm=el;Unique=keVO1+ZF4 test S> 250 End C> MLSD test S> 150 BINARY connection open for MLSD test D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test D> Type=pdir;Perm=e;Unique=keVO1+d?3; .. D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar D> Type=OS.unix=chr-13/29;Perm=;Unique=keVO1+5G4; device D> Type=OS.unix=blk-11/108;Perm=;Unique=keVO1+6G4; block D> Type=file;Perm=awr;Unique=keVO1+8G4; writable D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous D> Type=dir;Perm=;Unique=keVO1+1t2; no-exec D> Type=file;Perm=r;Unique=keVO1+EG4; two words D> Type=file;Perm=r;Unique=keVO1+IH4; leading space D> Type=file;Perm=r;Unique=keVO1+1G4; file1 D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; incoming D> Type=file;Perm=r;Unique=keVO1+1G4; file2 D> Type=file;Perm=r;Unique=keVO1+1G4; file3 D> Type=file;Perm=r;Unique=keVO1+1G4; file4 S> 226 MLSD completed C> MLSD test/incoming S> 150 BINARY connection open for MLSD test/incoming D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming D> Type=pdir;Perm=el;Unique=keVO1+ZF4; .. D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar D> Type=file;Perm=awdrf;Unique=keVO1+LH4; D> Type=file;Perm=rf;Unique=keVO1+1G4; file5 D> Type=file;Perm=rf;Unique=keVO1+1G4; file6 D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty S> 226 MLSD completed For the purposes of this example the fact set requested has been modified to delete the "size" and "modify" facts, and add the "unique" fact. First, facts about a file name have been obtained via MLST. Note that no fully qualified pathname was given this time. That was because the server was unable to determine that information. Then having determined that the file name represents a directory, that directory has been listed. That listing also shows no fully qualified pathname, for the same reason, thus has but a single "type=cdir" line. This directory (which was created especially for the purpose) contains several interesting files. There are some with OS dependent file types, several sub-directories, and several ordinary files.
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.
7.7.5. More Accurate Time Information
C> MLst file1 S> 250- Listing file1 S> Type=file;Modify=19990929003355.237; file1 S> 250 End In this example, the server-FTP is indicating that "file1" was last modified 237 milliseconds after 00:33:55 UTC on the 29th of September, 1999.7.7.6. A Different Server
C> MLST S> 250-Begin S> type=dir;unique=AQkAAAAAAAABCAAA; / S> 250 End. C> MLSD S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABCAAA; / D> type=dir;unique=AQkAAAAAAAABEAAA; bin D> type=dir;unique=AQkAAAAAAAABGAAA; etc D> type=dir;unique=AQkAAAAAAAAB8AwA; halflife D> type=dir;unique=AQkAAAAAAAABoAAA; incoming D> type=dir;unique=AQkAAAAAAAABIAAA; lib D> type=dir;unique=AQkAAAAAAAABWAEA; linux D> type=dir;unique=AQkAAAAAAAABKAEA; ncftpd D> type=dir;unique=AQkAAAAAAAABGAEA; outbox D> type=dir;unique=AQkAAAAAAAABuAAA; quake2 D> type=dir;unique=AQkAAAAAAAABQAEA; winstuff S> 226 Listing completed. C> MLSD linux S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABWAEA; /linux D> type=pdir;unique=AQkAAAAAAAABCAAA; / D> type=dir;unique=AQkAAAAAAAABeAEA; firewall D> type=file;size=12;unique=AQkAAAAAAAACWAEA; helo_world D> type=dir;unique=AQkAAAAAAAABYAEA; kernel D> type=dir;unique=AQkAAAAAAAABmAEA; scripts D> type=dir;unique=AQkAAAAAAAABkAEA; security S> 226 Listing completed. C> MLSD linux/kernel S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABYAEA; /linux/kernel D> type=pdir;unique=AQkAAAAAAAABWAEA; /linux D> type=file;size=6704;unique=AQkAAAAAAAADYAEA; k.config D> type=file;size=7269221;unique=AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz D> type=file;size=12514594;unique=AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz
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.7.7.7. Some IANA Files
C> MLSD S> 150 BINARY connection open for MLSD . D> Type=cdir;Modify=19990219183438; /iana/assignments D> Type=pdir;Modify=19990112030453; .. D> Type=dir;Modify=19990219073522; media-types D> Type=dir;Modify=19990112033515; character-set-info D> Type=dir;Modify=19990112033529; languages D> Type=file;Size=44242;Modify=19990217230400; character-sets D> Type=file;Size=1947;Modify=19990209215600; operating-system-names S> 226 MLSD completed C> MLSD media-types S> 150 BINARY connection open for MLSD media-types D> Type=cdir;Modify=19990219073522; media-types D> Type=cdir;Modify=19990219073522; /iana/assignments/media-types D> Type=pdir;Modify=19990219183438; .. D> Type=dir;Modify=19990112033045; text D> Type=dir;Modify=19990219183442; image D> Type=dir;Modify=19990112033216; multipart D> Type=dir;Modify=19990112033254; video D> Type=file;Size=30249;Modify=19990218032700; media-types S> 226 MLSD completed C> MLSD character-set-info S> 150 BINARY connection open for MLSD character-set-info D> Type=cdir;Modify=19990112033515; character-set-info D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info D> Type=pdir;Modify=19990219183438; .. D> Type=file;Size=1234;Modify=19980903020400; windows-1251 D> Type=file;Size=4557;Modify=19980922001400; tis-620 D> Type=file;Size=801;Modify=19970324130000; ibm775 D> Type=file;Size=552;Modify=19970320130000; ibm866 D> Type=file;Size=922;Modify=19960505140000; windows-1258 S> 226 MLSD completed C> MLSD languages S> 150 BINARY connection open for MLSD languages D> Type=cdir;Modify=19990112033529; languages D> Type=cdir;Modify=19990112033529; /iana/assignments/languages D> Type=pdir;Modify=19990219183438; .. D> Type=file;Size=2391;Modify=19980309130000; default D> Type=file;Size=943;Modify=19980309130000; tags D> Type=file;Size=870;Modify=19971026130000; navajo
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.7.7.8. A Stress Test of Case (In)dependence
The following example is intended to make clear some cases where case dependent strings are permitted in the MLSx commands, and where case independent strings are required. Note first that the "MLSD" command, shown here as "MlsD" is case independent. Clients may issue this command in any case, or combination of cases, they desire. This is the case for all FTP commands. C> MlsD S> 150 BINARY connection open for MLSD . D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; .. D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1 S> 226 MLSD completed Next, notice the labels of the facts. These are also case- independent strings; the server-FTP is permitted to return them in any case desired. User-FTP must be prepared to deal with any case, though it may do this by mapping the labels to a common case if desired. Then, notice that there are nine objects of "type" file returned. In a case-independent NVFS these would represent three different file names, "file1", "file2", and "file3". With a case-dependent NVFS all nine represent different file names. Either is possible, server-FTPs may implement a case dependent or a case independent NVFS. User-FTPs must allow for case dependent selection of files to manipulate on the server.
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.
7.7.9. Example from Another Server
C> MlsD
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150227;perm=el; /MISC
D> type=pdir;modify=19791231130000;perm=el; /
D> type=dir;modify=19990426150227;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; SRC
S> 226 Transfer finished successfully.
C> MlsD src
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src
D> type=pdir;modify=19990426150227;perm=el; /MISC
D> type=dir;modify=19990426150228;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; INSTALL
D> type=dir;modify=19990426150230;perm=el; INSTALLI
D> type=dir;modify=19990426150230;perm=el; TREES
S> 226 Transfer finished successfully.
C> MlsD src/install
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src/install
D> type=pdir;modify=19990426150228;perm=el; /MISC/src
D> type=file;modify=19990406234304;perm=r;size=20059; BOOTPC.C
D> type=file;modify=19980401170153;perm=r;size=278; BOOTPC.H
D> type=file;modify=19990413153736;perm=r;size=54220; BOOTPC.O
D> type=file;modify=19990223044003;perm=r;size=3389; CDROM.C
D> type=file;modify=19990413153739;perm=r;size=30192; CDROM.O
D> type=file;modify=19981119155324;perm=r;size=1055; CHANGELO
D> type=file;modify=19981204171040;perm=r;size=8297; COMMANDS.C
D> type=file;modify=19980508041749;perm=r;size=580; COMMANDS.H
...
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.
7.7.10. A Server Listing Itself
C> MLst f
S> 250-MLST f
S> Type=dir;Modify=20000710052229;Unique=AAD/AAAABIA; f
S> 250 End
C> CWD f
S> 250 CWD command successful.
C> MLSD
S> 150 Opening ASCII mode data connection for 'MLSD'.
D> Type=cdir;Unique=AAD/AAAABIA; .
D> Type=pdir;Unique=AAD/AAAAAAI; ..
D> Type=file;Size=987;Unique=AAD/AAAABIE; Makefile
D> Type=file;Size=20148;Unique=AAD/AAAABII; conf.c
D> Type=file;Size=11111;Unique=AAD/AAAABIM; extern.h
D> Type=file;Size=38721;Unique=AAD/AAAABIQ; ftpcmd.y
D> Type=file;Size=17922;Unique=AAD/AAAABIU; ftpd.8
D> Type=file;Size=60732;Unique=AAD/AAAABIY; ftpd.c
D> Type=file;Size=3127;Unique=AAD/AAAABIc; logwtmp.c
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.7.7.11. A Server with a Difference
C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,46) C> MLSD S> 150 I tink I tee a trisector tree D> Type=file;Unique=aaaaafUYqaaa;Perm=rf;Size=15741; x D> Type=cdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=file;Unique=aaaaajUYqaaa;Perm=rf;Size=5760; x4 D> Type=dir;Unique=aaabcaUYqaaa;Perm=elf; sub D> Type=file;Unique=aaaaagUYqaaa;Perm=rf;Size=8043; x1 D> Type=dir;Unique=aaab8aUYqaaa;Perm=cpmelf; files D> Type=file;Unique=aaaaahUYqaaa;Perm=rf;Size=4983; x2 D> Type=file;Unique=aaaaaiUYqaaa;Perm=rf;Size=6854; x3 S> 226 That's all folks... C> CWD sub S> 250 CWD command successful. C> PWD S> 257 "/sub" is current directory. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,44)
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.7.8. FEAT Response for MLSx
When responding to the FEAT command, a server-FTP process that supports MLST, and MLSD, plus internationalization of pathnames, MUST indicate that this support exists. It does this by including a MLST feature line. As well as indicating the basic support, the MLST feature line indicates which MLST facts are available from the server, and which of those will be returned if no subsequent "OPTS MLST" command is sent. mlst-feat = SP "MLST" [SP factlist] CRLF factlist = 1*( factname ["*"] ";" ) The initial space shown in the mlst-feat response is that required by the FEAT command, two spaces are not permitted. If no factlist is given, then the server-FTP process is indicating that it supports MLST, but implements no facts. Only pathnames can be returned. This would be a minimal MLST implementation, and useless for most practical purposes. Where the factlist is present, the factnames included indicate the facts supported by the server. Where the optional asterisk appears after a factname, that fact will be included in MLST format responses, until an "OPTS MLST" is given to alter the list of facts returned. After that, subsequent FEAT
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.7.8.1. Examples
C> Feat S> 211- Features supported S> REST STREAM S> MDTM S> SIZE S> TVFS S> UTF8 S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End Aside from some features irrelevant here, this server indicates that it supports MLST including several, but not all, standard facts, all of which it will send by default. It also supports two OS dependent facts, and one locally defined fact. The latter three must be requested expressly by the client for this server to supply them. C> Feat S> 211-Extensions supported: S> CLNT S> MDTM S> MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.group;unique; S> PASV S> REST STREAM S> SIZE S> TVFS S> Compliance Level: 19981201 (IETF mlst-05) S> 211 End. Again, in addition to some irrelevant features here, this server indicates that it supports MLST, four of the standard facts, one of which ("unique") is not enabled by default, and several OS dependent facts, one of which is provided by the server by default. This server actually supported more OS dependent facts. Others were deleted for the purposes of this document to comply with document formatting restrictions.
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.7.9. OPTS Parameters for MLST
For the MLSx commands, the Client-FTP may specify a list of facts it wishes to be returned in all subsequent MLSx commands until another OPTS MLST command is sent. The format is specified by: mlst-opts = "OPTS" SP "MLST" [ SP 1*( factname ";" ) ] By sending the "OPTS MLST" command, the client requests the server to include only the facts listed as arguments to the command in subsequent output from MLSx commands. Facts not included in the "OPTS MLST" command MUST NOT be returned by the server. Facts that are included should be returned for each entry returned from the MLSx command where they meaningfully apply. Facts requested that are not supported, or that are inappropriate to the file or directory being listed should simply be omitted from the MLSx output. This is not an error. Note that where no factname arguments are present, the client is requesting that only the file names be returned. In this case, and in any other case where no facts are included in the result, the space that separates the fact names and their values from the file name is still required. That is, the first character of the output line will be a space, (or two characters will be spaces when the line is returned over the control connection) and the file name will start immediately thereafter. Clients should note that generating values for some facts can be possible, but very expensive, for some servers. It is generally acceptable to retrieve any of the facts that the server offers as its default set before any "OPTS MLST" command has been given, however clients should use particular caution before requesting any facts not in that set. That is, while other facts may be available from the server, clients should refrain from requesting such facts unless
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.7.9.1. OPTS MLST Response
The "response-message" from [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 [6]. 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.7.9.2. Examples
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 Type;UNIX.mode;Perm; S> 200 MLST OPTS Type;Perm;UNIX.mode; 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 lang;type;charset;create; S> 200 MLST OPTS Type; 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 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.8. Impact on Other FTP Commands
Along with the introduction of MLST, traditional FTP commands must be extended to allow for the use of more than US-ASCII [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.
9. Character Sets and Internationalization
FTP commands are protocol elements, and are always expressed in
ASCII. FTP responses are composed of the numeric code, which is a
protocol element, and a message, which is often expected to convey
information to the user. It is not expected that users normally
interact directly with the protocol elements, rather the user-FTP
process constructs the commands, and interprets the results, in the
manner best suited for the particular user. Explanatory text in
responses generally has no particular meaning to the protocol. The
numeric codes provide all necessary information. Server-PIs are free
to provide the text in any language that can be adequately
represented in ASCII, or where an alternative language and
representation has been negotiated (see [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.
10. IANA Considerations
This specification makes use of some lists of values currently
maintained by the IANA, and creates two new lists for the IANA to
maintain. It does not add any values to any existing registries.
The existing IANA registries used by this specification are modified
using mechanisms specified elsewhere.
10.1. The OS-Specific Fact Registry
A registry of OS specific fact names shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a fact name to this OS specific registry of OS specific facts, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific fact name, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific fact name has not been previously defined, the IANA will add the specification to the registry. Any examples of OS specific facts found in this document are to be treated as examples of possible OS specific facts, and do not form a part of the IANA's registry merely because of being included in this document.10.2. The OS-Specific Filetype Registry
A registry of OS specific file types shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific file type has not been previously defined, the IANA will add the specification to the registry. Any examples of OS specific file types found in this document are to be treated as potential OS specific file types only, and do not form a part of the IANA's registry merely because of being included in this document.
11. Security Considerations
This memo does not directly concern security. It is not believed that any of the mechanisms documented here impact in any particular way upon the security of FTP. Implementing the SIZE command, and perhaps some of the facts of the MLSx commands, may impose a considerable load on the server, which could lead to denial of service attacks. Servers have, however, implemented this for many years, without significant reported difficulties. The server-FTP should take care not to reveal sensitive information about files to unauthorised parties. In particular, some underlying filesystems provide a file identifier that, if known, can allow many of the filesystem protection mechanisms to be by-passed. That identifier would not be a suitable choice to use as the basis of the value of the unique fact. The FEAT and OPTS commands may be issued before the FTP authentication has occurred [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 [13].
12. Normative References
[1] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. [2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [3] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [6] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998. [7] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999. [8] Postel, J. and J. Reynolds, "Telnet protocol Specification", STD 8, RFC 854, May 1983. [9] Braden, R,. "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. [10] ISO/IEC 10646-1:1993 "Universal multiple-octet coded character set (UCS) -- Part 1: Architecture and basic multilingual plane", International Standard -- Information Technology, 1993. [11] Internet Assigned Numbers Authority. http://www.iana.org Email: iana@iana.org. [12] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [13] Allman, M. and S. Ostermann, "FTP Security Considerations" RFC 2577, May 1999.
Acknowledgments
This document is a product of the FTPEXT working group of the IETF. The following people are among those who have contributed to this document: Alex Belits D. J. Bernstein Dave Cridland Martin J. Duerst Bill Fenner (and the rest of the IESG) Paul Ford-Hutchinson Mike Gleason Mark Harris Stephen Head Alun Jones Andrew Main James Matthews Luke Mewburn Jan Mikkelsen Keith Moore Buz Owen Mark Symons Stephen Tihor and the entire FTPEXT working group of the IETF. Apologies are offered to any inadvertently omitted. The description of the modifications to the REST command and the MDTM and SIZE commands comes from a set of modifications suggested for 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.RFC Editor Note:
Several of the examples in this document exceed the RFC standard line length of 72 characters. Since this document is a standards-track result of an IETF working group and is important to an IETF sub- community, the RFC Editor is publishing it with the margin violations. This is not a precedent.
Author's Address
Paul Hethmon Hethmon Software 10420 Jackson Oaks Way, Suite 201 Knoxville, TN 37922 EMail: phethmon@hethmon.com
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 ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.