As per Relevance of the word extension, we have this rfc below:
Network Working Group P.
Request for Comments: 2389 Hethmon
See Also: 959 R.
Category: Standards Track University of
August 1998
Feature negotiation mechanism for the File Transfer
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The File Transfer Protocol is, from time to time, extended with
commands, or facilities. Implementations of the FTP protocol
be assumed to all immediately implement all newly defined mechanisms
This document provides a mechanism by which clients of the
protocol can discover which new features are supported by
particular FTP server
Hethmon & Elz Standards Track [Page 1]
RFC 2389 Feature negotiation mechanism August 1998
Table of
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 ................................ 9
1.
This document amends the File Transfer Protocol (FTP) [1]. Two
commands are added: "FEAT" and "OPTS".
These commands allow a client to discover which optional commands
server supports, and how they are supported, and to select
various options that any FTP command may support
2. Document
This document makes use of the document conventions defined in BCP14
[2]. That provides the interpretation of some capitalized words
MUST, SHOULD, etc
Terms defined in [1] will be used here as defined there.
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
simply recall that these definitions exist here, and skip to the
section
Hethmon & Elz Standards Track [Page 2]
RFC 2389 Feature negotiation mechanism August 1998
2.1. Basic
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
use in this document
TCHAR = VCHAR / SP / HTAB ; visible plus white
The TCHAR type, and VCHAR from [3], give basic character types
varying sub-sets of the ASCII character set for use in
commands and responses
error-response = error-code SP *TCHAR
error-code = ("4" / "5") 2
Note that in ABNF, strings literals are case insensitive.
convention is preserved in this document. However note that ALPHA
in particular, is case sensitive, as are VCHAR and TCHAR
2.2. Server
Section 4.2 of [1] defines the format and meaning of replies by
server-PI to FTP commands from the user-PI. Those reply
are used here without change. Implementors should note that the
syntax (which was not used in [1]) in this document, and other
related documents, sometimes shows replies using the one line format
Unless otherwise explicitly stated, that is not intended to
that multi-line responses are not permitted. Implementors
assume that, unless stated to the contrary, any reply to any
command (including QUIT) may be of the multiline format described
[1].
Throughout this document, replies will be identified by the
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
It is not to be expected that all servers will necessarily
all of the new commands defined in all future amendments to the
protocol. In order to permit clients to determine which new
are supported by a particular server, without trying each
command, one new command is added to the FTP command repertoire
This command requests the server to list all extension commands,
extended mechanisms, that it supports. That is, all defined
specified commands and features not defined in [1], or this document
must be included in the FEAT command output in the form specified
Hethmon & 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,
features listed. This is not an error, and simply indicates that
server-FTP implementor has seen, and implemented, the
of a new feature that is unknown to the user-FTP
3.1. Feature (FEAT) Command
feat = "Feat"
The FEAT command consists solely of the word "FEAT". It has
parameters or arguments
3.2. FEAT Command
Where a server-FTP process does not support the FEAT command, it
respond to the FEAT command with a 500 or 502 reply. This is
the normal "unrecognized command" reply that any unknown
would elicit. Errors in the command syntax, such as
parameters, will result in a 501 reply
Server-FTP processes that recognize the FEAT command, but
no extended features, and therefore have nothing to report,
respond with the "no-features" 211 reply. However, as this case
practically indistinguishable from a server-FTP that does
recognize the FEAT command, a 500 or 502 reply MAY also be used.
"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
interpreted, and has no practical use, as this text is not
to be revealed to end users. The syntax of other reply lines
precisely defined, and if present, MUST be exactly as specified
feat-response = error-response / no-features / feature-
no-features = "211" SP *TCHAR
feature-listing = "211-" *TCHAR
1*( SP feature CRLF )
"211 End"
feature = feature-label [ SP feature-parms ]
feature-label = 1*
feature-parms = 1*
Note that each feature line in the feature-listing begins with
single space. That space is not optional, nor does it
general white space. This space guarantees that the feature line
Hethmon & Elz Standards Track [Page 4]
RFC 2389 Feature negotiation mechanism August 1998
never be misinterpreted as the end of the feature-listing, but
required even where there is no possibility of ambiguity
Each extension supported must be listed on a separate line
facilitate the possible inclusion of parameters supported by
extension command. The feature-label to be used in the response
the FEAT command will be specified as each new feature is added
the FTP command set. Often it will be the name of a new
added, however this is not required. In fact it is not required
a new feature actually add a new command. Any parameters
are to be specified with the definition of the command concerned
That specification shall also specify how any parameters present
to be interpreted
The feature-label and feature-parms are nominally case sensitive
however the definitions of specific labels and parameters specify
precise interpretation, and it is to be expected that
definitions will usually specify the label and parameters in a
independent manner. Where this is done, implementations
recommended to use upper case letters when transmitting the
response
The FEAT command itself is not included in the list of
supported, support for the FEAT command is indicated by return of
reply other than a 500 or 502 reply
A typical example reply to the FEAT command might be a
reply of the form
C>
S> 211-Extensions supported
S> MLST size*;create;modify*;perm;media-
S>
S>
S>
S> 211
The particular extensions shown here are simply examples of what
be defined in other places, no particular meaning should
attributed to them. Recall also, that the feature names returned
not command names, as such, but simply indications that the
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
order, or even to consistently return the same order when the
is repeated
Hethmon & Elz Standards Track [Page 5]
RFC 2389 Feature negotiation mechanism August 1998
FTP implementations which support FEAT MUST include in the
to the FEAT command all properly documented FTP extensions
those commands and mechanisms described in RFC959 [1], including
which existed before the existence of FEAT. That is, when a
receives a FEAT response from an FTP server, it can assume that
only extensions the server supports are those that are listed in
FEAT response
User-FTP processes should, however, be aware that there have
several FTP extensions developed, and in widespread use, prior to
adoption of this document and the FEAT command. The effect of
is that an error response to the FEAT command does not
imply that those extensions are not supported by the server-
process. User-PIs should test for such extensions individually if
error response has been received to the FEAT command
3.3. Rationale for
While not absolutely necessary, a standard mechanism for the server
PI to inform the user-PI of any features and extensions
will help reduce unnecessary traffic between the user-PI and server
PI as more extensions may be introduced in the future. If
mechanism existed for this, a user-FTP process would have to try
extension in turn resulting in a series of exchanges between
user-PI and server-PI. Apart from being possibly wasteful,
procedure may not always be possible, as issuing of a command just
determine if it is supported or not may have some effect that is
desired
4. The OPTS
The OPTS (options) command allows a user-PI to specify the
behavior of a server-FTP process when another FTP command (the
command) is later issued. The exact behavior, and syntax, will
with the target command indicated, and will be specified with
definition of that command. Where no OPTS behavior is defined for
particular command there are no options available for that command
Request Syntax
opts = opts-cmd SP command-
[ SP command-options ]
opts-cmd = "opts
command-name =
command-options = 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-
opts-good = "200" SP response-message
opts-bad = "451" SP response-message CRLF /
"501" SP response-message
response-message = *
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
permanent error. That is, for any case where simply repeating
command at some later time, without other changes of state, will
be an error. A 451 reply should be sent where some
condition at the server, not related to the state of
between user and server, prevents the command being accepted
issued, but where if repeated at some later time, a
environment for the server-FTP process may permit the command
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
implemented. Because of that, there is no indication in the list
features returned by FEAT to indicate that the OPTS command itself
supported. Neither the FEAT command, nor the OPTS command, have
optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS
commands
5. Security
No significant new security issues, not already present in the
protocol, are believed to have been created by this extension
However, this extension does provide a mechanism by which users
determine the capabilities of an FTP server, and from
additional information may be able to be deduced. While the
basic information could be obtained by probing the server for
various commands, if the FEAT command were not provided, that
may reveal an attacker by logging the attempts to access
extension commands. This possibility is not considered a
enough threat to be worthy of any remedial action
The security of any additional features that might be reported by
FEAT command, and manipulated by the OPTS command, should
addressed where those features are defined
Hethmon & Elz Standards Track [Page 7]
RFC 2389 Feature negotiation mechanism August 1998
6.
[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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
This protocol extension was developed in the FTPEXT Working Group
the IETF, and the members of that group are all acknowledged as
creators
Editors'
Paul
Hethmon
2305 Chukar
Knoxville, TN 37923
Phone: +1 423 690 8990
Email: phethmon@hethmon.
Robert
University of
Department of Computer
Parkville, Vic 3052
Email: kre@munnari.OZ.
Hethmon & Elz Standards Track [Page 8]
RFC 2389 Feature negotiation mechanism August 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Hethmon & Elz Standards Track [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
