draft-ietf-ftpext-mlst-15.txt

这是 关于FTP最新版本的PROFTP的 源码

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

                                                              April 2002


                           Extensions to FTP


                     draft-ietf-ftpext-mlst-15.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   This entire section has been prepended to this document automatically
   during formatting without any direct involvement by the author(s) of
   this draft.

Abstract

   This document specifies new FTP commands to obtain listings of remote
   directories in a defined format, and to permit restarts of
   interrupted data transfers in STREAM mode.  It allows character sets
   other than US-ASCII, and also defines an optional virtual file
   storage structure.





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


Table of Contents

          Abstract  ................................................   1
    1     Introduction  ............................................   3
    2     Document Conventions  ....................................   3
    2.1   Basic Tokens  ............................................   4
    2.2   Pathnames  ...............................................   4
    2.3   Times  ...................................................   6
    2.4   Server Replies  ..........................................   7
    2.5   Interpreting Examples  ...................................   7
    3     File Modification Time (MDTM)  ...........................   8
    3.1   Syntax  ..................................................   8
    3.2   Error responses  .........................................   9
    3.3   FEAT response for MDTM  ..................................   9
    3.4   MDTM Examples  ...........................................   9
    4     File SIZE  ...............................................  10
    4.1   Syntax  ..................................................  11
    4.2   Error responses  .........................................  11
    4.3   FEAT response for SIZE  ..................................  12
    4.4   Size Examples  ...........................................  12
    5     Restart of Interrupted Transfer (REST)  ..................  13
    5.1   Restarting in STREAM Mode  ...............................  13
    5.2   Error Recovery and Restart  ..............................  14
    5.3   Syntax  ..................................................  14
    5.4   FEAT response for REST  ..................................  16
    5.5   REST Example  ............................................  16
    6     A Trivial Virtual File Store (TVFS)  .....................  16
    6.1   TVFS File Names  .........................................  17
    6.2   TVFS Pathnames  ..........................................  18
    6.3   FEAT Response for TVFS  ..................................  19
    6.4   OPTS for TVFS  ...........................................  20
    6.5   TVFS Examples  ...........................................  20
    7     Listings for Machine Processing (MLST and MLSD)  .........  22
    7.1   Format of MLSx Requests  .................................  23
    7.2   Format of MLSx Response  .................................  24
    7.3   File name encoding  ......................................  26
    7.4   Format of Facts  .........................................  27
    7.5   Standard Facts  ..........................................  28
    7.6   System Dependent and Local Facts  ........................  36
    7.7   MLSx Examples  ...........................................  37
    7.8   FEAT response for MLSx  ..................................  49
    7.9   OPTS parameters for MLST  ................................  51
    8     Impact On Other FTP Commands  ............................  54
    9     Character sets and Internationalization  .................  55
   10     IANA Considerations  .....................................  55
   10.1   The OS specific fact registry  ...........................  55
   10.2   The OS specific filetype registry  .......................  56
   11     Security Considerations  .................................  56



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


   12     References  ..............................................  57
          Acknowledgments  .........................................  58
          Copyright  ...............................................  58
          Editors' Addresses  ......................................  59




1. Introduction

   This document amends the File Transfer Protocol (FTP) [3].  Four new
   commands are added: "SIZE", "MDTM", "MLST", and "MLSD".  The existing
   command "REST" is modified.  Of those, the "SIZE" and "MDTM"
   commands, and the modifications to "REST" have been in wide use for
   many years.  The others are new.

   These commands allow a client to restart an interrupted transfer in
   transfer modes not previously supported in any documented way, and to
   obtain a directory listing in a machine friendly, predictable,
   format.

   An optional structure for the server's file store (NVFS) is also
   defined, allowing servers that support such a structure to convey
   that information to clients in a standard way, thus allowing clients
   more certainty in constructing and interpreting pathnames.

2. Document Conventions

   This document makes use of the document conventions defined in BCP14
   [4].  That provides the interpretation of capitalized imperative
   words like MUST, SHOULD, etc.

   This document also uses notation defined in STD 9 [3].  In
   particular, the terms "reply", "user", "NVFS", "file", "pathname",
   "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP",
   "server-FTP process", "server-PI", "server-DTP", "mode", "type",
   "NVT", "control connection", "data connection", and "ASCII", are all
   used here as defined there.

   Syntax required is defined using the Augmented BNF defined in [5].
   Some general ABNF definitions are required throughout the document,
   those will be defined later in this section.  At first reading, it
   may be wise to simply recall that these definitions exist here, and
   skip to the next section.







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


