Subject: [Ltru] Re: New item in ISO 639-2 - Zaza

From: "Doug Ewell" <[email-masked]>
Date: Sat, 26 Aug 2006 10:27:49 -0700

Peter Constable <petercon at microsoft dot com> wrote:

> In the course of working on 3066bis, however, I realized that that 
> left a problem. This struck me particularly in the case of Chinese: 
> there is long established usage of "zh", and that usage is ambiguous: 
> it doesn't differentiate between distinct languages like Cantonese and 
> Mandarin. Plus, the IANA registry already had accepted tags of the 
> form "zh-yue" etc.: the initial thought was to treat them as 
> grandfathered anomalies, but of course there's always some preference 
> to have a model in which everything is systematic rather than having 
> ad-hoc anomalies.

This was pretty much my understanding all along, and I thought the 
question of whether we should use extended-language subtags for this 
scenario had been settled long ago.  That was why we went to the effort 
of defining them and setting up examples in RFC 3066bis even though no 
such subtags were actually going to exist until 3066ter.  I'm really 
surprised that we are rethinking this now and considering not using 
extlangs at all.

> rather than try to force the clumped items in 639-2 into a more 
> granular inventory, we could accept them as they are: ambiguous clumps

I know I'm supposed to understand intuitively whether "more granular" 
means "more finely grained" or "more coarsely grained," but it never 
works for me.  In photography a "grainy" image is one where the grains 
are coarser and clearly visible.

Later:

>> At the moment, we have no such option: if the various RAs and MAs add 
>> a new code element, we MUST add it to the registry.  The most we can 
>> do is deprecate it on the spot.
>>
>> If we want to add the option to reject (and I'd be nervous about 
>> it -- this list could in future be captured by Not Invented Here 
>> bigots), we need to add it to 3066ter.
>
> I suggested it for 3066bis, but either most weren't interested or the 
> focus was on other issues at the time.

We were trying to avoid accusations of "cherry-picking" the ISO code 
lists, adopting the code elements we "liked" and ignoring the others 
without justification.

We already do have a mechanism to reject -- more accurately, decline to 
create -- new subtags if they would conflict with existing ones.  That 
is as close as we currently get to solving this problem.

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

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

---

From: "Peter Constable" <[email-masked]>
Date: Sat, 26 Aug 2006 12:36:52 -0700

> From: Doug Ewell [mailto:[email-masked]]

> lists, adopting the code elements we "liked" and ignoring the others

Right; I remember "cherry-picking" being referred to. Mind you, I never considered it that, as I had in mind a particular justification: rejecting by rule any new 639-1 IDs for addition to the subtag registry where an alpha-3 from 639-2 already existed would eliminate a potential source of instability in language tags.

Peter Constable