draft-ietf-ftpext-mlst-15.txt

ProFTPd 是一款基于GPL协议的可配置的FTP服务器

   With the sole exception of the "/" character, any valid IS10646
   character [11] may be used in a TVFS file name.  When transmitted,
   file name characters are encoded using the UTF-8 encoding [2].











Elz & Hethmon            [Expires October 2002]                [Page 17]

Internet Draft        draft-ietf-ftpext-mlst-15.txt           April 2002


6.2. TVFS Pathnames

   A TVFS "Pathname" combines the file or directory name of a target
   file or directory, with the directory names of zero or more enclosing
   directories, so as to allow the target file or directory to be
   referenced other than when the server's "current working directory"
   is the directory directly containing the target file or directory.

   By definition, every TVFS file or directory name is also a TVFS
   pathname.  Such a pathname is valid to reference the file from the
   directory containing the name, that is, when that directory is the
   server-FTP's current working directory.

   Other TVFS pathnames are constructed by prefixing a pathname by a
   name of a directory from which the path is valid, and separating the
   two with the "/" character.  Such a pathname is valid to reference
   the file or directory from the directory containing the newly added
   directory name.

   Where a pathname has been extended to the point where the directory
   added is the unnamed root directory, the pathname will begin with the
   "/" character.  Such a path is known as a fully qualified pathname.
   Fully qualified paths may, obviously, not be further extended, as, by
   definition, no directory contains the root directory.  Being unnamed,
   it cannot be represented in any other directory.  A fully qualified
   pathname is valid to reference the named file or directory from any
   location (that is, regardless of what the current working directory
   may be) in the virtual file store.

   Any pathname which is not a fully qualified pathname may be referred
   to as a "relative pathname" and will only correctly reference the
   intended file when the current working directory of the server-FTP is
   a directory from which the relative pathname is valid.

   As a special case, the pathname "/" is defined to be a fully
   qualified pathname referring to the root directory.  That is, the
   root directory does not have a directory (or file) name, but does
   have a pathname.  This special pathname may be used only as is as a
   reference to the root directory.  It may not be combined with other
   pathnames using the rules above, as doing so would lead to a pathname
   containing two consecutive "/" characters, which is an undefined
   sequence.









Elz & Hethmon            [Expires October 2002]                [Page 18]

Internet Draft        draft-ietf-ftpext-mlst-15.txt           April 2002


6.2.1. Notes

     + It is not required, or expected, that there be only one fully
       qualified pathname that will reference any particular file or
       directory.
     + As a caveat, though the TVFS file store is basically tree
       structured, there is no requirement that any file or directory
       have only one parent directory.
     + As defined, no TVFS pathname will ever contain two consecutive
       "/" characters.  Such a name is not illegal however, and may be
       defined by the server for any purpose that suits it.  Clients
       implementing this specification should not assume any semantics
       at all for such names.
     + Similarly, other than the special case path that refers to the
       root directory, no TVFS pathname constructed as defined here will
       ever end with the "/" character.  Such names are also not
       illegal, but are undefined.
     + While any legal IS10646 character is permitted to occur in a TVFS
       file or directory name, other than "/", server FTP
       implementations are not required to support all possible IS10646
       characters.  The subset supported is entirely at the discretion
       of the server.  The case (where it exists) of the characters that
       make up file, directory, and pathnames may be significant.
       Unless determined otherwise by means unspecified here, clients
       should assume that all such names are comprised of characters
       whose case is significant.  Servers are free to treat case (or
       any other attribute) of a name as irrelevant, and hence map two
       names which appear to be distinct onto the same underlying file.
     + There are no defined "magic" names, like ".", ".." or "C:".
       Servers may implement such names, with any semantics they choose,
       but are not required to do so.
     + TVFS imposes no particular semantics or properties upon files,
       guarantees no access control schemes, or any of the other common
       properties of a file store.  Only the naming scheme is defined.

6.3. FEAT Response for TVFS

   In response to the FEAT command [6] a server that wishes to indicate
   support for the TVFS as defined here will include a line that begins
   with the four characters "TVFS" (in any case, or mixture of cases,
   upper case is not required).  Servers SHOULD send upper case.

   Such a response to the FEAT command MUST NOT be returned unless the
   server implements TVFS as defined here.

   Later specifications may add to the TVFS definition.  Such additions
   should be notified by means of additional text appended to the TVFS
   feature line.  Such specifications, if any, will define the extra



Elz & Hethmon            [Expires October 2002]                [Page 19]

