RFC3066bis: looking ahead

[Addison Phillips [wM]]

> Just to get the terminology straight, you are talking about
> 3-letter alphas
> from ISO 3166-1.

Yep. Slip of the brain.

> > The lang subtag isn't at issue here, as it isn't the lang code
> > that's the problem. It's the secondary tag. If ISO639-3 can identify a
> > language exactly, then it can appear in the first position.
>
> It *can* identify languages exactly.  The difficulty is in
> providing backward
> compatibility with systems that don't understand 639-3.  Let us
> suppose that
> the 639-3 code for Cantonese will be yue.  Then the tags "yue"
> and "zh-yue"
> would mean the same thing, but the first would be meaningless to
> systems that
> don't recognize it, whereas the second would at least be recognizable as
> a possible variety of "zh".

Okay, that makes sense to me. Now I understand what you and Peter are
saying. Even so: the problem here is that if ISO639-3 codes are alpha-3 and
ISO639-2 codes are alpha-3 and there is abundant data already tagged with
the perfectly legal ISO639-2 tags, then we need to separate the ISO639-3
tags from those tags anyway, right?

>
> All that's needed to allow both yue and zh-yue is to rule out
> 3-letter alphas
> from 3166-1, which are currently required only where a 2-letter alpha is
> ambiguous over time.  Using forms like "CS1" solves this problem.

At the expense of reintroducing the need to create and maintain an IANA
registry to register the values and track assiduously the activities of
ISO3166MA/RA, past, present, and future. In the current draft, as discussed
here previously, we only need to deal with cases of double-ambiguity (that
is, both the alpha2 and alpha3 code are ambiguous). If ISO3166 can be
convinced not to reassign alpha-3 codes, then there is no need for any IANA
registration stuff or digits. That has to be preferable.

Besides, I dislike having to peek inside tags to know what they are when we
have a design that doesn't require any peeking currently.

Addison