Anomaly in upcoming registry

Mark Davis ⌛ mark at
Mon Jun 29 23:35:42 CEST 2009

Good point; the target for 639-1/2 is different, and the threshold for
deprecation is different. And given this conversation, I think it is pretty
clear that we should un-deprecate sh in the registry; we are following 639-3
in not being restrictive about the codes we add (understatement) to the
registry, they considered the issue of deprecating hbs (=sh) and decided not
to, so we should follow their lead.


On Mon, Jun 29, 2009 at 13:22, John Cowan <cowan at> wrote:

> Mark Davis â?? scripsit:
> > hbs = sh, yet
> > hbs is not Deprecated, and
> > sh is Deprecated
> It's actually worse than that.  hbs in 639-2 is deprecated ("retired"),
> but hbs in 639-3 is not deprecated.
> > We could take ISO 639-3 as superseding 639-1 on the issue of deprecation,
> > and I think that would be the right thing to do. However, it would be
> > cleaner yet if ISO 639-1 were to un-deprecate sh, so that it was
> consistent
> > with ISO 639-3.
> For "639-1" read "639-1 and 639-2".  But there's a policy question here:
> coding a language in -1 or -2 is a policy decision, not merely a technical
> one: it involves an explicit value judgement on which languages are
> considered
> important enough to get -1 codes or membership in the -2 set.  The various
> RAs
> reserve the right, it seems to me, to change their minds about this (as we
> reserve the right to ignore it when they remove codes).
> --
> My corporate data's a mess!                     John Cowan
> It's all semi-structured, no less.    <>
>    But I'll be carefree                        cowan at
>    Using XSLT
> On an XML DBMS.
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Ietf-languages mailing list