reply other than a 500 or 502 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>  COMPRESSION        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.  Recall also, that the feature names returned are   not command names, as such, but simply indications that the server   possesses some attribute or other.   The order in which the features are returned is of no importance,   server-FTP processes are not required to implement any particular   order, or even to consistently return the same order when the command   is repeated.Hethmon & Elz               Standards Track                     [Page 5]RFC 2389             Feature negotiation mechanism           August 1998   FTP implementations which support FEAT MUST include in the response   to the FEAT command all properly documented FTP extensions beyond   those commands and mechanisms described in RFC959 [1], including any   which existed before the existence of FEAT.  That is, when a client   receives a FEAT response from an FTP server, it can assume that the   only extensions the server supports are those that are listed in the   FEAT response.   User-FTP processes should, however, be aware that there have been   several FTP extensions developed, and in widespread use, prior to the   adoption of this document and the FEAT command.  The effect of this   is that an error response to the FEAT command does not necessarily   imply that those extensions are not supported by the server-FTP   process.  User-PIs should test for such extensions individually if an   error response has been received to the FEAT command.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.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     = <any FTP command which allows option setting>        command-options  = <format specified by individual FTP command>Hethmon & Elz               Standards Track                     [Page 6]RFC 2389             Feature negotiation mechanism           August 1998   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 if 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 or 502   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.5. Security Considerations   No significant new security issues, not already present in the FTP   protocol, are believed to have been created by this extension.   However, this extension does provide a mechanism by which users can   determine the capabilities of an FTP server, and from which   additional information may be able to be deduced.  While the same   basic information could be obtained by probing the server for the   various commands, if the FEAT command were not provided, that method   may reveal an attacker by logging the attempts to access various   extension commands.  This possibility is not considered a serious   enough threat to be worthy of any remedial action.   The security of any additional features that might be reported by the   FEAT command, and manipulated by the OPTS command, should be   addressed where those features are defined.Hethmon & Elz               Standards Track                     [Page 7]RFC 2389             Feature negotiation mechanism           August 19986. References   [1]  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",        STD 9, RFC 959, October 1985.   [2]  Bradner, S., "Key words for use in RFCs to Indicate        Requirement Levels", BCP 14, RFC 2119, March 1997.   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax        Specifications: ABNF", RFC 2234, November 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: +1 423 690 8990   Email: phethmon@hethmon.com   Robert Elz   University of Melbourne   Department of Computer Science   Parkville, Vic   3052   Australia   Email: kre@munnari.OZ.AUHethmon & Elz               Standards Track                     [Page 8]RFC 2389             Feature negotiation mechanism           August 1998Full Copyright Statement   Copyright (C) The Internet Society (1998).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Hethmon & Elz               Standards Track                     [Page 9]