Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3659


Extensions to FTP

Part 2 of 3, p. 17 to 36
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 17 
6.  A Trivial Virtual File Store (TVFS)

   Traditionally, FTP has placed almost no constraints upon the file
   store (NVFS) provided by a server.  This specification does not alter
   that.  However, it has become common for servers to attempt to
   provide at least file system naming conventions modeled loosely upon
   those of the UNIX(TM) file system.  This is a tree-structured file
   system, built of directories, each of which can contain other
   directories, or other kinds of files, or both.  Each file and
   directory has a name relative to the directory that contains it,
   except for the directory at the root of the tree, which is contained
   in no other directory, and hence has no name of its own.

   That which has so far been described is perfectly consistent with the
   standard FTP NVFS and access mechanisms.  The "CWD" command is used
   to move from one directory to an embedded directory.  "CDUP" may be
   provided to return to the parent directory, and the various file
   manipulation commands ("RETR", "STOR", the rename commands, etc.) are
   used to manipulate files within the current directory.

   However, it is often useful to be able to reference files other than
   by changing directories, especially as FTP provides no guaranteed
   mechanism to return to a previous directory.  The Trivial Virtual
   File Store (TVFS), if implemented, provides that mechanism.

Top      Up      ToC       Page 18 
6.1.  TVFS File Names

   Where a server implements the TVFS, no elementary file name shall
   contain the character "/".  Where the underlying natural file store
   permits files, or directories, to contain the "/" character in their
   names, a server-PI implementing TVFS must encode that character in
   some manner whenever file or directory names are being returned to
   the user-PI, and reverse that encoding whenever such names are being
   accepted from the user-PI.

   The encoding method to be used is not specified here.  Where some
   other character is illegal in file and directory names in the
   underlying file store, a simple transliteration may be sufficient.
   Where there is no suitable substitute character a more complex
   encoding scheme, possibly using an escape character, is likely to be

   With the one exception of the unnamed root directory, a TVFS file
   name may not be empty.  That is, all other file names contain at
   least one character.

   With the sole exception of the "/" character, any valid IS10646
   character [10] may be used in a TVFS file name.  When transmitted,
   file name characters are encoded using the UTF-8 encoding [2].  Note
   that the two-character sequence CR LF occurring in a file name will
   make that name impossible to transmit over a data connection.
   Consequently, it should be avoided, or if that is impossible to
   achieve, it MUST be encoded in some reversible way.

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.

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

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

   +  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
      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

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

   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

Top      Up      ToC       Page 21 
   The ellipses indicate place holders where other features may be
   included, but 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.  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.


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


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

   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


   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

Top      Up      ToC       Page 23 
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 and MLSD.  MLST provides data about
   exactly the object named on its command line, and no others.  MLSD,
   on the other, lists the contents of a directory if a directory is
   named, otherwise a 501 reply is 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 STD 9, RFC 959 [3] and STD 3, 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.
   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
   does not open a data connection.  In all cases for MLST, a single set
   of fact lines (usually a single fact line) containing the information
   about the named file or directory shall be returned over the control
   connection, without opening a data connection.

   If no argument is given then MLSD must return a listing of the
   contents of the current working directory, and MLST must return a
   listing giving information about the current working directory
   itself.  For these purposes, the contents of a directory are whatever

Top      Up      ToC       Page 24 
   file or directory names (not pathnames) the server-PI will allow to
   be referenced when the current working directory is the directory
   named, and which the server-PI desires to reveal to the user-PI.
   Note that omitting the argument is the only defined way to obtain a
   listing of the current directory, unless a pathname that represents
   the directory happens to be known.  In particular, there is no
   defined shorthand name for the current directory.  This does not
   prohibit any particular server-PI implementing such a shorthand.

   No title, header, or summary, lines, or any other formatting, other
   than as is specified below, is ever returned in the output of an MLST
   or MLSD command.

   If the Client-FTP sends an invalid argument, the server-FTP MUST
   reply with an error code of 501.

   The syntax for the MLSx command is:

      mlst             = "MLst" [ SP pathname ] CRLF
      mlsd             = "MLsD" [ SP pathname ] CRLF

