IETF Logo Mail Archive

[idn] Re: stability

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

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25975 for <idn-archive@lists.ietf.org>; Tue, 15 Mar 2005 17:09:57 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBKCI-000EeM-Rl for idn-data@psg.com; Tue, 15 Mar 2005 22:07:30 +0000
Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBKCG-000Eds-TF for idn@ops.ietf.org; Tue, 15 Mar 2005 22:07:29 +0000
Received: (qmail 20791 invoked from network); 15 Mar 2005 22:07:27 -0000
Received: from unknown (HELO [80.185.154.213]) (544451@[80.185.154.213]) (envelope-sender <martin@v.loewis.de>) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <jas@extundo.com>; 15 Mar 2005 22:07:27 -0000
Message-ID: <42375C9E.8040001@v.loewis.de>
Date: Tue, 15 Mar 2005 23:07:26 +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: Simon Josefsson <jas@extundo.com>
CC: Erik van der Poel <erik@vanderpoel.org>, Mark Davis <mark.davis@jtcsv.com>, idn@ops.ietf.org
Subject: [idn] Re: stability
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>
In-Reply-To: <ilumzt47ezc.fsf@latte.josefsson.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

Simon Josefsson wrote:
> I believe it would be useful to start thinking of the problem in terms
> of a transition plan from what we have today and what we would like to
> have tomorrow.  It is not clear to me exactly what we would like to
> have tomorrow, so settling that would have to be part of the plan as
> well.

Indeed. For IDNA, I think the current specification serves fine for
today and tomorrow, so nothing needs to change at all.

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.

Regards,
Martin

v2.23.0 | Report a Bug | By Email