Re: [RFC 959] FTP in ASCII mode

John C Klensin <> Mon, 20 February 2006 16:47 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FBECC-0003uD-61; Mon, 20 Feb 2006 11:47:32 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1FBECA-0003ty-Fo for; Mon, 20 Feb 2006 11:47:30 -0500
Received: from ([] by with esmtp (Exim 4.43) id 1FBEC9-0004zM-5Z for; Mon, 20 Feb 2006 11:47:30 -0500
Received: from [] (helo=p3.JCK.COM) by with esmtp (Exim 4.34) id 1FBEC8-000HQr-6S; Mon, 20 Feb 2006 11:47:28 -0500
Date: Mon, 20 Feb 2006 11:47:27 -0500
From: John C Klensin <>
To: Sandeep Srivastava <>,
Message-ID: <FF2C916CBADA870F8847C260@p3.JCK.COM>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Subject: Re: [RFC 959] FTP in ASCII mode
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

--On Monday, 20 February, 2006 18:54 +0530 Sandeep Srivastava
<> wrote:

> Hi,
> RFC 959, says that FTP supports two modes to transfer files --
> ASCII and Binary. Now, if I have a UTF-8 (or any other
> encoding) encoded text file, containing, say Japanese
> characters, would it be correct to choose the transfer mode as
> ASCII? And if I choose the transfer mode as ASCII, is there a
> possibility that the content of the file on the receiving end
> is garbled?

Yes, it is quite likely.
> In a nutshell, does ASCII mode means that only ASCII encoded
> text files are supported?

Traditionally, there is a small ambiguity about ASCII mode.

If a server receives (and accepts) an ASCII mode request, RFC
959  requires it to be sure that its internal character set is
converted to ASCII and that the file be transmitted in NVT
(Network Virtual Terminal) form, i.e., with CRLF line endings
and 7bit ASCII characters right-justified in octets.   A strict
RFC 959 implementation might garble UTF-8 octets with the
high-order bit turned on but is arguably not required to do so.

You may want to take a look at RFC 2640 for a more extensive
discussion, and standards-track approach, to these issues.  I
don't know how widely it has been implemented; perhaps others
can help in that regard or, if you explore it, you can tell us.


Ietf mailing list