Re: [idn] Re: stability

John C Klensin <klensin@jck.com> Wed, 16 March 2005 17:45 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14668 for <idn-archive@lists.ietf.org>; Wed, 16 Mar 2005 12:45:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBcX3-0005Fg-VP for idn-data@psg.com; Wed, 16 Mar 2005 17:42:09 +0000
Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DBcX1-0005F9-MI for idn@ops.ietf.org; Wed, 16 Mar 2005 17:42:07 +0000
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1DBcWg-0003Kg-6m; Wed, 16 Mar 2005 12:41:47 -0500
Date: Wed, 16 Mar 2005 11:37:52 -0500
From: John C Klensin <klensin@jck.com>
To: Erik van der Poel <erik@vanderpoel.org>, "\"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
Message-ID: <5A007C107F429B5660DD3265@7AD4D3FB4841A5E367CCF211>
In-Reply-To: <4237917D.9080507@vanderpoel.org>
References: <421B8484.3070802@vanderpoel.org> <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> <ilumzt47ezc.fsf@latte.josefsson.org> <42375C9E.8040001@v.loewis.de> <4237917D.9080507@vanderpoel.org>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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: quoted-printable


--On Tuesday, March 15, 2005 5:53 PM -0800 Erik van der Poel 
<erik@vanderpoel.org> wrote:

> Martin v. Löwis wrote:
>> What is much more relevant is how further constraints in the
>> registry (beyond those imposed by IDNA) get implemented. Only
>> when that is sufficiently settled and deployed, considering
>> *updates* to IDNA should start.
>
> I disagree. The IETF should not wait for any of the registries
> to do anything before publishing new drafts or RFCs. The
> registries are not the only other players here. We have
> application developers and zone administrators depending on
> our work too.

Yes.

And let me add one observation.  At the moment, "the registries" 
(remember that there are around 275 of them) are going in every 
direction possible.  ICANN's guidance, based to some extent on 
the advice that IESG gave them, is so vague as to permit almost 
any interpretation, clearly doesn't work for some important 
cases (encouraging even more interpretations), and is being 
outright ignored by some ccTLDs.   If we want the registries to 
do something, we are going to need to provide some more specific 
guidance and we are going to need to document why it is a good 
idea.  The same observation applies to application writers: 
unless we actually change the standard (the algorithms or the 
tables), all we are doing is offering advice.  That advice will 
probably be taken if it is clear and well-reasoned and the 
reasoning is well- explained justified.  And, in both cases, it 
will be easier to persuade people to make changes before they 
have an installed base that has to be forced to adjust to new 
ways of doing things.  The more deployment occurs before we make 
suggestions or change things, the more likely whatever we do 
will be ignored.

   john