RFC3066bis: looking ahead

[jcowan at reutershealth.com]

Addison Phillips [wM] scripsit:

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

Cleverly, the ISO 639-3 codes are being allocated not to collide with the 639-2
ones except where the semantics is the same (English is "eng" in both, e.g.).

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

Except that the current MA doesn't think that's within their remit.  ISO 3166
is a set of codes for the *names* of countries, and not for the countries
themselves.  New name, new code.

The 3-digit codes for countries, OTOH, are assigned by the U.N. Statistics
Division, and they do designate the countries directly: they only change
when countries merge or split.  So the Right Thing for Serbia & Montenegro
might be to use the code 891.  Old unsplit Yugoslavia had the code 890,
so there's no ambiguity.

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

Well, I don't see that checking for digitness in the subtag is so much worse
than checking for length.  Most apps won't do any of this: they'll just do
prefix matching against a known list anyhow.

-- 
I suggest you call for help,                    John Cowan
or learn the difficult art of mud-breathing.    jcowan at reutershealth.com
        --Great-Souled Sam                      http://www.ccil.org/~cowan