Subject: [Ltru] Re: Comment: use VU for Vanuatu

From: "Doug Ewell" <[email-masked]>
Date: Sun, 10 Apr 2005 14:31:07 -0700

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

> In fact Jefsey said somewhere that he wants all the old codes
> (pre-1988) back.

I thought we'd resolved that already, but I see that ticket #895 was
never resolved:

http://www1.ietf.org/mail-archive/web/ltru/current/msg00749.html

I'll respond to that separately.

> Anyway, Addison's example about NH and VU
> was fictitious, asuming that we have NH today, and later it's
> changed to VU, and still later changed again to XX.

OK, you're right.  I'm getting confused by the example, which pretends
we are not following the Date A/B principles I thought we had agreed on.

So let's recast the example, with our Date A changed back to 1974 to
accommodate the New Hebrides/Vanuatu example, but with all other
historical facts intact.

There is a current ISO 3166 code element, VU, that stands for Vanuatu,
and another code element, NH, that stood for New Hebrides but was
withdrawn by ISO 3166/MA in 1980 in favor of VU (due to its independence
and name change).

So there would initially be two region subtags:

%%
Type: region
Subtag: NH
Description: New Hebrides
Added: 2004-07-06
Canonical: VU
Deprecated: 1980-01-01
%%
Type: region
Subtag: VU
Description: Vanuatu
Added: 2004-07-06
%%

Now let's jump to the future.  Suppose that on January 1, 2006, the
government of Vanuatu decides to change the official name of the country
to "Vonuatu" with an O, perhaps choosing a form used in one of the
country's minority languages instead of Bislama.  Suppose that ISO
3166/MA goes along and changes the code element from VU to VO.

Then, pending clerical review by the Language Subtag Reviewer, assisted
by ietf-language, a new, NON-CANONICAL region subtag would be added to
the registry:

%%
Type: region
Subtag: VO
Description: Vonuatu
Added: 2006-02-19
Canonical: VU
%%

Ah, but what do we do about the Deprecated field?  Section 3.1 says that
a subtag with a Canonical field MUST also have a Deprecated field.  Yet
the new ISO 3166 code element VO has certainly not been "deprecated" or
withdrawn by ISO 3166/MA; rather, that body has withdrawn VU.  It is the
Language Subtag Registry that keeps VU as the canonical value and makes
VO an alias, just like NH.

The existence of a Deprecated field at all is part of the recent
reconstruction of Section 3.1, and I consider it an inconsistency rather
than a change or disagreement about the policy of subtag stability.
There are two ways to solve this problem:

(1)  The draft should specify that subtags that are born non-canonical,
such as VO, must have a Deprecated date equal to the Added date.  That
is, the Deprecated date for such subtags represents the date the subtag
was deprecated *within the registry*, not within the related ISO
standard..

OR

(2)  The draft should remove the requirement that all records with a
Canonical field must also have a Deprecated field.

-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: Mon, 11 Apr 2005 00:29:48 +0200

Doug Ewell wrote:

> I see that ticket #895 was never resolved:

As far as I'm concerned it is resolved, all pre-date-B issues
were resolved by your date-A = 1988 proposal.  No idea why
Jefsey wants to keep it open or reopen it, or why Randy didn't
mark it as closed yet. <shrug />

> I'm getting confused by the example, which pretends we are
> not following the Date A/B principles I thought we had agreed
> on.

Yes, I'll ignore anything before date-B until somebody changes
date-A (please don't).

> There is a current ISO 3166 code element, VU, that stands for

ACK.  And in theory there could be an old code say NH with a
canonical value VU.  No problem, anything after date-A and
before date-B works as designed, we've lost three old regions
200, 280, and 720 automagically, but it's no serious problem
in these cases.

> Description: New Hebrides

Exactly.

> change the official name of the country to "Vonuatu" with an
> O, perhaps choosing a form used in one of the country's
> minority languages instead of Bislama.  Suppose that ISO
> 3166/MA goes along and changes the code element from VU to VO

Yes, that was the point.

> Canonical: VU

Yes, and that's IMHO ugly, it would be better to accept VO as
the new canonical value and do something like this:

| Type: region
| Subtag: NH
| Description: New Hebrides
| Added: 2004-07-06
| Canonical: VO
| Deprecated: 1980-01-01

Keeping NH as it was (canonical VU) is also possible, but less
obvious, because what I really want is:

| Type: region
| Subtag: VU
| Description: Vanuatu
| Added: 2004-07-06
| Deprecated: 2006-02-19
| Canonical: VO

You had some nightmares about changing all old VU tags and even
applications, but that's unnecessary, even old NH tags (in this
fictitious date-A example) are still valid and only deprecated.

My nightmare was a later attempt to reuse VU for something else
by ISO 3166-1, where some taggers could try to use the new VU,
which is NOT the same as VO.

> Section 3.1 says that a subtag with a Canonical field MUST
> also have a Deprecated field.

Now we're on the same track, that's why Addison introduced this
example.  We cannot insert a "Deprecated: 2006-02-19" into VU
while VU is still canonical elsewhere (NH and VO), and we
cannot insert "Deprecated: 2006-02-19" in VO, because VO is in
fact only "new" but not "canonical" in your version.

With my idea ("canonical" follows ISO 3166-1 until that's not
more possible, and then it uses the UN numbers) it should work.

> (1)  The draft should specify that subtags that are born
> non-canonical, such as VO, must have a Deprecated date equal
> to the Added date.

That's weird, please don't.

> (2)  The draft should remove the requirement that all records
> with a Canonical field must also have a Deprecated field.

Better, but not good enough for my SK-GE-CS-nightmares.  So my
idea is:

(3) Whenever ISO 3166-1 introduces a new region code which is
    not already in the registry, it's added to the registry.

    Otherwise the UN number is added.  In both cases the added
    code is the canonical value, all former codes for the same
    region are deprecated.

And pray that we don't get into trouble with major discrepancies
between the ISO 3166-1 concept of regions and the UN concept (TW
is a fair warning for us).
                           Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 11 Apr 2005 01:57:20 +0200

>mark it as closed yet. <shrug />

I documented that. We started using ISO 3166 in 1977 unformally (what 
permitted UK) and formally in 1978. As documented on this list langtags 
cover much more than XML and even IETF matters. The system must be 
consistent with any ISO 3166 table, concerning whatever period of the past, 
present and future. The 1988 could have been used to pre-load data (and I 
agreed then to the idea), but the way the things are understood now, make 
plain that there is a confusion between an occasional file and a principle.

There is no point in the Charter opposing that. Languages are not born in 
1988.
I documented that I favor the use of a 2 bytes yearly code, covering years 
-32.000 to +32.000
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Apr 2005 04:51:07 +0200

JFC (Jefsey) Morfin wrote:

> We started using ISO 3166 in 1977 unformally

I've no idea who this "we" is, and I don't care who it is, but
if your TINW still uses ISO 3166-1 today, then it does not use
any ISO 3166-1 alpha-2 codes deprecated in the stoneage before
date-A.  Your TINW also doesn't use crap like BU, DD, VD, or
the old CS today, because your TINW would be in deep shit for
the new CS, the new GE, the new SK, and so on.  If your TINW
uses ISO 3166-1 today, it either uses the valid codes today, or
it uses its own private vision derived from an old ISO 3166-1.

Please no courtesy copies, I read the list and don't want it
partially mirrored in my inbox.  TINW = "there is no we", bye.