draft-ietf-ftpext-mlst-15.txt

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

   a range of 00--60 (with 60 being used only at a leap second).  Years
   in the tenth century, and earlier, cannot be expressed.  This is not
   considered a serious defect of the protocol.

   The optional digits, which are preceded by a period, give decimal
   fractions of a second.  These may be given to whatever precision is
   appropriate to the circumstance, however implementations MUST NOT add
   precision to time-vals where that precision does not exist in the
   underlying value being transmitted.

   Symbolically, a time-val may be viewed as

        YYYYMMDDHHMMSS.sss

   The "." and subsequent digits ("sss") are optional.  However the "."
   MUST NOT appear unless at least one following digit also appears.

   Time values are always represented in UTC (GMT), and in the Gregorian
   calendar regardless of what calendar may have been in use at the date
   and time indicated at the location of the server-PI.




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


   The technical differences between GMT, TAI, UTC, UT1, UT2, etc, are
   not considered here.  A server-FTP process should always use the same
   time reference, so the times it returns will be consistent.  Clients
   are not expected to be time synchronized with the server, so the
   possible difference in times that might be reported by the different
   time standards is not considered important.

2.4. Server Replies

   Section 4.2 of [3] defines the format and meaning of replies by the
   server-PI to FTP commands from the user-PI.  Those reply conventions
   are used here without change.

        error-response = error-code SP *TCHAR CRLF
        error-code     = ("4" / "5") 2DIGIT

   Implementors should note that the ABNF syntax (which was not used in
   [3]) used in this document, and other FTP related documents,
   sometimes shows replies using the one line format.  Unless otherwise
   explicitly stated, that is not intended to imply that multi-line
   responses are not permitted.  Implementors should assume that, unless
   stated to the contrary, any reply to any FTP command (including QUIT)
   may be of the multi-line format described in [3].

   Throughout this document, replies will be identified by the three
   digit code that is their first element.  Thus the term "500 reply"
   means a reply from the server-PI using the three digit code "500".

2.5. Interpreting Examples

   In the examples of FTP dialogs presented in this document, lines that
   begin "C> " were sent over the control connection from the user-PI to
   the server-PI, lines that begin "S> " were sent over the control
   connection from the server-PI to the user-PI, and each sequence of
   lines that begin "D> " was sent from the server-PI to the user-PI
   over a data connection created just to send those lines and closed
   immediately after.  No examples here show data transferred over a
   data connection from the client to the server.  In all cases, the
   prefixes shown above, including the one space, have been added for
   the purposes of this document, and are not a part of the data
   exchanged between client and server.










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


3. File Modification Time (MDTM)

   The FTP command, MODIFICATION TIME (MDTM), can be used to determine
   when a file in the server NVFS was last modified.  This command has
   existed in many FTP servers for many years, as an adjunct to the REST
   command for STREAM mode, thus is widely available.  However, where
   supported, the "modify" fact which can be provided in the result from
   the new MLST command is recommended as a superior alternative.

   When attempting to restart a RETRieve, if the User-FTP makes use of
   the MDTM command, or "modify" fact, it can check and see if the
   modification time of the source file is more recent than the
   modification time of the partially transferred file.  If it is, then
   most likely the source file has changed and it would be unsafe to
   restart the previously incomplete file transfer.

   When attempting to restart a STORe, the User FTP can use the MDTM
   command to discover the modification time of the partially
   transferred file.  If it is older than the modification time of the
   file that is about to be STORed, then most likely the source file has
   changed and it would be unsafe to restart the file transfer.

   Note that using MLST (described below) where available, can provide
   this information, and much more, thus giving an even better
   indication that a file has changed, and that restarting a transfer
   would not give valid results.

   Note that this is applicable to any RESTart attempt, regardless of
   the mode of the file transfer.

3.1. Syntax

   The syntax for the MDTM command is:

        mdtm          = "MdTm" SP pathname CRLF

   As with all FTP commands, the "MDTM" command label is interpreted in
   a case insensitive manner.

   The "pathname" specifies an object in the NVFS which may be the
   object of a RETR command.  Attempts to query the modification time of
   files that exist but are unable to be retrieved may generate an
   error-response, or can result in a positive response carrying a time-
   val with an unspecified value, the choice being made by the server-
   PI.

   The server-PI will respond to the MDTM command with a 213 reply
   giving the last modification time of the file whose pathname was



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


   supplied, or a 550 reply if the file does not exist, the modification
   time is unavailable, or some other error has occurred.

        mdtm-response = "213" SP time-val CRLF /
                        error-response

   Note that when the 213 response is issued, that is, when there is no
   error, the format MUST be exactly as specified.  Multi-line responses
   are not permitted.

