IETF Logo Mail Archive

Re: [idn] stability

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

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07258 for <idn-archive@lists.ietf.org>; Tue, 15 Mar 2005 14:12:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBHLW-000K24-TR for idn-data@psg.com; Tue, 15 Mar 2005 19:04:50 +0000
Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBHLR-000K1P-8n for idn@ops.ietf.org; Tue, 15 Mar 2005 19:04:49 +0000
Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j2FJ4EKo131828; Tue, 15 Mar 2005 14:04:14 -0500
Message-ID: <423731AD.6060503@vanderpoel.org>
Date: Tue, 15 Mar 2005 11:04:13 -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: idn@ops.ietf.org
CC: Simon Josefsson <jas@extundo.com>, Mark Davis <mark.davis@jtcsv.com>
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> <iluk6odazwb.fsf@latte.josefsson.org> <00e801c528a8$99ad37d0$72703009@sanjose.ibm.com> <ilull8qb5n5.fsf@latte.josefsson.org> <42367B63.6080300@vanderpoel.org>
In-Reply-To: <42367B63.6080300@vanderpoel.org>
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

It's very quiet on this mailing list...

> The idempotence invariant seems 
> especially important.

Keep in mind that IDNA requires Nameprep to be applied a 2nd time in 
order to determine whether a Punycode label may be displayed in its 
Unicode form.

> If there is a time to break compatibility for 
> something, it is now, for this.

Note that we wouldn't actually be "breaking compatibility" since it is 
highly unlikely that anyone would have created a domain label with such 
strange combinations of characters. Also, even though there are 
implementations out there that implement UAX #15 the "wrong" way, keep 
in mind that there are also implementations that implement it the other 
way. This, in itself, is sufficient grounds for IETF to not only show 
concern, but also take action.

> On the other hand, 
> IDNA seems to have done it in the opposite order. First, the spec was 
> written, and now that we have deployed some implementations, we are 
> finding serious problems with punctuation marks and symbols.

Nobody has bothered to point out that this remark was unfair, so I'll 
just say it myself. IDNA is at the Proposed Standard Maturity Level, so 
we still have the opportunity to improve the specs for the Draft 
Standard and Internet Standard Maturity Levels. This is not only 
possible, it is expected.

Erik

v2.23.0 | Report a Bug | By Email