Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3659

Extensions to FTP

Pages: 61
Proposed Standard
Errata
Updates:  0959
Part 3 of 3 – Pages 36 to 61
First   Prev   None

Top   ToC   RFC3659 - Page 36   prevText

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   ToC   RFC3659 - 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   ToC   RFC3659 - Page 38
   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.
Top   ToC   RFC3659 - 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   ToC   RFC3659 - 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   ToC   RFC3659 - 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
   modifiable.
Top   ToC   RFC3659 - 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

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
Top   ToC   RFC3659 - 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

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
Top   ToC   RFC3659 - Page 44
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.
Top   ToC   RFC3659 - 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
   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
Top   ToC   RFC3659 - 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> 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
Top   ToC   RFC3659 - 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

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)
Top   ToC   RFC3659 - Page 48
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...
Top   ToC   RFC3659 - Page 49
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
Top   ToC   RFC3659 - 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> 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.
Top   ToC   RFC3659 - Page 51
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
Top   ToC   RFC3659 - 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   ToC   RFC3659 - 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
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
Top   ToC   RFC3659 - 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;
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.
Top   ToC   RFC3659 - 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 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.
Top   ToC   RFC3659 - 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 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.
Top   ToC   RFC3659 - 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 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].
Top   ToC   RFC3659 - 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. 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.
Top   ToC   RFC3659 - Page 59

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.
Top   ToC   RFC3659 - Page 60

Author's Address

Paul Hethmon Hethmon Software 10420 Jackson Oaks Way, Suite 201 Knoxville, TN 37922 EMail: phethmon@hethmon.com
Top   ToC   RFC3659 - 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
   "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.