Message-Id: <6.2.1.2.2.20050713161843.04b74340@mail.afrac.org>
Date: Wed, 13 Jul 2005 16:46:20 +0200
To: <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
In-Reply-To: <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp>
References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com>
	<200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com>
	<6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org>
	<008d01c58779$f5fe3f40$7f1afea9@oemcomputer>
	<6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Subject: [Ltru] Last call - the Draft must not be a political proposition
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 12:28 13/07/2005, Martin Duerst wrote:
>[with my co-chair hat on]
>I'd like to thank JFC on actually submitting real text.
>As both chairs have said repeatedly, this is the best way
>to move things forward.
>
>For everybody: If you make an actual proposal (rather than just
>discuss a proposal), please use a new subject. Also, please
>indicate clearly that you want this change to happen as part
>of WG Last Call. Otherwise, we're never sure whether that's
>what you want, or whether your proposal is just "as an idea".

Dear Martin,
I make this proposition two technical propositions. There is no worst 
politics than to involve oneself in polical issues in not defining the 
boarder and whi is responsible of what. Unless this Draft wants to be a UN 
declaration. So, in believing one does not make policy one makes be error 
a  political act. This Draft is not opposed for its technical aspects most 
ignores. It is strongly and w ill increasingly be opposed on political 
grounds. Silence is confusion.

>[with my co-chair hat off]
>I quite a bit agree with the sentiment in some of the text.
>(I have worked on Internationalization of the WWW and the
>Internet for a long time, so I hope this doesn't come as a
>surprise.) However, as an engineer, I think that what counts
>is the actual spec. As a technical project, the only thing
>we can do is to try to produce good technology, and hope
>it gets used the right way.

You cannot use technology to impose political choices in political fields, 
what the Draft does. The first part of my text I keep in this part is an 
exact equivalent (and therefore necessary) of RFC 1591 which covers ISO 
3166. This Draft otherwise is in contradiction with Jon Postel wise 
separation. Jon Postel commented ISO 3166, ISO 15924, ISO 639-X and UN.49 
are no IETF documents and their exact authoritativeness is to be documented.

The idea of correlating languages and countries is a very controverted 
political issue. It is not the role of IETF to take side. The argument to 
say this is not to be in an RFC it is like saying copyright mentions should 
not be in an RFC because these are lagalities.

>Engineers in general, and the
>IETF in particular, is rather bad at marketing and politics,
>and I think we should stay away from it.

True. And this is why it must be said. And politics to be left to politics.

>  Declarations like
>those in JFC's proposed text are very important in political
>fora, but in my opinion don't belong in a technical spec
>(like ours).

No. RFC 3066 was not really used and politics are not really aware of it. 
But RFC is a major political position. I do not think this political 
position belong to the ISO thao (the fact to permit a technical censoring 
on a political tag [I remind that ISO 3166 provide a code for a country 
name:Jon Postel associates it for IETF with the ccTLD Manager, here it is 
obviously linked to non Internet issues like Govs, Admin, Commerce]).

If Govs through ISO Members have not ventured into that area I think (this 
is a pesonal point of view, but quite shared) it is a decision, not a lack.

>The only bit where I'd like a bit more time to check the current
>draft text is JFCs first paragraph. If we are not clear enough
>that the draft and the registry don't define languages, but
>only provide identifiers, then I think may be a problem.

This is a major (also political and commercial issue). The problem is the 
same as ISO 3166 and creates a consistency problem.

>But if this is the case, then this should be fixed mostly
>by word tweaking, rather than by grandiose declarations.

See next post.

>As an example, looking at the first sentence of section @,
>it currently starts "The language tag always defines a language...".
>I think this should be changed to say
>"The language tag always identifies a language..."

This is not enough, because there are not enough information in the langtag 
to differentiate two languages elligible to the same langtag. This leads to 
the need to define the used words (this point was discussed after a 
proposition of yours). What is a language, what is its granularity?
Again, I underline that we are here IETF not ISO. This means that we are 
not in a static description of language items, but dynamic exchanges 
qualifications.

I repeat here the proposition of a leading paragraph.

1. it should include a definition of what are a language, a script and a 
region (country?)

2. it should include the following paragraph.

"The IANA is not in the business of deciding what is and what is not an 
appropriate correlation between a language, a script, a country and other 
cultural or human language elements as they may appear necessary [RFC 1591] 
The selection of ISO 639 to obtain a language/script/country correlating 
table and rules was made with the knowldge that ISO has procedures to 
determine which resulting language tags should be and should not be on such 
a list. It happens that ISO 639 does not provide yet such a list. So, 
however the IANA is not in the business of deciding if this is a lack ISO 
still has to address or if it is a deliberated authoritative decision, the 
IANA intends to extend the possibilities offered to Internet protocols and 
applications users by RFC 3066. This Memo describes under which technical 
terms this may be done, notwithstanding the national or international legal 
limitations which may be imposed elsewhere to the users."

jfc



_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru