Message-Id: <6.2.3.4.2.20050907230530.0484d360@mail.afrac.org>
Date: Thu, 08 Sep 2005 01:27:11 +0200
To: "Addison Phillips" <addison.phillips@quest.com>,
	"John C Klensin" <john-ietf@jck.com>, <iesg@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] Last call comments on LTRU registry and
	initialization documents
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0CB444CF@irvmbxw01.quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ltru@ietf.org
Precedence: list
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

Dear John,
I would like we all pay attention to what Addison says. I fully agree 
with him, and I thank him to be honest and at last so clear. He 
perfectly defines his target. What the IESG is to decide is:

- if this target is or not an unbearable source of permanent 
contention, confirming to the Internet balkanisation engaged by the IDNA
- if this target is or not a cleaning of the RFC 3066 errors (the 
first one being a far too limited and tight vision of language identification)
- if this target permits or not to complete the RFC 3066 limitations 
in using the Draft as a default for a general IRI-langtags solution.

At 21:19 07/09/2005, Addison Phillips wrote:
> > Comments on draft-ietf-ltru-registry and
> > draft-ietf-ltru-initial and, secondarily, on
> > draft-ietf-ltru-matching...
>I've thought a lot about the excellent analysis and comments in John 
>Klensin's message. My perception is that we have a divergent view of 
>the structure and significance of the LTRU draft(s).
>
>Although superficially the drafts are very different than the RFC 
>3066 that they seek to replace, in fact the structure is very 
>similar. The drafts are attempting to fill certain gaps unaddressed 
>by RFC 3066 for implementers or for tag choice by and the 
>requirements on "content authors" (people who choose tags or ranges).

Correct. The Draft tries to make RFC 3066 tighter. To fill certain 
gaps. Not to fill any of the needs RFC 3066 does not address.

>Here are my basic thoughts in response to those comments:
>
>1. All tags valid under the drafts would have been valid or valid to 
>register under RFC 3066. This is a key point.

No one knows where this targets comes from. RFC 3066 logic has three problems:
- the loose ABNF. This leads to confusion. The Draft addresses this. 
Still imperfectly, but the progress is real.
- the lack of modal description. There is an embryonic _addition_ of 
script support - however conflicting with charset
- an exclusivity resulting from its BCP status, excluding all the 
much needed other propositions. This is not addressed but reinforced.

>The tag grammar proposed is intended to be highly compatible not 
>just with RFC 3066 but also with existing implementation. It is 
>expressed as greater restriction on what may be registered. This 
>provides more regularity in tags, although tags themselves are not 
>greatly changed. A subtag registry is, in effect, a different way of 
>expressing what is already in place.

This proposition does not stand. What is already implemented is by 
nature RFC 3066 conformant, i.e. more loose - or RFC 3066 not 
conformant and this is not considered. RFC 3066 permits private use 
(x-). x-tags exist and may conflict in case of interconnection: this 
problem has been addressed with the URI-tags RFC: 
"x-private.space:tags". The Draft opposes that RFC.

>2. The fact that it *always* narrows the potential subtags that 
>could be registered *in the future*, but has no effect on any tags 
>or subtags already extant means that (from an RFC 3066 
>implementation perspective) the range of tags actually seen in the 
>wild will be more limited than it might have been. Commentators on 
>this thread have implied that it is an entirely new protocol, but I 
>think that goes too far: it is the same protocol with greater rigor 
>on what may go where.

It is not a new protocol. This is a progressive reduction of the 
capacity of description of languages. While the world needs to 
enlarge this description.  This intended narrowing will each time 
start a contention with the "narrowed" language or culture.

Let imagine that each "narrowed" person joins the IETF to protest ... 
and explains the competition and control reasons implied. I suspect 
the ietf-languages@alvestrand.no mailing list will also need a new 
server. May be a good way for IETF to reach out new cultures?

>3. The various rules and guidelines set down in the draft provide a 
>more rigorous registration process based on the experience of 
>operating ietf-languages for the seven or so years. This could be 
>seen to make it the "best current practice" for registering language 
>tags or their components. The switch to subtags was chosen to spare 
>the community immense numbers of registrations of various subtag 
>variations (examples from the current registry: two German 
>orthographic subtags, eight registrations; two Chinese script 
>subtags, *twelve* registrations).

This more rigorous process is simple:

- if you want to register a new script subtag you must first ask ISO. 
This is Unicode, Michael Everson.
- if ISO says "no", you will have to ask Michael Everson, 
ietf-languages@alvestrand.no

I have nothing against this. But it must be clear to everyone that 
this is what the Draft proposes the IESG to impose, through a BCP, to 
the internet global community, to the printing industry world wide.

Is there someone to believe that we will not immediately face a few 
alt-langroots? The problem is that they will support ISO 639-1-2 
small lists (current draft-registry) due to the size and the most 
common need. This will be a huge set-back by small languages and 
developing world and regional cultures.

