ISO 3166 and RFC 3066bis
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
> User-assigned code elements (AA, QM-QZ, XA-XZ, ZZ) are also no
> problem: they are private-use.
> 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
> 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.
> 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.
> 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
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
> Indeterminately reserved code elements (quite a few) are really not
> part of ISO  at all, but are reserved to avoid collisions with
> systems that are meant to be upward-compatible extensions of ISO
> . 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).
> Code elements not used at the present stage are WIPO codes for various
> transnational intellectual property associations. They are reserved
> and unused in ISO , but this may change in future. They have
> nothing to do with languages anyhow.
> Unassigned code elements are obviously not usable.
More information about the Ietf-languages