Region subtags under 3066 and 3066bis (long)
nobody at xyzzy.claranet.de
Mon Feb 21 16:46:33 CET 2005
Doug Ewell wrote:
> Nobody "picked" 1974 for anything.
That "nobody" includes me, I didn't know that 3166 "started"
1974. The public list has codes like RA, 2nd RB, RC, etc.
with the year 1949 for the reservation, or at least that's
how I interpreted "R49".
> let's talk about it. This is a philosophical change and not
> just a matter of this arbitrary date versus that one.
"If it wasn't allowed under 1766 and 3066, then don't use it" is
one possible philosophy. Excl. the private use codes allowed by
the 3066bis draft - not necessarily a good idea.
> Are you reading what I'm writing? The great likelihood is
> that there will not BE a future RH, or a future BQ, or any
> of these.
Reading is not believing after AI, CS, GE, SK. For ISO 639
there's an explicit statement quoted in RfC 3066 and 3066bis.
For ISO 3166 I didn't know that they consider to change their
> The latest draft revision proposes reserving withdrawn codes
> for 50 years before reusing them
JFTR, for FQ that would mean that they could reuse it 2029, for
VD it's 2025, and for NH 2030.
> 200 is a "previously used code" in UN M.49. It was the only
> alternative for encoding the former Czechoslovakia, which
> there is a perceived need to do, short of inventing our own
> code, which we most certainly don't want to do.
It's of course a nice example for the future 3066bis procedure,
and as motivation for the "region" entries in the new registry.
But it's not strictly necessary for the affected languages.
> We have the old PC because there is no new PC.
Based on your 1974 philosophy, yes. I mentioned 582, because
it's like 200 for a later start date based on [ISO 3166:1988]
as in RfC 3066.
> The old GE is not in the registry.
Okay, whatever GEHH 296 (KI+TV) instead of say GEKI 296 means,
you have the new AI, CS, GE, and SK.
> The code change from YU to CS had nothing to do with the plot
> of land. It had to do with the *name* of the country. ISO
> 3166 is a standard for encoding the *names* of countries, not
> for encoding the countries themselves (unlike UN M.49).
If they say BUMM, CSHH, DDDE, GEHH, VDVN, YDYE, and YUCS, then
they must have a reason to do so. Obviously they use XXHH for
1:n relationships, and XXYY for 1:1 or m:1 relationships. And
BYAA is something else.
If you insist on DD (278) without canonical DE, you would have
to add 280 for the old DE, both parts of the new DE (276). The
same reasoning would require 886 for the old YE, the new YE 887
includes YD + 886.
(Un)fortunately there's no UN number for an old VN minus VD.
[3066bis problems with too many dimensions]
>> As in en-boont, en-Latn-boont, en-US-boont, en-Latn-US-boont
> I've seen this claim before. What exactly is the problem?
The proposed matching algorithm failed to match en-boont with
en-US-boont etc. Maybe en-*-*-boont would work, I'm not sure.
> language variations within a country are one of the
> motivations for adding variant subtags, which you didn't
> seem to like.
I've no problem with en-boont and maybe en-Latn-boont, adding
US confuses it. Of course there are cases like de-CH-1996 or
en-GB-oed, where the old notation had a real meaning, but in
theory en-oed could be good enough. For de-1996 it's not so
simple, maybe de-1996 and de-sz96 (without and with ß)
> I'll accept the possibility that the population of a future
> FQ will end up hating me. As they say in Hollywood, there's
> no such thing as bad publicity.
Probably they just use their FQ and ignore any RfC saying that
that's a bad idea. Maybe I would ignore it for GG / IM / JE.
More information about the Ietf-languages