From: Debbie Garside (debbie@ictmarketing.co.uk)
Date: Wed Sep 13 2006 - 13:18:28 CDT
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: unicore-bounce@unicode.org
> [mailto:unicore-bounce@unicode.org] 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
> http://users.adelphia.net/~dewell/
> RFC 4645 * UTN #14
>
>
>
>
>
>
This archive was generated by hypermail 2.1.5 : Wed Sep 13 2006 - 13:21:47 CDT