7.2.  Format of MLSx Response

   The format of a response to an MLSx command is as follows:

      mlst-response    = control-response / error-response
      mlsd-response    = ( initial-response final-response ) /

      control-response = "250-" [ response-message ] CRLF
                         1*( SP entry CRLF )
                         "250" [ SP response-message ] CRLF

      initial-response = "150" [ SP response-message ] CRLF
      final-response   = "226" SP response-message CRLF

      response-message = *TCHAR

      data-response    = *( entry CRLF )

      entry            = [ facts ] SP pathname
      facts            = 1*( fact ";" )
      fact             = factname "=" value
      factname         = "Size" / "Modify" / "Create" /
                         "Type" / "Unique" / "Perm" /
                         "Lang" / "Media-Type" / "CharSet" /
                         os-depend-fact / local-fact
      os-depend-fact   = <IANA assigned OS name> "." token

Top      Up      ToC       Page 25 
      local-fact       = "X." token
      value            = *SCHAR

   Upon receipt of an MLSx command, the server will verify the
   parameter, and if invalid return an error-response.  For this
   purpose, the parameter should be considered to be invalid if the
   client issuing the command does not have permission to perform the
   requested operation.

   If the parameter is valid, then for an MLST command, the server-PI
   will send the first (leading) line of the control response, the entry
   for the pathname given, or the current directory if no pathname was
   provided, and the terminating line.  Normally exactly one entry would
   be returned, more entries are permitted only when required to
   represent a file that is to have multiple "Type" facts returned.  In
   this case, the pathname component of every response MUST be

   Note that for MLST the fact set is preceded by a space.  That is
   provided to guarantee that the fact set cannot be accidentally
   interpreted as the terminating line of the control response, but is
   required even when that would not be possible.  Exactly one space
   exists between the set of facts and the pathname.  Where no facts are
   present, there will be exactly two leading spaces before the
   pathname.  No spaces are permitted in the facts, any other spaces in
   the response are to be treated as being a part of the pathname.

   If the command was an MLSD command, the server will open a data
   connection as indicated in section 3.2 of STD 9, RFC 959 [3].  If
   that fails, the server will return an error-response.  If all is OK,
   the server will return the initial-response, send the appropriate
   data-response over the new data connection, close that connection,
   and then send the final-response over the control connection.  The
   grammar above defines the format for the data-response, which defines
   the format of the data returned over the data connection established.

   The data connection opened for a MLSD response shall be a connection
   as if the "TYPE L 8", "MODE S", and "STRU F" commands had been given,
   whatever FTP transfer type, mode and structure had actually been set,
   and without causing those settings to be altered for future commands.
   That is, this transfer type shall be set for the duration of the data
   connection established for this command only.  While the content of
   the data sent can be viewed as a series of lines, implementations
   should note that there is no maximum line length defined.
   Implementations should be prepared to deal with arbitrarily long

Top      Up      ToC       Page 26 
   The facts part of the specification would contain a series of "file
   facts" about the file or directory named on the same line.  Typical
   information to be presented would include file size, last
   modification time, creation time, a unique identifier, and a
   file/directory flag.

   The complete format for a successful reply to the MLSD command would

      facts SP pathname CRLF
      facts SP pathname CRLF
      facts SP pathname CRLF

   Note that the format is intended for machine processing, not human
   viewing, and as such the format is very rigid.  Implementations MUST
   NOT vary the format by, for example, inserting extra spaces for
   readability, replacing spaces by tabs, including header or title
   lines, or inserting blank lines, or in any other way alter this
   format.  Exactly one space is always required after the set of facts
   (which may be empty).  More spaces may be present on a line if, and
   only if, the pathname presented contains significant spaces.  The set
   of facts must not contain any spaces anywhere inside it.  Facts
   should be provided in each output line only if they both provide
   relevant information about the file named on the same line, and they
   are in the set requested by the user-PI.  See section 7.9 (page 51).
   There is no requirement that the same set of facts be provided for
   each file, or that the facts presented occur in the same order for
   each file.

7.2.1.  Error Responses to MLSx commands

   Many of the 4xy and 5xy responses defined in section 4.2 of STD 9,
   RFC 959 [3] are possible in response to the MLST and MLSD commands.
   In particular, syntax errors can generate 500 or 501 replies.  Giving
   a pathname that exists but is not a directory as the argument to a
   MLSD command generates a 501 reply.  Giving a name that does not
   exist, or for which access permission (to obtain directory
   information as requested) is not granted will elicit a 550 reply.
   Other replies (530, 553, 503, 504, and any of the 4xy replies) are
   also possible in appropriate circumstances.

7.3.  File Name Encoding

   An FTP implementation supporting the MLSx commands must be 8-bit
   clean.  This is necessary in order to transmit UTF-8 encoded file
   names.  This specification recommends the use of UTF-8 encoded file

