Internationalization of the File Transfer Protocol

Non-displayable characters in pathnames are RECOMMENDED to be presented in URL %HH format (RFC 1738) rather than silently dropped, preserving information for the user while acknowledging that glyph rendering is outside the scope of this specification.

The LANG command is issued before authentication to give the full benefit of localized error messages from the earliest server interaction. Issuance of HOST or REIN negates the effect of a prior LANG command, so re-negotiation may be needed.

The user-PI is required to send HOST or LANG before any other command so that the server can distinguish compliant from legacy clients and adjust its behavior accordingly; this mechanism avoids breaking the large installed base of older FTP clients.

UTF-8 was chosen over requiring support for multiple character sets because its single-byte range is identical to ASCII, allowing old ASCII-only clients to interoperate with new UTF-8 servers. A single universal encoding assures global interoperability without complex negotiation of arbitrary character set pairs.

Clients SHOULD anticipate 500 or 502 responses to the LANG command from older or non-compliant servers that do not implement it. A 501 response indicates syntactically incorrect argument; 504 indicates an unsupported but syntactically valid language tag.

Clients which detect a non-UTF-8 server via absence of the UTF8 FEAT response SHOULD adjust display appropriately. They MAY assume another encoding, allow user configuration, or persist encoding assumptions across sessions — this is a quality-of-implementation issue.

Legacy ASCII-only clients can still interoperate with new UTF-8 servers because UTF-8 single-byte sequences are identical to ASCII. Servers supporting this specification can detect whether a presented pathname is valid UTF-8 (see Annex B.1) to distinguish old from new clients.

Mirror servers MAY store and present the exact pathname bytes received from the main server to exactly reflect the mirrored site, even if those bytes are not UTF-8.

A server supporting LANG MUST include a FEAT response line in the format "SP LANG SP lang-fact CRLF" listing all supported language tags. At least one lang-tag MUST be included; the current language is indicated by an asterisk after the tag.

Clients and servers that conform to this specification MUST support the LANG command for language negotiation of greetings and explanatory text. FTP protocol elements (commands and numeric responses) are not affected.

Clients MUST support the FEAT command and recognize the "UTF8" feature to determine whether a server supports UTF-8 encoding. Clients presented with UTF-8 pathnames SHOULD parse UTF-8 correctly and attempt display.

Conforming clients and servers MUST support UTF-8 for transfer and receipt of pathnames. Unless configured for a specific native character set, implementations MUST check for a valid UTF-8 byte sequence to determine if a presented pathname is UTF-8.

Servers MUST advertise UTF-8 support in response to the FEAT command as a line containing exactly the string "UTF8" (case-insensitive, SHOULD be upper case). The feature line MUST follow RFC 2389 single-space indentation.

The character set for FTP internationalization SHALL be ISO/IEC 10646:1993, and it is STRONGLY RECOMMENDED that clients and servers use UTF-8 encoding when exchanging pathnames. Clients and servers are under no obligation to convert file contents for STOR or RETR operations.

email, crypto

The server's default language MUST be understandable by an English-speaking person (per RFC 2277 §4.5); this specification RECOMMENDS English encoded in ASCII as the server default. Once a language is negotiated, server-PI MUST return messages encoded in UTF-8 in that language.

There MUST be only one SP between an FTP command and the pathname; subsequent SP characters MUST be treated as part of the pathname. Implementations that allow multiple SP separators or pad 3-character commands with a trailing SP are non-compliant.

To avoid data loss, clients and servers SHOULD use UTF-8 encoded pathnames when they cannot convert them to a usable code set; when the encoding cannot be determined, raw bytes SHOULD be used.

UCS Transformation Format 8 (UTF-8) SHALL be used as the transfer encoding for the international character set. Prior to pathname exchange, pathnames SHOULD be converted to ISO/IEC 10646 format and UTF-8 encoded.

User-PI MUST send a HOST and/or LANG command before issuing any other command (other than FEAT). If HOST is not supported, a LANG command MUST be issued. Until either is received, server-PI SHOULD assume the client does not comply with this specification.

When a CR character appears in a pathname it MUST be padded with a NUL character before sending; on receipt the NUL following CR MUST be stripped. This follows the Telnet protocol convention for CR handling.

The LANG command takes an optional RFC 1766 language tag parameter (Primary-tag *("-" Sub-tag), each component 1–8 ALPHA). Responses are 200 on success, 500/502 for unrecognized/unimplemented, 501 for bad syntax, and 504 for unsupported language parameter.

RFC 2640 addresses only extended character set support and a language negotiation command; conformance to this document is stated to not induce a security risk.

security

Pathname syntax is redefined from BNF <pathname> ::= <string> to ABNF pathname = 1*(%x01..%xFF), removing the 7-bit restriction and accommodating embedded SP, CR, and LF when properly escaped.

The FEAT response for LANG has the form: SP "LANG" SP lang-fact CRLF, where lang-fact = lang-tag ["*"] *(";", lang-tag ["*"]). The initial space is mandatory and must be exactly one space character.

UTF-8 encodes UCS characters as 1–6 byte sequences: single-byte (0xxxxxxx) for U+0000–U+007F; two-byte (110xxxxx 10xxxxxx) for U+0080–U+07FF; three-byte (1110xxxx 10xxxxxx 10xxxxxx) for U+0800–U+FFFF; and longer sequences up to six bytes for U+04000000–U+7FFFFFFF. Continuation bytes always begin with 10.