[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 3659

FTPEXT Working Group                                          P. Hethmon
Internet Draft                                          Hethmon Brothers
Expiration Date: September 1997
                                                                  R. Elz
                                                 University of Melbourne

                                                              March 1997

                   MLST Command and Extensions to FTP


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


   In order to overcome the problems inherent in the current FTP LIST
   output, a new command is needed to transfer standardized listing
   information from Server-FTP to Client-FTP.  In addition, a way for
   the Server-FTP to let the Client-FTP know of this capability without
   imposing on the Client-FTP to randomly try new commands is needed.
   This proposal meets both of these requirements.

   This proposal also extends the FTP protocol to allow character sets
   other than US-ASCII[1] by allowing the transmission of 8-bit
   characters and the recommended use of UTF-8[2] encoding.

   This version of the document corrects some aspects of the previous
   draft, which was filed as: draft-hethmon-mlst-command-ftp-01.txt in
   particular some of the details of the ABNF used.  It also adds some

Hethmon & Elz                                                   [Page 1]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   editorial notes where questions to be resolved still exist.  This
   paragraph will be deleted from the final version of this document.

Table of Contents

         Status of this Memo  ......................................   1
         Abstract  .................................................   1
    1    Introduction  .............................................   3
    2    Knowledge of Extra Capabilities  ..........................   3
    2.1  The FEAT Command  .........................................   3
    2.2  Rationale for FEAT  .......................................   4
    3    MLST and MLSD Specification  ..............................   4
    3.1  Generalities  .............................................   4
    3.2  Encoding the data  ........................................   5
    3.3  Format of MLST Request  ...................................   5
    3.4  Format of MLST Response  ..................................   6
    3.5  Filename encoding  ........................................   7
    3.6  Format of Facts  ..........................................   7
    3.7  Standard Facts  ...........................................   8
    3.8  The type Fact  ............................................   9
    3.9  The unique Fact  ..........................................  11
    3.10 The perm Fact  ............................................  12
    3.11 The lang Fact  ............................................  15
    3.12 The size Fact  ............................................  15
    3.13 The media-type Fact  ......................................  15
    3.14 The charset Fact  .........................................  16
    3.15 Mandatory minimum reply for MLST  .........................  16
    4    The OPTS Command  .........................................  16
    4.1  OPTS parameters for MLST  .................................  16
    4.2  Using OPTS to select MLST output connection  ..............  17
    5    Impact On Other FTP Commands  .............................  17
    5.1  Impact on Pathnames and Filenames  ........................  18
    6    Security  .................................................  18
    7    References  ...............................................  18
         Acknowledgements  .........................................  19
         Editors' Addresses  .......................................  19

Hethmon & Elz                                                   [Page 2]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

1. Introduction

   This document amends the File Transfer Protocol (FTP) [6].  Four new
   commands are added, "FEAT", "OPTS", "MLST", and "MLSD".  These
   commands allow a client to discover which optional commands a server
   supports, and how they are supported, to select among various options
   that any FTP command may support, and most importantly, to obtain a
   directory listing in a machine friendly, predictable, way.

2. Knowledge of Extra Capabilities

2.1. The FEAT Command

   In order for the Client-FTP to know whether the Server-FTP
   understands the MLST command and future extensions to the FTP
   protocol, a new command, FEAT, can be used for the Client-FTP to
   query the Server-FTP on any extensions from RFC959 [6] the Server-FTP
   supports.  For Server-FTP's which do not support any extensions, the
   FEAT command may result in a 500 reply.

   The request syntax in augmented BNF syntax [3]: Note that literal
   strings in ABNF are case independent, where case dependence is
   required, terminal are, and must be, expressed as numeric strings.

        feat = feat-cmd CRLF
        feat-cmd = "feat"

   For Server-FTP's which do support extensions the correct reply code
   will be 211.  The reply to the FEAT command will typically be a
   multiline reply of the form:

        C> FEAT
        S> 211- Extensions supported:
        S>  MLST size*,create,modify*,perm,media-type
        S>  SIZE
        S>  MDTM
        S> 211 End

   Each extension supported must be listed on a separate line to
   facilitate the possible inclusion of parameters supported by each
   extension command.  Any parameters included are to be specified in
   the RFC defining that extension.

        feat-response = "211-" SP *CHAR CRLF *( SP feature CRLF )
                        "211" SP "End" CRLF
        feature       = 1*CHAR [ SP parms ]
        parms         = 1*CHAR

Hethmon & Elz                                                   [Page 3]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   FTP implementations which support MLST or other extension commands
   MUST support FEAT.

2.2. Rationale for FEAT

   While not absolutely necessary, a standard mechanism for the Server-
   FTP to inform the Client-FTP of any features and extensions supported
   will help reduce unnecessary traffic between the Client-FTP and
   Server-FTP as more extensions may be introduced in the future.  If no
   mechanism exists for this, a Client-FTP will have to try each
   extension in turn for the Server-FTP resulting in a series of

   It is also suggested for Client-FTP which retain information about a
   particular Server-FTP between uses that they cache the knowledge of a
   particular Server-FTP supporting extensions.  A Client-FTP would be
   expected to re-query the Server-FTP if any cached extension resulted
   in a 500 response code, or if the Client-FTP needs to determine the
   support for a newly introduced extension.

   [ Ed-Note: It has been questioned whether this paragraph is needed,
               or whether it may encourage behavior that we might with
               hindsight have preferred not to encourage.  Opinions? ]

3. MLST and MLSD Specification

3.1. Generalities

   The MLST command is intended to standardize the file and directory
   information returned by the Server-FTP process.  The MLST command
   differs from the LIST and NLST commands in that responses can be sent
   over either the control connection or data connection.  The default
   is to send responses over the data connection. It also differs in
   that the format of the replies is strictly defined although

   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 it is identical to MLST.  If no object is named, the
   current directory is assumed.  That will cause MLST to send a one
   line response, and MLSD to list the contents of the current

   In the sequel only MLST will be described, other than as previously
   mentioned, MLSD is identical.

Hethmon & Elz                                                   [Page 4]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   The MLST and MLSD commands also extend the FTP protocol as presented
   in RFC 959 [6] and RFC 1123 to allow that transmission of 8-bit data.
   Note this is not specifying character sets which are 8-bit, but
   specifying that FTP implementations are to specifically allow 8-bit
   bytes.  The MLST command allows both UTF-8/Unicode and "raw" forms as

   The MLST response is allowed over either the data connection or over
   the control connection.  The default is to send the response over the
   data connection.  Client-FTPs which wish to receive the response over
   the control connection must use the OPTS command as described in
   Section 4 to set the default response to use the control connection.

3.2. Encoding the data

   MLST commands and responses may contain arbitrary binary data, yet
   the data must be divided into lines for correct interpretation.  Each
   line is terminated with the two character ascii sequence carriage
   return, and line feed, in that order, with no intervening data.

   To allow that sequence to be transmitted as part of the data, without
   confusion, a NUL (character with binary value of 0) must be
   transmitted after every carriage-return character that is not the
   first half of the CRLF line terminating pair.  This is to be done
   regardless of what character follows the CR.

   Upon reception, exactly one NUL character (if present) must be
   deleted after any received CR, and that CR must then not be treated
   as being a part of a line terminator, regardless of what character
   follows the deleted NUL.

   Implementations should take care to correctly process all possible
   octet values, including the zero value (NUL character), as part of
   the MLST command or response.

3.3. Format of MLST Request

   The MLST command allows a single optional argument.  This argument
   may be either a directory name or a filename.  If a directory name is
   given then MLST must return a listing of the contents of the named
   directory.  If the argument is a filename, then MLST must return only
   a single fact line containing the information about the named file.

   If no argument is given then MLST must return a listing of the
   contents of the current working directory.

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

Hethmon & Elz                                                   [Page 5]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   The syntax for the MLST command is:

        mlst       = mlst-cmd [ SP ( utf-8-name / raw ) ] CRLF
        mlst-cmd   = "mlst"
        utf-8-name = <a UTF-8 encoded Unicode string>
        raw        = <any other 8-bit octet string>

3.4. Format of MLST Response

   The format of a response to the MLST command is as follows:

        mlst-response         = mlst-control-response /
        mlst-control-response = "212-" CRLF *(SP entry CRLF)
                                "212" SP end-token CRLF
        entry                 = *facts SP ( utf-8-name / raw )
        facts                 = fact *( ";" fact )
        fact                  = name "=" value
        end-token             = %h45.6e.64      ; "End" exactly as shown
        name                  = 1*ltext
        value                 = 1*ltext
        ltext                 = ALPHA / DIGIT / "," / "." / ":" / "!" /
                                "@" / "#" / "$" / "%" / "^" /
                                "&" / "(" / ")" / "-" / "_" /
                                "+" / "?" / "/" / "\" / "'" /
                                %h22     ; <"> -- double quote character
        mlst-data-response    = initial-response CRLF final-response
        initial-response      = "150" SP response-message CRLF
        response-message      = *ltext
        final-response        = "226" SP response-message CRLF

   When responses are sent over the data connection, the format of the
   control connection response is that of mlst-data-response.  When the
   response is sent over the control connection, then the mlst-control-
   response format is used.

   Given the path lengths available on various operating systems, this
   specification requires implementations to accept a minimum line
   length (for the entire line of a MLST reply, including the
   terminating CRLF, but not including null characters added after
   embedded CRs) of at least 2048 bytes.  It would be recommended that
   lengths of up to 4096 bytes be accepted if limits are necessary.

   The facts part of the specification would contain a series of "file
   facts" about the file/directory.  Typical information to be presented
   would include file size, last modification time, creation time,
   unique identifier, file/directory flag.

Hethmon & Elz                                                   [Page 6]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   The complete format for a successful reply to the MLST command would
   be (over the control connection):

        C> MLST
        S> 212-
        S>  facts utf-8-name
        S>  facts utf-8-name
        S>  facts utf-8-name
        S> 212 End

3.5. Filename encoding

   A FTP implementation using the MLST command must be 8-bit clean.
   This is necessary in order to transmit UTF-8 encoded filenames.  This
   specification recommends the use of UTF-8 encoded filenames.  FTP
   implementations SHOULD use UTF-8 whenever possible to encourage the
   maximum interoperability.

   Filenames 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 filenames as octet

   Note that this encoding DOES NOT apply to the contents of the file.

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

3.5.1. Notes about the Filename

   The filename returned in the MLST command should be an unqualified
   filename.  No path information should be given.  Path information is
   to be returned separately as specified in Section 3.7.

   [ Ed-Note: This reference to section 3.7 came from the previous
               version of the draft.  I am not sure it makes sense, but
               nor am I sure what it should be changed to, if 3.7 is not
               correct. ]

3.6. Format of Facts

   The "facts" for a file in a reply to a MLST command consist of
   information about that file.  The facts are a series of keyword=value
   pairs separated by a semi-colon (";") character.  The complete series
   of facts may not contain the space character.

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

Hethmon & Elz                                                   [Page 7]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997


3.7. Standard Facts

   This document defines a standard set of facts as follows:

        size       -- Size in bytes
        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 filename per IANA[5] 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-sensitive.  Size, size, and SIze are not the

   For keywords specifying time, the time is to be specified in one of
   the formats:





        yyyy -- 4 digit year
        mm   -- 2 digit month
        dd   -- 2 digit day
        hh   -- 2 digit hour
        ss   -- 2 digit second
        .sss -- optional digits for thousandths of a second

   [ Ed-Note: in the REST/MDTM/SIZE draft, the "sss" is permitted to be
               however long (accurate) the sender desires, is there ay
               reason here to make an incompatible spec? ]

   In ABNF, the syntax of a time value is:

Hethmon & Elz                                                   [Page 8]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

        time-val = 12*12DIGIT [ "." 1*DIGIT ]

   Time values are always represented in UTC (GMT).

   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

   Implementation specific keywords would be allowed by starting the
   keyword with the sequence "x.":

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

   [ Ed-Note: is the "x" in lower case only? ]

3.8. 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 current directory
        pdir -- the parent directory
        dir  -- a directory or sub-directory
        link -- the entry is a link to a file or directory

   The syntax is defined to be:

        type-fact  = type-label "=" type-val
        type-label = %h64.79.70.65                ; "type" in lower case
        type-val   = %h66.69.6c.65                              ; "file"
                     / %h63.64.69.72                            ; "cdir"
                     / %h70.64.69.72                            ; "pdir"
                     / %h64.69.72                               ; "dir"
                     / %h6c.69.6e.6b                            ; "link"

Hethmon & Elz                                                   [Page 9]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   [ Ed-Note: do we need to permit OS dependent file types? ]

3.8.1. 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, and perhaps be meaningful.

3.8.2. type=cdir

   The type=cdir fact indicates the listed entry is the full, qualified
   pathname of the directory whose contents are listed.  The value of
   this entry (the filename part) plus the value of a type=file entry
   together should represent a complete pathname suitable for a RETR
   command.  The value for the type=cdir entry should include any
   necessary system delimiters used between path components.  An example
   would be the forward slash "/" on a Unix system, or a back slash "\"
   on an OS/2 or Windows system.

   The type=cdir entry is required for all MLST replies which return
   directory listings.  It is not required for MLST replies which return
   information about a single file.

   [ Ed-Note: I'm afraid this makes no sense to me.  None at all.  I
               don't like the idea of attempting to mash server file
               names together in the client.  I don't understand the
               full, qualified pathname bit.  I don't understand what is
               supposed to happen.  My idea of the FTP model is that it
               is for the client (perhaps with the aid of PWD commands,
               where implemented) to keep track of where it is in the
               server's filesystem.  Note that filesystems need not be
               implemented as any kind of tree, lots of other models are
               possible.  Someone needs to provide lots of guidance, in
               the form of contributed text if this is to remain
               anything like this at all. ]

3.8.3. type=pdir

   If present, the type=pdir entry represents the fully qualified
   pathname of the parent directory of the type=cdir directory.  A CWD
   command with the value should change the user to the parent directory
   of the listed directory.  Client-FTPs should note not all responses
   will include this information.

Hethmon & Elz                                                  [Page 10]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

3.8.4. type=dir

   If present, the type=dir entry is the name of a directory.  When
   executed with the current directory in the appropriate place, a CWD
   with this argument should succeed (given the user has the appropriate
   system rights).

3.8.5. type=link

   [ Ed-Note: This might eventually say something not yet written.  What
               that might be is unclear (the whole type might be
               deleted).  It isn't clear to me what a nk" means in the
               FTP context.  If we're talking of symlinks (or aliases,
               or shortcuts, or the various other names they go by in
               various OS's), then we need a way to fetch the value of
               this thing - RETR cannot be it, it must (for sanity) read
               the file linked to, not the link itself.  If this is
               supposed to refer to original unix (hard) links, then I'm
               not sure of the need for this, given that the unique fact
               (next section) provides more useful information.
               Further, it isn't clear which of two unix links to a file
               should be considered to be the type=file and which should
               be considered to be type=link.  Someone who supports the
               existence of this type needs to describe what it means,
               and what operations are supported upon it. ]

3.9. The unique Fact

   The unique fact is used to present a unique identifier for a file or
   directory on a Server-FTP.  This 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 value of the unique fact should be considered an
   opaque string for comparison purposes.  The only conclusion that
   should be drawn is that if two different names each have the same
   value for the unique fact, then they refer to the same underlying

        unique-fact = unique-label "=" token
        unique-label = %h75.6e.                    ; "unique"

   [ Ed-Note: A definition of token is required ]

Hethmon & Elz                                                  [Page 11]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

3.10. The perm Fact

   [ Ed-Note: We need to choose what goes here.  That might be something
               close to one of the following, or something totally
               different. ]

3.10.1. Alternative One (The original)

   The perm fact is used to present the file permissions the user has in
   regard to the listed file.  The value of the fact is a 3 character
   sequence representing read, write, and execute privileges for the
   file or directory as pertaining to the login user.

        perm-fact  = perm-label "=" pvals
        perm-label = %h70.65.72.6d                              ; "perm"
        pvals      = readval writeval executeval
        readval    = "r" / "-"
        writeval   = "w" / "-"
        executeval = "x" / "-"

   The first character specifies the read permission.  The character "r"
   means read is available.  The character "-" means it is not.

   The second character specifies the write permission.  The character
   "w" means write is available while "-" means it is not.

   Likewise the third character specifies the execute permission.  The
   character "x" means execute is available while "-" means it is not.

   A file with read rights allows the User-FTP to retrieve (RETR) the
   file.  If it has executable rights, then the file is considered an
   executable (or runnable) program on the Server-FTP system.  Some
   Server-FTPs may allow the SITE EXEC extension to be used on the
   specified file.  If it has write rights, then the file may be
   appended to using APPE, or written to by STOR.

   A directory with read rights may be the target of a LIST, NLST or
   MLST command.  With execute right, it can be the target of a CWD
   command.  With write rights, new files/directories may be created,
   and existing files/directories deleted or renamed; under usual
   implementations, existing directories may only be deleted if they are

Hethmon & Elz                                                  [Page 12]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

3.10.2. Alternative Two (Revised)

   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-label "=" pvals
        perm-label = %h70.65.72.6d                              ; "perm"
        pvals      = *ALPHA

   There are eleven permission indicators currently defined.  Many are
   meaningful only when used with a particular type of object.  The
   eleven characters currently defined are:

        a c d e f l m p r w x

   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.  For type=file it indicates
   that the file may be deleted, that is, that the DELE command may be
   applied to it.  For the directory types it indicates that (some)
   files in the directory may be deleted.

   The "e" permission applies to the directory types.  When set on an
   object of type=dir or type=pdir it indicates that a CWD 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 should succeed.  For objects of type=cdir this
   permission will normally always be set, and indicates not very much
   at all.

   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 MLST may be applied to the
   directory in question, or to files in the directory.

Hethmon & Elz                                                  [Page 13]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   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 the
   RMD command may be used to remove (purge) the directory named.

   The "r" permission applies to type=file objects, and indicates that
   the RETR command may be applied to that object.

   The "w" permission applies to type=file objects, and indicates that
   the STOR command may be applied to the object named.

   The "x" permission is slightly unusual, as it does not directly
   relate to any standardized FTP command, yet conveys useful
   information.  This indicator conveys the information that the object
   named, which will be of file type, is an executable image, or program
   file.  Some FTP servers may permit a site specific command (eg:
   "SITE EXEC") to be applied to a file with this permission.

   Note: That a permission bit 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 "p" 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

        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.

   [ Ed-Note: The "x" permission flag may be better handled by using a
               different file type (type=prog, type=xfile, ...) instead.

Hethmon & Elz                                                  [Page 14]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

               Opinions? ]

3.11. The lang Fact

   The lang fact describes the natural language of the filename for use
   in display purposes.  Values used here should comply with the
   language registry of IANA.

        lang-fact  = lang-label "=" token
        lang-label = %h6c.61.6e.67                              ; "lang"

   Server-FTP implementations MUST not guess language values.  Language
   values must be determined in an unambiguous way such as filesystem
   tagging of language or by user configuration.

3.12. The size Fact

   The size 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.

   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 [7].  The
   most common need for this accuracy is likely to be in conjunction
   with the REST command described in the same document.

        size-fact  = size-label "=" 1*DIGIT
        size-label = %h73.69.7a.65                              ; "size"

3.13. The media-type Fact

   The media-type fact represents the IANA media type of the file.  The
   list of values used must follow the guidelines set by the IANA

        media-type  = media-label "=" <per IANA guidelines>
        media-label = %h6d.     ; "media-type"

   Server-FTP implementations MUST not guess media type values.  Media
   type values must be determined in an unambiguous way such as
   filesystem tagging of media-type or by user configuration.

Hethmon & Elz                                                  [Page 15]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

3.14. The charset Fact

   The charset fact represents the IANA character set name for the
   encoded names in a MLST response.  This is a optional fact.  The
   default character set is UTF-8 unless specified otherwise.  FTP
   implementations SHOULD use UTF-8 if possible to encourage maximum

3.15. Mandatory minimum reply for MLST

   The mandatory minimum response for MLST when returning a directory
   listing must include an entry for the listed directory (type=cdir).
   This requirement is lifted when returning information about a single

4. The OPTS Command

   The OPTS (options) command allows a Client-FTP to specify the exact
   set of facts for a Server-FTP to return within a MLST command.  The
   Client-FTP may use the FEAT command to determine the set of facts
   supported by the Server-FTP and then issue the OPTS command to
   specify the set of those facts it wishes to see.  Server-FTPs should
   implement the OPTS command.

   Request Syntax:
        opts            = opts-cmd SP command-name *(command-options) CRLF
        opts-cmd        = "opts"
        command-name    = <any FTP command which allows option setting>
        command-options = <format specified by individual FTP command>

   Response Syntax:
        opts-response   = opts-good / opts-bad
        opts-good       = "200" SP response-message CRLF
        opts-bad        = "451" SP response-message CRLF /
                          "501" SP response-message CRLF

4.1. OPTS parameters for MLST

   For the MLST command, the Client-FTP may specify a list of facts it
   wishes to be returned in all subsequent MLST commands until another
   OPTS MLST command is sent.  The format is specified by:

        mlst-opts = "OPTS" SP ST" SP *facts

   [ Ed-Note: Is the space after "MLST" required if there are no facts?

Hethmon & Elz                                                  [Page 16]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

   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 MLST 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 MLST
   command where they apply.  Facts requested that are not supported, or
   which are inappropriate to the file or directory being listed should
   simply be omitted from the MLST output.  This is not an error.

4.2. Using OPTS to select MLST output connection

   [ Ed-Note: This whole section is controversial.  There are some among
               us who believe that use of the control connection for the
               output of the MLST command is positively insane, and
               should simply be abolished, not negotiated... ]

   One of the facts given to the "OPTS MLST" command, but used only in
   this command is one of the special case facts:

        chan-sel      = connect-label "=" connection
        connect-label = %h63.6f.6e.6e.   ; "connection"
        connection    = %h64.6f.6e.74.72.6f.6c               ; "control"
                        / %h64.61.74.61                         ; "data"

   When the "connection=data" is used on the "OPTS MLST" command, output
   from the MLST command is to be sent on a separate data connection, as
   is done with the LIST command [6].  When the "connection=control" is
   used on the "OPTS MLST" command, output from the MLST command is to
   be sent back as a reply to the MLST command, over the control
   connection, as described in section 3.4.  Where no "OPTS MLST"
   command has been sent, or no "connection=" ct" has been sent, the
   default is for the data connection to be used.

5. 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 or EBCDIC
   character sets.  In general, the support of MLST requires support for
   arbitrary character sets wherever filenames and directory names are
   allowed.  This applies equally to both arguments given to the
   following commands and to the replies from them.


Hethmon & Elz                                                  [Page 17]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997


   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 CRs and NULs.  See section 3.2.

5.1. Impact on Pathnames and Filenames

   The design of MLST requires the Server-FTP to allow concatenation of
   certain elements of a MLST response.  Specifically, a typical
   response would include an element which indicates the current
   directory and one or more elements which are files in the indicated
   directory.  A Server-FTP must be able to accept a simple
   concatenation of these two names even if the underlying operating
   system does not accept a simple concatenation.  The Server-FTP must
   perform any translation of the concatenated name to local

   [ Ed-Note: I don't believe a word of this.  Directories can be handed
               to the CWD command, and then the file names to RETR
               (etc).  Do we really need this section, and other related
               text? ]

6. Security

   This memo does not yet discuss security.  It is possible that no new
   security concerns are raised in this memo above what already exists
   within the FTP protocol.  However, the working group needs to
   consider this carefully.

7. References

   [1]  Coded Character Set--7-bit American Standard Code for Information
        Interchange, ANSI X3.4-1986.

   [2]  F. Yergeau, "UTF-8, a transformation format of Unicode and ISO
        10646", RFC 2044, Alis Technologies, October 1996.

   [3]  D. Crocker, "Augmented BNF for Syntax Specifications: ABNF",
        Work In Progress <draft-ietf-drums-abnf-02.txt>, Internet
        Mail Consortium, March 1997.

   [4]  W. Curtin, "Internationalization of the File Transfer Protocol",
        Work In Progress <draft-ietf-ftpext-itln-00.txt>, Defense

Hethmon & Elz                                                  [Page 18]

Internet Draft       draft-ietf-ftpext-mlst-00.txt            March 1997

        Information Systems Agency, November 1996.

   [5]  Internet Assigned Numbers Authority. http://www.isi.edu/div7/iana/
        Email: iana@iana.org.

   [6]  J. Postel, J. Reynolds, "File Transfer Protocol (FTP)",
        STD 9 (RFC 959), ISI, October 1985

   [7]  D. Borman, R. Adams, "REST Command and Extensions to FTP",
        Work in progress (draft-ietf-ftpext-restart-00.txt), Berkeley Software
        Design, Inc, UUNET, March, 1997.


   The following people have contributed to this document:

        Alex Belits
        D. J. Berstein
        Martin J. Duerst
        Mark Harris
        Alun Jones
        James Matthews
        Keith Moore
        and the entire FTPEXT working group of the IETF.

Editors' Addresses

   Paul Hethmon
   Hethmon Brothers
   2305 Chukar Road
   Knoxville, TN 37923 USA

   Phone: 423-690-8990
   Email: phethmon@hethmon.com

   Robert Elz
   University of Melbourne
   Department of Computer Science
   Parkville, Vic   3052

   Email: kre@munnari.OZ.AU

Hethmon & Elz                                                  [Page 19]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/