Network Working Group                                         P. HethmonRequest for Comments: 2389                              Hethmon BrothersSee Also: 959                                                     R. ElzCategory: Standards Track                        University of Melbourne                                                             August 1998      Feature negotiation mechanism for the File Transfer ProtocolStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.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.Hethmon & Elz               Standards Track                     [Page 1]RFC 2389             Feature negotiation mechanism           August 1998Table of Contents          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  ......................................   6    4     The OPTS Command  ........................................   6    5     Security Considerations  .................................   7    6     References  ..............................................   8          Acknowledgements  ........................................   8          Editors' Addresses  ......................................   8          Full Copyright Statement  ................................   91. 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               Standards Track                     [Page 2]RFC 2389             Feature negotiation mechanism           August 19982.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, VCHAR, SP, etc.  To that, the following terms are added for   use in this document.        TCHAR          = VCHAR / SP / HTAB    ; visible plus white space   The TCHAR type, and VCHAR from [3], 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 VCHAR 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, or   extended mechanisms, that it supports.  That is, all defined and   specified commands and features not defined in [1], or this document,   must be included in the FEAT command output in the form specified inHethmon & Elz               Standards Track                     [Page 3]RFC 2389             Feature negotiation mechanism           August 1998   the document that defines the extension.   User-FTP PIs must expect to see, in FEAT command responses, unknown   features listed.  This is not an error, and simply indicates that the   server-FTP implementor has seen, and implemented, the specification   of a new feature that is unknown to the user-FTP.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 or 502 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 or 502 reply MAY also be used.  The   "no-features" reply MUST NOT use the multi-line response format,   exactly one response line is required and permitted.   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, and has no practical use, as this text is not expected   to be revealed to end users.  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                          1*( SP feature CRLF )                          "211 End" CRLF        feature         = feature-label [ SP feature-parms ]        feature-label   = 1*VCHAR        feature-parms   = 1*TCHAR   Note that each feature line in the feature-listing begins with a   single space.  That space is not optional, nor does it indicate   general white space.  This space guarantees that the feature line canHethmon & Elz               Standards Track                     [Page 4]RFC 2389             Feature negotiation mechanism           August 1998   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   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 feature-label and feature-parms are nominally case sensitive,   however the definitions of specific labels and parameters specify the   precise interpretation, and it is to be expected that those   definitions will usually specify the label and parameters in a case   independent manner.  Where this is done, implementations are   recommended to use upper case letters when transmitting the feature   response.   The FEAT command itself is not included in the list of features   supported, support for the FEAT command is indicated by return of a