FTP Command and Extension Registry
updates
- rfc-959 — File Transfer Protocol
Extracted elements (15)
Placeholder 'pseudo FEAT codes' (listed in lowercase) are introduced for commands predating RFC 2389 and others lacking a formal FEAT keyword. These reserve reasonable feature names for future standardization and are not intended to appear in FEAT responses. Real FEAT keywords are listed in uppercase; IANA enforces uniqueness case-insensitively.
The FEAT String registration item is optional because in many cases the FEAT string consists solely of the FEAT Code itself, making the field redundant. It should only be specified when the FEAT string contains mandatory elements beyond the FEAT Code (e.g., REST STREAM for REST+, or AUTH TLS for AUTH+).
The registry's primary purpose is to avoid conflicting uses of the same extension names, not to 'approve' extensions. Registration via Expert Review requires only that the extension be documented in a public specification or actually implemented in generally available FTP clients and servers.
Deployed FTP clients still make use of the deprecated XCUP/XCWD/XMKD/XPWD/XRMD commands, and most FTP servers support them as aliases for the standard RFC 959 successors. Implementations should be aware of this widespread practice.
Command names MUST be entered in all uppercase in the registry. For extensions amending a specific command, a plus sign ('+') is appended to the command name. For extensions affecting overall parameter handling not bound to a specific command, '-N/A-' is used.
For a command or extension to be marked mandatory ('m'), an IETF Standards Track specification is required. Beyond initial registrations, Standards Action is needed to register new mandatory entries or move entries to historic.
While a Standards Action would be required to make the FEAT mechanism itself mandatory, implementation of FEAT and OPTS is clearly required in conjunction with any extension or feature that depends on it. FEAT and OPTS are thus listed as mandatory ('m') in the registry.
Base FTP commands from RFC 959 are assigned the immutable pseudo FEAT code 'base'. Mandatory commands include 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 include CDUP, MKD, PWD, RMD, SMNT, STOU, SYST.
Command Type field uses single characters: 'a' for Access control, 'p' for transfer Parameter setting, 's' for Service execution, following RFC 959 Section 4.1. Combinations (e.g., 's/p') are allowed.
Conformance Requirements field uses: 'm' for mandatory-to-implement, 'o' for optional, and 'h' for historic/obsoleted entries. Historic entries are retained to avoid conflicts with deployed implementations.
Each registry entry includes: Command Name (all uppercase, '+' suffix for amendments, '-N/A-' for general extensions), FEAT Code (uppercase for real keywords, lowercase for pseudo/placeholder codes), Description, optional FEAT String, Command Type (a/p/s), Conformance Requirements (m/o/h), and Reference.
Obsolete commands XCUP, XCWD, XMKD, XPWD, XRMD (from RFC 775, deprecated by RFC 1123) and LPRT, LPSV (from RFC 1545/1639, FOOBAR effort) are assigned the immutable pseudo FEAT code 'hist' and marked conformance 'h' (historic). They remain in the registry to avoid conflicts with deployed implementations.
RFC 5797 establishes the IANA 'FTP Commands and Extensions' registry to reduce likelihood of conflicting extension names and command keywords. The registry records FTP commands, their FEAT codes, descriptions, types, conformance requirements, and references.
The initial registry includes five pseudo FEAT codes: 'base' (RFC 959 standard commands), 'hist' (historic experimental commands, RFC 775/1639), 'secu' (FTP Security Extensions, RFC 2228), 'feat' (FTP Feature Negotiation, RFC 2389), and 'nat6' (FTP Extensions for NAT/IPv6, RFC 2428).
The creation of this registry provides improved documentation and protection against interoperability problems arising from name conflicts in FTP extensions. The registry introduces no new security issues.