TOC 
Network Working GroupJ. Klensin
Internet-Draft 
Updates: 959 (if approved)A. Hoenes
Intended status: Standards TrackTR-Sys
Expires: June 21, 2010December 18, 2009


FTP Command and Extension Registry
draft-klensin-ftp-registry-04c

Abstract

Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 21, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.



Table of Contents

1.  Introduction
    1.1.  Discussion List
2.  Registry Definition
    2.1.  Registry Name
    2.2.  Registry Format
    2.3.  Criteria for Registration
    2.4.  Base FTP Commands
    2.5.  Obsolete Commands
3.  Initial Contents of Registry
4.  Acknowledgments
5.  IANA Considerations
6.  Security Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Change Log
    A.1.  Changes in Version -01
    A.2.  Changes in Version -02
    A.3.  Changes in Version -03
    A.4.  Changes in Version -04
§  Authors' Addresses




 TOC 

1.  Introduction

Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959 [RFC0959] (Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.). RFC 2389 (Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,” August 1998.) [RFC2389] established a mechanism for specifying and negotiating extensions to the FTP protocol specified in RFC 959, by means of "FEAT Strings" identifying extensions supported by the FTP server, and sent in response to a "FEAT" command. The number of extensions continues to grow, not all of them supported by FEAT. An IANA registry is established to reduce the likelihood of conflict of names and the consequent ambiguity and to encourage the sharing of information. This specification establishes that registry.



 TOC 

1.1.  Discussion List

[[ RFC Editor: please remove this section before publication. ]]

Until and unless a WG is created, this proposal will be discussed on the list apps-discuss@ietf.org



 TOC 

2.  Registry Definition



 TOC 

2.1.  Registry Name

The recommended name of this registry is "FTP Commands and Extensions".



 TOC 

2.2.  Registry Format

IANA is requested to establish a registry for FTP commands and extensions. Registration requests and registry entries should include the following:

Command Name -
The FTP command, either new or modified, used in the extension or with which the extension is used.
Following the long-standing practice to capitalize command names in specification documents for FTP, the command names are entered in all uppercase. For extensions amending the operation of a command, a plus sign ("+") is appended to the command name. However, an extension might not be bound to one command (or a small number of commands), but affect the overall command parameter handling and/or transaction processing; in this case, the string "-N/A-" is entered.

It is intended to have the registry entries ordered by ascending ASCII collation order of this column (including the "+" suffix if present).
Extension name -
The name of the extension.
FTP extensions predating RFC 2389 (Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,” August 1998.) [RFC2389], and some extensions published after it, did not specify a keyword to identify the extension in a FEAT response. Some later specifications established FEAT strings with the respective command names as their keywords. In order to provide for keywords for future specifications in such cases, this document establishes 'placeholder' keywords to reserve reasonable feature names for future standardization. Similarly, placeholder keywords are used for the basic FTP commands specified in RFC 959 (Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.) [RFC0959] and those of its predecessors that are still in use. These placeholder keywords are placed in the registry for convenience; it is not intended that they be returned in FEAT responses.
To compensate for this idiosyncrasy, the column in the registry is entitled "FEAT Code", and to clearly distinguish between the two cases, defined FEAT keywords codes are listed in all uppercase, whereas 'placeholder' keywords (henceforth called "pseudo FEAT codes") are listed in lowercase. Future specifications are allowed to "upgrade" a placeholder to a true keyword unless it is specifically declared 'immutable' below, but otherwise IANA maintains uniqueness of feature names (FEAT codes) based on case-insensitive comparison.
Description -
A brief description of the extension and, where appropriate, the command.
FEAT String -
(optional in registration requests to the IANA)
The string expected to be included in the response to the FEAT command [RFC2389] (Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,” August 1998.) if the extension is supported.

In many cases, the FEAT string required to identify an extension only consists of the "FEAT Code", making this item redundant. Therefore, this item should only be specified if it is intended to register a FEAT string that contains mandatory elements other than the "FEAT Code" itself.

