Return-Path: Received: from eikenes.alvestrand.no ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.1.11-Mandrake-RPM-2.1.11-1mdk) with LMTP; Wed, 16 Mar 2005 13:32:30 +0100 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BD2661C19 for ; Wed, 16 Mar 2005 13:32:30 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13846-03 for ; Wed, 16 Mar 2005 13:32:28 +0100 (CET) Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 214A961BD6 for ; Wed, 16 Mar 2005 13:32:28 +0100 (CET) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBXeK-000Bge-Te for idn-data@psg.com; Wed, 16 Mar 2005 12:29:20 +0000 Received: from [63.247.76.195] (helo=montage.altserver.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DBXeJ-000BgR-TY for idn@ops.ietf.org; Wed, 16 Mar 2005 12:29:20 +0000 Received: from lns-p19-19-idf-82-254-246-100.adsl.proxad.net ([82.254.246.100] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DBXeD-0007HA-73; Wed, 16 Mar 2005 04:29:13 -0800 Message-Id: <6.1.2.0.2.20050316125429.04464370@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Mar 2005 13:04:49 +0100 To: Erik van der Poel , "Martin v. LXwis" From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: stability Cc: Simon Josefsson , Mark Davis , idn@ops.ietf.org In-Reply-To: <4237917D.9080507@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <42322CE2.4040509@vanderpoel.org> <4232B2FD.1080104@vanderpoel.org> <4232BA56.5090001@vanderpoel.org> <00e801c528a8$99ad37d0$72703009@sanjose.ibm.com> <42367B63.6080300@vanderpoel.org> <4237450A.9010901@v.loewis.de> <423754F3.50405@vanderpoel.org> <42375C9E.8040001@v.loewis.de> <4237917D.9080507@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-idn@ops.ietf.org Precedence: bulk X-Virus-Scanned: by amavisd-new at alvestrand.no X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char F6 hex) in message header 'To' To: ...derpoel.org>,\n\t"Martin v. L\366wis" 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. Fully true. But we are in a real world. If you propose anything again without the support of the Registries you will have a lack of understanding, adherence and support. Also what you will propose will be less reviewed from different point of view and will have more risks to have its own flaws. You will not be able to tell the Registries they shared in the mistake they have to share in the fix. A second blunder and the multilingual internet will disinterest itself from the IETF and work out its own solutions - I think we all know. Which means a split between ASCII Internet and Multilingual Internet. What we all want to avoid, I hope. The first step is to permit the Registries to operate in this still debated environement. I have asked responses about that and got no answer. I can only infer from your position and of this lack of concern, that this debate is purely theoretical. IETF does not rule but advises. What are the objections (and BTW were to find described the consquences for a Registry) to Adam and Simon positions? jfc