Top      Up      ToC       Page 27 
   names.  FTP implementations SHOULD use UTF-8 whenever possible to
   encourage the maximum inter-operability.

   File names are not restricted to UTF-8, however treatment of
   arbitrary character encodings is not specified by this standard.
   Applications are encouraged to treat non-UTF-8 encodings of file
   names as octet sequences.

   Note that this encoding is unrelated to that of the contents of the
   file, even if the file contains character data.

   Further information about file name encoding for FTP may be found in
   "Internationalization of the File Transfer Protocol" [7].

7.3.1.  Notes about the File Name

   The file name returned in the MLST response should be the same name
   as was specified in the MLST command, or, where TVFS is supported, a
   fully qualified TVFS path naming the same file.  Where no argument
   was given to the MLST command, the server-PI may either include an
   empty file name in the response, or it may supply a name that refers
   to the current directory, if such a name is available.  Where TVFS is
   supported, a fully qualified pathname of the current directory SHOULD
   be returned.

   File names returned in the output from an MLSD command SHOULD be
   unqualified names within the directory named, or the current
   directory if no argument was given.  That is, the directory named in
   the MLSD command SHOULD NOT appear as a component of the file names

   If the server-FTP process is able, and the "type" fact is being
   returned, it MAY return in the MLSD response, an entry whose type is
   "cdir", which names the directory from which the contents of the
   listing were obtained.  Where TVFS is supported, the name MAY be the
   fully qualified pathname of the directory, or MAY be any other
   pathname that is valid to refer to that directory from the current
   working directory of the server-FTP.  Where more than one name
   exists, multiple of these entries may be returned.  In a sense, the
   "cdir" entry can be viewed as a heading for the MLSD output.
   However, it is not required to be the first entry returned, and may
   occur anywhere within the listing.

   When TVFS is supported, a user-PI can refer to any file or directory
   in the listing by combining a type "cdir" name, with the appropriate
   name from the directory listing using the procedure defined in
   section 6.2.

Top      Up      ToC       Page 28 
   Alternatively, whether TVFS is supported or not, the user-PI can
   issue a CWD command ([3]) giving a name of type "cdir" from the
   listing returned, and from that point reference the files returned in
   the MLSD response from which the cdir was obtained by using the file
   name components of the listing.

7.4.  Format of Facts

   The "facts" for a file in a reply to a MLSx command consist of
   information about that file.  The facts are a series of keyword=value
   pairs each followed by semi-colon (";") characters.  An individual
   fact may not contain a semi-colon in its name or value.  The complete
   series of facts may not contain the space character.  See the
   definition or "RCHAR" in section 2.1 for a list of the characters
   that can occur in a fact value.  Not all are applicable to all facts.

   A sample of a typical series of facts would be: (spread over two
   lines for presentation here only)


7.5.  Standard Facts

   This document defines a standard set of facts as follows:

      size       -- Size in octets
      modify     -- Last modification time
      create     -- Creation time
      type       -- Entry type
      unique     -- Unique id of file/directory
      perm       -- File permissions, whether read, write, execute is
                    allowed for the login id.
      lang       -- Language of the file name per IANA [11] registry.
      media-type -- MIME media-type of file contents per IANA registry.
      charset    -- Character set per IANA registry (if not UTF-8)

   Fact names are case-insensitive.  Size, size, SIZE, and SiZe are the
   same fact.

   Further operating system specific keywords could be specified by
   using the IANA operating system name as a prefix (examples only):

      OS/2.ea   -- OS/2 extended attributes
      MACOS.rf  -- MacIntosh resource forks
      UNIX.mode -- Unix file modes (permissions)

Top      Up      ToC       Page 29 
   Implementations may define keywords for experimental, or private use.
   All such keywords MUST begin with the two character sequence "x.".
   As type names are case independent, "x." and "X." are equivalent.
   For example:

      x.ver  -- Version information
      x.desc -- File description
      x.type -- File type