2.1. Basic Tokens

   This document imports the core definitions given in Appendix A of
   [5].  There definitions will be found for basic ABNF elements like
   ALPHA, DIGIT, SP, etc.  To that, the following terms are added for
   use in this document.

        TCHAR          = VCHAR / SP / HTAB    ; visible plus white space
        RCHAR          = ALPHA / DIGIT / "," / "." / ":" / "!" /
                         "@" / "#" / "$" / "%" / "^" /
                         "&" / "(" / ")" / "-" / "_" /
                         "+" / "?" / "/" / "\" / "'" /
                         DQUOTE   ; <"> -- double quote character (%x22)
        SCHAR          = RCHAR / "=" ;

   The VCHAR (from [5]), RCHAR, SCHAR, and TCHAR types give basic
   character types from varying sub-sets of the ASCII character set for
   use in various commands and responses.

        token          = 1*RCHAR

   A "token" is a string whose precise meaning depends upon the context
   in which it is used.  In some cases it will be a value from a set of
   possible values maintained elsewhere.  In others it might be a string
   invented by one party to an FTP conversation from whatever sources it
   finds relevant.

   Note that in ABNF, string literals are case insensitive.  That
   convention is preserved in this document, and implies that FTP
   commands added by this specification have names that can be
   represented in any case.  That is, "MDTM" is the same as "mdtm",
   "Mdtm" and "MdTm" etc.  However note that ALPHA, in particular, is
   case sensitive.  That implies that a "token" is a case sensitive
   value.  That implication is correct, except where explicitly stated
   to the contrary in this document, or in some other specification
   which defines the values this document specifies be used in a
   particular context.

2.2. Pathnames

   Various FTP commands take pathnames as arguments, or return pathnames
   in responses.  When the MLST command is supported, as indicated in
   the response to the FEAT command [6], pathnames are to be transferred
   in one of the following two formats.







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


        pathname       = utf-8-name / raw
        utf-8-name     = <a UTF-8 encoded Unicode string>
        raw            = <any string not being a valid UTF-8 encoding>

   Which format is used is at the option of the user-PI or server-PI
   sending the pathname.  UTF-8 encodings [2] contain enough internal
   structure that it is always, in practice, possible to determine
   whether a UTF-8 or raw encoding has been used, in those cases where
   it matters.  While it is useful for the user-PI to be able to
   correctly display a pathname received from the server-PI to the user,
   it is far more important for the user-PI to be able to retain and
   retransmit the identical pathname when required.  Implementations are
   advised against converting a UTF-8 pathname to a local charset that
   isn't capable of representing the full Unicode character repertoire,
   and then attempting to invert the charset translation later.  Note
   that ASCII is a subset of UTF-8.  See also [1].

   Unless otherwise specified, the pathname is terminated by the CRLF
   that terminates the FTP command, or by the CRLF that ends a reply.
   Any trailing spaces preceding that CRLF form part of the name.
   Exactly one space will precede the pathname and serve as a separator
   from the preceding syntax element.  Any additional spaces form part
   of the pathname.  See [7] for a fuller explanation of the character
   encoding issues.  All implementations supporting MLST MUST support
   [7].

   Implementations should also beware that the control connection uses
   Telnet NVT conventions [8], and that the Telnet IAC character, if
   part of a pathname sent over the control connection, MUST be
   correctly escaped as defined by the Telnet protocol.

   Implementors should also be aware that although Telnet NVT
   conventions are used over the control connections, Telnet option
   negotiation MUST NOT be attempted.  See section 4.1.2.12 of [9].

2.2.1. Pathname Syntax

   Except where TVFS is supported (see section 6) this specification
   imposes no syntax upon pathnames.  Nor does it restrict the character
   set from which pathnames are created.  This does not imply that the
   NVFS is required to make sense of all possible pathnames.  Server-PIs
   may restrict the syntax of valid pathnames in their NVFS in any
   manner appropriate to their implementation or underlying file system.
   Similarly, a server-PI may parse the pathname, and assign meaning to
   the components detected.






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


2.2.2. Wildcarding

   For the commands defined in this specification, all pathnames are to
   be treated literally.  That is, for a pathname given as a parameter
   to a command, the file whose name is identical to the pathname given
   is implied.  No characters from the pathname may be treated as
   special or "magic", thus no pattern matching (other than for exact
   equality) between the pathname given and the files present in the
   NVFS of the Server-FTP is permitted.

   Clients that desire some form of pattern matching functionality must
   obtain a listing of the relevant directory, or directories, and
   implement their own file name selection procedures.

2.3. Times

   The syntax of a time value is:

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

   The leading, mandatory, fourteen digits are to be interpreted as, in
   order from the leftmost, four digits giving the year, with a range of
   1000--9999, two digits giving the month of the year, with a range of
   01--12, two digits giving the day of the month, with a range of
   01--31, two digits giving the hour of the day, with a range of
   00--23, two digits giving minutes past the hour, with a range of
   00--59, and finally, two digits giving seconds past the minute, with