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
- [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) Doug Ewell
- Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… r&d afrac
- Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… Randy Presuhn
- Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… r&d afrac
- [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2...) Doug Ewell
- Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… Ned Freed
- Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… r&d afrac
- Jefsey update (Re: [Ltru] Re: ISO 3166 alpha-2 (w… Harald Tveit Alvestrand
- [Ltru] Procedural issues (was: ISO 3166 alpha-2) Frank Ellermann
- Re: Jefsey update (Re: [Ltru] Re: ISO 3166 alpha-… r&d afrac
- Re: Jefsey update (Re: [Ltru] Re: ISO 3166 alpha-… r&d afrac
- Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… Mark Davis
- [Ltru] Procedural issues (was: ISO 3166 alpha-2) Frank Ellermann
- Re: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… r&d afrac
- RE: [Ltru] Re: ISO 3166 alpha-2 (was ISO 3166-2..… Scott Hollenbeck