Message-Id: <6.2.3.4.2.20050823020225.048c75e0@mail.afrac.org>
Date: Tue, 23 Aug 2005 03:45:14 +0200
To: "Randy Presuhn" <randy_presuhn@mindspring.com>,
	"Scott Hollenbeck" <sah@428cobrajet.net>,
	"The IESG" <iesg-secretary@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Publication request for
	<draft-ietf-ltru-registry-12.txt> as RFC (BCP)
In-Reply-To: <003c01c5a750$76021f40$7f1afea9@oemcomputer>
References: <003c01c5a750$76021f40$7f1afea9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: LTRU Working Group <ltru@ietf.org>
Precedence: list
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

The following few comments are in order:

At 21:34 22/08/2005, Randy Presuhn wrote:
>The document has received detailed review within the ltru WG.  Reviews
>have been solicited outside the working group, but to date none have
>been received. Given the depth and breadth of expertise of the working
>group's members, we are not concerned about the adequacy of the review.

The documents does not even allude to languages as used in a specific 
networked context. This denotes that the small score of experts 
involved are no experts in that area. The planned participation 
statistics to the WG will document this.

>   1.c) Do you have concerns that the document needs more review from a
>         particular (broader) perspective (e.g., security, operational
>         complexity, someone familiar with AAA, etc.)?

Languages as interintelligibility protocols are one layer above 
Internet interoperability protocols and support interculturation 
processes. This is a domain commanding the whole development of the 
digital ecosystem relational continuity and usage architectures. It 
is certainly of high complexity: it involves 20.000 listed languages 
(in ISO 639-6 project) and actually the different individual forms of 
speaking, reading and exchanging of 6.5 billions of persons. This may 
amount to thousands of billions of linguistic versions.

Everyone can understand that the attempt to tag them through a 
reduction of the RFC 3066 flexibility is a challenging task calling 
for a pervasive acceptance, an IETF WG (or any WG) cannot deliver at 
this time, with the current status of R&D in the different concerned matters.

>No.
>
>    1.d) Do you have any specific concerns/issues with this document that
>         you believe the ADs and/or IESG should be aware of?  For
>         example, perhaps you are uncomfortable with certain parts of the
>         document, or have concerns whether there really is a need for
>         it.  In any event, if your issues have been discussed in the WG
>         and the WG has indicated it that it still wishes to advance the
>         document, detail those concerns in the write-up.
>
>No.

This WG-ltru obviously has not the technical expertise, the cultural 
consensus and the political support to decide of a IANA language 
identification system users should universally adhere to (BCP). It 
has however the technical expertise, the application need (to be 
confirmed) and the commercial support to document one of the ways 
some Internet users and software publishers could use.

The personal user's risks represented by this langtag system calls 
for high civil society concerns, as it associates a language to a 
Government political line. This may put the IESG at the apex of a 
major political and human right diatribe, in particular at the WSIS: 
it may not be what the IESG wants.

>    1.e) How solid is the WG consensus behind this document? Does it
>         represent the strong concurrence of a few individuals, with
>         others being silent, or does the WG as a whole understand and
>         agree with it?
>
>Strong (rough) consensus, with one outlier.

This consensus is a silent consensus by exhaustion. The WGLC did not 
lead to significant expressed support even of the leading affinity 
group (20% of the Members). As the outlier I will add (as explained 
many times) this was a deliberate effort of mine to keep a working 
relation between the real world and the WG, while preventing the WG 
to be overthrown without real signification and a waste of time for 
all by an opposing group of scholars.

I note that this WG on languages issues is overwhelmingly manned by 
people having the same linguistic vision (English mother-tongue) and 
that an attempt to participate from different vision was qualified of 
"troll" leading the concerned academic person to leave.

>    1.f) Has anyone threatened an appeal or otherwise indicated extreme
>         discontent?  If so, please summarise the areas of conflict in
>         separate email to the Responsible Area Director.
>
>Yes, details supplied separately.

I wait for a courtesy copy of these details to make sure the IESG is 
correctly informed. I proposed the authors of the PROTO Draft to make 
this transparency the rule and not a courtesy.

>   Technical Summary
>
>    This document describes the structure, content, construction, and
>    semantics of language tags for use in cases where it is desirable to
>    indicate the language used in an information object.  It also
>    describes how to register values for use in language tags and the
>    creation of user defined extensions for private interchange.
>
>    This document was produced as part of the effort to develop a
>    successor to RFC 3066, and is the primary deliverable the working
>    group was chartered to produce.

This document pretends to be _the_ successor to RFC 3066. Should it 
not claim to replace BCP 47 and to support a future global language 
support framework for a Multilingual Internet as indicated here, 
permitting to immediately document and support other language tags 
formats adequate to the users needs, open source projects and current 
developments, there would be an unanimous acceptation of the document.

What is objected is not the content, but the IANA exclusivity and 
status quo: the exclusion of competing solutions and innovation.

>Working Group Summary
>
>    Use of the existing IANA Language Tag registry revealed several
>    shortcomings, leading to the development of this document.
>    In addressing the requirements of its charter, the working group
>    found it necessary to significantly change the registry format.

