Anomaly in upcoming registry

Doug Ewell doug at
Thu Jul 9 06:04:47 CEST 2009

Mark Davis ⌛ wrote:

> There are two reasons for having a non-deprecated sh. First, the 
> equivalent hbs is in ISO 639-3, which we are taking as a basis for our 
> expansion in many ways. Having that one macrolanguage be deprecated is 
> just anomalous.

What's anomalous is for 'sh' to be deprecated in ISO 639-1 but for the 
equivalent 'hbs' not to be deprecated in 639-3.

'sh' was given the Deprecated status in the Registry on the basis of its 
status in 639-1.  For us to overturn this decision basically means that 
we consider 639-3 to be a higher authority than 639-1.  I don't see how 
we justify that.

> Second, there is a real use case. According to a good deal of feedback 
> from native speakers in Google, what we call Serbian, Croatian, and 
> Bosnian are really dialects of the one language -- according to the 
> criteria of mutual comprehension. They are really just like the 
> situation with "mo" and "ro".

They are just like 'mo' and 'ro', with the rather significant exception 
that ISO 639 hasn't deprecated 'sr' or 'hr' or 'bs'.  I'm in full 
agreement with you on the linguistic issue, but we follow the core 
standards except where they create an untenable conflict, which this 

> Had we had BCP 47 some time ago (and the right country boundaries), 
> they would have been sh-RS (or maybe sh-Cyrl), sh-BA, sh-HR. Having 
> "sh" as a macrolanguage recognizes that situation, and gives us a 
> neutral general code to express the situation.

We already have 'sh' as a macrolanguage.  As you said many times during 
the course of LTRU development, Deprecated does not mean the subtag 
can't be used.

I won't fight too hard against undeprecating 'sh' if others seem to 
agree with you, but I don't like the potential perception that we're 
second-guessing ISO 639.

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

More information about the Ietf-languages mailing list