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 Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.