Subject: [Ltru] Re: UN region code list change

From: "Doug Ewell" <[email-masked]>
Date: Sat, 16 Jul 2005 09:51:17 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

>> Basically true, for codes that represent countries.  Early this year
>> they split one macrogeographical code into two.  I have no idea how
>> often that sort of thing happens, but in the future it will result in
>> two new subtags.
>
> I hope you mean two *potential* new subtags.  There would be no reason
> to register either of the new codes as language subtags unless they
> were useful for distinguishing language varieties.

My reading of Section 3.2 of draft-registry is that such new codes would
be added more or less automatically, unless there were a conflict with
existing subtags.

The alternative would be to require ietf-languages to determine whether
a newly assigned UN code is "useful for distinguishing language
varieties."  I don't know if they or we are in a position to do that.
Certainly we have assumed that to be the case for all of the existing
codes, including 001, because we add them all to the initial registry.

> Presumably the original code could continue to be used as a subtag,
> particularly if it more accurately characterized some linguistic
> phenomenon of interest.

Of course, the original subtag is not removed or deprecated.

Let's use the recent case of "South-central Asia."  Originally (for our
purposes) this was one region, coded as 062.  Recently the UNSD split
this into "Southern Asia," codes as 034, and "Central Asia," coded as
143.  If this split had occurred after Date B, the Reviewer, upon seeing
that 034 and 143 did not conflict with any existing subtags, would
presumably add them.  Note that region subtag 062 would remain in the
registry, and users who regard "South-central Asia" as most accurately
characterizing their linguistic phenomonon would be able to continue
using that.  (There is also 142 "Asia" for those who prefer that.)

Because this split happened *before* Date B, and the rules are to
register only those UN codes valid as of Date B, we don't actually
register 062.  Doing so is not necessarily for backward compatibility of
language tags, because unlike ISO 639 and 3166 codes, these UN thingies
were not previously valid in language tags.

> One of our objectives here was to insulate the users of language tags
> from churn in the sources.

We insulate them from the worst kinds of churn: codes that are changed
and deleted, thus invalidating existing tags, and (worst of all) codes
that change their meaning.  We don't necessarily insulate them from
newly created codes.  Those actually give them more flexibility.

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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 16 Jul 2005 11:19:02 -0700

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, July 16, 2005 9:51 AM
> Subject: [Ltru] Re: UN region code list change
>

> be added more or less automatically, unless there were a conflict with

You're right, but the split codes in no way *displace* the existing code.
The new subtags would not affect any existing data, unless the
owners of that data felt the split code(s) for some reason better
reflected their needs.  Consequently, I still think there's no problem.

> codes, including 001, because we add them all to the initial registry.

I think it's too late for such a change, and don't want to propose one.

> Of course, the original subtag is not removed or deprecated.

Great.  This is my main point.  Disregard the rest as the result of
typing past my bed-time.  :-)

> using that.  (There is also 142 "Asia" for those who prefer that.)

This is as it should be.

> were not previously valid in language tags.

Suboptimal, if there are any languages for which this code would be useful.
However, I can live with it if the rest of the group can.  We discussed this
before on the mailing list.  (Issue #1034)  The resolution that was agreed
is in http://www1.ietf.org/mail-archive/web/ltru/current/msg02404.html
The only nagging concern I have is that someone might need 062, and we'd
have no way to put it in, but if this doesn't bother anyone else, ok.

> newly created codes.  Those actually give them more flexibility.
...

All good.  I'm just overly worried about the codes that got left out.  :-)

Randy