Feature negotiation mechanism for the File Transfer Protocol
RFC 2389

Document Type RFC - Proposed Standard (August 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2389 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         P. Hethmon
Request for Comments: 2389                              Hethmon Brothers
See Also: 959                                                     R. Elz
Category: Standards Track                        University of Melbourne
                                                             August 1998

      Feature negotiation mechanism for the File Transfer Protocol

Status 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 1998

Table 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  ................................   9

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               Standards Track                     [Page 2]
RFC 2389             Feature negotiation mechanism           August 1998

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, 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
Show full document text