Due to space restrictions, and to allow registrants to provide additional information as well, IANA should present these registration items (if given) in numbered footnotes to the table, not in an additional table column.
Command Type -
The type (or 'kind') of the command.
Section 4.1 of RFC 959 (Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.) [RFC0959] introduced a subdivision of FTP commands into three types: Access control, transfer Parameter {setting}, and Service {execution}. For clarity and as a service to the user of the registry, this subdivision is extended to all registered FTP commands, using the characteristic initial of the type, 'a', 'p', or 's', respectively, filed in the registry column entitled "type"; combinations are allowed, e.g. 'p/s'.
Conformance Requirements -
The support expectation for the command.
RFC 959 specifies mandatory-to-implement commands and optional commands. This classification is carried over to all registered commands, using a column entitled "conf" carrying a single character -- either 'm' or 'o', for "mandatory" and "optional", respectively. Similarly, obsoleted or historic entries are left in the registry to avoid conflicts with deployed implementations, and these entries are marked with 'h' (for "historic").
Beyond the initial registrations, Standards Action [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) is needed to register new "mandatory" entries or to move such entries to "historic".
Reference -
A reference to an RFC or other definition of the extension and/or to implementations supporting it (see the next section).



 TOC 

2.3.  Criteria for Registration

This registry is primarily intended to avoid conflicting uses of the same extension names and command keywords for different purposes, not to demonstrate that an extension is somehow "approved". The "expert review" method will be used, but the designated expert is expected to check only that at least one of the two criteria that follow are met.

  1. The extension is documented in a permanent and readily available public specification (This is the same as the "Specification Required" registration policy defined in RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226].
  2. The extension is actually implemented in FTP client and server systems that are generally available (not necessarily either free or unencumbered, but available).

For an extension or command to be marked "mandatory" ('m' in the "conf" column), an IETF Standards Track Specification is required. An IESG Standards Action is allowed to direct IANA to change the Conformance Requirements listed for any entry.



 TOC 

2.4.  Base FTP Commands

The following commands are part of the base FTP specification [RFC0959] (Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.) and are listed in the registry with the immutable pseudo FEAT code "base".

Mandatory commands:

ABOR, ACCT, ALLO, APPE, CWD, DELE, HELP, LIST, MODE, NLST, NOOP, PASS, PASV, PORT, QUIT, REIN, REST, RETR, RNFR, RNTO, SITE, STAT, STOR, STRU, TYPE, USER

Optional commands:

CDUP, MKD, PWD, RMD, SMNT, STOU, SYST

Note: STD 3 (Braden, R., “Requirements for Internet Hosts - Application and Support,” October 1989.) [RFC1123] clarified and updated the status and implementation requirements of these standard FTP commands, and it contains important complementary information for the following commands:

LIST, NLST, PASV, REST, SITE, STOU



 TOC 

2.5.  Obsolete Commands

The following commands were specified as experimental in an extension to an early version of the FTP specification [RFC0775] (Mankins, D., Franklin, D., and A. Owen, “Directory oriented FTP commands,” December 1980.) but later deprecated by RFC 1123 (Braden, R., “Requirements for Internet Hosts - Application and Support,” October 1989.) [RFC1123], because Standard FTP [RFC0959] (Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.) specifies their standard successors. They are listed in the registry with the immutable pseudo FEAT code "hist".

XCUP, XCWD, XMKD, XPWD, XRMD

Implementation note:
Deployed FTP clients still make use of the deprecated commands and most FTP servers support them as aliases for the standard commands.

The following commands were specified as part of the "FOOBAR" IPng effort in RFC 1545 (Piscitello, D., “FTP Operation Over Big Address Records (FOOBAR),” November 1993.) [RFC1545] and, later, RFC 1639 (Piscitello, D., “FTP Operation Over Big Address Records (FOOBAR),” June 1994.) [RFC1639] and are now obsolete. They are listed in the registry with the immutable pseudo FEAT code "hist".

LPRT, LPSV



 TOC 

3.  Initial Contents of Registry

As a service to users of the registry and the authors of existing specifications, all FTP commands and features published in RFCs after STD 3 (Braden, R., “Requirements for Internet Hosts - Application and Support,” October 1989.) [RFC1123] and up to the time of this writing are to be included into the registry upon creation.

The following pseudo FEAT codes have been assigned, according to Section 2 (Registry Definition):

base - FTP standard commands [RFC0959] (Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.)

hist - Historic experimental commands [RFC0775] (Mankins, D., Franklin, D., and A. Owen, “Directory oriented FTP commands,” December 1980.), [RFC1639] (Piscitello, D., “FTP Operation Over Big Address Records (FOOBAR),” June 1994.)

secu - FTP Security Extensions [RFC2228] (Horowitz, M., “FTP Security Extensions,” October 1997.)

feat - FTP Feature Negotiation [RFC2389] (Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,” August 1998.)

nat6 - FTP Extensions for NAT/IPv6 [RFC2428] (Allman, M., Ostermann, S., and C. Metz, “FTP Extensions for IPv6 and NATs,” September 1998.)