7.5.1.  The Type Fact

   The type fact needs a special description.  Part of the problem with
   current practices is deciding when a file is a directory.  If it is a
   directory, is it the current directory, a regular directory, or a
   parent directory?  The MLST specification makes this unambiguous
   using the type fact.  The type fact given specifies information about
   the object listed on the same line of the MLST response.

   Five values are possible for the type fact:

      file         -- a file entry
      cdir         -- the listed directory
      pdir         -- a parent directory
      dir          -- a directory or sub-directory -- an OS or file system dependent file type

   The syntax is defined to be:

      type-fact       = type-label "=" type-val
      type-label      = "Type"
      type-val        = "File" / "cdir" / "pdir" / "dir" /

   The value of the type fact (the "type-val") is a case independent
   string.  type=file

   The presence of the type=file fact indicates the listed entry is a
   file containing non-system data.  That is, it may be transferred from
   one system to another of quite different characteristics, and perhaps
   still be meaningful.  type=cdir

   The type=cdir fact indicates the listed entry contains a pathname of
   the directory whose contents are listed.  An entry of this type will
   only be returned as a part of the result of an MLSD command when the

Top      Up      ToC       Page 30 
   type fact is included, and provides a name for the listed directory,
   and facts about that directory.  In a sense, it can be viewed as
   representing the title of the listing, in a machine friendly format.
   It may appear at any point of the listing, it is not restricted to
   appearing at the start, though frequently may do so, and may occur
   multiple times.  It MUST NOT be included if the type fact is not
   included, or there would be no way for the user-PI to distinguish the
   name of the directory from an entry in the directory.

   Where TVFS is supported by the server-FTP, this name may be used to
   construct pathnames with which to refer to the files and directories
   returned in the same MLSD output (see section 6.2).  These pathnames
   are only expected to work when the server-PI's position in the NVFS
   file tree is the same as its position when the MLSD command was
   issued, unless a fully qualified pathname results.

   Where TVFS is not supported, the only defined semantics associated
   with a "type=cdir" entry are that, provided the current working
   directory of the server-PI has not been changed, a pathname of type
   "cdir" may be used as an argument to a CWD command, which will cause
   the current directory of the server-PI to change so that the
   directory that was listed in its current working directory.  type=dir

   If present, the type=dir entry gives the name of a directory.  Such
   an entry typically cannot be transferred from one system to another
   using RETR, etc., but should (permissions permitting) be able to be
   the object of an MLSD command.  type=pdir

   If present, which will occur only in the response to a MLSD command
   when the type fact is included, the type=pdir entry represents a
   pathname of the parent directory of the listed directory.  As well as
   having the properties of a type=dir, a CWD command that uses the
   pathname from this entry should change the user to a parent directory
   of the listed directory.  If the listed directory is the current
   directory, a CDUP command may also have the effect of changing to the
   named directory.  User-FTP processes should note not all responses
   will include this information, and that some systems may provide
   multiple type=pdir responses.

   Where TVFS is supported, a "type=pdir" name may be a relative
   pathname, or a fully qualified pathname.  A relative pathname will be
   relative to the directory being listed, not to the current directory
   of the server-PI at the time.

Top      Up      ToC       Page 31 
   For the purposes of this type value, a "parent directory" is any
   directory in which there is an entry of type=dir that refers to the
   directory in which the type=pdir entity was found.  Thus it is not
   required that all entities with type=pdir refer to the same
   directory.  The "unique" fact (if supported and supplied) can be used
   to determine whether there is a relationship between the type=pdir
   entries or not.  System Defined Types

   Files types that are specific to a specific operating system, or file
   system, can be encoded using the "OS." type names.  The format is:

      os-type   = "OS." os-name "=" os-kind
      os-name   = <an IANA registered operating system name>
      os-kind   = token

   The "os-name" indicates the specific system type that supports the
   particular localtype.  OS specific types are registered by the IANA
   using the procedures specified in section 10.  The "os-kind" provides
   the system dependent information as to the type of the file listed.
   The os-name and os-kind strings in an os-type are case independent.
   "OS.unix=block" and "OS.Unix=BLOCK" represent the same type (or
   would, if such a type were registered.)

   Note: Where the underlying system supports a file type that is
   essentially an indirect pointer to another file, the NVFS
   representation of that type should normally be to represent the file
   that the reference indicates.  That is, the underlying basic file
   will appear more than once in the NVFS, each time with the "unique"
   fact (see immediately following section) containing the same value,
   indicating that the same file is represented by all such names.
   User-PIs transferring the file need then transfer it only once, and
   then insert their own form of indirect reference to construct
   alternate names where desired, or perhaps even copy the local file if
   that is the only way to provide two names with the same content.  A
   file which would be a reference to another file, if only the other
   file actually existed, may be represented in any OS dependent manner
   appropriate, or not represented at all.  Multiple Types

   Where a file is such that it may validly, and sensibly, treated by
   the server-PI as being of more than one of the above types, then
   multiple entries should be returned, each with its own "Type" fact of
   the appropriate type, and each containing the same pathname.  This
   may occur, for example, with a structured file, which may contain
   sub-files, and where the server-PI permits the structured file to be

