Feature negotiation mechanism for the File Transfer Protocol
Extracted elements (21)
Each feature line in a FEAT response is required to begin with a single space that is not optional and does not indicate general whitespace. This space guarantees the feature line can never be misinterpreted as the `211 End` terminator.
FEAT was designed to reduce unnecessary traffic between user-PI and server-PI as more extensions are introduced. Without FEAT, a client would have to probe each extension in turn, which may be wasteful and may have undesired side effects from issuing commands merely to test support.
The FEAT command itself is not included in the list of returned features; support for FEAT is indicated by returning any reply other than 500 or 502. Similarly, OPTS is not listed because it is mandatory whenever FEAT is implemented.
Feature-label and feature-parms are nominally case sensitive, but definitions of specific labels will usually specify them in a case-independent manner; implementations are recommended to use upper case when transmitting the feature response.
Several FTP extensions were developed and in widespread use prior to the adoption of FEAT. An error response to FEAT does not necessarily mean those pre-existing extensions are unsupported; user-PIs should test for such extensions individually when FEAT returns an error.
Where no OPTS behavior is defined for a particular FTP command, there are no options available for that command; neither "OPTS FEAT" nor "OPTS OPTS" are valid because neither command has optional functionality.
A 451 reply SHOULD be sent for OPTS when a temporary server condition prevents acceptance of the command but where the command might succeed if repeated later under changed conditions.
An opts-good 200 reply MUST be sent when the command-name in OPTS is recognized and the command-options (if any) are recognized and appropriate.
FTP implementations that support FEAT MUST include in the FEAT response all properly documented FTP extensions beyond RFC 959, including those that existed before FEAT. A client receiving a FEAT response may assume the listed extensions are the only ones supported.
Replies to the FEAT command MUST comply with the specified ABNF syntax; the format of feature lines is precisely defined and MUST be exactly as specified.
Servers that recognize FEAT but have no extended features to report SHOULD respond with the "no-features" 211 reply, though a 500 or 502 reply MAY also be used since the cases are practically indistinguishable.
The "no-features" 211 reply MUST NOT use the multi-line response format; exactly one response line is required and permitted when the server supports FEAT but implements no extended features.
The OPTS command MUST be implemented whenever the FEAT command is implemented. Because of this coupling, OPTS is not listed in the FEAT response.
User-FTP PIs MUST expect to see unknown features in FEAT command responses; encountering an unlisted feature is not an error and simply indicates the server has implemented a new specification unknown to the client.
The FEAT command requests the server to list all extension commands and extended mechanisms it supports beyond those defined in RFC 959. It has no parameters or arguments.
The OPTS command allows a user-PI to specify the desired behavior of a server-FTP process when a target FTP command is later issued. The exact behavior and syntax vary with the target command.
No significant new security issues beyond those already in FTP are introduced by this extension. The FEAT command does allow users to enumerate server capabilities, but the same information could be obtained by probing commands; this capability-disclosure risk is not considered a serious threat warranting remedial action.
The security implications of any additional features reported by FEAT or manipulated by OPTS should be addressed in the specifications that define those individual features, not in this document.
FEAT command syntax is simply `feat = "Feat" CRLF` with no parameters. FEAT response uses a 211 multi-line format where each feature line begins with a mandatory single space, and the listing terminates with `211 End CRLF`.
OPTS command syntax: `opts = opts-cmd SP command-name [SP command-options] CRLF`. Response is either `opts-good = "200" SP response-message CRLF` or `opts-bad = "451" / "501" SP response-message CRLF`.
The FEAT response ABNF: `feature-listing = "211-" *TCHAR CRLF / 1*(SP feature CRLF) / "211 End" CRLF`. Each feature line is `feature = feature-label [SP feature-parms]` where feature-label is 1*VCHAR and feature-parms is 1*TCHAR.