cmdFEAT CodedescriptiontypeconfRFC#s/References and Notes
ABOR base Abort s m 959
ACCT base Account a m 959
ADAT secu Authentication/ Security Data a o 2228, 2773, 4217
ALLO base Allocate s m 959
APPE base Append (with create) s m 959
AUTH secu Authentication/ Security Mechanism a o 2228
AUTH+ AUTH Authentication/ Security Mechanism a o 2773, 4217 #2
CCC secu Clear Command Channel a o 2228
CDUP base Change to Parent Directory a o 959
CONF secu Confidentiality Protected Command a o 2228
CWD base Change Working Directory a m 959
DELE base Delete File s m 959
ENC secu Privacy Protected Command a o 2228, 2773, 4217
EPRT nat6 Extended Port p o 2428
EPSV nat6 Extended Passive Mode p o 2428
FEAT feat Feature Negotiation a m #1 2389
HELP base Help s m 959
LANG UTF8 Language (for Server Messages) p o 2640
LIST base List s m 959, 1123
LPRT hist Data Port {FOOBAR} p h 1545, 1639
LPSV hist Passive Mode {FOOBAR} p h 1545, 1639
MDTM MDTM File Modification Time s o 3659
MIC secu Integrity Protected Command a o 2228, 2773, 4217
MKD base Make Directory s o 959
MLSD MLST List Directory (for machine) s o 3659
MLST MLST List Single Object s o 3659
MODE base Transfer Mode p m 959
NLST base Name List s m 959, 1123
NOOP base No-Op s m 959
OPTS feat Options p m #1 2389
PASS base Password a m 959
PASV base Passive Mode p m 959, 1123
PBSZ secu Protection Buffer Size p o 2228
PBSZ+ PBSZ Protection Buffer Size p o 4217
PORT base Data Port p m 959
PROT secu Data Channel Protection Level p o 2228
PROT+ PROT Data Channel Protection Level p o 4217
PWD base Print Directory s o 959
QUIT base Logout a m 959
REIN base Reinitialize a m 959
REST base Restart s/p m 959, 1123
REST+ REST Restart (for STREAM mode) s/p m 3659 #3
RETR base Retrieve s m 959
RMD base Remove Directory s o 959
RNFR base Rename From s/p m 959
RNTO base Rename From s m 959
SITE base Site Parameters s m 959, 1123
SIZE SIZE File Size s o 3659
SMNT base Structure Mount a o 959
STAT base Status s m 959
STOR base Store s m 959
STOU base Store Unique a o 959, 1123
STRU base File Structure p m 959
SYST base System s o 959
TYPE base Representation Type p m 959 #4
USER base User Name a m 959
XCUP hist {precursor for CDUP} s h 775, 1123
XCWD hist {precursor for CWD} s h 775, 1123
XMKD hist {precursor for MKD} s h 775, 1123
XPWD hist {precursor for PWD} s h 775, 1123
XRMD hist {precursor for RMD} s h 775, 1123
-N/A- TVFS Trivial Virtual File Store p o 3659

 Table 1 

Notes:

#1
While an IETF Standards Action would be required to make the FEAT mechanism [RFC2389] (Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,” August 1998.) mandatory, implementation of that extension mechanism is clearly required in conjunction with any extension or feature that depends on it.
#2
FEAT String for RFC 4217: AUTH TLS FEAT String for RFC 2773: AUTH KEA-SKIPJACK
#3
FEAT String: REST STREAM
#4
FEAT String: TYPE {semicolon-separated list of supported types}



 TOC 

4.  Acknowledgments

Any work to update or extend FTP depends on the base specification in RFC 959. The contributions of its editors, Jon Postel and Joyce Reynolds, are gratefully acknowledged. The option negotiation mechanism specified in RFC 2389 and the accumulation of features that has followed it made this registry relevant; the authors of those documents are acknowledged as well.

Barry Leiba and Alexey Melnikov made several suggestions about earlier drafts of this document, most of which have been incorporated.

Anthony Bryan spotted a few typographical errors.

Scott Bradner suggested a clarification to the "expert review" text that has been incorporated.

The authors appreciate the comments and support for this work received from FTP implementers and many IETF participants. Comments from the IESG helped to shape this document and registry to improve its utility.



 TOC 

5.  IANA Considerations

IANA is requested to establish the registry described in Section 2 (Registry Definition) using the initial content specified in Section 3 (Initial Contents of Registry) and including the body of 2.4 (Base FTP Commands) and 2.5 (Obsolete Commands) as explanatory text in the preface of the registry.

