Subject: [Ltru] Re: "Obsolete" region subtags

From: "Doug Ewell" <[email-masked]>
Date: Wed, 16 Mar 2005 08:27:15 -0800

Frank Ellermann <omniplex at freenet dot de> wrote:

>> I think that the draft as it sits embodies most of your
>> suggestion anyway.
>
> For a "clean" start date like 1995 (RfC 1766) they'd be almost
> identical, maybe minus the five notorious ccTLDs.  And they'd
> stay that way for at least 5 years + 1 day.   Or at least 50
> years if ISO 3166 adopts this transition period for old CCs.

We have tried to be consistent in following ISO 3166 in the initial
draft registry.  AC, GG, IM, JE, and UK are *not* officially assigned
ISO 3166 codes.  They are ccTLDs, and they have been reserved by ISO
3166 for possible future assignment (except UK, which is reserved to
*prevent* it from being assigned).

It is possible that ISO 3166/MA will assign these codes at some point in
the future with the meaning we currently expect.  Or, it is possible
that they will shift gears and assign them to some completely different
entity.  Remember that the alpha-3 code ROU was once reserved, because
of its use for "Republic of Uruguay" in another context, and was
subsequently assigned to Romania.  "Reserved" is no guarantee of
anything.

> The earliest differences could then creep into the registry
> after 1995 +50 = 2045, if ISO 3166 is forced to recycle an old
> country code.  With your startegy 3066bis would then stick to
> the old 1995 CC, my strategy would allow to follow ISO 3166.

The whole point of mapping ISO 3166 to region subtags in the registry,
instead of using them directly, is that "following ISO 3166" faithfully
can lead to instability when a code is changed, or worse, reused.  That
is what happened with CS.  The draft removes this instability, at the
expense of breaking with perfect adherence to ISO 3166 if necessary.

Your strategy allows non-ISO 3166 ccTLDs, so that's not exactly
"following ISO 3166" either.

> Both strategies are compatible with RfC 3066, arguably my idea
> is "more compatible", because it lets ISO 3166 do whatever it
> wants, like RfC 3066 does at the moment.

As stated above, letting ISO 3166 do whatever it wants is precisely a
non-goal of the draft.

> Yes, that's what you'd get for a 3066bis start date before the
> split of CS.  Of course you won't pick this date, it would be
> incompatible with today's RfC 3066.  IIRC Bruce found some Web
> pages with a lang= or xml:lang= using the new CS in a 3066 tag.

Yes, and the draft has been changed so that the magic cutoff date will
be the date of publication of the draft.  That ensures compatibility
with RFC 3066 and should close this particular debate.

>> if ISO 3166 doesn't stick to 50-year reservations of
>> withdrawn codes, we will see sporadic creation of numeric
>> UN M.49 codes.
>
> The "we" in Internet community would see it for any transition
> period.  5 years or 50 years doesn't change the necessity to
> find a good mnemonic in ISO 3166-1.  The "we" in you and me
> would probably manage to never see this strange effect, if you
> pick 1995 as start date, and if they don't invent immortality.

"Inventing immortality" is a phrase that is best avoided in this
peaceful and cooperative environment.  What the draft attempts to do is
"enforce stability."

>> Countries will probably take notice of this and try to avoid
>> obtaining problematic codes when they change their names.
>
> New countries won't pick their names only to avoid a frozen CC
> in the 3066bis registry.  If FQ makes sense for say Quebec they
> would go for it, and don't care about any FQ = Terre Adelaide.

Language tags are not the only application that call for more stability
that ISO 3166 has provided thus far.  They received criticism from other
groups as well for reusing CS.  I imagine that in the future, the MA
will take a closer look at avoiding the reuse of codes.

Note that Addison did not say a country would choose its name to avoid a
problematic code, only that they would not request the code itself.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Mar 2005 20:13:41 +0100

Doug Ewell wrote:

> "following ISO 3166" faithfully can lead to instability when
> a code is changed, or worse, reused.  That is what happened
> with CS.

Yes, it was a stupid idea to follow ISO 3166-1 faithfully, they
are forced to reuse old codes if countries want to have a code
somehow reflecting the name of the coutry.  We (or at least me)
only didn't see how stupid this was until the new CS forced us
to think.

The draft tries a compromise, freeze all codes as they are now,
allow new codes not conflicting with "frozen codes", otherwise
use the UN number.  I proposed another compromise, accept that
some old codes must be reassigned sooner or later, and support
UN numbers as "canonical" alternatives where stability is the
most important issue.

In a case like YT they were probably desperate to find a code
for Mayotte, and they only didn't use MA, MO, MT, or MY because
all these codes were already assigned.  And for CS they looked
into their table and found that SA, SB, SE, SM, and CM aren't
free, but the old CS was "free" under their old rules.

BTW, that's strange, I hated CS right from the moment when I
first saw it, and now I'm defending them, because it's really
not their fault if somebody else wants stability where it's
almost impossible.

The country codes aren't arbitrary combinations of 26 * 26 - 42
character pairs, they are generally abbreviations or acronyms.

The draft kills ISO 3166-1 very slowly, one CC after the other
as soon as it's reassigned, drifting away from ISO 3166-1 and
forever listing some then prehistoric codes.  Like the RH in
the actual snapshot of a possible registry.

> Your strategy allows non-ISO 3166 ccTLDs

That's an independent detail, IANA as filter for the ISO 3166-1
input.  This strategy would also work without the five ccTLDs.