Not correct. The very basis of this WG is an undocumented "consensus" 
"obliging" to strictly respect the RFC 3066 ABNF up to
- the absurd obligation to respect old blocking formats for new 
applications (which by nature never used them)
- and the refusal of an escape sequence permitting to seamlessly 
introduce other formats and new developments.

The Charter has never been discussed by the WG.

>    Since language tags are used in a large number of protocols and
>    formats, the working group maintained compatibility with existing
>    language tag syntax, though it did change the syntax of registry
>    entries and updated the procedures for the maintenance of the
>    registry.  There was strong consensus on all of these.

"maintaining compatibility" does not means here that the new format 
must support the old format.It means that the old format had to 
contain the new format. This "retro-compatibility"has been qualified 
of "reverse compatibility".

>    Two issues are noteworthy for the amount of debate needed
>    before the working group was able to reach rough consensus on
>    them.  The first was the order of subtags, in particular of the script
>    identifier.

The script identifier position does not result from a debate of the 
WG but from the continuation of the Addison/Davis Draft which was the 
only discussed matter, from the very fist day of the WG. The lack of 
debate lead in particular to disregard several important issues:

- the lack of documentation of the oral modes. While langtags are 
supposed to be for every usage, voice, sign, etc.attributes are not documented.
- the lack of documentation of the language identification main 
attributes such as the referent system (dictionary, publisher, etc.) 
and the context (style, relation, space of exchange, etc.) and the 
date of publication. Even without being a human relations specialist 
one can understand that what Words supports (dictionary, style, 
version) are elements important to the identification of a content vehicle.

The Draft organises and protect a langtag scarcity. This has serious 
reasons, but these reasons should have been discussed, analysed and 
better addressed. It also represents important commercial and 
industrial interests. The same they should be discussed and an equal 
opportunity for all the concerned stakeholders protected. These 
points have never been investigated.

>   The second was the "Suppress-Script" registry field.

This is another "script only" issue, underlining the WG-ltru did not 
considered multimodal aspects.

>    These two are closely related, and the tradeoffs involved a desire
>    to avoid re-tagging existing data and a need to keep the tag format
>    syntactically compatible with existing software, versus a desire
>    to provide a tag structure that was in some ways more consistent.
>    The working group opted for compatibility and avoiding re-tagging.

This translates the desire to impose for ever a closely constrained 
exclusive format, the status quo of which will benefit to market 
dominants, excluding innovation, pretending that other projects 
re-tag into an inadequate approach.

That attitude can only lead to competition (called by the author: 
"that the best win") between solutions instead of an inclusive 
support of the various user needs and existing/future systems. A 
competition, due to the care importance of the matter to users, can 
only lead to a "tag war", where the only losers will be the IETF, the 
IANA and the users.

>Protocol Quality
>
>     This document received extensive review and discussion within the
>     ltru working group.
>
>     Since language tags are used in a large number of protocols and
>     formats, the working group maintained compatibility with existing
>     language tag syntax.

Incorrect. The Charter quotes existing use in HTML, XML, CLDR. HTML 
has not been much discussed. XML has. CLDR has not been, nor even 
been documented (while it is a project conducted by one of the 
authors). Clarifications concerning the CLDR's IPR issues have been 
denied- while the concerns for Open Source are serious. Relations of 
the language tags with LDAP have been partly considered. DNS, OPES 
and programming languages were denied consideration. One or two other 
protocols have been alluded to. No systematic review of all the 
possibly affected protocols has been carried by the WG.

>      At the time of this summary, likely additions to the registry had
>     already been discussed, but the WG agreed that since such
>     changes are part of the normal operation of the IANA Language
>     Subtag Registry, they should be handled on the mailing list
>     ietf-languages@iana.org after the registry has been initialized.

Incorrect. A Draft has been produced to build an initial registry one 
shot. The IESG should be aware that some entries may rise some 
political controversies.

There is currently not such a list as "ietf-languages@iana.org". 
There is a alias of that name for the real list 
"ietf-languages@alvestrand.no". As a result it has not the 
international recognition it should, to warranty a transparent 
process. The organisation of this list creates problems not addressed 
by the Draft; they directly engage the responsibility of the IESG:
- selection and renewal of its reviewer by the IESG
- management of the list - its current manager uses its private 
nature to assimilate it to IETF mailing list, without providing 
appeal protection
- technical expertise of the reviewer is only script oriented
- there is no liaison with other SDOs possibly relying on langtag 
IANA registry entries.

A major point of concern of this registry is its real use by users 
and therefore of its real operation cost and operational feasibility. 
This point has been discussed without offering a documented scenario.

These are only quick comments on the current write-up. They represent 
only a small part of the planned comments for a Last Call and for 
possible IETF, IAB, IANA, etc. appeals.

They would be immediately removed should the intent above of not 
replacing BCP 47, but to only be one of the contributions to a BCP 47 
replacement was confirmed and the concerned sentence to be reworded 
accordingly.

jfc morfin
AFRAC,vp r&d







_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru