Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...)

r&d afrac <rd@afrac.org> Sun, 06 November 2005 17:01 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYntz-0005J3-Qj; Sun, 06 Nov 2005 12:01:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnty-0005Iv-5y for ltru@megatron.ietf.org; Sun, 06 Nov 2005 12:01:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08086 for <ltru@ietf.org>; Sun, 6 Nov 2005 12:01:29 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYo9P-0007N1-Ei for ltru@ietf.org; Sun, 06 Nov 2005 12:17:51 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EYnte-0005yY-Le; Sun, 06 Nov 2005 09:01:45 -0800
Message-Id: <6.2.3.4.2.20051106104527.03fb5b80@mail.afrac.org>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Sun, 06 Nov 2005 16:39:33 +0100
To: Doug Ewell <dewell@adelphia.com>, LTRU Working Group <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...)
In-Reply-To: <004f01c5e1d6$0e0e5b40$050aa8c0@DGBP7M81>
References: <20051104171042.OOCV31446.edge4.adelphia.net@megatron.ietf.org> <004f01c5e1d6$0e0e5b40$050aa8c0@DGBP7M81>
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 - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - afrac.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc:
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

At 07:56 05/11/2005, Doug Ewell wrote:
>I am only responding to this because it was directed at me.

Bravo. It seems you grasp the true spirit of a WG.

>r&d afrac <rd at afrac dot org> wrote:
>>I documented why/how we made that "error". And that I do not want to
>>repeat it with RFC 3066 bis.
>
>Your post and mine crossed in the mail.  I don't wish to belabor 
>this. ISO 3166 does not exist to mirror ccTLDs.

ISO 3166 does not exist to document languages.

>>BTW may I ask you how you catalog ".cat". I note that the consensus
>>of the WG-ltru has been NOT to consider the DNS as concerned by the
>>langtags.
>
>What is ".cat" and how would one be expected to catalog it?  Does it 
>have something to do with identifying languages?
>
>The consensus of the WG has been that ccTLDs are one use of ISO 
>3166-1 alpha-2 code elements, and language tags are another, and 
>that is the only relationship between the two.

I do not want to harp on this answer by the author of the proposed 
IANA language registry. I know you are a Unicode, W3C, ISO expert. 
But this is the IETF. This triggers the RFC 3935 principle of 
competence. This is a serious cause for appeal of your proposed registry.

Since the current WG-ltru debate is over filtering, it shows that 
important Internet (cf. RFC 3935 definition) aspects are not considered.

>>Question: is the "only the larger island" meant to exclude the Isles
>>of Wight, the Hebridies, the Orkneys, the Shetlands, Rockall, etc.
>>and the claim they may still have on Corsica?
>
>Don't ask me.  I'm not the one who keeps insisting that GB stands 
>for something other than the entire United Kingdom.

This also trigger the RFC 3935 principle of competence and of 
responsibility for your registry proposition.
- you published a Draft registry where you releate territories and languages.
- you comment one entry (GB) seeming to exclude the reference to a 
larger territory than many other territories in the registry
- when asked about it you answer "Don't ask me". Who else should I ask?

We cannot expect from you as an author to be an expert in every 
international issue at hand. But we can expect you have a methodology 
to address them.

> > This is is the WG-ltru, so I suppose
> > your mail is relevant and is an illustration of the world you want us
> > to live in under RFC 3066 bis under constraints, managed by an
> >unprecise group of experts.
>Your accusation that I wish to remake the world in some nefarious 
>way and force everyone else to live by my rules is as far out of 
>line as ever.  We are talking about a coding system for identifying 
>the language of computerized content.  Stop treating it like it's a 
>declaration of war.

Again, you totally invent a position of mine you can oppose.

You are the author of RFC 3066 bis comburent document, I suppose you 
want to see applied and used? Authors of the RFC 3066 bis have 
documented enough they add constraints to RFC 3066 to ensure its 
better use. This use depends on experts you currently embodies as the 
registry authors the point above permits me to qualify as unprecise.

I do not think RFC 3066 bis is nefarious (your term) but uncomplete. 
Imposing a proprietary naming system to language products, solutions 
etc. It will also lead to unprecise and contradictory filtering.

The question is simple: who is most authoritative over what people 
do. The experts who feed their computers or the people themselves? 
This is like parents for their kids. At the begining the experts are. 
Then technology and the people's expertise develops and becomes more 
pertinent. There is a need for a transition.

Transitions are costly and mean (power, control, market, recognition, 
etc.) domain losses. So, some experts want to stay in the lead 
instead of transfering. They progressively lose (RFC 3935) competence 
and responsibility capacity. This is why I think it is upto 
responsible engineers to organise the new technical context for 
experts to assist people, instead of shepherding them.

These reluctant experts may be unaware or nostalgic, I do not judge 
them. They may confuse some merchants for a while (commercial 
interest is _never_ to oppose the market). But they are on the wrong 
track, and the work they do (which unfortunately might be precious) 
might be lost. We saw that all the time, in all the technologies. 
"the customer/user is king" is not a commercial trick, but a long 
time experience.

jfc


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru