Subject: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu

From: "Doug Ewell" <[email-masked]>
Date: Sat, 16 Jul 2005 13:52:07 -0700

I support this proposal.

--
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: Sat, 16 Jul 2005 15:33:16 -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.
>
> 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.

I didn't think the split code would displace the existing code.  There
would be one old code and two new codes.  All would become valid as
subtags, and since retagging of existing data is not encouraged, there
would be no problem with existing data.

I'm just saying that the overwhelming likelihood, based on the draft and
what I consider common sense, is that the new codes would be registered
as subtags, more or less automatically, not rejected on the basis that
ietf-languages had some overriding reason to believe they would not be
useful.

>> 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.
>
> I think it's too late for such a change, and don't want to propose
> one.

I didn't suggest a change.  I don't think ietf-languages should try to
make such a determination with regard to codes from core standards.
Proposals to add primary language subtags and variant subtags are where
they need to exercise judgment.

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

062 is no different from any number of mystery codes that UNSD might
have added and removed in the past.  We know about 062 because this
project was started before 062 was removed, but we have no way of
knowing what the others were.