Internet Draft        draft-ietf-ftpext-mlst-15.txt           April 2002


   text.

   Until such a specification is defined, servers should not include
   anything after "TVFS" in the TVFS feature line.  Clients, however,
   should be prepared to deal with arbitrary text following the four
   defined characters, and simply ignore it if unrecognized.

   A typical response to the FEAT command issued by a server
   implementing only this specification would be:

        C> feat
        S> 211- <any descriptive text>
        S>  ...
        S>  TVFS
        S>  ...
        S> 211 end

   The ellipses indicate place holders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory [6], and is not counted as one of the
   first four characters for the purposes of this feature listing.

   The TVFS feature adds no new commands to the FTP command repertoire.

6.4. OPTS for TVFS

   There are no options in this TVFS specification, and hence there is
   no OPTS command defined.

6.5. TVFS Examples

   Assume a TVFS file store is comprised of a root directory, which
   contains two directories (A and B) and two non-directory files (X and
   Y).  The A directory contains two directories (C and D) and one other
   file (Z).  The B directory contains just two non-directory files (P
   and Q) and the C directory also two non-directory files (also named P
   and Q, by chance).  The D directory is empty, that is, contains no
   files or directories.













Elz & Hethmon            [Expires October 2002]                [Page 20]

Internet Draft        draft-ietf-ftpext-mlst-15.txt           April 2002


   This structure may depicted graphically as...

                      (unnamed root)
                        /  |  \   \
                       /   |   \   \
                      A    X    B   Y
                     /|\       / \
                    / | \     /   \
                   C  D  Z   P     Q
                  / \
                 /   \
                P     Q

   Given this structure, the following fully qualified pathnames exist.

        /
        /A
        /B
        /X
        /Y
        /A/C
        /A/D
        /A/Z
        /A/C/P
        /A/C/Q
        /B/P
        /B/Q

   It is clear that none of the paths / /A /B or /A/D refer to the same
   directory, as the contents of each is different.  Nor do any of / /A
   /A/C or /A/D.  However /A/C and /B might be the same directory, there
   is insufficient information given to tell.  Any of the other
   pathnames (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the
   same underlying files, in almost any combination.

   If the current working directory of the server-FTP is /A then the
   following pathnames, in addition to all the fully qualified
   pathnames, are valid

        C
        D
        Z
        C/P
        C/Q

   These all refer to the same files or directories as the corresponding
   fully qualified path with "/A/" prepended.




Elz & Hethmon            [Expires October 2002]                [Page 21]

Internet Draft        draft-ietf-ftpext-mlst-15.txt           April 2002


   That those pathnames all exist does not imply that the TVFS sever
   will necessarily grant any kind of access rights to the named paths,
   or that access to the same file via different pathnames will
   necessarily be granted equal rights.

   None of the following relative paths are valid when the current
   directory is /A

        A
        B
        X
        Y
        B/P
        B/Q
        P
        Q

   Any of those could be made valid by changing the server-FTP's current
   working directory to the appropriate directory.  Note that the paths
   "P" and "Q" might refer to different files depending upon which
   directory is selected to cause those to become valid TVFS relative
   paths.

7. Listings for Machine Processing (MLST and MLSD)

   The MLST and MLSD commands are intended to standardize the file and
   directory information returned by the Server-FTP process.  These
   commands differ from the LIST command in that the format of the
   replies is strictly defined although extensible.

   Two commands are defined, MLST which provides data about exactly the
   object named on its command line, and no others.  MLSD on the other
   hand will list the contents of a directory if a directory is named,
   otherwise a 501 reply will be returned.  In either case, if no object
   is named, the current directory is assumed.  That will cause MLST to
   send a one line response, describing the current directory itself,
   and MLSD to list the contents of the current directory.

   In the following, the term MLSx will be used wherever either MLST or
   MLSD may be inserted.

   The MLST and MLSD commands also extend the FTP protocol as presented
   in RFC 959 [3] and RFC 1123 [9] to allow that transmission of 8-bit
   data over the control connection.  Note this is not specifying
   character sets which are 8-bit, but specifying that FTP
   implementations are to specifically allow the transmission and
   reception of 8-bit bytes, with all bits significant, over the control
   connection.  That is, all 256 possible octet values are permitted.



Elz & Hethmon            [Expires October 2002]                [Page 22]

Internet Draft        draft-ietf-ftpext-mlst-15.txt           April 2002


   The MLSx command allows both UTF-8/Unicode and "raw" forms as
   arguments, and in responses both to the MLST and MLSD commands, and
   all other FTP commands which take pathnames as arguments.

7.1. Format of MLSx Requests

   The MLST and MLSD commands each allow a single optional argument.
   This argument may be either a directory name or, for MLST only, a
   file name.  For these purposes, a "file name" is the name of any
   entity in the server NVFS which is not a directory.  Where TVFS is
   supported, any TVFS relative pathname valid in the current working
   directory, or any TVFS fully qualified pathname, may be given.  If a
   directory name is given then MLSD must return a listing of the
   contents of the named directory, otherwise it issues a 501 reply, and