Re: New RFC 4645-4647 (language tags)

From: Doug Ewell (
Date: Tue Sep 12 2006 - 23:59:58 CDT

  • Next message: Balasankar: "registration of dialects"

    Philippe Verdy <verdy underscore p at wanadoo dot fr> wrote:

    >> No language will have two codes assigned in the registry. Users will,
    >> presumably, choose the code that best meets their needs.
    > How will they be able to choose if there's only one code in the
    > registry? Through the registered replacements and the language tag
    > canonicalisation described in RFC 4646? When I read the reply from
    > Doug, it seems that one of the code needs to be registered in the IANA
    > registry, otherwise, neither can be used (even if they are in some
    > part of ISO 639).

    This is correct. The Language Subtag Registry is the single source for
    all (non-private) subtags that may be used in RFC 4646 language tags.
    There is no need for users to search through various ISO standards (this
    was one of the reasons for having a registry).

    > So the IANA registry becomes the only reference for language tags, and
    > it serves another purpose than ISO 639: code stability in IANA with
    > RFC 4646 (even if one code is weak), instead of currentness and
    > completeness if possible with ISO 639 (even if ISO codes have been
    > changed and reassigned, something that's nearly impossible to track in
    > applications with the current ISO 639 standard).

    Not entirely impossible. ISO 639 RA/JAC does send out announcements
    when they make changes, and most changes do not cause conflicts and are
    not expected to.

    As a matter of fact, ISO 639 announced a new code element this past
    August 23 ("zza" for the language Zaza, spoken in Turkey) and the
    corresponding RFC 4646 language subtag was approved and sent to IANA and
    added to the Registry only five days later. Meanwhile, the new code
    element *still* has not been added to any of the official online ISO 639
    tables or to their Change Notice page!

    > At some future time, the two competing standards will diverge, unless
    > new policies are adopted in ISO 639 (and ISO 3166 as well) that will
    > also respect the RFC 4646 stability rules; this would require an
    > agreement between the (private) IETF/IESG working group and related
    > (half-public and official, government-supported) ISO working groups.
    > For now, given the existing writers of this RFC suite, there's little
    > risk, given that they are already working with other ISO standard
    > bodies.

    The "JAC" in ISO 639 RA/JAC stands for "Joint Advisory Committee." The
    word "joint" means just that: the standards within the ISO 639 family
    are closely coordinated, and are not in any way "competing." For the
    most part, stability has not been a problem with ISO 639 for many years,
    although there was an episode in 2003 where several new alpha-2 code
    elements appeared on the official Web site years after a moratorium was
    supposed to have gone into effect. ISO 3166 has been more problematic
    with regard to stability.

    Doug Ewell
    Fullerton, California, USA
    RFC 4645  *  UTN #14

    This archive was generated by hypermail 2.1.5 : Wed Sep 13 2006 - 01:12:07 CDT