Fwd: WG Action: Language Tag Registry Update (ltru)

From: Martin Duerst (duerst@w3.org)
Date: Thu Mar 10 2005 - 23:44:24 CST

  • Next message: Arcane Jill: "Re: Encoded rendering instructions (was Unicode's Mandate)"

    This should be of interest for people interested in
    language codes. Regards, Martin.

    >To: IETF Announcement list <ietf-announce@ietf.org>
    >Cc: Randy Presuhn <randy_presuhn@mindspring.com>,Martin Duerst
    ><mduerst@w3.org>, ltru@ietf.org
    >From: IESG Secretary <iesg-secretary-reply@ietf.org>
    >Subject: WG Action: Language Tag Registry Update (ltru)
    >Date: Tue, 08 Mar 2005 16:33:22 -0500

    >A new IETF working group has been formed in the Applicationa Area.
    >For additional information, please contact the Area Directors
    >or the WG Chairs.
    >Language Tag Registry Update (ltru)
    >Current Status: Active Working Group
    >Randy Presuhn <randy_presuhn@mindspring.com>
    >Martin Duerst <mduerst@w3.org>
    >Applications Area Director(s):
    >Ted Hardie <hardie@qualcomm.com>
    >Scott Hollenbeck <sah@428cobrajet.net>
    >Applications Area Advisor:
    >Ted Hardie <hardie@qualcomm.com>
    >Mailing Lists:
    >General Discussion: ltru@ietf.org
    >To Subscribe: https://www1.ietf.org/mailman/listinfo/ltru
    >Archive: http://www.ietf.org/mail-archive/web/ltru/index.html
    >Description of Working Group:
    >RFC 3066 and its predecessor, RFC 1766, defined language tags for use
    >on the Internet. Language tags are necessary for many applications,
    >ranging from cataloging content to computer processing of text. The
    >RFC 3066 standard for language tags has been widely adopted in various
    >protocols and text formats, including HTML, XML, and CLDR, as the best
    >means of identifying languages and language preferences. Since the
    >publication of RFC 3066, however, several issues have faced
    >implementors of language tags:
    >* Stability and accessibility of the underlying ISO standards
    >* Difficulty with registrations and their acceptance
    >* Lack of clear guidance on how to identify script and region where
    >* Lack of parseability and the ability to verify well-formedness.
    >* Lack of specified algorithms, apart from pure prefix matching,
    >for operations on language tags.
    >This working group will address these issues by developing two
    >documents. The first is a successor to RFC 3066. It will describe the
    >structure of the IANA registry and how the registered tags will relate
    >to the generative mechanisms (originally described in RFC 3066, but
    >likely to be updated by the document). In order to be complete, it
    >will need to address each of the challenges set out above:
    >- For stability, it is expected that the document will describe how
    >the meaning of language tags remains stable, even if underlying
    >references should change, and how the structure is to remain stable in
    >the future. For accessibility, it is to provide a mechanism for easily
    >determining whether a particular subtag is valid as of a given date,
    >without onerous reconstruction of the state of the underlying standard
    >as of that time.
    >- For extensibility, it is expected that the document will describe
    >how generative mechanisms could use ISO 15924 and UN M.49 codes
    >without explicit registration of all combinations. The
    >current registry contains pairs like uz-Cyrl/uz-Latn and
    >sr-Cyrl/sr-Latn, but RFC 3066 contains no general mechanism or
    >guidance for how scripts should be incorporated into language tags;
    >this replacement document is expected to provide such a mechanism.
    >- It is also expected to provide mechanisms to support the evolution
    >of the underlying ISO standards, in particular ISO 639-3, mechanisms to
    >support variant registration and formal extensions, as well as
    >allowing generative private use when necessary.
    >- It is expected to specify a mechanism for easily identifying the role
    >of each subtag in the language tag, so that, for example, whenever a
    >script code or country code is present in the tag it can be extracted,
    >even without access to a current version of the registry. Such a
    >mechanism would clearly distinguish between well-formed and valid
    >language tags, to allow for maximal compatibility between
    >implementations released at different times, and thus using different
    >versions of the registry.
    >The second document will describe matching algorithms for use with
    >language tags. Language tags are used in a broad variety of contexts
    >and it is not expected that any single matching algorithm will fit all
    >needs. Developing a small set of common matching algorithms does seem
    >likely to contribute to interoperability, however, as it seems likely
    >that using protocols could reference these well-known algorithms in
    >their specifications.
    >This working group will not take over the existing review function of
    >the ietf-languages list. The ietf-languages list will continue to
    >review tags according to RFC 3066 until the first document produced by
    >the WG is approved by the IESG for publication as an RFC. Then it will
    >review according to whatever procedures the first document specifies.
    >Goals and Milestones:
    >Mar 05 Sumbit first working group draft of registry-structure draft
    >Apr 05 Submit first draft of matching algorithms draft
    >May 05 Submit first draft of matching algorithms draft
    >Aug 05 Submit matching algorithms draft for IETF Last Call

    This archive was generated by hypermail 2.1.5 : Thu Mar 10 2005 - 23:46:46 CST