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

From: "Doug Ewell" <[email-masked]>
Date: Sat, 25 Jun 2005 10:15:33 -0700

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

> 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.

I really don't like this.  It puts numeric region subtags into a
completely different category from alphabetic ones, for no immediately
obvious reason.

Numeric region codes MAY be useful, are available in an existing
standard, and SHOULD be available for language tagging without the need
for users to register them individually.  We (1) incorporate the ISO
639-1, 639-2, 15924, and 3166-1 code lists automatically, using the Date
A/B rules, and (2) require users to request variants and extensions,
which have no associated standard.  UN M.49 codes should go into
category (1), not a new category of their own somewhere between (1) and
(2).

The only controversy here seems to be whether to allow 062, not whether
the entire class of numeric region codes should be included in the
initial registry.

The problem seems to be that the rules regarding Dates A and B (which of
course don't use that exact terminology) require the initial registry to
use "the date of the standard referenced in RFC 1766."  That is Date A.
Obviously the only ISO standards for which this makes sense are ISO
639-1 and 3166-1; the others didn't exist when RFC 1766 was published.
Instead, for ISO 639-2 and 15924, we use the date of initial publication
of each standard ("the dawn of time").

I don't really know whether UN M.49 existed as such on Date A, and I
would have no possible way of determining what its contents were at any
historical time, since UNSD does not maintain a change-history page on
it.

If we were building the initial registry from scratch now, instead of in
June 2004, region subtag 062 would never have been included, since it
was deleted last January.  OTOH, if we had built it a few years ago,
there might have been some additional codes that we don't have.  How
would we know?  They don't publish a change history.

I promised I would not fight to the death over deleting or keeping this
one subtag, but whatever the solution is, it should *not* involve
discarding all of the UN-based subtags (or almost all of them) and
making users register them one by one.  I think that is major overkill.

Addison Phillips <addison dot phillips at quest dot com> replied:

> It would be possible to do so. The question is whether it would be
> appropriate to do so. The point of incorporating the various standards
> into the registry ab initio is to avoid the need to painstakingly
> review all of the potential items later.

I agree.

> I favor being conservative about the codes we incorporate (on the
> theory that ietf-languages is perfectly capable of resolving whether
> to add any omissions, but that no one is permitted to remove badly
> chosen inclusions), but not to the point of leaving out all of the
> macro-regions.
>
> On that basis I would:
>
> 1. Follow the Date A/Date B rules to create a list of potential
> candidates (i.e. what Doug has already done)
> 2. Remove any that are questionable or controversial.

That would be 062.  We've already removed the others (003, 200, 830
through 833).

> 3. Document in the initial-registry draft which ones those are (that
> is, codes that are valid to register but were not initially
> registered)

Easy enough to do.

> 4. Let ietf-languages and the process be used to incorporate those few
> that are needed from that list (or later assignments) at a later date.

I support this.

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

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

---

From: "Mark Davis" <[email-masked]>
Date: Sat, 25 Jun 2005 11:18:22 -0700

I agree with Doug. My suggestion is that we go with the codes that are valid
now.

‎Mark

----- Original Message ----- 
From: "Doug Ewell" <[email-masked]>
To: "LTRU Working Group" <[email-masked]>
Sent: Saturday, June 25, 2005 10:15
Subject: [Ltru] Re: [psg.com #1034] Add region subtags 034 and 143,delete
062

---

From: r&d afrac <[email-masked]>
Date: Sat, 25 Jun 2005 20:57:14 +0200

>completely different category from alphabetic ones, for no immediately

Doug,
all your arguments are good. They would be better if substantiated by the 
missing definition of what the subtags M.49 should stand for. But would we 
have read the Charter together we would commonly know you are right because 
Charter says: "For extensibility, it is expected that the document will 
describe how generative mechanisms could use ISO 15924 and UN M.49 codes 
without explicit registration of all combinations."
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 26 Jun 2005 16:06:28 +0200

Mark Davis wrote:
 
> I agree with Doug.
> My suggestion is that we go with the codes that
> are valid now.

ACK, that was the idea of date-B == NOW instead of
date-B == 2005-01-01.
                       Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 27 Jun 2005 14:42:32 -0700

Hi -

I've marked issue #1034 as "resolved", since there's been no disagreement
(despite continued postings) since last week.

Randy, ltru co-chair