We expect in fact that ISO 639-1 is a closed set; that no new 2-letter codes will be created. An exception would be if a new language were to be added to 639-1, 639-2, and 639-3 simultaneously: this would be a language obscure enough to be missed by 639-3, and well-known enough to require a 639-1 entry. The only scenario I can foresee requiring such an action is if dialect drift has been large enough over a long enough time (probably centuries) that it becomes the scientific consensus that English or French or Spanish has broken apart into two or more distinct languages.
I do worry that the MA will bow to political pressure and register "Macedonian" in this way, just as was done with "Serbian" and "Croatian" and "Bosnian." I hope my worries are unfounded.
-(iii) On page 22, inside "3.1.1. File Format", the last phrase describing the representation "2004-06-28" in the Gregorian calendar is a direct application of the standard ISO 8601:2004Data elements and interchange formats-Information interchange-Representation of dates and times, third edition", 2004 that should be mentionned inside "9.1 Normative references".The normative reference is to RFC 3339, which is a profile of ISO 8601. It is not necessary to understand ISO 8601 to understand RFC 3339.
In fact, in theory we could probably say "in year-month-day format, separated by hyphens" and be done with it. There shouldn't be any IPR on the format.
Using RFCs as references to other RFCs is often a cleaner solution than using equivalent ISO standards, because of the guarantee that the entire spec is freely available (as in both speech and beer). And for our *very* limited purposes, RFC 3339 is equivalent to ISO 8601.
-(ix) On page 66, inside"4.6. Considerations for Private Use Subtag", the paragraph concerning user-reserved ISO 3166-1 alpha-2 code elements should be enriched by adding that "Article 8.2.of ISO 3166-1 considers essential that all user should notify to ISO 3166/MA every occurrence of their intentions concerning user-assigned code elements, so as to coordinate such uses and to avoid that two differents alpha-2 code elements be choosen by two different users for the same "country name" in the same domain of use.For example, there is today no entry and no reserved code element inside ISO 3166-1 concerning the country name "KOSOVO". But, as the European Union notified the use of the user-reserved alpha-2 code element "XK", ISO 3166/MA is stongly recommanding to use "XK" when representation of the country name "KOSOVO" is needed.As a matter of implicit policy we abstain from such statements about private-use codes. They who use them in interchange do so entirely at their own risk.
I don't think there's any real harm in reminding people who want to create subtags in the private-use space that the MA wants to know what code elements they chose.
I do, however, agree that we should not echo back the MA's "strong recommendations," as users have a tendency to equate those with formally assigned code elements (which is kind of how we got involved with "exceptionally reserved" code elements).
I would also advocate for the addition of ISO 3166-2 :2007. Codes for the representation of names of countries and their subdivisions--Part 2: Country subdivision code", December 2007.3166-2 codes are not used in BCP 47. A normative reference implies that understanding of the referent is needed to understand BCP 47 fully, which is not the case for 3166-2.
It should not even be an informative reference, since neither BCP 47 nor the Registry mentions informatively, or even alludes to, ISO 3166-2.
For reasons that have been outlined here before, ISO 3166-2 -- as useful as it is in other contexts -- is not appropriate for BCP 47 language tagging. Slipping a new entry into the References section will not change this.
-(xi) On page 79, inside "9.2. Informative References", I would like to add "Glossary of Terms for the Standardization of Geographical Names"--United Nations Group of Experts for Geographical Names--Statistics Division, Department of Economic and Social Affairs--Manual M85--New York, May 2002."Je ne vois pas la nécessité." --Talleyrand
Since we don't formalize the use of UNGEGN terminology, the only thing this reference would accomplish would be to cause IETF Last Call reviewers to ask why it was added.
2.2 In fact, I am completely prepared to admit that "political correctness" has gradually pushed "scientific progress" and ISO 639/RA-JAC to recognize "Sign languages", that were not initially intended to be covered, as possible entries inside ISO 639-3 and ISO 639-5 and pseudo-linguistic entities. So we observe in french languge a shift from "langage des signes", that was historically the only way to translate "Sign languages" until recently, to "langue des signes" that became much more politically correct. But, please, it is not necessary to rewrite history for this.
I wonder what has caused Gérard to object so strenuously to the encoding of sign languages in ISO 639. Somehow I doubt it is just the origins of "langue" and "langage."
-- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.