ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

[ga] National sovereignty on names, numbers and languages is a GAC issue

  • To: GA <ga@xxxxxxxxxxxxxx>
  • Subject: [ga] National sovereignty on names, numbers and languages is a GAC issue
  • From: "J-F C. (Jefsey) Morfin" <jefsey@xxxxxxxxxxxxxxxx>
  • Date: Wed, 23 Mar 2005 18:10:58 +0100
  • Cc: vinton.g.cerf@xxxxxxx, chair@xxxxxxxxxxxxx
  • Sender: owner-ga@xxxxxxxxxxxxxx

As an Internet user I like ICANN and ITU coopete to my best interest. ITU can do things ICANN not do, but ICANN can do things ITU cannot do.

One of the things ICANN has known to build is the GAC, welcoming the ITU main members in a structure to overlook the IANA. I would love the ITU eventually to start an ITU-I, to welcome the Internet users when they want to relate with the Telcos and talk about bandwidth, infrastructure, radio-frequencies, interphone support and directory, etc.

A major issue develops around the world - this may not have not noticed: this is multilingualism. This is not an easy issue as the evolution from an ASCII Internet to a Multilingual Internet may call for architectural aspects (in particular classes) the Internet technology has defaulted (there is only one "IN" - Internet - class while we may need one class per language, at least). The current IDNA solution does not address the need and may lead to grassroots solutions wich may hurt the DNS (like PADs, private alias directories) while no one else than our @large based effort has followed on the ICANN ICP-3 call for experimentation.

The first problem of multilingualism is "language normalization" (the normalization of the "containers" of the language). The first point is the normalization (ISO) of the name of the languages, scripts, etc. and their documentation on a geopolitical basis. This is an highly debated and disputed issue among specialists, but also politics and Governments. We touch here the core of the culture which is the core of the human being. A really touchy issue - still more than to countries.

ICANN should be protected from this. The same as Jon Postel said (RFC 1591) IANA is "not be in the business of deciding what is a country" and relies on ISO 3166, IANA should not be in the business if deciding what is language and use ISO 639 - which in the same kind of list of all the languages in English and in French and of their 2 and 3 letters code, ISO 15924 for scripts and its same ISO 3166 reading for ccTLD and languages.

Yet some want the IANA to get involved in this debate. Why? Because XML, HTML, etc. need a language tag to tell the users the language they must know to read the page. To that end RFC 3066 defines language tags (language code, script code, country code - using ISO) and has established a procedure to register the codes, when the users would need codes which are not in the ISO 639. This is a concept equivalent to the addition of Jersey, Guernsey, .EU for Europe to the ISO 3166 list.

But there is a much bigger need. The need is to start _defining_ the languages. Why? The Unicode consortium (http://unicode.org) has started the CLDR project to standardize the "locales" (all the information to "internationalize" your computer as American, English, French, Spanish, Chinese, etc.). This is a great idea, they have carried a lot of work, ... but this is controverted and politically touchy. Some OS developers, some countries, disagree or most just do not know them yet. Others also want to have a common language understanding for word processors, optical readers, grammar correctors, etc...

This is so touchy that many countries may call on the WSIS to remove ICANN and the IANA, or at least the IANA from ICANN for that. Saying the IANA is not a commercial or political advantage for "word oppressors".


I think this could be the occasion of a master move by ICANN, both addressing the situation, showing its maturity, getting a GAC support and this way stabilizing better the whole internet intergovernance.



Users do not want the IETF to be prevented to proceed (W3C and Unicode people wait for this support). Users do not want Governments to oppose ICANN on this key matter. Users and businesses need stability and protection.


The IANA is ruled by an MoU between ICANN, IANA and IETF. http://www.icann.org/general/ietf-icann-mou-01mar00.htm. (RFC 2860). This MoU makes the IETF the IANA source for everything (with appeal to IESG and IAB), except on names and numbers. I would strongly suggest that everything concerning languages would have to be accepted by the concerned countries with an appeal to the GAC. This shared control on the most important human resource could only serve the international usefulness and credibility of ICANN.


The IETF has created a WG on the language tags issue http://ietf.org/html.charters/ltru-charter.html The current proposition cannot be consensually adopted (it has already failed the IETF "Last Call" twice and has not substantially changed since then). We have decided to propose a Draft looking really at a consensus. It will not support any rigid exclusiveness, but it will strive to support the W3C and Unicode needs, as well as the IDN needs, and any other (existing or to come) applications needs, with the same precision but also the same adaptation to the specific needs of each application.


The WG-ltru's Charter calls on documentation of the IANA registration procedure. The Draft will say that IANA acknowledges the State sovereignty on their national names, numbers and lingual spaces as advised by the GAC, and that the ICANN's IANA jurisdiction over names and numbers extends to all what may concern languages (updating RFC 2860).

The current text says: "4.3. Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU." The Draft will propose the addition of "language documentation" to these two assigned spaces.
jfc






======================================================
Standardizing Tags for the Identification of Languages should not be a way
to standardize languages and to unify the world under a dominant culture.
======================================================
For your convenience:
RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066
Draft: 	http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt
Charter: http://ietf.org/html.charters/ltru-charter.html
gmane: http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
======================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
 as a basis for country code top-level domain names was made with
 the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
======================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
======================================================
It seems that what works for countries and ISO 3166 since 1978, should
apply to languages and to ISO 693.
======================================================




<<< Chronological Index >>>    <<< Thread Index >>>