Re: [RFC 959] FTP in ASCII mode

Masataka Ohta <> Tue, 21 February 2006 04:35 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FBPFA-0006i6-Ou; Mon, 20 Feb 2006 23:35:20 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1FBPF9-0006i1-FN for; Mon, 20 Feb 2006 23:35:19 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1FBPF7-0000zh-Tn for; Mon, 20 Feb 2006 23:35:19 -0500
Received: (qmail 59833 invoked from network); 21 Feb 2006 05:31:55 -0000
Received: from (HELO ( by with SMTP; 21 Feb 2006 05:31:55 -0000
Message-ID: <>
Date: Tue, 21 Feb 2006 12:03:13 +0900
From: Masataka Ohta <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: John C Klensin <>
References: <802d52a30602200524w560fe214n67cb074f5f6f8332@mail.gma> <> <30C473BA61A6E355540B54DE@p3.JCK.COM>
In-Reply-To: <30C473BA61A6E355540B54DE@p3.JCK.COM>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
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: <>, <>

John C Klensin wrote:

> Sandeep's question raises another interesting issue.  I just
> went back and reread RFC 2640.   It does not seem to address the
> "TYPE A" issue at all.  It does say (Section 2, paragraph 1)
> "Clients and servers are, however, under no obligation to
> perform any conversion on the contents of a file for operations
> such as STOR or RETR", which I would take to imply that it
> anticipates I18N FTP operations to be entirely binary ("TYPE I")
> although that is not explicit.

As for Japanese processing, UTF-8 is not visible by users and on
the network, because UTF-8 is not only useless but also harmful.

Instead, ISO-2022-JP, ShiftJIS and EUC are the major character sets.
Some ftp implementations does assume (sometimes depending on environment
 variables) network character code ShiftJIS or EUC and perform appropriate
conversions, which garbles UTF-8.

On the other hand, if you use ISO-2022-JP, which is 7 bit pure and ASCII
compatible (in a sense, it is pure ASCII), we can safely use ASCII mode
of vanilla ftp and there is no confusion as long as we are in ASCII

Similar encoding can be profiled using ISO 2022 to obtain a fully
internationalized, 7 bit pure, ASII compatible character encoding.

The only problem for RFC2460 was that it does not need MIME for
charset and 8bit extension that it makes it clear that MIME is

Note that long term state maintainance of full ISO 2022 is not
more complex than that of UTF-8. Note also that, carefully profiled
ISO 2022, such as ISO-2022-JP, requires state maintainance a lot
simpler than that of UTF-8.

> Whether the characters in use are UTF-8 or not, we've still got
> that issue with line-endings.   

Line-ending issues of any ISO 2022 based encoding are just as simple
as those of ASCII.

							Masataka Ohta

Ietf mailing list