Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP

From: John Cowan <[email-masked]>
Date: Mon, 13 Dec 2004 09:11:17 -0500

Peter Constable scripsit:

> 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.

Umm, not quite.  The UNSD defines what a "country" is, and assigns it
a 3-digit code (normative) and a name (informative); the ISO 3166 MA
then specifies 2-letter and 3-letter codes for that name.

> 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.

UNSD had nothing to do with this.  It assigned the hitherto-unused code
891 for the country now called "Serbia and Montenegro".  (Yugoslavia
had the code 890, Czechoslovakia the code 200).  This was a reasonable
judgment in the circumstances: the question of when a country has changed
into another country is always fuzzy.  It was the ISO 3166 MA and no
one else who chose to assign the 2-letter code "CS" to the new country.

UNSD historically has assigned new numerical codes when new "countries"
come into existence, and has managed to avoid reusing any of its 3-digit
identifiers, which is precisely why those identifiers are being used as
trusted backups in RFC 3066bis for the unstable ISO 3166 identifiers.

> This is a situation we do not intend to repeat.

Agreed, but let's make sure not to blame the innocent.

> It is not uncommon for users to confuse "JA" and "JP". 

*blush*

I've done it myself, and in implementation, not merely in discussion.
Fortunately, the evidence is now buried.

-- 
John Cowan  www.reutershealth.com  www.ccil.org/~cowan  [email-masked]
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash,
The day and hour soon are coming / When all the IT folks say "Gosh!"
It isn't from a clever lawsuit / That Windowsland will finally fall,
But thousands writing open source code / Like mice who nibble through a wall.
        --The Linux-nationale by Greg Baker

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Deborah Goldsmith <[email-masked]>
Date: Mon, 13 Dec 2004 12:33:25 -0800

And here's hoping they go to four digits or otherwise extend the scheme 
instead of recycling when they run out, a non-hypothetical issue if 
they're already up to 891.

Deborah Goldsmith
Internationalization, Unicode liaison
Apple Computer, Inc.
[email-masked]

On Dec 13, 2004, at 6:11 AM, John Cowan wrote:

> identifiers

---

From: "Peter Constable" <[email-masked]>
Date: Sun, 12 Dec 2004 23:05:42 -0800

> From: [email-masked] [mailto:ietf-languages-
> [email-masked]] 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.

> > 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.

> 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.

"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

---

From: John Cowan <[email-masked]>
Date: Tue, 14 Dec 2004 11:32:02 -0500

> they're already up to 891.

Not much to worry about.  Of 1000 possible codes, currently 232 are
assigned to countries, 32 are assigned to regions, and 10 are retired,
leaving 726 codes yet to be assigned.  I think that provides a comfortable
pad for the future.  It's not obvious on what principles, if any, the
individual codes were assigned.

For the fun of it, the retired codes represent Czechoslovakia,
Ethiopia+Eritrea (then known as Ethiopia), East Germany, West Germany,
the Netherlands Antilles, the Pacific Islands Trust Territories (now
split up), the USSR, Yemen, Democratic Yemen, and Yugoslavia.

-- 
Do NOT stray from the path!             John Cowan <[email-masked]>
        --Gandalf                       http://www.ccil.org/~cowan