proposed ISO 639 change for "arn"

Doug Ewell doug at
Wed Jan 9 23:35:12 CET 2013

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

> I object. A fundamental goal of BCP47 is stability. This runs the risk
> of introducing the "iw" / "he" problem which has plagued us to this
> day.

BCP 47 doesn't prevent instability in the core standards, nor can it. It
manages instability by deprecating subtags instead of deleting them
outright and leaving them open for reuse, as the standards either do or
formerly did.

ISO 639-3 deletes (withdraws, retires) code elements every year, as part
of its annual change series. Last year they withdrew 28 code elements.
The year before, there were only 9, but in 2010 there were 18, and 38 in
2009. Often this is to split one code element for Able into two code
elements for Able and Baker. BCP 47 handles this instability by
retaining the old Able as an alias for the new Able. It is designed for
exactly this scenario.

Last year, when ISO 639-3 retired the code element 'kpp' for Paku Karen
and created a new code element 'jkp' for Paku Karen, did that introduce
a major instability? If not, how is this different?

> While we did allow for this in extremis, to allow for technical
> conflicts, this is not one of those. See
> 2. Values in the fields 'Preferred-Value' and 'Deprecated' MAY be
> added, altered, or removed via the registration process. These changes
> SHOULD be limited to changes necessary to mirror changes in one of the
> underlying standards (ISO 639, ISO 15924, ISO 3166-1, or UN M.49) and
> typically alteration or removal of a 'Preferred-Value' is limited
> specifically to region codes.

That last bit about "region codes" is there because we anticipated
changes in ISO 3166 code elements in response to changing country names.
We didn't anticipate changes in ISO 639 language code elements,
especially a long-established one, in response to it being rejected
comparatively recently by its speakers as "offensive." That seems to be
the reality, however.

> A major reason for the development of BCP47 was to guard against the
> instability of underlying ISO standards. If iana goes down this path,
> I think the result will be a new standard on top of BCP47 that guards
> against instability in that! Nobody should want that.

Is your preference to have the RA retain 'arn' as a collection or a
macrolanguage, neither of which would have been created but for a desire
to make 'arn' somehow magically go away, which by your own admission
will not happen anyway?

I don't like the idea that after everything we and the RA go through to
honor the 639-3 concept of "macrolanguage," we would encourage the RA to
create an ill-conceived macrolanguage just to have a particular
preconceived effect on the three-letter symbol.

I suspect your preference is as you stated before: no change. I too
would prefer no change; I did put the word "IF" in capital letters in my
post. But if there absolutely has to be a change, I am convinced this is
the right change for the right reason, and the other options are just
playing games.

Doug Ewell | Thornton, CO, USA | @DougEwell ­

More information about the Ietf-languages mailing list