Subject: [Ltru] Re: Old country codes

From: "Doug Ewell" <[email-masked]>
Date: Sun, 7 Aug 2005 08:50:22 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> Since 1999...
>
> Older stuff is their "initial" 3166-3, it's not as old as the
> other parts.  See their iso3166-past-present-and-future page:
> ...
> 3166-3 was created 1997-99, the newsletters cover all updates.
> One of my several "date A" proposals was "5th edition" (1999).

I acknowledge that the free ISO 3166-3 newsletters cover the full range
of updates since 1999.  The standard itself, including all the entries
for 3166-1 codes withdrawn between 1975 and 1999, is not free.

> Somebody here ordered and got it, and IIRC the result was that
> your unofficial source of code changes was complete.

I really should write to Clive Feather and thank him for his clear and
accurate page that served as my unofficial source.

> Nobody cared to
> produce any tags deprecated before 1995, maybe not one exists,
> but we can't be sure.

Well, that's exactly the point: we can't be sure.  More on this later.

>> DY as a historical code element is just as legitimate as TL.
>
> Not in language tags, it was never valid under 1766 / 3066.
> If DYBN was 1977, then it was dead 11 years before 1988, and
> 18 years before RfC 1766.  There are precisely zero reasons
> to find it in the wild in 1766 / 3066 / 3066bis language tage.

You didn't quote me fully:

"But for an application that really uses ISO 3166 code elements per se,
and might have to recognize all previous code elements for its own
compatibility reasons, DY as a historical code element is just as
legitimate as TL."

We are not such an application.  We only care about code elements valid
as of 1988.  The point is that *somebody else* might care about code
elements going back to the original 1974 version, and somebody else
might only care about the ones that are current.  That is why I say it
is only the case that the pre-1988 codes are "crap" because we ignore
them (i.e. they fall before our cutoff date); it is not the case that we
ignore them because they are inherently crap.

>> Older deprecated subtags don't cause any
>> problems that newer (or future) deprecated subtags won't
>> cause.
> ...
> We all discussed this here again and again, of course they
> are a PITA because they are blocked for future "recycling".

I know we had that discussion, as you said, "again and again."  We were
never able to see eye to eye on whether (a) the likelihood that ISO
3166/MA would reuse these codes was greater than (b) the likelihood that
there's a language tag somewhere that uses it, with which we have to
stay compatible.  We'll never know, really.

> Nobody can use any future BU in language tags, because it's
> blocked by the old BUMM.  Unlike DY and NH.   BUMM was 1989,
> one year after "date A", but still before the WWW was started,
> and maybe also before somebody counted 18 letters in I18N.

But after the date of the standard referenced by RFC 1766.

Remember that in 1995, neither ISO 639 RA/JAC nor ISO 3166/MA had a Web
site, and often the only source for these ISO code lists was someone's
private typed-up copy (sort of like Clive's page, but much less
diligently maintained).  Before the Web there were bulletin boards and
the "file areas" of CompuServe forums, where you could get the same
private copies.  These were very seldom updated every time a code like
BU was withdrawn; often the curators of these lists had no way of
knowing there was an ISO change.

There was also a list of ISO 639-1 codes, created and maintained by some
very respected people, that accidentally omitted the codes "ti" for
Tigrinya and "tr" for Turkish, which led me (at least) to think ISO had
somehow omitted these important languages.

And EVEN NOW, there is a list of language codes on the Unicode Web site
that says, in reference to pairs of codes like "he, iw*" where the
latter was deprecated 16 years ago in favor of the former:

"When writing: write the second, (oldest) one - marked with an
asterisk - for legacy applications that cannot manage correctly the new
standard code or for classes of applications for which you are not
certain that they can use the new standard."

So even now, in 2005, there are still plenty of opportunities for users
to find code elements that they don't know have been deprecated, and
apply them in language tags and elsewhere.

>> If you already have to support TP, there is no additional
>> cost to supporting BU.
>
> As far as I'm concerned this error is the main reason why an
> LTRU WG was created.  Plus the "most perverse tag" issue, and
> "Suppress-Script".  Anything else is essentially the same as
> you (= language tag list) already had it in the old last call.

I thought you said before that we had changed lots of things, mostly to
your satisfaction.

--
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: Sun, 07 Aug 2005 19:47:52 +0200

Doug Ewell wrote:
 
> I really should write to Clive Feather and thank him for his
> clear and accurate page that served as my unofficial source.

ACK - after his 240 KB nntpext-base-27 monster draft I won't
forget his name.

> We only care about code elements valid as of 1988.  The point
> is that *somebody else* might care about code elements going
> back to the original 1974 version

Oh, yes, of course.  There's even a group trying to "invent" 
historical codes for obsolete regions.  And I also care about
obscure region codes in my "rxwhois" script, codes like EA, EH,
FX, or existing ccTLDs like AC, AX, etc.

But that's about public whois servers, not language tags.

> We were never able to see eye to eye on whether (a) the
> likelihood that ISO 3166/MA would reuse these codes was
> greater than (b) the likelihood that there's a language
> tag somewhere that uses it

In theory we could compute it, 26*26 - private use codes,
changes over the last 30 years, so far three (?) collisions
with old codes (GE, SK, CS) => one collision per decade, so
let's say in about 1000 years all region codes in language
tags are either numeric or deprecated.

OTOH the frequency of the 1766 / 3066 / 3066bis updates was
shorter than 3166-1 collisions so far.

> Before the Web there were bulletin boards and the "file
> areas" of CompuServe forums, where you could get the same
> private copies.

Yes, but using region codes in laguage tags was invented 1995,
before that time we only had locales like en-UK and of course
ccTLDs.  FidoNet had zone and region numbers at this time, on
top of an older system with only net and node numbers.

> EVEN NOW, there is a list of language codes on the Unicode
> Web site that says, in reference to pairs of codes like 
> "he, iw*" where the latter was deprecated 16 years ago

Yes, one of your pet peeves, I'm more worried about my region
code zoo, because it changes more frequently.  Actually I'm
more interested in TLDs, the problems aren't exactly the same
as for language codes.  Slightly different POV => slightly
different conclusions.  Nobody proposes to use TP instead of
TL, they just need some time for the transition.

> I thought you said before that we had changed lots of things,
> mostly to your satisfaction.

Yes, lots of details like the ABNF, references, record-jar,
etc., but in essence it's still what you had last year.

Plus "Suppress-Script", 2047-compatibility, and better rules
for the region code zoo.  If we still missed something really
important let's hope that the "IETF last call" finds it.  Or
in other words Bruce Lilly ;-)
                               Bye, Frank