New entries should be added to this registry when extensions to FTP are approved or defined in published RFCs or when extensions that are already in use and well-documented are identified. In other words, the requirement for registration is a slightly relaxed version of "Specification Required" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) with Expert Review. See Section 2.3 (Criteria for Registration) for specifics and exceptions.



 TOC 

6.  Security Considerations

The creation of this registry provides improved documentation and protection against interoperability problems. It introduces no new security issues.



 TOC 

7.  References



 TOC 

7.1. Normative References

[RFC0959] Postel, J. and J. Reynolds, “File Transfer Protocol,” STD 9, RFC 959, October 1985 (TXT).
[RFC2389] Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,” RFC 2389, August 1998 (TXT, HTML, XML).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).


 TOC 

7.2. Informative References

[RFC0775] Mankins, D., Franklin, D., and A. Owen, “Directory oriented FTP commands,” RFC 775, December 1980 (TXT).
[RFC1123] Braden, R., “Requirements for Internet Hosts - Application and Support,” STD 3, RFC 1123, October 1989 (TXT).
[RFC1545] Piscitello, D., “FTP Operation Over Big Address Records (FOOBAR),” RFC 1545, November 1993 (TXT).
[RFC1639] Piscitello, D., “FTP Operation Over Big Address Records (FOOBAR),” RFC 1639, June 1994 (TXT).
[RFC2228] Horowitz, M., “FTP Security Extensions,” RFC 2228, October 1997 (TXT, HTML, XML).
[RFC2428] Allman, M., Ostermann, S., and C. Metz, “FTP Extensions for IPv6 and NATs,” RFC 2428, September 1998 (TXT, HTML, XML).
[RFC2773] Housley, R. and P. Yee, “Encryption using KEA and SKIPJACK,” RFC 2773, February 2000 (TXT).
[RFC4217] Ford-Hutchinson, P., “Securing FTP with TLS,” RFC 4217, October 2005 (TXT).
[RFC4844] Daigle, L. and Internet Architecture Board, “The RFC Series and RFC Editor,” RFC 4844, July 2007 (TXT).


 TOC 

Appendix A.  Change Log

[[ RFC Editor: Please remove this Appendix before publication. ]]



 TOC 

A.1.  Changes in Version -01

Updated document to reflect new date and IPR statement.



 TOC 

A.2.  Changes in Version -02



 TOC 

A.3.  Changes in Version -03

Version -03 was produced in response to IETF Last Call and subsequent IESG comments:

  • Removed References section entry for RFC 2119 -- not used.
  • Added all "base" (RFC 959/ 1123) commands and obsolete commands (RFCs 0775, 1545/1639) to registry after discussion during Last Call and with IESG. Tentatively recast title and several bits of the document to refer to "FTP Commands and Extensions", not just extensions and made related text changes.
  • Clarified instructions to IANA including the "peer reviewed publication" requirement in Section 2.3 (Criteria for Registration).
  • Adjusted references so that those which support commands in the registry are all informative.
  • Removed language more appropriate to a proposal than to a finished spec (e.g., a few uses of "it appears useful").
  • Clarified the IANA Considerations text about "specification required" to make it consistent with Section 2.3 (Criteria for Registration). Specifically, specifications of a quality needed to permit interoperable implementations are not required although they are certainly desirable.
  • After an extended discussion about the possible role of this document in making some extensions mandatory to implement, returned it to its status as a registry specification only. The former text that made the RFC 2389 and 2428 extensions mandatory has been removed. RFC 2389 (the FEAT mechanism itself) is now identified as mandatory for the extensions that depend on it (with a new Note); RFC 2389 (the nat6 extensions) are now simply optional as far as FTP is concerned as they should probably remain unless the IETF concludes that nat6 is either required or very broadly deployed.
  • More editorial fixes.


 TOC 

A.4.  Changes in Version -04

Final editing patches -- probably will not be posted until after IESG signoff.

  • Correction of small typos spotted after -03 was posted.
  • Another attempt at reformatting the table for better readability.
  • Cleanup of comments used in the XML to keep the editors synchronized. These changes do not affect the text (or other) output forms of the document.
  • Changed the registration criteria (See Section 2.3 (Criteria for Registration)) at IESG request.


 TOC 

Authors' Addresses

  John C Klensin
  1770 Massachusetts Ave, Ste 322
  Cambridge, MA 02140
  USA
Phone:  +1 617 245 1457
Email:  john+ietf@jck.com
  
  Alfred Hoenes
  TR-Sys
  Gerlinger Str. 12
  Ditzingen D-71254
  Germany
Email:  ah@TR-Sys.de