Message-Id: <6.2.3.4.2.20050907112337.0475e1b0@mail.jefsey.com>
Date: Wed, 07 Sep 2005 15:37:46 +0200
To: John C Klensin <john-ietf@jck.com>,
	Sam Hartman <hartmans-ietf@mit.edu>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <EFAFFC7D681AFA7F592E18AF@scan.jck.com>
References: <DE3D67514661E20ADB65F357@scan.jck.com>
	<tslu0gy101q.fsf@cz.mit.edu>
	<EFAFFC7D681AFA7F592E18AF@scan.jck.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ltru@ietf.org, iesg@ietf.org
Subject: [Ltru] Re: Last call comments on LTRU registry and initialization
 documents
Precedence: list
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

At 22:19 06/09/2005, John C Klensin wrote:
>         * when there is no evidence that it is "best" (even if
>         one agrees that no better options are on the table or
>         even that none are likely to be searched out and found
>         unless, someone, this approach is shown to fail as RFC
>         3066 was shown to fail), and

John,
you can say that!

There are four propositions. The Draft is the least network oriented, 
but has its place for catalogs, library organisation, related menus, 
and e-commerce contracts. It should have been a WTO, W3C, LDAP, MPEG 
proposition, but it supports a consistent content-database-computer 
management system (HTML, XML, CLDR [some Locale standardisation 
attempt]). The problem is simply that it would constrain human 
relations and cultural life support protocols to its locale 
"internationalisation" conceptual level, and miss key networked 
communication aspects.

A two minutes consideration of the difference between the way 
Shakespeare wrote a page and the way you store, distribute and read 
it today, may give you some hints about the difference between what 
the Draft wants to do and what the IETF needs. The Draft drastically 
extends the basic error of the lose RFC 3066 (rigidifying orthogonal 
language/country information) and wants to see it enforced and made 
universal.

A content container should at least document if the language 
description is from the author, to the reader or for the protocol. It 
should the document seven properties (language, mode, community, 
referent, context, style, media) and the property description 
version. Your own Words program just does that. Each of these 
elements may include many sub-elements.

There are three other propositions than status-quo:

A. the current Draft using of ISO 639-1, 2, 3 and additional ISO 
codes. That proposition is based upon the SIL list of 7500 documented 
languages. It is supported by Peter Constable (on the list), author 
of ISO 639-3.

B. Linguasphere (planned to be ISO 639-6). It identifies 20.000 
community language 4 letters not reusable codes and is built as ISO 
11179 compliant for far more information. They fully replace langtags 
when no legal aspect is involved. They are planned to be discussed 
when an ISO standard. It is supported by Debbie Garside (on the list) 
and Dr. David Dalby.

C. the "grassroots approach". The approach is to accept in a network 
and multilingual way everything existing and to relate it to an "ISO 
11179" compatible system. Still at basic thinking and experimental 
stage. This is part of a generalised DRS (distributed registries 
system) to include every network/local/user registry (including 
langtag). The URI-tags seem to fully support the network aspects, the 
IRI-tags the multilingual concept. It obviously support the two 
systems above which can be its defaults. I accepted to spend time on 
the representation of  industrial, political and users interests in that area.

There is no "better" solution. There are more adequate solutions in 
specific situations (A and B can be defaults of C). Each helping the 
other to better define itself. However the A proponents think their 
proposition must be exclusive. They wanted a counter-proposition of 
mine so the "best" might "win". Their ad-hominems were their way to 
exclude a "competition". Their non-technical mails on the IETF main 
list fully exposed that strategy.

The text proposed in December was not acceptable. The currently 
proposed text still appears as an "industrial and commercial Trojan 
Horse" with risks of commercial, political and technical confusion. 
But its authors have trimmed enough their ABNF "against me" to block 
"C" leaks there and threfore a lot of confusion. Yet, we have still 
have no support of non-script mode and three sources of conflicts:

- charset of a document vs script.
- script of a document in a politically oriented (privacy/racial 
violation) tag.
- lingual community information - what may imply a conflicting 
language, script and charset - may conflict with langtags.

My proposition is:

1. to reduce the charset/script conflicts in defining the Internet 
meaning of a script (equivalent to ccTLD IDN tables). No big deal, 
since the tables are already published by Unicode.

2. to define the relation between ccTLDs and langtags "regions" - 
probably one sentence to be approved by IANA, ICANN and the ccTLD community.

3. to include the IRI-tags into the Draft, through the multilingual 
(numeric) "0-" hook, so we support different but not alternative descriptions.

I was opposed over ISO 11179. It seems this has changed since the 
August ISO meeting. I can only rejoice. IMHO the DRS issue is far 
more complex than ISO 11179 and should be addressed separately (may 
be after some experience has been gained with the IRI-langtags?)

jfc


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru