Re: [Ltru] Fwd: draft-davis-t-langtag-ext

Roozbeh Pournader <roozbeh@htpassport.com> Thu, 07 July 2011 21:58 UTC

Return-Path: <roozbeh@htpassport.com>
X-Original-To: ltru@ietfa.amsl.com
Delivered-To: ltru@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180D311E8077 for <ltru@ietfa.amsl.com>; Thu, 7 Jul 2011 14:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level:
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIvMRgW210IE for <ltru@ietfa.amsl.com>; Thu, 7 Jul 2011 14:58:07 -0700 (PDT)
Received: from mx2.htpassport.net (mx2.htpassport.net [173.13.187.84]) by ietfa.amsl.com (Postfix) with ESMTP id 993B221F8903 for <ltru@ietf.org>; Thu, 7 Jul 2011 14:58:07 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.htpassport.net (HTP_ESMTP) with ESMTP id 350FFAFA804; Thu, 7 Jul 2011 14:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at htpassport.com
Received: from [192.168.0.40] (unknown [192.168.0.40]) by mx2.htpassport.net (HTP_ESMTP) with ESMTP id 18D76AFA802; Thu, 7 Jul 2011 14:58:05 -0700 (PDT)
From: Roozbeh Pournader <roozbeh@htpassport.com>
To: Debbie Garside <debbie@ictmarketing.co.uk>
In-Reply-To: <07de01cc3cea$c0b56930$42203b90$@co.uk>
References: <4E14F473.6030101@qualcomm.com> <4E152E4F.9070203@gmail.com> <CAJ2xs_Fm0NLOyL6PLps=77mb=o-gU2cCvi0=i0nj6NQJ01qnVw@mail.gmail.com> <075f01cc3cbf$0f04ba90$2d0e2fb0$@co.uk> <CAJ2xs_ED6pmF=t=0g9G5fUJH8GyM8X+G=_juC93uuw0JHtcsJQ@mail.gmail.com> <07be01cc3ce6$114dfc90$33e9f5b0$@co.uk> <1310071653.2702.3.camel@tehran.htpassport.net> <07de01cc3cea$c0b56930$42203b90$@co.uk>
Content-Type: text/plain; charset="UTF-8"
Organization: HighTech Passport
Date: Thu, 07 Jul 2011 14:58:04 -0700
Message-ID: <1310075884.2702.21.camel@tehran.htpassport.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14)
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 07 Jul 2011 20:07:17 -0700
Cc: 'Pete Resnick' <presnick@qualcomm.com>, 'CLDR list' <cldr@unicode.org>, 'LTRU Working Group' <ltru@ietf.org>
Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 07 Jul 2011 21:58:08 -0000

On Thu, 2011-07-07 at 22:13 +0100, Debbie Garside wrote:

> I have heard from a colleague who has been instrumental in adding 100
> locales to CLDR that many volunteers are disillusioned and have
> stopped contributing.

That's not because of committee voting. Maintaining and updating the
data in CLDR locales uses a vetting procedure vastly different from the
CLDR commitee itself. And I have seen the feedback from experts with
limited voting right incorporated not only in CLDR data, but also in
updates to the CLDR data vetting process. From what I've seen, most
volunteer experts objections has been about not being able to keep up
with the pace of data that comes from some full members. So, it's mostly
been volunteer contributors (myself included) trying to slow down the
process, instead of voting members. So contrary to what you think, it's
the organizational and data support from the voting members that makes
sure the process is fast enough. Not only it doesn't put development
back for years, it's usually volunteer contributors who want the process
slowed down so they can catch up.

Again, all of that is about "locale data", which is really very large
amount of data. I don't think we can use that experience to see how the
"t" extension will be maintained. A better comparison is how the Unicode
Consortium and the CLDR committee has been maintaining the
already-registered "u" extension. Do you know anybody who has had a
problem with that?

> I would hate for IETF to find that they agree to "outsource" this work
> and then find that their volunteer experts disappear.

Well, Unicode has been here for more than two decades, and I have yet to
see expertise disappear from it. Not only that, but also almost all the
core people are still contributing.

Roozbeh