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

Bruce Lilly blilly at
Wed Dec 15 15:44:41 CET 2004

>  Date: 2004-12-13 02:05
>  From: "Peter Constable" <petercon at>
>  To: ietf-languages at, ietf at

> > > If for whatever reason ISO and the UN decided that "US" should
> > > be used to designate the country of France[...]

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

> This scenario is not hypothetical; it actually occurred in the case of
> CS.

In the case of "CS", but *NOT* "US" a country had quite
some time earlier ceased to exist.  That is what makes
your "US" scenario hypothetical.

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

That is precisely what would be repeated, and the problem
would remain.  "CS" currently means "Serbia and Montenegro",
and its use in accordance with RFC 3066 has precisely that
meaning.  Changing "CS" to mean something else at some
future time (if/when the proposed draft goes into effect)
would result in at least as many different definitions as
exist at present, and adds yet another time epoch that
needs to be considered in order to determine the meaning
of "CS".

> > > 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?),
> It is not uncommon for users to confuse "JA" and "JP". 

Which clearly demonstrates why mere codes in the absence
of definitions associated with the codes is a pointless
proposition. And it illustrates the fact that the only
practical way for a code to become associated with a
particular piece of text is by way of the associated
definition (or something derived from it) rather than

> > > As for what is silly, if the UN country ID for Canada changed to
> > > CN (and that for PRC changed to something else)[....]

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

Last time I checked, "US" didn't mean France, and "CN"
didn't mean Canada -- I suggest that you might want to
brush up on the definition of hypothetical, as it is
difficult to have a rational discussion unless we're in
agreement on basic definitions (just as it is difficult
to have effective communications about what language is
indicated by a code without agreement on the *definitions*
of the codes).

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

But the current meaning under RFC 3066 is quite different.  What
about maintaining the "stability" of that meaning?

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

Your inference (which you incorrectly claim as my implication)
is different from my claim.  My claim is that under RFC 3066,
the definitions of the country and language codes is available
in two languages (yes, it's true -- but irrelevant to that
point -- that the IANA registered complete tags do not have
that characteristic), and that the proposed registry would
lack that characteristic of the current BCP (unnecessarily).
> > 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.

True but irrelevant to the point.  We now have definitions of
specific types of elements (viz. country and language tags) in
multiple languages, and the objection is to the unnecessary
removal of that characteristic.

Ietf mailing list
Ietf at

More information about the Ietf-languages mailing list