Message-Id: <6.2.1.2.2.20050525154843.03837eb0@mail.jefsey.com>
Date: Wed, 25 May 2005 15:49:06 +0200
To: ltru@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Subject: [Ltru] On the records (was Editorial error in BNF)
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Doug,
Thank you for going on the record for these points. This permits me to go 
on the records with the following comments. It will save time further on 
for the Last Call.

On 07:16 25/05/2005, Doug Ewell said:
>For what it is worth, I will go on record as saying the following:
>
>I do not believe the mechanism described in draft-ietf-ltru-registry-*
>is intended only for XML, or suitable only for XML.  I believe it is
>suitable for many different tagging purposes, only one of which is XML.

This comment by itself shows that I am right. The comment certainly fits a 
specific RFC. To fit BCP 47, you should be _certain_ that it is suitable 
for _every_ language tagging purpose on the Internet. In saying "_many_" 
you are honest and show that you are not certain about the total 
scalability of your proposition. This is normal, it is too specific. We 
fully agree.

I only regret that the refusal of this group of investigating that "many". 
It could have helped developer and kept some RFC consistent and secure (the 
one wich refers to RFC 3066).  We discussed, inconclusively since no text 
resulted, some cons and pros about text, HTML, CLDR, XML, LDAP, Java, MIME. 
Do I forget some?

>I do not believe the mechanism is supported only by "W3C people."

If this is to comment a remark of mine, I said that because it is supported 
by W3C people, it will be used for XML. And that for that reason it MUST be 
clear to XML developers and users. Any other reading would be biaised.

Since we are on the records, I also made clear in other mails that there is 
no "end-user" in the IETF thinking who would be addressed in a different 
way. IETF deliverables are for everyone. All users from every language are 
to enjoy the same lingual, technical, cultural opportunity to share in the 
technology usage, development, specifications and contribution. This is 
their absolute security. Whatever their mother tongue they must be able to 
use it the same way as you do yours, in contributing, specifying, 
developing and using the Internet technology. The technical needs of every 
national, local, global, cultural, private Internet communities must be 
equally considered and loyally addressed. Technology and current budgets 
cannot warranty this will happen, but technology MUST be designed for it to 
be possible, at least in using double indexing usual solutions. English, 
French, etc. are each only one of the 7520 languages of ISO 639-3 and of 
the 20.000 ones of ISO 639-6.

This is not the case of what is specified here, and this is the main reason 
why the proposed Draft is inadequate, not fitting the IETF, UN and UNESCO 
core values. This can obviously be accepted for a temporary fix of 
documents also not matching yet these values. It cannot for what is by 
essence a funding building block of the MGN (Multilingual Global NGN). It 
cannot when it is specifically build over a denying of these values (even 
bilingualism was formally opposed here: why it would have been a hook for 
multilingualism, and a first step towards multilingual QA).

This is a general deny of innovation because all the collateral general 
technical advances we can all expect from a correct multilingual support 
R&D are delayed or blocked. Because, when IAB starves for Government R&D 
funding (RFC 3869) all the public R&D budgets Internet could get from the 
unanimous multilingual priority of 192 Governments (ITU and WSIS 
resolutions) will go somewhere else. For you to understand what it means in 
immediate results: should the proposed text be written both in English and 
in French, and may be in Russian, Spanish, Arabic and Chinese, I bet the 
text would be clearer, each paragraph more well thought and its inner logic 
analysed, its implementation far easier and its technical coverage and 
registry management feasibility far more practical. I accept it would take 
more time, effort and persons: this is the price of better quality.

This is the reason why, even if what is named in some governmental spheres 
the "lingual Yalta" is an understandable try and has brought some real 
first good things, it is not a good move for the Internet and for the 
world. Sorry. Please read RFC 3869: IAB explains the reasons why very well. 
You know, some others than this WG also happen to be right from time to time.

This is all the more understandable that its proposed solution is _much_ 
more complex than a digital generalised one.

>I do not believe the concept of "script" is undefined, or even poorly
>defined, either in the draft or anywhere else.

The best way to address that contentious point is to define the term 
"script" in the proposed RFC initial recital of used terms.

>And I do not believe anyone secretly wants to "kill the project."  Those
>who want it to fail have been very public about it.

This is something I am afraid you are misinformed about. There are many who 
oppose the principle of the project as a BCP 47, and this is the reason why 
they do not even bother to discuss it. I have only accepted, at the request 
of some of them, to spend time in being be vocal about its architectural 
flaws (the reasons why it failed its Last Call twice) to try to help 
adapting it - but I see it is useless. It also was because I wanted to 
learn from this WG during your much delayed debate on the IESG charter 
thorny points. But now most of the members are gone...

I patiently and loyally made available another language, another experience 
and another culture to this WG and I did not spare my warning. It was a 
collective choice of (the most vocale part of ?) this WG to waste time in 
fighting/banning it instead of saving time in using it. This is was its 
consenual (?) choice. May be they are right and know better than so many else.

This is now in the records. Thank you to have permitted it. I just stay 
around to show there is no consensus by exhaustion.

All the best.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru