ISO 3166 and RFC 3066bis

Doug Ewell dewell at adelphia.net
Mon Jul 19 08:38:11 CEST 2004


Way back on June 22, John Cowan <cowan at ccil dot org> wrote:

> I think the different types of code elements in the ISO 3166-1 code
> space ought to be straightened out with respect to their usability in
> RFC 3066bis.
.
I agree completely.  Let's square it away now.

> Officially assigned code elements are no problem: RFC 3066bis can use
> them.
>
> User-assigned code elements (AA, QM-QZ, XA-XZ, ZZ) are also no
> problem: they are private-use.

True.

> Exceptionally reserved code elements (AC Ascension Island, CP
> Clipperton Island, DG Diego Garcia, EA Ceuta and Melilla, EU the
> European Union, FX metropolitan France, GG Guernsey, IC Canary
Islands,
> IM Isle of Man, JE Jersey, TA Tristan da Cunha, UK United Kingdom)
> don't have clear status in RFC 3066bis (or any predecessor).  UK is
> problematic because it is a synonym for GB, but language varieties
> like en-TA and es-IC represent sensible notions.  IMHO, RFC 3066bis
> should say which of these can be used.

Of these, only FX is valid in RFC 3066bis, because it was once a real
ISO 3166-1 code before being removed in 1997.  AFAIK, the rest are not
valid, but as John said, perhaps some should be.

Addison responded:

> Okay. That sounds reasonable. I can add an instruction for the
> conversion of the registry. IMHO, these should be special cases.

Should this be up to the Reviewer at registry-conversion time, or should
it be debated here?

> Transitionally reserved code elements (BU Burma, NT Neutral Zone
> [whose?], SF Finland, SU U.S.S.R., TP East Timor, YU Yugoslavia, ZR
> Zaire) are officially available in RFC 3066bis.  I'm a little troubled
> that sites allowing Finland-Swedish (sv-fi) must be prepared to accept
> the bizarre sv-sf as well, given that sf has been deprecated since
> 1995 and may be reassigned at any time. in which case we would be in
> the silly situation that both the well-known fi and the unknown sf
> would be usable, but the new sf would not.

I thought SF would not be valid, because it is not listed in ISO 3166-3
and hence was removed from 3166-1 sometime before 1974.  (The rest are
valid not because they are transitionally reserved, but because their
presence in 3166-3 shows they were once 3166-1 codes.)

If we even need to allow SF for Finland, such that the *decoding table*
is necessary to help identify valid region subtags, then that proves
once and for all that a comprehensive registry is needed.

Addison replied:

> The problem here is the slippery slope. Do we obsolete data that uses
> these defunct names or regions, just because it isn't likely that
> we'll create more data. I'm in favor of deprecating the old codes, but
> banning them seems suspicous. If CS was a bad decision, why is SU, YU,
> BU, TP, etc. a good enough one to allow in? The obvious problem here
> is that, given an alpha2 namespace for ISO 3166 to work with and a
> reasonably desire for mnemonicity (is that a word??), it won't be that
> long before we have a healthy list of UN M49 numbers resulting from
> reassignments.

I don't think 3166/MA will reuse code elements all that frequently, at
least not any more, with all the bad publicity.  But of course it can
happen.

> Indeterminately reserved code elements (quite a few) are really not
> part of ISO [3166] at all, but are reserved to avoid collisions with
> systems that are meant to be upward-compatible extensions of ISO
> [3166].  They are not supposed to be used except in those particular
> systems.  RFC 3066bis should exclude them.

> I assume that reserved codes that aren't assigned are codes that are
> not assigned (and thus banned).

I agree.

> Code elements not used at the present stage are WIPO codes for various
> transnational intellectual property associations.  They are reserved
> and unused in ISO [3166], but this may change in future.  They have
> nothing to do with languages anyhow.
>
> Unassigned code elements are obviously not usable.

I agree.

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




More information about the Ietf-languages mailing list