Print

Print


Gérard:

 

The document you cite is a working group report on recommendations, not an actual specification for implementation. The actual specification is here:

 

http://www.icann.org/en/resources/idn/fast-track/idn-cctld-implementation-plan-05nov13-en.pdf

 

ICANN needs to have limits on what display labels can be used as internationalized country top-level domain (ccTLD) name labels — meaning ccTLDs in other than ASCII characters — and one limit they adopted is that the label must be in a language of public administration or with some legal status in the territory. That means they must have ways of determining whether a language meets such criteria in relation to a given territory. Reference to ISO 3166 evidently is one means they have apparently sanctioned for doing that.

 

I worry somewhat about ISO 3166-1 being used by ICANN as a source for determining administrative languages of territories, as much as I’d worry about ISO 3166 being a source for, say, determining names, symbols or formatting rules for currencies of various territories. ISO 3166 exists to provide coded representations to designate territories, not arbitrary facts about those territories, even facts that might be determined and controlled by the political administrations of those territories.

 

But be that as it may, a couple of things can be noted about this usage by ICANN:

 

First, the identification of the language is not an end purpose in their process. Rather, the end purpose is to determine whether a string is an acceptable label. Thus, it really doesn’t matter whether “Shikomor” is appropriately considered a distinct language identity for general purposes. Rather, what matters is whether a string such as “ÇáÇÊÍÇÏ ÇáÞãÑí” is the name or part of the name of the region in some administrative/official language of the territory and, hence, can be accepted as a ccTLD label.

 

Secondly, the ICANN process does not depend on languages being listed in ISO 3166 as administrative languages; that is only one of a few mechanisms allowed for to determine the status of the putative language in question. Moreover, it is important to note that there is no dependency whatsoever in ICANN’s process on languages having alpha-2 identifiers in ISO 639-1.

 

This ICANN process doesn’t rely on use of ISO 639 identifiers in any kind of public data interchange protocol or other ICT applications. On the other hand, changes in ISO 639 can have significantly harmful effects on ICTs, such as problems that result from creating dual encoded representations (e.g. the possibility of having errors in query algorithms that result in incorrect datasets). We certainly should not be making changes in ISO 639 based on a non-requirement from an ICANN process that doesn’t even use ISO 639 IDs in any ICT applications while doing so can create real risks to actual ICT applications.

 

 

Peter

 

 

From: Gérard Lang-Marconnet [mailto:[log in to unmask]]
Sent: April 13, 2014 4:40 AM
To: ISO 639 Joint Advisory Committee; Peter Constable; Rivers Bill; Simons Gary; DeCamp Jennifer; Lang Gérard
Subject: External use of administrative languages Coherence between codes in ISO 639-1, ISO 639-2 andISO 639-3 ////ISO 639-1 language code request for "Shikomor"

 

Dear Peter,

As you seem to have doubts about the fact that "administrative use" defined in ISO 3166-1:2006 (or quasi-equivalently the list of languages defined in Part 3 of the "Technical reference Manual for the standardization of Geographical Names" edited in 2007 as document M87 of the UNGEGN) could have external use, I join to the present message an ICANN report (Final report IDN ccNSO Policy Development Process) dated 29 May 2013 by Bart Boswinkel.

Notably, see point "Distinguished Languages" as defined in point "D: A meaningful representation of the name of a territory must be in a Distinguished Language of the Territory" of the "2.1.2: Criteria for the selection  of an IDN ccTLD string" within "2.1: Policy Recommendations IDN ccTLD Strings Selection Criteria, Requirements and Process" of "2: Recommendations", pages 8-9.

Let me add that Bart is the substitute of Jaap Akkerhuis as ICANN's  representative in the ISO 3166 Maintenance Agency.

Bien cordialement.

Gérard Lang