FYI: ISO 639-5 reconfirmation ballot

Mark Davis ☕️ mark at
Sat Jul 16 07:14:20 CEST 2016

I disagree. If it is withdrawn, and replaced by something else, it still
orphans the codes in the language registry. And if it is replaced by
something that doesn't use the same namespace (a statement like "why use
alpha-3 codes which look identical to language codes?" is worrisome) it
will cause no end of confusion in implementations.

> And it is nowhere near complete enough to be useful.

It should be fleshed out, in that case. Clearly linguists may also need a
more elaborate structure, with more information that would be of little
interest to lay people. And for that it could be useful to have an
*additional* part.

But there would be value value to providing standard 3-letter code to
complete the common groupings like those under "Language Family" on the
right page of, even when the
categorization changes over time.


On Sat, Jul 16, 2016 at 6:23 AM, John Cowan <cowan at> wrote:

> Peter Constable scripsit:
> > So, if nothing else, I think 639-5 should not be withdrawn. Because my
> > main concern is BCP 47, I would have no qualms if 639-5 and its code
> > table remain unchanged.
> I disagree.
> If it were withdrawn, our Registry would remain unchanged.  Our only
> obligation with respect to ISO 639-5 is to add any subtags that the RA
> (the Library of Congress) should decide to add.  If the RA ceases to
> exist, we don't have to do anything.  Certainly we wouldn't remove any
> of the codes from the former standard.
> So I think we should be neutral on the subject, rather than insisting
> that ISO 639-5 must be kept because *in the past* we made a copy of its
> code elements.
> --
> John Cowan        cowan at
> Let's face it: software is crap. Feature-laden and bloated, written under
> tremendous time-pressure, often by incapable coders, using dangerous
> languages and inadequate tools, trying to connect to heaps of broken or
> obsolete protocols, implemented equally insufficiently, running on
> unpredictable hardware -- we are all more than used to brokenness.
>                    --Felix Winkelmann
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ietf-languages mailing list