Addison's strategy also allows to use IANA ccTLDs as filtered
ISO 3166-1 input, if the draft would say, so that has nothing
to do with the procedure for future changes.

As you said we'd be in trouble if ISO 3166-1 assigns these five
codes to something else.  ICANN would be also in trouble, what
should they do, redelegate e.g. IM against the will of NIC.IM ?

Let's forget my idea of using all ccTLDs for the moment.  Maybe
it's a bad idea.  The best solution for all interested parties
would be to assign AC, IM, GG, and JE officially, but I now see
that a BCP about _language_ tags is not the place to start this.

ISO 3166-1 should do it.  Introducing UK as an alias for GB in
a BCP about language tags is admittedly too odd to consider it,
even if implementations tolerate it as a well-known user error.

> the draft has been changed so that the magic cutoff date will
> be the date of publication of the draft.

At the moment you still have BQ, DD, RH, 200, etc. deprecated
long before 2005, and blocking any future BQ, DD, or RH as CC.

The deprecated 200 cannot block anything, so that's no problem.

Are you sure that you want 172 "commonwealth of indepedent
states" ?  It's not exactly clear what it's meant to be, but
all indepedent states have their own CC, and they all belonged
to the former SU.  172 is apparently SU excl. Estonia, Latvia,
and Lithuania.  It's listed below the "selected economic and
other groupings" as a subdivision of 778 on the UN page.

> "Inventing immortality" is a phrase that is best avoided in
> this peaceful and cooperative environment.

Sorry. it was meant as a joke, with a new 50+ years transition
period we're probably not more here when something odd happens
with a future registry based on CCs 1995.  They could reassign
DY or VD after 2027, blocked in the registry based on 197?.

> They received criticism from other groups as well for reusing
> CS.

Yes, among others I did.  And I was wrong, at least partially.
The IAB said something about 300 years IIRC.  Try to invent a
hypothetical 3166-IAB starting A.D. 1700, it's IMHO impossible.

                      Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Mar 2005 14:39:42 +0900

Hello Frank and Doug,

The two of you are very at easy to discuss the particulars
of some of these country codes. However, I fear that most
people don't remember them as well as you do. Also, some
people may be new to this WG and not have followed the
discussion on the ietf-languages list.

Would it be possible for the two of you (and others, of course)
to provide a bit more of background information with your
discussion? I'm not asking for lengthy discussions, just a little
bit of additional info to help new people.

Many thanks in advance,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 17 Mar 2005 08:48:59 +0100

Martin Duerst wrote:
 
> Would it be possible for the two of you (and others, of
> course) to provide a bit more of background information
> with your discussion?

The "last call" was draft 8.  What we discussed on the
languages list were drafts 9 and 10.  The idea in these
drafts was to define some rules how an existing registry
would be updated.  The start for this registry was the
creation of ISO 3166-1 (about 1974) for country codes
and the introduction of UN numbers (1982).

I didn't know that these were the actual start dates until
Doug told me so, and there was some confusion while I tried
to find out what apparently arbitrary start date he picked.

When that was clear what he had as registry was the result
of applying the draft 9..10 rules on a registry started in
1974.  This had some odd effects for country codes like CS,
the old CZ+SK, but today the successor of the rest of YU.

For compatibility with RfC 3066, which supports ISO 3166-1
CCs as they are at the day when 3066bis is published, the
old CS won't do in an initial registry.

Therefore we were looking for a better start day, the year
of the publication of RfC 1766 (1995) would avoid most odd
effects like old vs. new CS, deprecated RH, DD without a
canonical DE despite of ISO 3166-3 "DDDE", and many more.

That's not yet state of the art, the registry still has
all these relics, where they don't conflict with RfC 3066,
e.g. RH and DD.

The CS issue is settled, that will be the new CS.  It's
not yet clear what to do with the deprecated 200 for the
old CS.  For a start date 1995 or later it wouldn't exist
in the registry.  With the rules of draft 9..10 it also
wouldn't exist, these rules would keep the old CS and add
891 instead of the new CS.  But that's incompatible with
RfC 3066 tags today, where CS is the new CS.

200 is still unclear, it could be introduced as a special
case.  We observed some other peculiar effects with the
rules in draft 9..10:  In some cases country codes must
be "exactly the same territory" as defined by UN numbers.

Therefore DD can't get a canonical value DE, because 278
is not the same as 276, it's only a part of 276 (new DE).

The registry would keep a (deprecated) DD without pointer
to a better value.  OTOH the old DE (with UN number 280)
is implicitly replaced by the new DE (276), and there's
no value at all in the registry for the old DE or 276.

Same problem with VD / VN and YD / YE.  The worst case
YU also has this problem, the old YU (UN number 890)
kept its country code YU (UN number 891), and then the
code was changed to CS.  The registry therefore has a
deprecated YU corresponding to UN number 891.  If there
is a CC the number isn't listed under the actual rules,
and so 891 is not in the registry.

And 890 is also not in the registry, because the change
from YU to CS was later, when the territory was 891.

Old YU tags like sl-YU therefore lost their original
region, and replacing them by sl-SI is not necessarily
correct, maybe sl is also used in parts of HR (Croatia).

sl = Slovenian, SI = Slovenia, 
YU = was Yugoslavia, listed as deprecated value for CS
CS = Serbia and Montenegro

My original idea to avoid all these historic problems
was a start date like 1995.  Apparently Doug now thinks
that this was a good idea in certain cases.  And I now
think that it only hides a general design problem today,
but it could be a similar mess in 100 years.  Bye, Frank