Re: [idn] Re: stability

Erik van der Poel <erik@vanderpoel.org> Wed, 16 March 2005 01:25 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12145 for <idn-archive@lists.ietf.org>; Tue, 15 Mar 2005 20:25:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBNCz-00072A-0U for idn-data@psg.com; Wed, 16 Mar 2005 01:20:25 +0000
Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBNCs-00071X-76 for idn@ops.ietf.org; Wed, 16 Mar 2005 01:20:23 +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 j2G1Jc9N249342; Tue, 15 Mar 2005 20:19:42 -0500
Message-ID: <423789AA.9010203@vanderpoel.org>
Date: Tue, 15 Mar 2005 17:19:38 -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> <423754F3.50405@vanderpoel.org> <42375C05.1000204@v.loewis.de>
In-Reply-To: <42375C05.1000204@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:
>> 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,

I was referring to the RFC that has a pointer to UAX #15, i.e. RFC 3454 
(Stringprep). The pointer should be updated to tracking number 24 or 
higher. Since this issue is hard to understand, it might also be a good 
idea to add an explanation in the new versions of Stringprep and the 
IDNA family.

http://www.unicode.org/reports/tr15/tr15-24.html

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

There may be some organizations that ignore some or all of the changes 
we make to the RFCs, but others are paying attention, and I'm pretty 
sure they will follow at least some parts of the new RFCs. Mozilla and 
Opera have already indicated that they believe the punctuation mark and 
symbol problem is a big problem, and that they would/will address this 
problem whether or not the RFCs do.

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

This specific issue is already mentioned in RFC 3490 (IDNA) in the 
Security Considerations section. Of course, it is up to the implementors 
whether they will adhere to the letter of the specs, but the IETF tries 
to achieve a "rough consensus" among the parties discussing the matter, 
and the authors try to write clear specs that foster interoperability.

Erik