FTPEXT Working Group P. Hethmon Internet Draft Hethmon Brothers Expiration Date: December 1997 R. Elz University of Melbourne June 1997 Feature negotiation mechanism for the File Transfer Protocol draft-ietf-ftpext-feat-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 The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms. This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. This draft extracts the FEAT and OPTS commands from the "mlst" draft, into this draft of their own. The descriptions of those commands have been updated in an editorial way, no changes of substance have been made. This paragraph will be deleted from the final version of this document. Hethmon & Elz [Page 1] Internet Draft draft-ietf-ftpext-feat-00.txt June 1997 Table of Contents Status of this Memo ..................................... 1 Abstract ................................................ 1 1 Introduction ............................................ 2 2 Document Conventions .................................... 2 2.1 Basic Tokens ............................................ 3 2.2 Server Replies .......................................... 3 3 Knowledge of Extra Capabilities - the FEAT Command ...... 3 3.1 Feature (FEAT) Command Syntax ........................... 4 3.2 FEAT Command Responses .................................. 4 3.3 Rationale for FEAT ...................................... 5 4 The OPTS Command ........................................ 6 5 Security ................................................ 7 6 References .............................................. 7 Acknowledgements ........................................ 7 Editors' Addresses ...................................... 7 1. Introduction This document amends the File Transfer Protocol (FTP) [1]. Two new commands are added: "FEAT" and "OPTS". These commands allow a client to discover which optional commands a server supports, and how they are supported, and to select among various options that any FTP command may support. 2. Document Conventions This document makes use of the document conventions defined in BCP14 [2]. That provides the interpretation of some capitalized words like MUST, SHOULD, etc. Terms defined in [1] will be used here as defined there. These include ASCII, reply, server-FTP process, user-FTP process, server- PI, user-PI, and user. Syntax required is defined using the Augmented BNF defined in [3]. Some general ABNF definitions are required throughout the document, those will be defined here. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section. Hethmon & Elz [Page 2] Internet Draft draft-ietf-ftpext-feat-00.txt June 1997 2.1. Basic Tokens This document imports the definitions given in Appendix A of [3]. 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. PCHAR = %x21-7e ; a printing character, ! to ~ TCHAR = PCHAR / SP / %x08 ; printing plus white space The PCHAR and TCHAR types give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses. error-response = error-code SP *TCHAR CRLF error-code = ("4" / "5") 2DIGIT Note that in ABNF, strings literals are case insensitive. That convention is preserved in this document. However note that ALPHA, in particular, is case sensitive, as are PCHAR and TCHAR. 2.2. Server Replies Section 4.2 of [1] 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. Implementors should note that the ABNF syntax (which was not used in [1]) 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 multiline format described in [1]. 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". 3. Knowledge of Extra Capabilities - the FEAT Command It is not to be expected that all servers will necessarily support all of the new commands defined in all future amendments to the FTP protocol. In order to permit clients to determine which new commands are supported by a particular server, without trying each possible command, one new command is added to the FTP command repertoire. This command requests the server to list all extension commands that it supports. Hethmon & Elz [Page 3] Internet Draft draft-ietf-ftpext-feat-00.txt June 1997 3.1. Feature (FEAT) Command Syntax feat = "Feat" CRLF The FEAT command consists solely of the word "FEAT". It has no parameters or arguments. 3.2. FEAT Command Responses Where a server-FTP process does not support the FEAT command, it will respond to the FEAT command with a 500 reply. This is simply the normal "unrecognized command" reply that any unknown command would elicit. Errors in the command syntax, such as giving parameters, will result in a 501 reply. Server-FTP processes that recognize the FEAT command, but implement no extended features, and therefore have nothing to report, SHOULD respond with the "no-features" 211 reply. However, as this case is practically indistinguishable from a server-FTP that does not recognize the FEAT command, a 500 reply MAY also be used. It is also possible to indicate that no features are implemented by returning a "feature-listing" 211 reply, with no features actually included, however server-FTP processes SHOULD NOT use this method. Replies to the FEAT command MUST comply with the following syntax. Text on the first line of the reply is free form, and not interpreted, but the syntax of other reply lines is precisely defined, and if present, MUST be exactly as specified. feat-response = error-response / no-features / feature-listing no-features = "211" SP *TCHAR CRLF feature-listing = "211-" *TCHAR CRLF *( SP feature CRLF ) "211 End" CRLF feature = feature-label [ SP parms ] feature-label = 1*PCHAR parms = 1*TCHAR Note that each feature line in the feature-listing begins with a space. That space is not optional, nor does it indicate general white space. This space guarantees that the feature line can never be misinterpreted as the end of the feature-listing, but is required even where there is no possibility of ambiguity. Each extension supported must be listed on a separate line to facilitate the possible inclusion of parameters supported by each extension command. The feature-label to be used in the response to the FEAT command will be specified as each new feature is added to Hethmon & Elz [Page 4] Internet Draft draft-ietf-ftpext-feat-00.txt June 1997 the FTP command set. Often it will be the name of a new command added, however this is not required, in fact it is not required that a new feature actually add a new command. Any parameters included are to be specified with the definition of the command concerned. That specification shall also specify how any parameters present are to be interpreted. The FEAT command itself is not included in the list of features supported, support for the FEAT command is indicated by return of a reply other than a 500 reply. A typical example reply to the FEAT command might 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 The particular extensions shown here are simply examples of what may be defined in other places, no particular meaning should be attributed to them. FTP implementations which support extension commands beyond those commands described in RFC959 [1] MUST support FEAT. 3.3. Rationale for FEAT While not absolutely necessary, a standard mechanism for the server- PI to inform the user-PI of any features and extensions supported will help reduce unnecessary traffic between the user-PI and server- PI as more extensions may be introduced in the future. If no mechanism existed for this, a user-FTP process would have to try each extension in turn resulting in a series of exchanges between the user-PI and server-PI. Apart from being possibly wasteful, this procedure may not always be possible, as issuing of a command just to determine if it is supported or not may have some effect that is not desired. Hethmon & Elz [Page 5] Internet Draft draft-ietf-ftpext-feat-00.txt June 1997 4. The OPTS Command The OPTS (options) command allows a user-PI to specify the desired behavior of a server-FTP process when another FTP command (the target command) is later issued. The exact behavior, and syntax, will vary with the target command indicated, and will be specified with the definition of that command. Where no OPTS behavior is defined for a particular command there are no options available for that command. Request Syntax: opts = opts-cmd SP command-name [ SP 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 response-message = *TCHAR An "opts-good" response (200 reply) MUST be sent when the command- name specified in the OPTS command is recognized, and the command- options, if any, are recognized, and appropriate, An "opts-bad" response is sent in other cases. A 501 reply is appropriate for any permanent error. That is, for any case where simply repeating the command at some later time, without other changes of state, will also be an error. A 451 reply should be sent where some temporary condition at the server, not related to the state of communications between user and server, prevents the command being accepted when issued, but where is repeated at some later time, a changed environment for the server-FTP process may permit the command to succeed. If the OPTS command itself is not recognized, a 500 reply will, of course, result. The OPTS command MUST be implemented whenever the FEAT command is implemented. Because of that, there is no indication in the list of features returned by FEAT to indicate that the OPTS command itself is supported. Neither the FEAT command, nor the OPTS command, have any optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS" commands. Hethmon & Elz [Page 6] Internet Draft draft-ietf-ftpext-feat-00.txt June 1997 5. 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. 6. References [1] J. Postel, J. Reynolds, "File Transfer Protocol (FTP)", STD 9 (RFC 959), ISI, October 1985 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 (RFC 2119), Harvard University, March 1997 [3] D. Crocker, "Augmented BNF for Syntax Specifications: ABNF", Work In Progress , Internet Mail Consortium, March 1997. Acknowledgements This protocol extension was developed in the FTPEXT Working Group of the IETF, and the members of that group are all acknowledged as its creators. 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 7]