> From: ietf-languages-bounces@xxxxxxxxxxxxx [mailto:ietf-languages- > bounces@xxxxxxxxxxxxx] On Behalf Of Bruce Lilly > > That misses the point entirely. The point is that IDs used by political > > administrations may change for any number of reasons, and those > > admministrations may have no qualms with such changes; > > For such changes to become enshrined in an ISO standard > requires a bit more than a mere whim on the part of one > party; in the case of the particular ISO standards under > discussion, it requires convincing the duly appointed > maintenance authority to make the change. The ISO 3166 MA maintains that standard in accordance with the identifiers specified by the UN Statistics Division; a change by the UN is all the convincing that is required. > > If for whatever reason ISO and the UN decided that "US" should > > be used to designate the country of France, I doubt you'd expect every > > software vendor to update all of their deployed installations to use > > "fr-US" instead of "fr-FR", and for every user to go through every data > > repository they manage to make such changes in their data. > > The only way that would be likely to happen would be if > there were no longer a "US" *and* if the ISO and UN > representatives of France were to initiate a request for > such a change. One would presume that they would have > good reason to do so, and could explain said reasons in > order to convince their ISO and UN counterparts to agree > to the change. Under those hypothetical circumstances, I > can only assume that software vendors who care about such > matters would either agree with the hypothetical reasons > or would have acted to convince those in favor of the change > of reasons to avoid the change. This scenario is not hypothetical; it actually occurred in the case of CS. The change was solely under the control of the UN Statistics Division; it is not part of their process to consult with developers and users of IT systems in general, and they were not consulted in this case. They were completely powerless to influence the change, learning about it only after the fact. This is a situation we do not intend to repeat. > And while I would not > expect users to retroactively change documents any more than > I would expect coins and paper money to be reissued with old > dates but new designations of country name, I would expect > that as of the agreed-upon effective date of the change that > new documents would be prepared in accordance with the new > standard. It's difficult to be more precise about such a > wild hypothetical, but consider similar changes made to > time zones... I have no interest in considering time zones; I will leave that to people that solve problems related to time zones. Content cannot be assumed to have any language tags in its metadata tagged to indicate version, so versioning is not a general solution. There are ways that we can impose stability, and that is what we seek and intend to do. > > The usability flaw in treating ISO 639 and ISO 3166 as human-readable is > > evident in the confusion between ja and JP (or is it jp and JA?), and GB > > vs UK. > > Without looking I can easily tell that jp and uk are country > codes precisely *because* they are well-known as TLDs. It is not uncommon for users to confuse "JA" and "JP". "UK" is not an officially-assigned ISO 3166 country code; it's status is "exceptionally reserved". The alpha-2 ID listed in ISO 3166-1 for United Kingdom is "GB". > > As for what is silly, if the UN country ID for Canada changed to > > CN (and that for PRC changed to something else), I'm sure it would cause > > far greater problems for users to have to change the last two letters in > > domain names than for them to keep doing what they always did. > > And it is precisely because of such problems that it is > as unlikely to happen as your hypothetical FR->US change. Again, not hypothetical at all. > > > > Neither RFC 1766 or RFC 3066 has ever presented "official" > > translations; > > > > > > Both defer to the ISO lists for definitions (not "translations") > > > of the various codes. > > > > Definitions; not language names for display use. > > Feh. Whatever. The human-readable stuff that corresponds > to the code which you say shouldn't be read. The stuff > without which codes are meaningless. The stuff without > which two communicating parties cannot agree on the meaning > of "XX". The stuff that defines the meaning of "XX" where "XX" comes from an ISO standard is the ISO standard. That was the case in RFC 3066. This draft does not change that; it merely provides some info that may save you having to go look up the ISO standard, but that info is not the last word. > So, you're saying that the ISO definition of "CS" as > "Serbia and Montenegro" will continue to be valid, with > that meaning, in a language-tag? The meaning of an ID in the registry that came from an ISO standard is the meaning it had in the version of that ISO standard from which it was obtained. (Typically, that is the current version of the ISO standard at the time the ID is added to the registry, though the initial registry being prepared will have some exceptions to resolve pre-existing ambiguous cases, such as CS.) If you're really wanting to know what the meaning of "CS" would be per the proposed draft, the proposal is that it will forever remain valid with the meaning "Czechoslovakia" as it was originally defined in ISO 3166. > The foolishness is your insistence on trying to tie > the definitions to a localization issue. It was you who established it as a localization issue, very clearly: <quote> > Surely, though, this is not a technical argument against the proposal. Not purely technical, though it presents problems for existing implementors who provide bilingual support. Eliminating bilingual descriptions for the language, country (and UN region) codes leaves implementors in a quandary. </quote> > I haven't specifically discussed "display names"; that is your > assertion, and not my basis for objection. You didn't use the term "display names", but it is clearly implied by your reference to bilingual implementations. > I refer to the > definitions and the need to map to and from those definitions > at either end of the communications channel. Whether or not > that happens by "display" is incidental to the issue of the > number of languages that the definitions are provided in. Definitions in multiple languages are not a requisite to establishing the denotation of a coded element. There are widely-adopted coding standards that establish denotations using one language only. In this case, though, the denotations of ISO IDs is established by the ISO standard (and particular version of that standard) from which they were obtained. The registry contains a description that dismbiguates which ISO definition is to be used, but is not a replacement for the ISO definition. Peter Constable Microsoft Corporation _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
