Anomaly in upcoming registry
Mark Davis ⌛
mark at macchiato.com
Mon Jun 29 05:09:23 CEST 2009
I agree that this is an anomaly inherited from ISO, so in the best case the
part1 and part3 would both go one way or another. Let's revisit this once
the new version comes into force; there's nothing we can do anyway until
On Sun, Jun 28, 2009 at 19:48, Doug Ewell <doug at ewellic.org> wrote:
> Mark Davis <mark at macchiato dot com> wrote:
> > In the registry, we have 'sh' as Deprecated. Once we update to 639-3
> > with the new registry and version of BCP 47, I think it will be time
> > to fix this, removing the "Deprecated" field from 'sh'. I'll plan on
> > submitting a Registration Form to that end.
> This was largely intentional in draft-4645bis, because the code element
> was deprecated in (or withdrawn from, they use both terms) ISO 639-1.
> Part of it may have been a side effect of overlooking the change from
> RFC 4646, where a Deprecated field in the Registry could never be
> removed, to draft-4646bis, where it can.
> Quoting from the ISO 639-2 change page:
> "This code was deprecated in 2000 because there were separate language
> codes for each individual language represented (Serbian, Croatian, and
> then Bosnian was added). It was published in a revision of ISO 639-1,
> but never was included in ISO 639-2. It is considered a macrolanguage
> (general name for a cluster of closely related individual languages) in
> ISO 639-3. Its deprecated status was reaffirmed by the ISO 639 JAC in
> The real anomaly, then, is within ISO 639, in which:
> part 1 includes the 2-letter code element but deprecates it,
> part 3 includes the 3-letter code element and does not deprecate it, and
> part 2 does not include the 3-letter code element at all.
> In draft-4646bis we are adding ISO 639-3 to the list of source
> standards, not necessarily replacing ISO 639-1 and -2. At least I can't
> find any text in draft-4646bis to the effect that -3 trumps -1 and -2 in
> case of conflicts. So to me, it is not clear whether this subtag should
> be left alone (following part 1 but not part 3) or should be
> un-deprecated (following part 3 but not part 1). It certainly isn't
> patently obvious to me that this is a bug in the draft-4645bis Registry
> that needs to be fixed.
> Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
> http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ietf-languages