Anomaly in upcoming registry

Doug Ewell doug at
Tue Jun 30 14:55:00 CEST 2009

Mark Davis ? <mark at macchiato dot com> wrote:

> 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.

This makes it sound as though 'sh' would not be in the Registry if we 
didn't un-deprecate it.  It's there, just as it always has been, but 
with a note stating in essence that it is best not to use it.  Senders 
are still permitted to create it; receivers are still required to treat 
it as valid, just like any other deprecated tag or subtag.

If we do make this change, is it likely to be perceived as a political 
statement about the identity of "Serbo-Croatian" versus the individual 
languages as coded in ISO 639?  (Remember I'm one who believes they are 
all dialects of the same language, but ISO 639 has decided differently.) 
Think of the controversy when 'mo' was deprecated in favor of 'ro'.

I hope this change is at least being suggested because it is considered 
in the best interests of BCP 47 language tagging, not because some other 
mechanism (ICU or CLDR or some other locale mechanism) requires 'sh' to 
be un-deprecated for "completeness" or because a tool can't cope with 
one deprecated subtag having the Macrolanguage property.

Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14  ˆ

More information about the Ietf-languages mailing list