3.2. Error responses

   Where the command is correctly parsed, but the modification time is
   not available, either because the pathname identifies no existing
   entity, or because the information is not available for the entity
   named, then a 550 reply should be sent.  Where the command cannot be
   correctly parsed, a 500 or 501 reply should be sent, as specified in
   [3].  Various 4xy replies are also possible in appropriate
   circumstances.

3.3. FEAT response for MDTM

   When replying to the FEAT command [6], an FTP server process that
   supports the MDTM command MUST include a line containing the single
   word "MDTM".  This MAY be sent in upper or lower case, or a mixture
   of both (it is case insensitive) but SHOULD be transmitted in upper
   case only.  That is, the response SHOULD be

        C> Feat
        S> 211- <any descriptive text>
        S>  ...
        S>  MDTM
        S>  ...
        S> 211 End

   The ellipses indicate place holders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory [6].

3.4. MDTM Examples

   If we assume the existence of three files, A B and C, a directory D,
   two files with names that end with the string "ile6", and no other
   files at all, then the MDTM command may behave as indicated.  The
   "C>" lines are commands from user-PI to server-PI, the "S>" lines are
   server-PI replies.





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


        C> MDTM A
        S> 213 19980615100045.014
        C> MDTM B
        S> 213 19980615100045.014
        C> MDTM C
        S> 213 19980705132316
        C> MDTM D
        S> 550 D is not retrievable
        C> MDTM E
        S> 550 No file named "E"
        C> mdtm file6
        S> 213 19990929003355
        C> MdTm 19990929043300 File6
        S> 213 19991005213102
        C> MdTm 19990929043300 file6
        S> 550 19990929043300 file6: No such file or directory.

   From that we can conclude that both A and B were last modified at the
   same time (to the nearest millisecond), and that C was modified 20
   days and several hours later.

   The times are in GMT, so file A was modified on the 15th of June,
   1998, at approximately 11am in London (summer time was then in
   effect), or perhaps at 8pm in Melbourne, Australia, or at 6am in New
   York.  All of those represent the same absolute time of course.  The
   location where the file was modified, and consequently the local wall
   clock time at that location, is not available.

   There is no file named "E" in the current directory, but there are
   files named both "file6" and "19990929043300 File6".  The
   modification times of those files were obtained.  There is no file
   named "19990929043300 file6".

4. File SIZE

   The FTP command, SIZE OF FILE (SIZE), is used to obtain the transfer
   size of a file from the server-FTP process.  That is, the exact
   number of octets (8 bit bytes) which would be transmitted over the
   data connection should that file be transmitted.  This value will
   change depending on the current STRUcture, MODE and TYPE of the data
   connection, or a data connection which would be created were one
   created now.  Thus, the result of the SIZE command is dependent on
   the currently established STRU, MODE and TYPE parameters.

   The SIZE command returns how many octets would be transferred if the
   file were to be transferred using the current transfer structure,
   mode and type.  This command is normally used in conjunction with the
   RESTART (REST) command when STORing a file to a remote server in



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


   STREAM mode, to determine the restart point.  The server-PI might
   need to read the partially transferred file, do any appropriate
   conversion, and count the number of octets that would be generated
   when sending the file in order to correctly respond to this command.
   Estimates of the file transfer size MUST NOT be returned, only
   precise information is acceptable.

4.1. Syntax

   The syntax of the SIZE command is:

        size          = "Size" SP pathname CRLF

   The server-PI will respond to the SIZE command with a 213 reply
   giving the transfer size of the file whose pathname was supplied, or
   an error response if the file does not exist, the size is
   unavailable, or some other error has occurred.  The value returned is
   in a format suitable for use with the RESTART (REST) command for mode
   STREAM, provided the transfer mode and type are not altered.

        size-response = "213" SP 1*DIGIT CRLF /
                        error-response

   Note that when the 213 response is issued, that is, when there is no
   error, the format MUST be exactly as specified.  Multi-line responses
   are not permitted.

4.2. Error responses

   Where the command is correctly parsed, but the size is not available,
   perhaps because the pathname identifies no existing entity, or
   because the entity named cannot be transferred in the current MODE
   and TYPE (or at all), then a 550 reply should be sent.  Where the
   command cannot be correctly parsed, a 500 or 501 reply should be
   sent, as specified in [3].  The presence of the 550 error response to
   a SIZE command MUST NOT be taken by the client as an indication that
   the file can not be transferred in the current MODE and TYPE.  A
   server may generate this error for other reasons -- for instance if
   the processing overhead is considered too great.  Various 4xy replies
   are also possible in appropriate circumstances.











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


4.3. FEAT response for SIZE

   When replying to the FEAT command [6], an FTP server process that
   supports the SIZE command MUST include a line containing the single