Message-Id: <6.1.2.0.2.20050317111343.0329c540@mail.jefsey.com>
Date: Thu, 17 Mar 2005 12:29:00 +0100
To: Martin Duerst <duerst@w3.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] Re: "Obsolete" region subtags
In-Reply-To: <6.0.0.20.2.20050317141918.08dcbbb0@localhost>
References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org>
	<002701c52833$a99cdd00$030aa8c0@DEWELL>
	<6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com>
	<006201c52843$6b79ee40$030aa8c0@DEWELL>
	<6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com>
	<42364EDB.197@xyzzy.claranet.de>
	<6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com>
	<6.0.0.20.2.20050317141918.08dcbbb0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: LTRU Working Group <ltru@ietf.org>
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

On 06:29 17/03/2005, Martin Duerst said:
>At 20:28 05/03/15, JFC (Jefsey) Morfin wrote:
>
> >What I try to make understood is that the document this WG will produce 
> will be counterproductive if it is not supported by the entities in 
> charge (Governments) and their usual delegates (GAC, national NICs, 
> Culture Ministries, Academic and Computer people), their common bodies 
> (ISO, ITU, UNESCO, WSIS) and their national users. Worst, if it is opposed.

Dear Martin,
we probably disagree/agree on minor points IRT ccTLD, etc. But this is not 
a major issue. The market will decide. I did not sleep this night. It is 
noon and I am tired. I will however try to make you understand. Excuse me 
if this is not perfect.

>RFC 1766 and RFC 3066 haven't had either much support or much
>opposition from governements and related organizations.
>My understanding is that this was because they did the job
>they were designed to do reasonably well.

Let drop all the RFC introduction confusion adding verbs to verbs. Their 
real job is to permit qualify language related issues and text as belonging 
to a language. The interest of the IDN Tables is that it is a (only?) 
application within the IANA.

It target is to get a text in French and to describe it as fr-Latn-FR so 
everyone understand what it is. Great.
The langtag is used to qualify/name the language of a text.

>What makes you think that for the update we are currently working on,
>this will be different? My assumption is that if we produce something
>that does it's job reasonably well, people (individuals, governements,
>companies,...) will just use it.

If this was still the same, yes. This is why we were several to say no 
problem with the Draft should it be used in the same way as 3066. But 
actually the reason why RFC 3066 has no problem it is because it is not 
applied.

- the ietf-languages list is an unknown list with no exposure and it did 
not registered much tags. The intent is to change that and to support every 
language with a registered tag. Associating in the IANA tables language 
names, countries, registrants and documentation for all of them. Look at 
the situation of the wikipedia on a certain number of languages and you 
will understand the change. This is why this list must get the proper 
exposure, to get acknowledged experts from every languages, familiar with 
the network technology and their national situation and policy. This way no 
one will be able to object the system is biased and a State sovereignty 
violation.

- the RFC 3066 describes a lot of applications which are quoted the same in 
the draft. But these applications are not used. This changes with the new 
formalization and exposure. Quoted applications such as word processors, 
grammar checker, etc will be really considered.

Big difference,  they are no more read-only/qualify, they are write and 
produce.

Let say there is a Greek text and I start editing it in French and I keep 
the Greek langtag. How will you be able to say I am wrong? I will say "this 
is Greek". To prove me wrong you need a reference to be run against my 
text, a syntax, a semantic, a grammar, a dictionary, etc. Short of that you 
may know that my text is not Greek, but you cannot do anything more. You 
need two additional descriptors to do that: an authoritative reference you 
can oppose me or force me to apply, and you need a style to say how you 
want me to apply it.

There may be other descriptors needed, but Word uses only these 5 
descriptors and my analysis says the same. You may say "I describe and I do 
not know where to document your additional descriptors from (may be style, 
but not reference, in most of the cases)". I say "you define and if you 
define with 3 descriptors this only it means you use defaults". The entire 
world will understand the defaults are the version of the langtag 
registrant. IBM, Microsoft, Apple. This is unthinkable.

So there are two things to do here:

1. to reduce/keep the additonal registrations of subtags identical to the 
concerned ISO list. There should be no reference to a registrant, nor to 
additional elements. This should be reserved to the review process. The 
registration should be bilingual when ISO is bilingual (for the same two 
different sources of study). They should be concerted with the ISO reviewer 
who may have good reasons why not to have it. There should be several 
elected reviewers, otherwise the pressure will be to much. Look a the way 
Michael reacted to my friendly pressure. Others will be tough.

2. let define that the language tag uses 5 main descriptors which can be 
reduced to 1, 2, 3 or more when qualifying and having to be 5 when defining.

Otherwise it would be analyse flaw. This would only lead States to block 
the issue at the IANA. States go slowly. They take time to understand and 
to decide. So, they may take one to three years. But they will definitely 
block what they will consider as a major violation of their cultural 
sovereignty. They are here to protect us, and they will carry their job.

>If there is anybody out there that does not trust us to do a reasonable
>job, the best thing for them is to join and help us do better.

Thx! It happens that this is why I am here. And I keep reporting.

It happens that the world is not at the order of the IESG and interested in 
sharing in the IETF. They have several way to help. This year 
through  through the WSIS (I know IETF is not interested), then the GAC (I 
know IETF is interested in ICANN only when they obey the RFCs), then the 
ITU (I know IETF does not want to relate with them). This does not make 
things easy.

You have to also understand, that in September the IAB has sent an RFC to 
the States asking their money to fund Internet R&D. This RFC does not 
allude to languages. So, States deduced that IETF is not interested. Then, 
some said this is not true, this RFC was only intended for the US 
Government. It was not necessarily a good move.

>If somebody isn't joining, then the details that we work on are probably
>just not important enough to them, and they are ready to use whatever
>we produce, in the same way they have been fine with previous RFCs.

Do you really believe this?

All this Unicode people effort is of interest. The analysis should be 
completed, some warranties worked out and it should be sold to everyone 
concerned. Namely a few key Governments, International institutions, etc. 
And to be demonstrated, reported, documented. Support obtained from OS 
developers, national Linux communities.

Otherwise it cannot fly. It can take-off. But it will not fly. You are 
touching culture at the core!
Or present something no one can object and sell it around asking everyone 
"do you object to something?". Once you have 40 ccTLDs (local communities), 
30 main governments supporting it, start a pilot process. Keep reporting. 
There is no big problem in getting through, if done the proper way with the 
proper logic.

jfc




_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru