Subject: [Ltru] Re: [psg.com #1034] Add region subtags 034 and 143, delete 062

From: "Doug Ewell" <[email-masked]>
Date: Thu, 23 Jun 2005 07:23:24 -0700

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

> I guess what I'm having trouble understanding is this:
> (1) What is the value of deleting UN M.49 codes?

It's not actually being "deleted," despite the subject line of this
thread.  I'm proposing that it be "non-added" to the registry on the
basis that it is not current as of Date B, and can be safely "non-added"
because it has never been allowable in language tags.

Alternatively, we could try to gather a list of all numeric region codes
that UNSD has defined in the past and subsequently withdrawn.  This
would be difficult because they don't maintain a change-history page on
the macro codes.  But there wouldn't be any difference between such a
code, withdrawn 10 years ago when their classifications were different
(for whatever reason), and 062.

> (2) If there is no particular benefit dervied from deletions, why
> bother?

The benefit I see in not including 062 in this case is to be consistent,
and not to admit some withdrawn codes that we happen to know about while
not also admitting others we can't.

> (3) If we delete one, and, in the future, someone discovers they need
> it, how will it be restored?

Again, I don't think of it as being "restored" if it was not in the
initial registry to begin with.  Suppose I need a macrogeographical code
for Northern and Western Europe together (the UN distinction might seem
a bit arbitrary).  I can't register one, but what if UNSD had had such a
code many years ago?  Would we consider that a matter of "restoring" a
deleted code?

> (4) If a mechanism to handle (3) is in place, then why don't we simply
> start with an empty list, rather than fretting over these cases one-
> by-one?

There's only one case I can think of.  UN withdrew one macro code, 062,
before the initial LTRU registry was approved.  It's never been valid in
language tags, so we don't have to preserve it for backward
compatibility.  If UN ever does this again, say by splitting Northern
Europe into "Scandinavian" and "non-Scandinavian" parts, the old code
154 would still be retained in the registry because it was once valid in
tags.

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

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

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 23 Jun 2005 07:28:24 -0700

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

> They're not deleted in the tag registry, once in (reflecting
> the "valid at date-B" state), forever in.  If they'd delete
> e.g. 419 after date-B it won't affect valid es-419 tags.
>
> Many possible reasons why they might want to reorganize their
> macro-regions, as we have seen for the old 003, 062, and 830.

Exactly.  But I don't propose future deletion of subtags that have been
valid in RFC 3066bis language tags in the past.

>> (2) If there is no particular benefit dervied from deletions,
>>     why bother?
>
> Because the draft says so.  Nobody is interested in obsolete
> UN macro-region numbers for say the former SU excl. EE/LT/LV,
> we even have a (deprecated) SU for those who think to need it.

Deprecated subtags like SU aren't there so that people can generate them
today, for new content.  They're there so that tags for existing content
don't suddenly become invalid.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 24 Jun 2005 12:14:12 -0700

Hi -

As a technical contributor...

Since the registry draft (section 2.2.4 of -06) gives the rules specifying
whether a given UN M.49 code may be added to the registry, wouldn't
it be sufficient for the purposes of the initial registry to just
supply the one such code (419) that is currently needed, leaving
requests for the addition of others up to those who find a use for
them?  This would allow us to sidestep all this discussion of the
merits of individual codes on this list, moving it to ietf-languages
when our work is approved, where such discussion properly belongs.

Randy