ISO 639 and RFC 3066bis

[Addison Phillips [wM]]

John Cowan opined:
>
> > 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 suspicious. 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.
>
> There's a difference between obsoleting codes and reusing them, though
> with a fixed space obsoleting codes eventually implies reusing them.
> I'd say don't allow any codes that were obsolete before some magic date.

That seems reasonable at first glance. The question is: do we create
problems for existing data by disallowing (some of) these codes now? And
separately, old withdrawn codes will most likely be recycled, sooner or
later. A good magic date might be March 1995 (the publication date of RFC
1766), since presumably language tags before that date aren't "real" RFC
3066bis family codes....? (That kills SF, at least).
>
> > I assume that reserved codes that aren't assigned are codes that are
> > not assigned (and thus banned).
>
> I don't understand this sentence.

If a code has been reserved so that it will not be assigned, then that code
is an unassigned code. Unassigned codes are not valid. Thus, reserved codes
are not valid.

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.