Randy posted to the ietf-languages thread (below) that most of you are probably aware of, the following message. I'm cross-posting it so that I can respond.
I oppose rechartering LTRU at this time. We've completed the essential work of incorporating ISO 639-3 and our work has brought a few other enhancements. I think we've allowed sufficient room for the registration process to do its magic and handle most of the language identification community's needs. I would like to see the new document in use for awhile before we go to tinkering with it.
If ISO 639-6 were ready (as it is not), then LTRU could be reconstituted to look into whether or not to incorporate it (and if so, how). I suspect it might be a couple of years before that is upon us. In the meantime, we could use some experience with rfc-to-be-4646bis. Constant rewriting will not improve matters.
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
-----Original Message-----
From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Randy Presuhn
Sent: Sunday, July 12, 2009 11:51 PM
To: ietf-languages at iana.org
Subject: Re: Anomaly in upcoming registry
Hi -
Discussion of re-chartering the ltru working group belongs on
the ltru at ietf.org mailing list, not here. This is the time
for such discussions.
Randy
----- Original Message -----
From: "Gerard Meijssen" <gerard.meijssen at openprogress.org>
To: "Doug Ewell" <doug at ewellic.org>
Cc: <ietf-languages at iana.org>
Sent: Sunday, July 12, 2009 11:28 PM
Subject: Re: Anomaly in upcoming registry
Hoi,
With all due respect for the diligence of the process but when you consider
the length of time it took, the ISO-639-6 will make this same process
impossible because of the amount of data involved. When this process only
starts when the publication is imminent, it will take maybe at least a
decade based on the number of new entries that ISO 639-6 will bring. That
means imho that for ISO-639-6 we will have to rethink the process. We do
have room before the publication of the new standard.. it could be seen as
pre-emptive involvement because of the huge amount of data involved.
Thanks,
Gerard
2009/7/13 Doug Ewell <doug at ewellic.org>
> Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:
>
> > There's no way that I'd be willing to start another round of ltru
> > revsions to make the handling of such a hypothetical any clearer. At
> > some point folks need to realize that the BCP is not an algorithm for
> > execution by finite state automata. It gives guidelines to humans
> > who, one would hope, are capable of exercising a bit of common sense.
>
> I would hope it's blindingly obvious to Randy and everyone else that I
> agree with this statement. I would not want to start another round of
> LTRU revisions for almost any reason.
>
> Every so often we talk about adding ISO 639-6 support, which would be a
> good enough reason, but only if (a) the draft and data were fully
> available for WG review, (b) ISO publication appeared imminent, and (c)
> the WG had some hope of agreeing where to put the subtags
> architecturally.
>
> --
> Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
> http://www.ewellic.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
--------------------------------------------------------------------------------
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.