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 draft-ietf-ftpext-mlst-00.txt 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). Abstract 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 exchanges. 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 extensible. 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 directory. 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 arguments. 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 = raw = 3.4. Format of MLST Response The format of a response to the MLST command is as follows: mlst-response = mlst-control-response / mlst-data-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 sequences. 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 size=4161;lang=en-us;modify=19970214165800;create=19961001124534; type=file;x.myfact=foo,bar 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 same. For keywords specifying time, the time is to be specified in one of the formats: yyyymmddhhmmss.sss or yyyymmddhhmmss where 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 object. unique-fact = unique-label "=" token unique-label = %h75.6e.69.71.75.65 ; "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 empty. 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 directory. 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 registry. media-type = media-label "=" media-label = %h6d.65.64.69.61.2d.74.79.70.65 ; "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 interoperability. 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 file. 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 = command-options = 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.65.63.74.69.6f.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. CWD RETR STOR APPE RNFR RNTO Hethmon & Elz [Page 17] Internet Draft draft-ietf-ftpext-mlst-00.txt March 1997 DELE RMD MKD PWD STAT 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 equivalents. [ 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 , Internet Mail Consortium, March 1997. [4] W. Curtin, "Internationalization of the File Transfer Protocol", Work In Progress , 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. Acknowledgements 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 Australia Email: kre@munnari.OZ.AU Hethmon & Elz [Page 19]