Re: [idn] stability

"Martin v. Löwis" <martin@v.loewis.de> Sat, 12 March 2005 12:14 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00502 for <idn-archive@lists.ietf.org>; Sat, 12 Mar 2005 07:14:50 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DA5Qs-000JD6-Ki for idn-data@psg.com; Sat, 12 Mar 2005 12:09:26 +0000
Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DA5Qq-000JBq-2s for idn@ops.ietf.org; Sat, 12 Mar 2005 12:09:24 +0000
Received: (qmail 1545 invoked from network); 12 Mar 2005 12:09:19 -0000
Received: from unknown (HELO [80.185.147.201]) (544451@[80.185.147.201]) (envelope-sender <martin@v.loewis.de>) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <erik@vanderpoel.org>; 12 Mar 2005 12:09:19 -0000
Message-ID: <4232DBEE.3090601@v.loewis.de>
Date: Sat, 12 Mar 2005 13:09:18 +0100
From: "\"Martin v. Löwis\"" <martin@v.loewis.de>
User-Agent: Debian Thunderbird 1.0 (X11/20050116)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik van der Poel <erik@vanderpoel.org>
CC: idn@ops.ietf.org
Subject: Re: [idn] stability
References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <D872CCF059514053ECF8A198@scan.jck.com> <421D8411.9030006@vanderpoel.org> <p06210208be4390618c81@[192.168.0.101]> <421E0D0C.2000309@vanderpoel.org> <p06210202be43c3888991@[192.168.0.101]> <E07CE813AD23B2D95DA0C740@scan.jck.com> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <A574CA1BE87BFDA3C2A1AC0E@scan.jck.com> <42322CE2.4040509@vanderpoel.org> <4232B2FD.1080104@vanderpoel.org> <4232BA56.5090001@vanderpoel.org>
In-Reply-To: <4232BA56.5090001@vanderpoel.org>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Erik van der Poel wrote:
> Also, IDNA apps depend on tables for converting from various non-Unicode 
> encodings to Unicode. This is another place where instability could 
> affect lookups, potentially even in dangerous ways. Stringprep and IDNA 
> already mention this issue in their Security Considerations sections.

I think an evaluation of whether something is potentially dangerous
should take linguistic research into account.

As a layman, I recognize that these are all compatibility characters
(and all for CJK encodings). For example, F951 is, according to my
Linux /usr/share/i18n/charmaps, part of CP 949, EUC-KR, and JOHAB.
Looking at the character tables privided by the Unicode consortium,
it seems obvious that it is correctly mapped to 964B and not 96FB
(but it could be that the font tables were explicitly designed to
show the same glyph).

According to Unicode corrigendum 3,

http://www.unicode.org/versions/corrigendum3.html

this character is only used for Korean encodings, to support
a different pronounciation (so the character was duplicated
in the Korean standard also). The corrigendum also asserts
that the character will not readily be recognized by most Korean
speakers (Chinese speakers recognize the character, but they
won't use the compatibility character).

So in practical life, it appears that this normalization change
is unlikely to occur, so it is hard to see how it could cause
danger. I believe the same is true for all the other cases where
the normalization has changed.

The real danger is to judge other people's work inadequately,
and to believe one can do better than them. The people who
created these tables are experts in their field (linguistics
and scripts), if they make mistakes, then likely because the
subject matter is so obscure that "normal people" never
encounter the issue at hand.

I'm not concerned about stability of IDN.

Regards,
Martin