Top      Up      ToC       Page 32 
   treated as a unit, or treated as a directory allowing the sub-files
   within it to be referenced.  When this is done, the pathname returned
   with each entry MUST be identical to the others representing the same

7.5.2.  The unique Fact

   The unique fact is used to present a unique identifier for a file or
   directory in the NVFS accessed via a server-FTP process.  The value
   of this fact should be the same for any number of pathnames that
   refer to the same underlying file.  The fact should have different
   values for names that reference distinct files.  The mapping between
   files, and unique fact tokens should be maintained, and remain
   consistent, for at least the lifetime of the control connection from
   user-PI to server-PI.

      unique-fact  = "Unique" "=" token

   This fact would be expected to be used by server-FTPs whose host
   system allows things such as symbolic links so that the same file may
   be represented in more than one directory on the server.  The only
   conclusion that should be drawn is that if two different names each
   have the same value for the unique fact, they refer to the same
   underlying object.  The value of the unique fact (the token) should
   be considered an opaque string for comparison purposes, and is a case
   dependent value.  The tokens "A" and "a" do not represent the same
   underlying object.

7.5.3.  The modify Fact

   The modify fact is used to determine the last time the content of the
   file (or directory) indicated was modified.  Any change of substance
   to the file should cause this value to alter.  That is, if a change
   is made to a file such that the results of a RETR command would
   differ, then the value of the modify fact should alter.  User-PIs
   should not assume that a different modify fact value indicates that
   the file contents are necessarily different than when last retrieved.
   Some systems may alter the value of the modify fact for other
   reasons, though this is discouraged wherever possible.  Also a file
   may alter, and then be returned to its previous content, which would
   often be indicated as two incremental alterations to the value of the
   modify fact.

   For directories, this value should alter whenever a change occurs to
   the directory such that different file names would (or might) be
   included in MLSD output of that directory.

      modify-fact  = "Modify" "=" time-val

Top      Up      ToC       Page 33 
7.5.4.  The create Fact

   The create fact indicates when a file, or directory, was first
   created.  Exactly what "creation" is for this purpose is not
   specified here, and may vary from server to server.  About all that
   can be said about the value returned is that it can never indicate a
   later time than the modify fact.

      create-fact  = "Create" "=" time-val

   Implementation Note: Implementors of this fact on UNIX(TM) systems
      should note that the unix "stat" "st_ctime" field does not give
      creation time, and that unix file systems do not record creation
      time at all.  Unix (and POSIX) implementations will normally not
      include this fact.

7.5.5.  The perm Fact

   The perm fact is used to indicate access rights the current FTP user
   has over the object listed.  Its value is always an unordered
   sequence of alphabetic characters.

      perm-fact    = "Perm" "=" *pvals
      pvals        = "a" / "c" / "d" / "e" / "f" /
                     "l" / "m" / "p" / "r" / "w"

   There are ten permission indicators currently defined.  Many are
   meaningful only when used with a particular type of object.  The
   indicators are case independent, "d" and "D" are the same indicator.

   The "a" permission applies to objects of type=file, and indicates
   that the APPE (append) command may be applied to the file named.

   The "c" permission applies to objects of type=dir (and type=pdir,
   type=cdir).  It indicates that files may be created in the directory
   named.  That is, that a STOU command is likely to succeed, and that
   STOR and APPE commands might succeed if the file named did not
   previously exist, but is to be created in the directory object that
   has the "c" permission.  It also indicates that the RNTO command is
   likely to succeed for names in the directory.

   The "d" permission applies to all types.  It indicates that the
   object named may be deleted, that is, that the RMD command may be
   applied to it if it is a directory, and otherwise that the DELE
   command may be applied to it.

   The "e" permission applies to the directory types.  When set on an
   object of type=dir, type=cdir, or type=pdir it indicates that a CWD

