Re: [RFC 959] FTP in ASCII mode

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 21 February 2006 04:35 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPFA-0006i6-Ou; Mon, 20 Feb 2006 23:35:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPF9-0006i1-FN for ietf@ietf.org; Mon, 20 Feb 2006 23:35:19 -0500
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBPF7-0000zh-Tn for ietf@ietf.org; Mon, 20 Feb 2006 23:35:19 -0500
Received: (qmail 59833 invoked from network); 21 Feb 2006 05:31:55 -0000
Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 21 Feb 2006 05:31:55 -0000
Message-ID: <43FA82F1.9010401@necom830.hpcl.titech.ac.jp>
Date: Tue, 21 Feb 2006 12:03:13 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
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 <john@jck.com>
References: <802d52a30602200524w560fe214n67cb074f5f6f8332@mail.gma il.com> <43F9ED6A.5090901@peter-dambier.de> <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
Cc: ietf@ietf.org
Subject: Re: [RFC 959] FTP in ASCII mode
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

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
environment.

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
useless.

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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf