Fwd: WG Action: Language Tag Registry Update (ltru)
Randy Presuhn
randy_presuhn at mindspring.com
Thu Mar 10 16:38:21 CET 2005
Hi -
As co-chairs, Martin and I are happy to announce that the ltru WG mailing list
is now operational. We request that discussions falling within that WG's charter
be moved from the ietf-languages at iana.org to the working group's mailing
list, ltru at ietf.org. Please note that you must first subscribe to that list before
posting.
Randy
>To: IETF Announcement list <ietf-announce at ietf.org>
>Cc: Randy Presuhn <randy_presuhn at mindspring.com>,Martin Duerst
><mduerst at w3.org>, ltru at ietf.org
>From: IESG Secretary <iesg-secretary-reply at ietf.org>
>Subject: WG Action: Language Tag Registry Update (ltru)
>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
>
>Chair(s):
>Randy Presuhn <randy_presuhn at mindspring.com>
>Martin Duerst <mduerst at w3.org>
>
>Applications Area Director(s):
>Ted Hardie <hardie at qualcomm.com>
>Scott Hollenbeck <sah at 428cobrajet.net>
>
>Applications Area Advisor:
>Ted Hardie <hardie at qualcomm.com>
>
>Mailing Lists:
>General Discussion: ltru at 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
>necessary
>* 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
More information about the Ietf-languages
mailing list