Message-Id: <6.2.1.2.2.20050625040256.043689f0@mail.afrac.org>
Date: Sat, 25 Jun 2005 04:32:30 +0200
To: "Peter Constable" <petercon@microsoft.com>, <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] Submission: LTRU registry draft-06
In-Reply-To: <F8ACB1B494D9734783AAB114D0CE68FE0659051D@RED-MSG-52.redmon
	d.corp.microsoft.com>
References: <F8ACB1B494D9734783AAB114D0CE68FE0659051D@RED-MSG-52.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 02:18 25/06/2005, Peter Constable wrote:
>Well, we could delay completion of the draft while we debate
>Wittgenstein or even basic assumptions regarding epistemology, but I
>don't know how useful that would be.

Useful enough to make the difference between confusion and utilisation (I 
mean by the users. For marketeers: the tags are good enough to report the 
locale of the computer used to generate the content)..

>After all, how do I know when you
>say "author" or "is" or whatever that you mean the same thing that I
>think you mean?
>At *some* point, communicative interaction assumes a conventional
>semantics.

The problem is that your semantic is the semantic of a text oriented 
linguist, mixing data and metadata and definitions in the three main 
cultural root areas (languages, modes and geography) .... Your conventional 
understanding is not the user conventional understanding. Because there are 
a multiplicity of lingual, modal, media, logical, etc. understandings. I 
would say this is supermarket. Not culture.

>This group has all along been assuming that it can treat the semantics
>of "Spanish" or "Latin America" as conventional.

OK. please define this semantic. This is all what I ask for. Even if it 
does not match the need, at least it will be less confuse....

>  I understand that in strict terms that is simplistic, and that it may 
> not correspond to what e.g. the WG responsible for ISO 3166 assume,

OK. We agree that this WG does not intend to correspond to the Charter 
intent. This is no problem to me: this is exactly what Jon Postel did with 
ccTLDs; except that he said what ISO 3166 code were going to mean in his 
mind. You do not. Addison says in the same sentence: a warranty, a 
geography, an intent, a market... Up to now "cn" is CNNIC and "fr" is 
AFNIC. You have to say what it is for you.

>but for purposes of development of this specification I believe the 
>majority here consider it good enough.

I do not know where did you find that KISS meant imprecise and "good 
enough". To the contrary it means that simplicity and evidence come from 
the exact concept to be used at the exact place. Scalability requires that. 
"good enough for this specification" means scalability problems. This 
cannot be accepted for an RFC; except if that RFC indicates the limit of 
its scope and is scalable within that limit. This is what I ask.

>Since the start of work on RFC 1766, I don't know that this issue has come 
>up until now.

No one has used the langtag in the way you want to use it. I am perfectly 
happy with the lack of precision of RFC 3066 because no one wants to use it 
precisely. Harald never claimed anything else than to port ISO 639 codes in 
Internet environment. To identify languages. Not to warranty, assert, etc. 
No problem to leave for ever with RFC 3066 and to have tags for languages, 
country, market, scripts, rates, etc.

Take care.
jfc


BTW, we both know that this Draft does not match the needs of the Internet, 
does not match the Charter and will create more confusion and conflict that 
anything else. I do not want you to accept it.

But that at the same time that it represents a lot of work and some or real 
interest if it was presented otherwise. And I accept it from the very 
beginning - so you know it is not trolling.

I think my QED mail describes a solution which will work - including for 
your strategy - if you do not claim to replace RFC 3066.



_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru