ISO 3166 and RFC 3066bis

Addison Phillips [wM] aphillips at
Mon Jul 19 17:58:10 CEST 2004

A few comments on Doug's comments below.

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

Appendix C in drafts 4 and 5 say that the process is basically that the authors of the draft will provide the converted registry. There should be text that provides a period for review and comment by the community before the registry is adopted, let's say two weeks, since provisions in the draft require that this foundation be stable and thus limits correction of mistakes in the originating registry. Note that draft 4 makes the authors responsible for the work in the conversion task and not the subtag reviewer.

Note that subtags originally excluded or overlooked can be added to the registry later, though. However, to the extent possible, I think this debate should take place now: your prototype registry, Doug, serves a number of useful purposes in completing this project, not the least of which is resolving issues of this type, and this will allow the community to see the shape and nature of the results more clearly.

That way, when the details in the RFC process are complete we can move quickly to implementations.


Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: ietf-languages-bounces at 
> [mailto:ietf-languages-bounces at]On Behalf Of Doug Ewell
> Sent: 2004年7月18日 23:38
> To: ietf-languages at
> Subject: Re: ISO 3166 and RFC 3066bis
> 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
> x
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at

More information about the Ietf-languages mailing list