As a JAC member, I may have opinions on what should or shouldn’t be included in ISO 3166, but that’s outside the scope of the JAC to act on. So, my main focus here is on what factors to consider in evaluating proposed changes in ISO 639.
In that regard, the ICANN and UNGEGN documentation you have provided do not demonstrate any need either for encoding “Shikomor” or for adding any new alpha-2 IDs in ISO 639-1.
As for more general considerations, you said,
“Sure the ICANN's document, as such, does not advocate for the creation of alpha-2 ISO 639-1 code elements that are lacking for some administrative languages. But it is one more sign of how such code elements could be needed and used.”
These appear to be contradictory statements, “ICANN’s document doesn’t provide evidence for X, but does provide evidence for X”. In fact, ICANN’s document does _not_ demonstrate any usage scenario for alpha-2 language identifiers.
Thank you for your reference dated 5 november 2013, that is better that mine, but whose text is identical concerning the questions we are interested in.
The title of my message was "External use of administrative languages", and this message was to provide an example, pertaining to the information technology sector, of an effective use of the concept of administrative language (even if this concept is not explicitly quoted in the text of the document) as defined quasi-identically by the ISO 3166 standard and by the Manual M87 of the UNGEGN. This is effectively done in point "3.2: Language and Script Criteria" of "Module 3: TLD String Criteria and Requirements" (pages 7 and 8). Moreover point "3.3: String Meaningfulness Requirements" is also precisely referring to the strings given in the Manual M87 of the UNGEGN.
Sure the ICANN's document, as such, does not advocate for the creation of alpha-2 ISO 639-1 code elements that are lacking for some administrative languages. But it is one more sign of how such code elements could be needed and used.
Concerning the many, many uses of ISO 3166 in standardization and outside standardization as well, this is a long story. But these many uses are only a consequence of the fact that ISO 3166 is very largely considered as a most reliable source, carefully maintained and correctly managed following very precise written rules available in the normative text of the ISO 3166 standard and in the Guidelines.
Le 15 avr. 2014 à 08:39, Peter Constable a écrit :
The document you cite is a working group report on recommendations, not an actual specification for implementation. The actual specification is here:
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.
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.