Top      Up      ToC       Page 34 
   command naming the object should succeed, and the user should be able
   to enter the directory named.  For type=pdir it also indicates that
   the CDUP command may succeed (if this particular pathname is the one
   to which a CDUP would apply.)

   The "f" permission for objects indicates that the object named may be
   renamed - that is, may be the object of an RNFR command.

   The "l" permission applies to the directory file types, and indicates
   that the listing commands, LIST, NLST, and MLSD may be applied to the
   directory in question.

   The "m" permission applies to directory types, and indicates that the
   MKD command may be used to create a new directory within the
   directory under consideration.

   The "p" permission applies to directory types, and indicates that
   objects in the directory may be deleted, or (stretching naming a
   little) that the directory may be purged.  Note: it does not indicate
   that the RMD command may be used to remove the directory named
   itself, the "d" permission indicator indicates that.

   The "r" permission applies to type=file objects, and for some
   systems, perhaps to other types of objects, and indicates that the
   RETR command may be applied to that object.

   The "w" permission applies to type=file objects, and for some
   systems, perhaps to other types of objects, and indicates that the
   STOR command may be applied to the object named.

   Note: That a permission indicator is set can never imply that the
      appropriate command is guaranteed to work -- just that it might.
      Other system specific limitations, such as limitations on
      available space for storing files, may cause an operation to fail,
      where the permission flags may have indicated that it was likely
      to succeed.  The permissions are a guide only.

   Implementation note: The permissions are described here as they apply
      to FTP commands.  They may not map easily into particular
      permissions available on the server's operating system.  Servers
      are expected to synthesize these permission bits from the
      permission information available from operating system.  For
      example, to correctly determine whether the "D" permission bit
      should be set on a directory for a server running on the UNIX(TM)
      operating system, the server should check that the directory named
      is empty, and that the user has write permission on both the
      directory under consideration, and its parent directory.

Top      Up      ToC       Page 35 
      Some systems may have more specific permissions than those listed
      here, such systems should map those to the flags defined as best
      they are able.  Other systems may have only more broad access
      controls.  They will generally have just a few possible
      permutations of permission flags, however they should attempt to
      correctly represent what is permitted.

7.5.6.  The lang Fact

   The lang fact describes the natural language of the file name for use
   in display purposes.  Values used here should be taken from the
   language registry of the IANA.  See [12] for the syntax, and
   procedures, related to language tags.

      lang-fact  = "Lang" "=" token

   Server-FTP implementations MUST NOT guess language values.  Language
   values must be determined in an unambiguous way such as file system
   tagging of language or by user configuration.  Note that the lang
   fact provides no information at all about the content of a file, only
   about the encoding of its name.

7.5.7.  The size Fact

   The size fact applies to non-directory file types and should always
   reflect the approximate size of the file.  This should be as accurate
   as the server can make it, without going to extraordinary lengths,
   such as reading the entire file.  The size is expressed in units of
   octets of data in the file.

   Given limitations in some systems, Client-FTP implementations must
   understand this size may not be precise and may change between the
   time of a MLST and RETR operation.

   Clients that need highly accurate size information for some
   particular reason should use the SIZE command as defined in section
   4.  The most common need for this accuracy is likely to be in
   conjunction with the REST command described in section 5.  The size
   fact, on the other hand, should be used for purposes such as
   indicating to a human user the approximate size of the file to be
   transferred, and perhaps to give an idea of expected transfer
   completion time.

      size-fact  = "Size" "=" 1*DIGIT

Top      Up      ToC       Page 36 
7.5.8.  The media-type Fact

   The media-type fact represents the IANA media type of the file named,
   and applies only to non-directory types.  The list of values used
   must follow the guidelines set by the IANA registry.

      media-type  = "Media-Type" "=" <per IANA guidelines>

   Server-FTP implementations MUST NOT guess media type values.  Media
   type values must be determined in an unambiguous way such as file
   system tagging of media-type or by user configuration.  This fact
   gives information about the content of the file named.  Both the
   primary media type, and any appropriate subtype should be given,
   separated by a slash "/" as is traditional.

7.5.9.  The charset Fact

   The charset fact provides the IANA character set name, or alias, for
   the encoded pathnames in a MLSx response.  The default character set
   is UTF-8 unless specified otherwise.  FTP implementations SHOULD use
   UTF-8 if possible to encourage maximum inter-operability.  The value
   of this fact applies to the pathname only, and provides no
   information about the contents of the file.

      charset-type  = "Charset" "=" token

7.5.10.  Required Facts

   Servers are not required to support any particular set of the
   available facts.  However, servers SHOULD, if conceivably possible,
   support at least the type, perm, size, unique, and modify facts.

(page 36 continued on part 3)

Next RFC Part