>4. The creation of a registry simplifies the work incumbent on 
>implementers or content authors, since they no longer have to refer 
>to (under RFC 3066) four separate tag-or-subtag repositories and 
>then synthesize the rules in RFC 3066 for choosing between certain 
>overlapping subtags (for example ISO 639-1/-2). The fact that there 
>is a registry doesn't change the fact that "somewhere" there is a 
>list of subtags that may be validly combined into tags.

This is true. But this does not address the desire of people wanting 
to use the "engl" ISO 639-6-to-be code as an equivalent langtag to 
"en-latn-uk". Or people wanting to use the comon French "franglish" 
for my "en-latn-fr".

>5. There is a perfectly good matching scheme loosely described in 
>RFC 3066. This scheme is enshrined in numerous places, including RFC 
>3282 (which, you'll note, also "Obsoletes: 1766", an example with 
>3066 of two RFCs obsolescing the same BCP on separate days over a year apart).

Please do not underline the endemic inappropriate management of 
lingual issues by the IETF!
The main interest of RFC 3282 is that is standard track and do not 
use langtags.

Not every RFC becomes a standard, but BCPs "standardize practices" 
(RFC 2026.5).

>The additional forms of matching described by the matching draft are 
>interesting and may be useful in a variety of applications 
>(draft-matching gives some examples). But they are unnecessary to 
>the specific task of updating RFC 3066. Applications of language 
>tags in the future may wish to choose one or another of the other 
>schemes from draft-matching to produce more interesting results. But 
>such additional schemes are not necessary to the task of updating RFC 3066.

Correct. This is why there is a need for:

- a multilingual internet framework dealing with language negotiation 
procedures (not only match or ... English, as documented)
- adequate documents for each proposed format and its filtering.

>If the community feels that matching is so important that 
>draft-registry must deal with it directly, my suggestion would be to 
>take Section 2.5 verbatim from RFC 3066 and include it in 
>draft-registry. This preserves the vital reference to language-ranges.

Good idea! But the Draft ABNF should then be associated with its 
filtering strategy in the second draft.

>It should be noted that RFC 3066 nowhere provides an explicit 
>treatise on matching. Both it and draft-registry were written for 
>compatibility with known matching schemes. Success or failure of the 
>draft should necessarily be measured by its interoperability with 
>existing matching protocols. My belief is that there is high 
>interoperability, since the matching scheme is quite basic and the 
>rules governing tag choice gave careful consideration to the problem 
>of script subtags.
>
>6. The tag forms used in the draft are, in fact, being registered 
>and adopted. I note that Google this morning returns 41,600 hits for 
>"zh-Hant" as a piece of content. Many of these appear to be valid 
>usages as language tags---script subtags in the wild--rather than 
>just mentions of the registration. Thus the draft merely recognizes 
>the "reality on the ground" with regard to language tags. It does so 
>by reorganizing how tags are registered to make the scheme more manageable.

This is the most worrying part. RFC 3066 is currently not really 
enforced. I will not dwell on the Chinese case, a sensible case. I 
will only note that today an RFC 3066 loosely used langtag gives 
41,600 associated URLs. Delivering language, cultural, indirectly 
racial information, on their authors, then on their readers 
_even_if_they_do_not_want_it_. This privacy violation is the worst 
problem created (and partly documented by RFC 3066: we all know its 
nickname among human right people).

This privacy violation is far more dangerous than cookies and spam. 
Everyone knows about the French law used against Yahoo!. Should the 
Draft be accepted without a user protection possibility, it is likely 
that several legal actions will be undertaken in different countries 
which will lead to the blocking of the pages with a language tag when 
not approved by the user. Or may be to the blocking of the registry. 
We are in a real world.

>7. The choice between STD and BCP tracks is really a toss-up. There 
>are very good arguments on both sides. The creation and management 
>of a registry does not lend itself to STD, but the creation and 
>testing of implementations does not lend itself to BCP. My thought 
>here is that one can view the draft entirely through the lens of 
>existing RFC 3066 implementers: these documents represent a set of 
>BCPs related to various aspects of registering, choosing, and 
>implementing language tags. New implementations may be different as 
>a result of the improvements made (certain kinds of assumptions can 
>be made about a 3066bis tag that cannot be made about a 3066 tag). 
>All such implementations will be recognizably implementations of RFC 
>3066, though, and to the benefit of all concerned (IMHO) they 
>represent the best current thinking on the manner in which to 
>identify languages on the Internet (given our legacy considerations).

The question is simply: "is this Draft to standardise _now_ or in the 
future from obtained experience".

>As a participant in this effort, I have to say that it has been a 
>remarkable and exhausting effort. I certainly hope that LTRU has, in 
>fact, achieved its goals and hope too that, after a lot of work, we 
>can move forward to a recognizable conclusion to these efforts.

This Draft can be:
- a remarkable exclusion effort, pushing aside/outside of the 
Internet 70% of the world population.
- a good solution for e-commerce and the root of the Multilingual 
Internet if including IRI-tags into a common language identification solution.

This will depending on the IAB final decision if one has to come to 
appeals. I hope that all this effort will pay back with the second 
solution and that we may quickly find in common a solution to the 
racial/cultural disclosure issue.
jfc  


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru