Re: [idn] Re: character tables

"JFC (Jefsey) Morfin" <jefsey@jefsey.com> Mon, 28 February 2005 03:54 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04830 for <idn-archive@lists.ietf.org>; Sun, 27 Feb 2005 22:54:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5bvI-000KWh-Pt for idn-data@psg.com; Mon, 28 Feb 2005 03:50:20 +0000
Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5bvH-000KWS-Eb for idn@ops.ietf.org; Mon, 28 Feb 2005 03:50:19 +0000
Received: from lns-p19-1-idf-82-251-93-168.adsl.proxad.net ([82.251.93.168] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D5bvE-0005hr-CK; Sun, 27 Feb 2005 19:50:17 -0800
Message-Id: <6.1.2.0.2.20050228042227.02d41cc0@mail.jefsey.com>
X-Sender: jefsey+jefsey.com@mail.jefsey.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 28 Feb 2005 04:50:04 +0100
To: John C Klensin <klensin@jck.com>, Erik van der Poel <erik@vanderpoel.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [idn] Re: character tables
Cc: idn@ops.ietf.org
In-Reply-To: <45781B7428C6AA07C3B283BD@scan.jck.com>
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> <421FA55B.9000308@vanderpoel.org> <421FCBD7.8000805@vanderpoel.org> <42227EBF.9040703@vanderpoel.org> <45781B7428C6AA07C3B283BD@scan.jck.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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 - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
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

At 03:58 28/02/2005, John C Klensin wrote:
>To have three different, and incompatible, tables --associated with three 
>different registries-- for "the same language" is not only possible, but 
>likely.

There are 260 TLDs. There are 7260 languages, some of them having 2 or even 
3 scripts. There are around 13000 dialects of some importance (one consider 
that a language needs 100.000 people speaking it to survive. e-colonization 
(dominance of an e-culture) should probably lead to the initial deprecation 
of some languages, but recent history shows a cultural resistance and 
resurgence after such a chock.So one can consider that Internet will most 
probably help languages to survive and develop: a 50.000 people minium 
might be a good rule of thumb (think of trade, community idioms).

So roughly one can consider that 50.000 languages with possible 260 
variants (at TLD level) are to be considered when planning a solution able 
to scale. Obviously most of them will try to use the same script as much as 
they can for the TLDs. But this cannot be considered as systematic all 
throughout a language. So one has to consider 10 millions possibilities 
most of them synonyms or not implemented. I am just talking of the legacy: 
PADs may introduce 10 times this.

This looks an impossible task in following the IDNA internationalization 
concepts. I do not think it is a big deal for the DNS concepts if respected 
and real life constraints.

jfc

NB. The problem discussed was the phishing permitted by IDNA. Not to 
(re)build a consistent global namespace support by the DNS. The current 
grassroots process of which NETPIA is only one of the participants will 
necessarily address it, only because 86% of the people need it. IMHO if we 
wanted the IETF to do something positive in that area, we should start in 
making a review of all the existing solutions, projects, trends, and 
probable possibilities and try to give them some common guidance towards a 
common consistency.