RE: New RFC 4645-4647 (language tags)

From: Debbie Garside (
Date: Wed Sep 13 2006 - 13:18:28 CDT

  • Next message: Debbie Garside: "RE: New RFC 4645-4647 (language tags)"

    Doug wrote:

    > ISO 3166
    > has been more problematic with regard to stability.

    I think the WG responsible for ISO 3166 are now fully aware of the issues
    surrounding code changes. Having recently attended the meeting of TC46/WG2
    in Geneva (last week I fact), I am charged with creating a NWIP (New Work
    Item Proposal) that will make "minor revisions" to the standard (the not yet
    published FDIS version); I will be looking at stability issues and hope to
    extend the 50 year rule. If anyone has any opinions, observations or
    suggestions I am happy to receive private emails (or public for that matter
    but it is rather OT for these lists).

    Best regards

    Debbie Garside
    BSI Liaison IDT/2/11 and TC46/WG2


    > -----Original Message-----
    > From:
    > [] On Behalf Of Doug Ewell
    > Sent: 13 September 2006 06:00
    > To: Unicode Mailing List; UnicoRe Mailing List
    > Cc: Philippe Verdy; Addison Phillips; Mark E. Shoulson
    > Subject: Re: New RFC 4645-4647 (language tags)
    > 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 - 13:21:47 CDT