[I18nrp] missing layer six (was Re: administrivia: i18nrp vs. i18n-discuss)

JFC Morfin <jefsey@jefsey.com> Thu, 07 February 2019 13:44 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: i18nrp@ietfa.amsl.com
Delivered-To: i18nrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3812872C for <i18nrp@ietfa.amsl.com>; Thu, 7 Feb 2019 05:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FORGED_MUA_EUDORA=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WbgUrfmleJF for <i18nrp@ietfa.amsl.com>; Thu, 7 Feb 2019 05:44:43 -0800 (PST)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15C3126CB6 for <i18nrp@ietf.org>; Thu, 7 Feb 2019 05:44:43 -0800 (PST)
Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:63883 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.91) (envelope-from <jefsey@jefsey.com>) id 1grjyq-0006ki-Tr for i18nrp@ietf.org; Thu, 07 Feb 2019 14:44:41 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 07 Feb 2019 14:44:36 +0100
To: i18nrp@ietf.org
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <2f9c2241-a034-d84a-7ba6-9a1534f8e009@mozilla.com>
References: <2f9c2241-a034-d84a-7ba6-9a1534f8e009@mozilla.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 - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: host.presenceweb.org: jefsey@jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
Message-Id: <20190207134443.A15C3126CB6@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/DzCpXBcu8RTYthEiIlWfJ3iJzHA>
Subject: [I18nrp] missing layer six (was Re: administrivia: i18nrp vs. i18n-discuss)
X-BeenThere: i18nrp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Review Procedures <i18nrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18nrp/>
List-Post: <mailto:i18nrp@ietf.org>
List-Help: <mailto:i18nrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 13:44:45 -0000

As we identified it, a default table has a cost and therefore must 
have a financial return either in money or in security to attract an 
maintainer. RF6852 should lead us identifying the "global community" 
the market of which would most/best benefit from a secure uniform 
stable universal character coding reference table.

I see three of them: the banking community, their interpol/customs 
protectors, the integrated users multitude  (please note that tables 
from per country/langague sources without coordination seem odd in a 
multilateral, multilanguage multimatics context, what rules out 
national investments). We now have historically evidenced that ICANN, 
IETF, industry and OpenSource communities cannot provide arry that job.

Hence, the task belongs to the ITU (if not: to EU or BRICS which may 
have a more immediate need and pave the way) and ultimately to an 
inter-user multitude to structure (lead-users). You know my position 
for years about CLDR. This is an issue that has to do with cultures, 
law violation/enforcement,  (sovereignty),etc.: it cannot be 
delegated to a commercial consortium of vendors (cf. 
http://cldr.unicode.org/index). I know: "the less IETF hears from the 
ITU/UN the best they feel", but the less international public, 
private and civil users can internationnally interact. This seems a 
typical compatibility of interest issues between several global 
communities (business, legal/national, manufacturers, standardization 
bodies, etc.). As per my two denied appeals RFC 6852 should have 
addressed this.

I see two ways out: either the IAB/IETF can devise a solution for a 
global telematics technological governance accepted by sovereign 
nations (Wesphalia) or IUsers have to confederate as "the multitude" 
in order/and to publish the terms of a multimatics "internext" 15 
layers model. From IDNA2003/2018 experience I suppose the delay in 
getting the two solutions off the ground could be equivalent: 15 years?.

Any idea to speed it up? And to positively accomodate the present.
jfcm