Dear All,


Thank you Håvard for the swift and clear reply.

I vaguely remember that there was such a request probably in the 1980s, when experts were not yet aware of many issues in language coding.

According to Håvard’s reply such a case – if it existed – was not recorded and in practice not enforced. So what could be the conclusions?


(1) Today, we should not do something line “reserving a symbol” for a potential future change (except maybe for a new symbol, which is under discussion for inclusion in the 639 codes by JAC).

- in any case not for 2-letter symbols, where the possible combinations are so limited anyhow

- in fact also not for 3-letter symbols

From a practical point of view, such a decision could also be an internal temporary decision by the JAC, which does not need codification in the future ISO 639.


(2) JAC – out of its experience – could formulate a recommendation to that extent to the present 639 AHG and future ISO 639 JWG for modifying that clause in the future ISO 639.


Would that be agreeable?


Best regards




Von: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] Im Auftrag von Håvard Hjulstad
Gesendet: Mittwoch, 11. September 2013 05:39
An: [log in to unmask]
Betreff: SV: Request from the ISO/TC 46 to the ISO 639/RA-JAC for the creation of 11 alpha-2 ISO 639-1 code elements concerning the name of administrative languages




Just a quick response to “1 a”: I have never had to process any requests for “reserved identifier”. The way I interpreted the rule is: (1) request for identifier; (2) JAC processing results in “no”; (3) request to “at least reserve an identifier”, in case things change; (4) new JAC processing of that request. There never were any “(3)” during my time, and consequently no “(4)”.


Best regards,


Håvard Hjulstad

  prosjektleder / Project Manager

  Standard Norge / Standards Norway
  [log in to unmask]
P Tenk på miljøet før du skriver ut denne e-posten. / Please consider the environment before printing this e-mail.


Fra: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] På vegne av Christian Galinski
Sendt: 10. september 2013 22:58
Til: [log in to unmask]
Emne: WG: Request from the ISO/TC 46 to the ISO 639/RA-JAC for the creation of 11 alpha-2 ISO 639-1 code elements concerning the name of administrative languages


Dear Colleagues,


we will have to deal with the official request of ISO/TC 46 concerning 2- and 3-letter symbols for 11 languages. Before starting the process I would like to suggest that we clarify 2 issues:


(1) concerning ISO 639-1:2002 clause A.3.4 “Reservation of identifiers":

"When a request for inclusion of a new entity has been rejected, ISO 639-1/RA may reserve the requested identifier for the use of the applicant and others possible users. ISO 639-1 will keep a record of such reservations and will inform the ISO 639-2/RA of such."

In this connection I would like to ask

a) Håvard whether he has a record on such reservations (because such cases were long in the past),

b) all of you, whether we have considered this clause in our discussions after the problem with the reuse of an outdated country symbol to another country by ISO 3166/MA – in fact, whether this clause is still necessary or will need rewording in future ISO 639.


(2) concerning the assignment of language symbols based on mnemotechnic principles (whether based on the English name of a language or the original name of it):

In this connection I would like to ask you to consider a slight modification of the rules – or rather our practice to apply the rules –:

a) we will run for sure into more problematic cases the more language names are coded, and our argument that the language symbol is merely a code and not an abbreviation is weak.

(in this connection the alignment with country names is probably not really helpful either)

b) our colleague Marion Kresse suggested to select new language symbols from a table showing available letter combinations (as we do) – but choosing the second and/or third letter in such a way that they do not look too much like an abbreviation of the language name in question. In several cases we had to do this anyhow – either due to the lack of letter combinations to choose for the language symbol or because of two or more different languages had similar names.

c) we had internally agreed to reserve as much as possible the letters x, y and z for difficult cases in the future (see for instance airport codes, such as YMX for Montreal International or YND for Ottawa or XRH for Richmond in AUS /=Australia, not AUT=Austria/ - similar problems in different coding systems)


Best regards