Re: [idn] Re: stability

"Martin v. Löwis" <martin@v.loewis.de> Tue, 15 March 2005 22:08 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25907 for <idn-archive@lists.ietf.org>; Tue, 15 Mar 2005 17:08:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBK9o-000E9q-QF for idn-data@psg.com; Tue, 15 Mar 2005 22:04:56 +0000
Received: from [80.67.18.15] (helo=smtprelay03.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBK9n-000E9Z-S7 for idn@ops.ietf.org; Tue, 15 Mar 2005 22:04:56 +0000
Received: (qmail 4899 invoked from network); 15 Mar 2005 22:04:54 -0000
Received: from unknown (HELO [80.185.154.213]) (544451@[80.185.154.213]) (envelope-sender <martin@v.loewis.de>) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <erik@vanderpoel.org>; 15 Mar 2005 22:04:54 -0000
Message-ID: <42375C05.1000204@v.loewis.de>
Date: Tue, 15 Mar 2005 23:04:53 +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: 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> <423754F3.50405@vanderpoel.org>
In-Reply-To: <423754F3.50405@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:
> 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.

Not sure what aspect you are referring to, however, I doubt that the
majority of the implementations cares too much about what the RFC says.
So whether the RFC is changed or not in a minor aspect has little
impact on reality.

In the specific case of normalization, I think most IDNA implementations
will rely on a normalization implementation created elsewhere - few
IDNA implementations will come with their own normalization routines.
This is because normalization is difficult to implement, so you rather
reuse than reinvent. Then, when the underlying normalization routine
is changed, the IDNA implementation also changes - most likely without
the author of the IDNA implementation (let alone its user) even knowing.
In that scenario, the implementor of IDNA has little control over what
specific incarnation of normalization is used.

Regards,
Martin