Re: [idn] Re: stability

Erik van der Poel <erik@vanderpoel.org> Tue, 15 March 2005 21:42 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24120 for <idn-archive@lists.ietf.org>; Tue, 15 Mar 2005 16:42:34 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBJhA-000A3q-1L for idn-data@psg.com; Tue, 15 Mar 2005 21:35:20 +0000
Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBJh3-000A3U-Og for idn@ops.ietf.org; Tue, 15 Mar 2005 21:35:18 +0000
Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j2FLYh9N268304; Tue, 15 Mar 2005 16:34:48 -0500
Message-ID: <423754F3.50405@vanderpoel.org>
Date: Tue, 15 Mar 2005 13:34:43 -0800
From: Erik van der Poel <erik@vanderpoel.org>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "\"Martin v. Löwis\"" <martin@v.loewis.de>
CC: Simon Josefsson <jas@extundo.com>, Mark Davis <mark.davis@jtcsv.com>, idn@ops.ietf.org
Subject: Re: [idn] Re: 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> <iluk6odazwb.fsf@latte.josefsson.org> <00e801c528a8$99ad37d0$72703009@sanjose.ibm.com> <ilull8qb5n5.fsf@latte.josefsson.org> <42367B63.6080300@vanderpoel.org> <4237450A.9010901@v.loewis.de>
In-Reply-To: <4237450A.9010901@v.loewis.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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: 8bit

Martin v. Löwis wrote:
> Erik van der Poel wrote:
>> I feel that we are still at the very beginning of the adoption of the 
>> particular Unicodes affected by this mistake. Most of them are for 
>> South Asian languages. Hangul is much further along, but not the 
>> particular Unicodes that are affected here (i.e. the Jamo).
> 
> It's not that easy. When you use the old algorithm, you get normal
> Hangul syllables, which would be allowed in IDNA. It's only that the
> sequence *before* the normalization should not be allowed.

No, these strange sequences should not be disallowed. The specs should 
be corrected so that the implementations can all treat these strange 
sequences the same way.

>> More importantly, this mistake only affects highly unusual, malformed 
>> data. I think that if IDNA decides not to follow Unicode's 
>> recommendation now or in the next couple of years, 10 or 20 years from 
>> now we would look back in time and regret this decision. 
> 
> I don't think so. "We" could still change the decision in 20 years, and
> not a single registration would be affected. The sequences causing the
> behaviour change are *really* unusual - I don't know if software can
> visually render them in a meaningful way, and I guess a native speaker
> would just consider them moji-bake. So it is unlikely that anybody would
> try to use them as input to IDNA in the next 20 years in a reasonable
> application.

If we do not correct the specs, more and more implementations will be 
created and deployed, some implementing it one way, the others the other 
way. It is hard to change something when a lot of implementations have 
been deployed. This is why we have to act now (or soon). We have to nip 
it in the bud.

Erik