Re: [Ltru] rechartering (to handle 639-6 or otherwise)

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Tue, 14 July 2009 05:35 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A500F3A6995 for <ltru@core3.amsl.com>; Mon, 13 Jul 2009 22:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.381
X-Spam-Level:
X-Spam-Status: No, score=0.381 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_75=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUaVj75D0GCB for <ltru@core3.amsl.com>; Mon, 13 Jul 2009 22:35:10 -0700 (PDT)
Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 2A8293A6903 for <ltru@ietf.org>; Mon, 13 Jul 2009 22:35:10 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n6E5XwR9024621 for <ltru@ietf.org>; Tue, 14 Jul 2009 14:33:58 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4a54_eda2dae4_7037_11de_922d_001d096c566a; Tue, 14 Jul 2009 14:33:58 +0900
Received: from [IPv6:::1] ([133.2.210.1]:35101) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1183E3D> for <ltru@ietf.org> from <duerst@it.aoyama.ac.jp>; Tue, 14 Jul 2009 14:31:40 +0900
Message-ID: <4A5C18B8.9000109@it.aoyama.ac.jp>
Date: Tue, 14 Jul 2009 14:33:44 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: "Phillips, Addison" <addison@amazon.com>
References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com>
In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: LTRU Working Group <ltru@ietf.org>
Subject: Re: [Ltru] rechartering (to handle 639-6 or otherwise)
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2009 05:35:11 -0000

For the record, and hats off, I can't currently see any purpose in 
rechartering. The tags being added by RFC4645bis and the ongoing 
registry process via ISO and via ietf-languages cover the greatest 
majority of language tagging needs (at least something like four or five 
nines). Also, while the current text isn't perfect, it's not good use of 
our time to spend another year or two on further tweaking. In addition, 
I cannot think of any other topics or issues that are currently unsolved 
and would need a WG.

Regards,   Martin.

On 2009/07/14 0:26, Phillips, Addison wrote:
> 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@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Randy Presuhn
> Sent: Sunday, July 12, 2009 11:51 PM
> To: ietf-languages@iana.org
> Subject: Re: Anomaly in upcoming registry
>
> Hi -
>
> Discussion of re-chartering the ltru working group belongs on
> the ltru@ietf.org mailing list, not here.  This is the time
> for such discussions.
>
> Randy
> ----- Original Message -----
> From: "Gerard Meijssen"<gerard.meijssen@openprogress.org>
> To: "Doug Ewell"<doug@ewellic.org>
> Cc:<ietf-languages@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@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@alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>>
>
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Ietf-languages mailing list
>> Ietf-languages@alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>>
>
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp