[Ltru] Re: Old country codes

["Doug Ewell" <dewell at adelphia.net>]

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
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru