< draft-ietf-ftpext-mlst-15.txt   draft-ietf-ftpext-mlst-16.txt >
FTPEXT Working Group R. Elz FTPEXT Working Group R. Elz
Internet Draft University of Melbourne Internet Draft Prince of Songkla University
Expiration Date: October 2002 Expiration Date: March 2003
P. Hethmon P. Hethmon
Hethmon Brothers Hethmon Brothers
April 2002 September 2002
Extensions to FTP Extensions to FTP
draft-ietf-ftpext-mlst-15.txt draft-ietf-ftpext-mlst-16.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
Abstract ................................................ 1 Abstract ................................................ 1
1 Introduction ............................................ 3 1 Introduction ............................................ 3
2 Document Conventions .................................... 3 2 Document Conventions .................................... 3
2.1 Basic Tokens ............................................ 4 2.1 Basic Tokens ............................................ 4
2.2 Pathnames ............................................... 4 2.2 Pathnames ............................................... 4
2.3 Times ................................................... 6 2.3 Times ................................................... 6
2.4 Server Replies .......................................... 7 2.4 Server Replies .......................................... 7
2.5 Interpreting Examples ................................... 7 2.5 Interpreting Examples ................................... 8
3 File Modification Time (MDTM) ........................... 8 3 File Modification Time (MDTM) ........................... 8
3.1 Syntax .................................................. 8 3.1 Syntax .................................................. 9
3.2 Error responses ......................................... 9 3.2 Error responses ......................................... 9
3.3 FEAT response for MDTM .................................. 9 3.3 FEAT response for MDTM .................................. 10
3.4 MDTM Examples ........................................... 9 3.4 MDTM Examples ........................................... 10
4 File SIZE ............................................... 10 4 File SIZE ............................................... 11
4.1 Syntax .................................................. 11 4.1 Syntax .................................................. 11
4.2 Error responses ......................................... 11 4.2 Error responses ......................................... 12
4.3 FEAT response for SIZE .................................. 12 4.3 FEAT response for SIZE .................................. 12
4.4 Size Examples ........................................... 12 4.4 Size Examples ........................................... 12
5 Restart of Interrupted Transfer (REST) .................. 13 5 Restart of Interrupted Transfer (REST) .................. 13
5.1 Restarting in STREAM Mode ............................... 13 5.1 Restarting in STREAM Mode ............................... 14
5.2 Error Recovery and Restart .............................. 14 5.2 Error Recovery and Restart .............................. 14
5.3 Syntax .................................................. 14 5.3 Syntax .................................................. 15
5.4 FEAT response for REST .................................. 16 5.4 FEAT response for REST .................................. 16
5.5 REST Example ............................................ 16 5.5 REST Example ............................................ 17
6 A Trivial Virtual File Store (TVFS) ..................... 16 6 A Trivial Virtual File Store (TVFS) ..................... 17
6.1 TVFS File Names ......................................... 17 6.1 TVFS File Names ......................................... 18
6.2 TVFS Pathnames .......................................... 18 6.2 TVFS Pathnames .......................................... 18
6.3 FEAT Response for TVFS .................................. 19 6.3 FEAT Response for TVFS .................................. 20
6.4 OPTS for TVFS ........................................... 20 6.4 OPTS for TVFS ........................................... 21
6.5 TVFS Examples ........................................... 20 6.5 TVFS Examples ........................................... 21
7 Listings for Machine Processing (MLST and MLSD) ......... 22 7 Listings for Machine Processing (MLST and MLSD) ......... 22
7.1 Format of MLSx Requests ................................. 23 7.1 Format of MLSx Requests ................................. 23
7.2 Format of MLSx Response ................................. 24 7.2 Format of MLSx Response ................................. 24
7.3 File name encoding ...................................... 26 7.3 File name encoding ...................................... 26
7.4 Format of Facts ......................................... 27 7.4 Format of Facts ......................................... 27
7.5 Standard Facts .......................................... 28 7.5 Standard Facts .......................................... 28
7.6 System Dependent and Local Facts ........................ 36 7.6 System Dependent and Local Facts ........................ 36
7.7 MLSx Examples ........................................... 37 7.7 MLSx Examples ........................................... 37
7.8 FEAT response for MLSx .................................. 49 7.8 FEAT response for MLSx .................................. 49
7.9 OPTS parameters for MLST ................................ 51 7.9 OPTS parameters for MLST ................................ 51
8 Impact On Other FTP Commands ............................ 54 8 Impact On Other FTP Commands ............................ 54
9 Character sets and Internationalization ................. 55 9 Character sets and Internationalization ................. 55
10 IANA Considerations ..................................... 55 10 IANA Considerations ..................................... 55
10.1 The OS specific fact registry ........................... 55 10.1 The OS specific fact registry ........................... 55
10.2 The OS specific filetype registry ....................... 56 10.2 The OS specific filetype registry ....................... 56
11 Security Considerations ................................. 56 11 Security Considerations ................................. 56
12 References .............................................. 57 12 Normative References .................................... 58
Acknowledgments ......................................... 58 Acknowledgments ......................................... 59
Copyright ............................................... 58 Copyright ............................................... 59
Editors' Addresses ...................................... 59 Editors' Addresses ...................................... 60
1. Introduction 1. Introduction
This document amends the File Transfer Protocol (FTP) [3]. Four new This document updates the File Transfer Protocol (FTP) [3]. Four new
commands are added: "SIZE", "MDTM", "MLST", and "MLSD". The existing commands are added: "SIZE", "MDTM", "MLST", and "MLSD". The existing
command "REST" is modified. Of those, the "SIZE" and "MDTM" command "REST" is modified. Of those, the "SIZE" and "MDTM"
commands, and the modifications to "REST" have been in wide use for commands, and the modifications to "REST" have been in wide use for
many years. The others are new. many years. The others are new.
These commands allow a client to restart an interrupted transfer in These commands allow a client to restart an interrupted transfer in
transfer modes not previously supported in any documented way, and to transfer modes not previously supported in any documented way, and to
obtain a directory listing in a machine friendly, predictable, obtain a directory listing in a machine friendly, predictable,
format. format.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
Unless otherwise specified, the pathname is terminated by the CRLF Unless otherwise specified, the pathname is terminated by the CRLF
that terminates the FTP command, or by the CRLF that ends a reply. that terminates the FTP command, or by the CRLF that ends a reply.
Any trailing spaces preceding that CRLF form part of the name. Any trailing spaces preceding that CRLF form part of the name.
Exactly one space will precede the pathname and serve as a separator Exactly one space will precede the pathname and serve as a separator
from the preceding syntax element. Any additional spaces form part from the preceding syntax element. Any additional spaces form part
of the pathname. See [7] for a fuller explanation of the character of the pathname. See [7] for a fuller explanation of the character
encoding issues. All implementations supporting MLST MUST support encoding issues. All implementations supporting MLST MUST support
[7]. [7].
Note: for pathnames transferred over a data connection, there is no
way to represent a pathname containing the characters CR and LF in
sequence, and distinguish that from the end of line indication.
Hence, pathnames containing the CRLF pair of characters cannot be
transmitted over a data connection. Data connections only contain
file names transmitted from server-FTP to user-FTP as the result of
one of the directory listing commands. Files with names containing
the CRLF sequence must either have that sequence converted to some
other form, such that the other form can be recognised and be
correctly converted back to CRLF, or be omitted from the listing.
Implementations should also beware that the control connection uses Implementations should also beware that the control connection uses
Telnet NVT conventions [8], and that the Telnet IAC character, if Telnet NVT conventions [8], and that the Telnet IAC character, if
part of a pathname sent over the control connection, MUST be part of a pathname sent over the control connection, MUST be
correctly escaped as defined by the Telnet protocol. correctly escaped as defined by the Telnet protocol.
NVT also distinguishes between CR, LF, and the end of line CRLF, and
so would permit pathnames containing the pair of characters CR and LF
to be correctly transmitted. However, because such a sequence cannot
be transmitted over a data connection (as part of the result of a
LIST, NLST, or MLSD command) such pathnames are best avoided.
Implementors should also be aware that although Telnet NVT Implementors should also be aware that although Telnet NVT
conventions are used over the control connections, Telnet option conventions are used over the control connections, Telnet option
negotiation MUST NOT be attempted. See section 4.1.2.12 of [9]. negotiation MUST NOT be attempted. See section 4.1.2.12 of [9].
2.2.1. Pathname Syntax 2.2.1. Pathname Syntax
Except where TVFS is supported (see section 6) this specification Except where TVFS is supported (see section 6) this specification
imposes no syntax upon pathnames. Nor does it restrict the character imposes no syntax upon pathnames. Nor does it restrict the character
set from which pathnames are created. This does not imply that the set from which pathnames are created. This does not imply that the
NVFS is required to make sense of all possible pathnames. Server-PIs NVFS is required to make sense of all possible pathnames. Server-PIs
skipping to change at page 8, line 21 skipping to change at page 8, line 35
supported, the "modify" fact which can be provided in the result from supported, the "modify" fact which can be provided in the result from
the new MLST command is recommended as a superior alternative. the new MLST command is recommended as a superior alternative.
When attempting to restart a RETRieve, if the User-FTP makes use of 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 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 source file is more recent than the
modification time of the partially transferred file. If it is, then modification time of the partially transferred file. If it is, then
most likely the source file has changed and it would be unsafe to most likely the source file has changed and it would be unsafe to
restart the previously incomplete file transfer. restart the previously incomplete file transfer.
Because the User and server FTPs' clocks are not necessarily
synchronised, User FTPs intending to use this method should usually
obtain the modification time of the file from the server before the
initial RETRieval, and compare that with the modification time before
a RESTart. If they differ, the files may have changed, and RESTart
would be inadvisable. Where this is not possible, the User FTP
should make sure to allow for possible clock skew when comparing
times.
When attempting to restart a STORe, the User FTP can use the MDTM When attempting to restart a STORe, the User FTP can use the MDTM
command to discover the modification time of the partially command to discover the modification time of the partially
transferred file. If it is older than the modification time of the 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 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. changed and it would be unsafe to restart the file transfer.
Note that using MLST (described below) where available, can provide Note that using MLST (described below) where available, can provide
this information, and much more, thus giving an even better this information, and much more, thus giving an even better
indication that a file has changed, and that restarting a transfer indication that a file has changed, and that restarting a transfer
would not give valid results. would not give valid results.
skipping to change at page 17, line 43 skipping to change at page 18, line 28
Where there is no suitable substitute character a more complex Where there is no suitable substitute character a more complex
encoding scheme, possibly using an escape character, is likely to be encoding scheme, possibly using an escape character, is likely to be
required. required.
With the one exception of the unnamed root directory, a TVFS file 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 name may not be empty. That is, all other file names contain at
least one character. least one character.
With the sole exception of the "/" character, any valid IS10646 With the sole exception of the "/" character, any valid IS10646
character [11] may be used in a TVFS file name. When transmitted, character [11] may be used in a TVFS file name. When transmitted,
file name characters are encoded using the UTF-8 encoding [2]. 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 6.2. TVFS Pathnames
A TVFS "Pathname" combines the file or directory name of a target A TVFS "Pathname" combines the file or directory name of a target
file or directory, with the directory names of zero or more enclosing file or directory, with the directory names of zero or more enclosing
directories, so as to allow the target file or directory to be directories, so as to allow the target file or directory to be
referenced other than when the server's "current working directory" referenced other than when the server's "current working directory"
is the directory directly containing the target file or directory. is the directory directly containing the target file or directory.
By definition, every TVFS file or directory name is also a TVFS By definition, every TVFS file or directory name is also a TVFS
skipping to change at page 44, line 21 skipping to change at page 44, line 37
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1
S> 226 MLSD completed S> 226 MLSD completed
Next, notice the labels of the facts. These are also case Next, notice the labels of the facts. These are also case
independent strings, Server-FTP is permitted to return them in any independent strings, Server-FTP is permitted to return them in any
case they desire. User-FTP must be prepared to deal with any case, case desired. User-FTP must be prepared to deal with any case,
though it may do this by mapping the labels to a common case if though it may do this by mapping the labels to a common case if
desired. desired.
Then, notice that there are nine objects of "type" file returned. In Then, notice that there are nine objects of "type" file returned. In
a case independent NVFS these would represent three different file a case independent NVFS these would represent three different file
names, "file1", "file2", and "file3". With a case dependent NVFS all names, "file1", "file2", and "file3". With a case dependent NVFS all
nine represent different file names. Either is possible, server-FTPs nine represent different file names. Either is possible, server-FTPs
may implement a case dependent or a case independent NVFS. User-FTPs may implement a case dependent or a case independent NVFS. User-FTPs
must allow for case dependent selection of files to manipulate on the must allow for case dependent selection of files to manipulate on the
server. server.
skipping to change at page 56, line 43 skipping to change at page 56, line 47
This memo does not directly concern security. It is not believed This memo does not directly concern security. It is not believed
that any of the mechanisms documented here impact in any particular that any of the mechanisms documented here impact in any particular
way upon the security of FTP. way upon the security of FTP.
Implementing the SIZE command, and perhaps some of the facts of the Implementing the SIZE command, and perhaps some of the facts of the
MLSx commands, may impose a considerable load on the server, which MLSx commands, may impose a considerable load on the server, which
could lead to denial of service attacks. Servers have, however, could lead to denial of service attacks. Servers have, however,
implemented this for many years, without significant reported implemented this for many years, without significant reported
difficulties. difficulties.
Server FTP should take care not to reveal sensitive information about
files to unauthorised parties. In particular, some underlying
filesystems provide a file identifier which, if known, can allow many
of the filesystem protection mechanisms to be by-passed. That
identifier would not be a suitable choice to use as the basis of the
value of the unique fact.
The FEAT and OPTS commands may be issued before the FTP The FEAT and OPTS commands may be issued before the FTP
authentication has occurred [6]. This allows unauthenticated clients authentication has occurred [6]. This allows unauthenticated clients
to determine which of the features defined here are supported, and to to determine which of the features defined here are supported, and to
negotiate the fact list for MLSx output. No actual MLSx commands may negotiate the fact list for MLSx output. No actual MLSx commands may
be issued however, and no problems with permitting the selection of be issued however, and no problems with permitting the selection of
the format prior to authentication are foreseen. the format prior to authentication are foreseen.
A general discussion of issues related to the security of FTP can be A general discussion of issues related to the security of FTP can be
found in [14]. found in [14].
12. References 12. Normative References
[1] Coded Character Set--7-bit American Standard Code for Information [1] Coded Character Set--7-bit American Standard Code for Information
Interchange, ANSI X3.4-1986. Interchange, ANSI X3.4-1986.
[2] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO [2] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996. 10646", RFC 2044, October 1996.
[3] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)", [3] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)",
STD 9, RFC 959, October 1985 STD 9, RFC 959, October 1985
skipping to change at page 59, line 25 skipping to change at page 60, line 25
the second. the second.
Note that the authors of this document are the IETF community at Note that the authors of this document are the IETF community at
large, and the FTPEXT working group in particular. Those individuals large, and the FTPEXT working group in particular. Those individuals
named below are merely those who copied the IETF's work onto named below are merely those who copied the IETF's work onto
(electronic) paper. (electronic) paper.
Editors' Addresses Editors' Addresses
Robert Elz Robert Elz
University of Melbourne Prince of Songkla University
Department of Computer Science Department of Computer Enginering
Parkville, Vic 3052 Hat Yai, 90112
Australia Thailand
Email: kre@munnari.OZ.AU Email: kre@munnari.OZ.AU
Paul Hethmon Paul Hethmon
Hethmon Brothers Hethmon Brothers
2305 Chukar Road 2305 Chukar Road
Knoxville, TN 37923 USA Knoxville, TN 37923 USA
Phone: +1 423 690 8990 Phone: +1 423 690 8990
Email: phethmon@hethmon.com Email: phethmon@hethmon.com
 End of changes. 21 change blocks. 
30 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/