Message-Id: <6.2.1.2.2.20050708211132.0498be80@mail.afrac.org>
Date: Fri, 08 Jul 2005 22:14:21 +0200
To: "Peter Constable" <petercon@microsoft.com>,
	"LTRU Working Group" <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] Re: status? last call?
In-Reply-To: <F8ACB1B494D9734783AAB114D0CE68FE067B0198@RED-MSG-52.redmon
	d.corp.microsoft.com>
References: <F8ACB1B494D9734783AAB114D0CE68FE067B0198@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 21:06 08/07/2005, Peter Constable wrote:
> > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]
>On
> > Behalf Of r&d afrac
>
>
> > ISO 639-4 is the ISO document which commits on the consistency of ISO
>639
> > series, 15924 and 3166 series.
>ISO 639-4 does not attempt to ensure consistency in ISO 15924 or ISO
>3166.
>
>
> > ISO 639-4 is to describe the possible
> > relations between these codes. The matter is debated and not made. It
> > would
> > be odd if IETF standardised relations between codes the authors of
>that
> > codes would identify as wrong.
>
>ISO 639-4 will describe in general terms that the ISO 639 codes can be
>combined with other codes defined in other standards. It will not define
>any specific constraints (e.g. that Latf cannot be used in combination
>with zh),

you speak of code elements.

>  nor will it impose any particular syntactic mechanisms for
>combining different codes.

Correlations are to be documented. Some propositions are fuzzy. I will not 
tell you that the Draft is verbose and incomplete in definitions: ISO texts 
tend to be much more concise and accurate. Standard call for a rigor in 
terminology I do not find in the Draft. As long I have not seen the 
approved ISO document I think it is a waste of time to want to acclimate it 
into the IETF.

>Nothing being done in the draft for 3066bis is contrary to what is 
>anticipated in ISO 639-4.

You are prophet?
One is probable: this WG has voted "no" to ISO 11179.

> > This is why we must do the things in
> > sequence. Our charter is to deal with ISO 639.
>
>No, our charter is to revise RFC 3066. I don't see "deal with ISO 639"
>anywhere in the charter.

Oh!

> > The author of ISO 639-3
> > being at the origin of all this effort,
>
>All what effort? AFAIK, the editor for 639-3 cannot claim to be the
>origin for LTRU, work on 3066bis, 639-4, or even 639-3.

Don't be so humble .... you made some progress since 
http://xml.coverpages.org/Constable-LanguageIdentificationIssues20020204.html 
and this is good. But some other priorities were added.

> > I undersnand that he insisted on
> > ISO 639-3.
>
>I have not insisted on anything to do with ISO 639-3 in the context of
>LTRU. Suggestions for future developments, particularly in relation to
>incorporation of 639-3 and in relation to extlang, have been made, and
>there has been some broad consensus on general issues. But nothing has
>transpired on the basis of my insistence.

I meant that ISO 639-3 is specifically quoted in the Charter (I know ... it 
is not). There is no shame to that! Without you we would certainly not be 
so far. But the problem - that you very well evaluated BTW from the very 
beginning - is that this approach is for IT. Computers. Objects.

The problem is all that is that you do not consider the most important 
difference between Unicode, W3C and IETF is that Unicode deals with static 
objects (a character is a character). W3C deals with dynamic objects (pages 
being accessed, web services, applications). IETF deals with interactive 
objects (networks), and this is not easy - all the more than this precise 
topic (multilingualism) deals a layer more above end to end 
interoperability, with person to person Interintelligbility and (I pretend) 
with community into community inculturation.

The strength of RFC 3066 is to be lose. We all know it is incomplete, with 
errors, and not much respected. But this way it supports in a way the much 
wider scope to be dealt with. The Draft understands the problem, but tries 
to resolve it in an IT way, even in a static way, because Addison as a W3C 
knows that a web service, an XML page, an HTML page can work with it. And 
Mark Davis knows that he can accommodate Locales with that.

But they fail to see that the Internet cannot accommodate that narrowing. 
So, when challenged they say the DNS is odious, the dont want to address 
Java, they dont really respond to LDAP, they ignore OPES, they say that 
CRCs are inflammatory, etc. That cannot work. I fully understand their 
problem. But understanding is not identifying and not resolving.

This is why they must start with a recital of all the used words and give 
their meaning. So we understand what they want to talk about. From there we 
can help. Before we will stay in confusion for ever. RFC 3066 confusion was 
acceptable because it was not structured. The Draft is structured: 
confusion cannot play the same role as with RFC 3066. And the Charter tells 
us to fix the problems of RFC 3066.

All your supporters can claim for years that I am disruptive, that I do not 
propose text changes, that this is a no starter, etc... that will not 
change that the Draft today is meaningless and adding text to a meaningless 
document (a part from the cosmetic proposed for the last three months) is 
impossible. Now, if you give it a meaning (which is very easy) you will be 
obliged to chose which meaning and this way to acknowledge it has a precise 
scope. Back to December: this scope is narrower than RFC 3066 and the Draft 
cannot be a replacement for BCP 47.

What is a language in a network?
What is a script in a network?
What is a country in a network?
What is the purpose of a langtag in a network?

These are the basic questions. What are you talking about? There is a huge 
difference between a monologue (Unicode: I send), a dialogue (W3C - I 
send/receive one to one) and a polylogue (IETF - we exchange many to many 
all over the place). There is a big difference between the hardware of a 
typographer, the software if an IT engineer as you related SIL to, and the 
brainware of a cultural community. You made a comparison of SIL and 
linguasphere, and said SIL was more adapted to computer and linguasphere to 
understand the sociolinguistic elements.

As a brainware person, I think you were right in a way, but as an English 
mother tongue person, you do not relate your culture as other people often 
do to your language (you probably see the American culture as more attached 
to the nation, the flag, the history, the literature). There are all the 
variations on Earth: as a French speaking person, I relate my culture to 
the capabilities of my language and my nation and history are more examples 
of the capacity of the language than the other way around. Great authors 
did not build French, they are natural by-products of the common people 
language and effort. There is no Shakespeare in French: there are millions 
of co-speakers. This certainly influenced our values. Franck could tell, 
but I suppose German is similar? Try to understand the African culture if 
you do not understand the coexistance of language, family, economy, poetry, 
in a quasi geographical continuity. What are going to mean there "sn, co, 
iv, bn, etc.???".

But I also think you miss a layer above which is the noosphere of which the 
languages are the internal protocols. I will not buy Theilard and Engelbart 
ideas on SuperBrain, but what you are opposed today are the structures of 
this noosphere which say "no good" to your limitations. They can be very 
useful tools, practical solutions, etc. but not to manage the whole thing...

That Draft can complement RFC 3066, not replace it.
All what Randy can say will not change that: or it has to be rewritten, 
starting from a clean sheet analysis of the Charter .... This is why I 
proposed we co-write it at the beginning.

jfc



_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru