Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 3659


Extensions to FTP

Part 3 of 3, p. 36 to 61
Prev RFC Part


prevText      Top      Up      ToC       Page 36 
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.

Top      Up      ToC       Page 37 
   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

Top      Up      ToC       Page 38 
   and server, not formats that would normally ever be reported to the
   user of the client.

7.7.1.  Simple MLST

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

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.

Top      Up      ToC       Page 39 
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.

Top      Up      ToC       Page 40 
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.

Top      Up      ToC       Page 41 
   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

Top      Up      ToC       Page 42 
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

S> 250-Begin
S>  type=dir;unique=AQkAAAAAAAABCAAA; /
S> 250 End.
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

Top      Up      ToC       Page 43 
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

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

Top      Up      ToC       Page 44 
D> Type=file;Size=699;Modify=19950911140000; no-bok
S> 226 MLSD completed
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

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

   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

Top      Up      ToC       Page 45 
   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

   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

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

Top      Up      ToC       Page 46 
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>  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.
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

Top      Up      ToC       Page 47 
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

S> 227 Entering Passive Mode (127,0,0,1,255,46)
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.
S> 257 "/sub" is current directory.
S> 227 Entering Passive Mode (127,0,0,1,255,44)

Top      Up      ToC       Page 48 
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...
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.
S> 257 "/sub/dir/ect" is current directory.
S> 227 Entering Passive Mode (127,0,0,1,255,40)
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.
S> 227 Entering Passive Mode (127,0,0,1,255,36)
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...

Top      Up      ToC       Page 49 
C> RNFR mlst.c
S> 350 File exists, ready for destination name
C> RNTO list.c
S> 250 RNTO command successful.
S> 227 Entering Passive Mode (127,0,0,1,255,34)
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

Top      Up      ToC       Page 50 
   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>  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>  MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;;unique;
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.

Top      Up      ToC       Page 51 
S> 211-Features supported
S>  MLST Type*;Size*;Modify*;Perm;Unique*;
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

Top      Up      ToC       Page 52 
   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

Top      Up      ToC       Page 53 
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
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

Top      Up      ToC       Page 54 
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;
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.

Top      Up      ToC       Page 55 
      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

   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.

Top      Up      ToC       Page 56 
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

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.

Top      Up      ToC       Page 57 
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

   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].

Top      Up      ToC       Page 58 
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.

   [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.

Top      Up      ToC       Page 59 

   This document is a product of the FTPEXT working group of the IETF.

   The following people are among those who have contributed to this

      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.

Top      Up      ToC       Page 60 
Author's Address

   Paul Hethmon
   Hethmon Software
   10420 Jackson Oaks Way, Suite 201
   Knoxville, TN 37922


Top      Up      ToC       Page 61 
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

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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.