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

"Broome, Karen" <Karen.Broome@am.sony.com> Sun, 10 July 2011 00:46 UTC

Return-Path: <Karen.Broome@am.sony.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 2DDB021F88FE for <ltru@ietfa.amsl.com>; Sat, 9 Jul 2011 17:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 aFxFtEL7a249 for <ltru@ietfa.amsl.com>; Sat, 9 Jul 2011 17:46:45 -0700 (PDT)
Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id E6DFD21F88F7 for <ltru@ietf.org>; Sat, 9 Jul 2011 17:46:44 -0700 (PDT)
Received: from mail117-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Sun, 10 Jul 2011 00:46:43 +0000
Received: from mail117-va3 (localhost.localdomain [127.0.0.1]) by mail117-va3-R.bigfish.com (Postfix) with ESMTP id 43771142830D; Sun, 10 Jul 2011 00:46:43 +0000 (UTC)
X-SpamScore: -52
X-BigFish: VPS-52(zf7Iz936eK9371M542M1dbaL1418M1432N98dKzz1202hzz1033IL8275dhz2fh668h839h93fh61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:160.33.98.74; KIP:(null); UIP:(null); IPVD:NLI; H:mail7.fw-bc.sony.com; RD:mail7.fw-bc.sony.com; EFVD:NLI
Received-SPF: pass (mail117-va3: domain of am.sony.com designates 160.33.98.74 as permitted sender) client-ip=160.33.98.74; envelope-from=Karen.Broome@am.sony.com; helo=mail7.fw-bc.sony.com ; -bc.sony.com ;
Received: from mail117-va3 (localhost.localdomain [127.0.0.1]) by mail117-va3 (MessageSwitch) id 1310258802965597_20259; Sun, 10 Jul 2011 00:46:42 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.253]) by mail117-va3.bigfish.com (Postfix) with ESMTP id E6678132004F; Sun, 10 Jul 2011 00:46:42 +0000 (UTC)
Received: from mail7.fw-bc.sony.com (160.33.98.74) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id 14.1.225.22; Sun, 10 Jul 2011 00:46:39 +0000
Received: from mail2x.bc.in.sel.sony.com (mailx.bc.in.sel.sony.com [43.144.100.56]) by mail7.fw-bc.sony.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id p6A0jdsl004524; Sun, 10 Jul 2011 00:46:38 GMT
Received: from USBMAXHUB12.am.sony.com (hub.bc.in.sel.sony.com [43.145.127.73]) by mail2x.bc.in.sel.sony.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p6A0ZqQb024276 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 10 Jul 2011 00:46:37 GMT
Received: from USSDIXHUB13.am.sony.com (43.130.150.23) by USBMAXHUB12.am.sony.com (43.145.127.73) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 9 Jul 2011 20:41:48 -0400
Received: from USSDIXMSG11.am.sony.com ([43.130.150.12]) by USSDIXHUB13.am.sony.com ([43.130.150.23]) with mapi; Sat, 9 Jul 2011 17:41:47 -0700
From: "Broome, Karen" <Karen.Broome@am.sony.com>
To: Debbie Garside <debbie@ictmarketing.co.uk>, "'Steven R. Loomis'" <srl@icu-project.org>
Date: Sat, 09 Jul 2011 17:41:43 -0700
Thread-Topic: [Ltru] Fwd: draft-davis-t-langtag-ext
Thread-Index: Acw9DtbUXcoPM6XxTU65e0/PWxSODAANbkfAAFVQBJA=
Message-ID: <2CB55BFC7405E94F830537BD924318D5EBF0AB321F@USSDIXMSG11.am.sony.com>
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> <1310075884.2702.21.camel@tehran.htpassport.net> <07fb01cc3cf3$16c46170$444d2450$@co.uk> <20110707182756.7333f020@naf.sanjose.ibm.com> <083a01cc3d45$4c365a50$e4a30ef0$@co.uk>
In-Reply-To: <083a01cc3d45$4c365a50$e4a30ef0$@co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: am.sony.com
Cc: 'Pete Resnick' <presnick@qualcomm.com>, 'Roozbeh Pournader' <roozbeh@htpassport.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: Sun, 10 Jul 2011 00:46:46 -0000

I tend to agree with Debbie on this. I'm not sure this is best handled by an external, if tightly coupled, organization. This seems to be a useful extension to the main body of work so it seems like it should be handled in the same way.

Regards,

Karen Broome

-----Original Message-----
From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Debbie Garside
Sent: Friday, July 08, 2011 6:02 PM
To: 'Steven R. Loomis'
Cc: 'LTRU Working Group'; 'CLDR list'; 'Pete Resnick'; 'Roozbeh Pournader'
Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext

Hi Steven

Thanks.  I really am not trying to criticise CLDR.  I understand (somewhat) the problems and the needs of industry.  As already mentioned, I am a supporter of both Unicode and CLDR.  I will ask my colleague to speak with you about his concerns.

My concern here on IETF-LTRU is that a process is being taken out of IETF unnecessarily IMHO - at least from the responses received so far, I can see no added value in CLDR functioning as the Registrar for -t extensions.

Best wishes

Debbie



-----Original Message-----
From: cldr-bounce@unicode.org [mailto:cldr-bounce@unicode.org] On Behalf Of Steven R. Loomis
Sent: 08 July 2011 02:28
To: Debbie Garside
Cc: 'Roozbeh Pournader'; 'Mark Davis ☕'; 'Mykyta Yevstifeyev'; 'Pete Resnick'; 'LTRU Working Group'; 'CLDR list'
Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext

Debbie,

I think that the concern about the data dump was due to some
 misunderstandings regarding the CLDR process. As the one who developed
 and manages major parts of the CLDR tooling (along with many others),
 I can say that the human users involved with the "data dump" (which
 was another misconception, that it was merely a one-way "dump") were
 very involved with the CLDR forum process.

We are hard at work to make the vetting process easier to use for
everyone. The sheer number of increased users and data the last time
around, brought to the forefront stability and performance issues that
were still unresolved. One of the issues is the amount of data that is
in a CLDR locale can be daunting, it would be in the tens of thousands
of data items. We've already introduced a system ('coverage') that lets
the user reduce what is shown normally to just critical items. This
system is already slated to be improved.  As well, we have some faster
hardware to run the server on that we will be testing out soon.

I realize that you are relaying a concern from a third party, but I
would invite your colleague to discuss the specific concerns with us if
they had not already.  One of the very exciting parts, for me, of this
process is that anyone regardless of other 'status' can (and does) sign
up and contribute data, and has a voice. Previous to the launch of the
CLDR project about eight years ago, this locale data existed in
multiple organization's repositories, where it would take a bug report
to cause any change.  Then I (and others in different companies,
independently) would have to look at the bug report and decide when and
if to spend time updating that data.  Now there is a process for
sorting out the data, and also a common repository and format for many
projects (both open-source and commercial) to pick up and use. It's not
a perfect process, but it's a process.

Regards,

Steven



On Thu, 7 Jul 2011 23:13:19 +0100
"Debbie Garside" <debbie@ictmarketing.co.uk> wrote:

> I will say just say a couple of things on this and then will let it
> go.  I really am not about attacking either Unicode or CLDR as I
> believe I am still a member (and have been since they last printed a
> hard copy - whenever that was).
> 
> I believe that CLDR has lost experts due to a data dump from Google
> that overwrote their work.  I had a face to face conversation with a
> colleague involved whilst in Korea three weeks ago.
> 
> Saying that all the core people are still there after 20 years does
> not address the issue of paying for votes - they may have been paying
> for 20 years.  In any case, I believe CLDR was created some 7 years
> ago (or maybe 8).
> 
> One could ask, how many people are on the proposed CLDR committee
> and, of these, how many are not attached to paying organisations?
> 
> Best wishes
> 
> Debbie
> 
> -----Original Message-----
> From: cldr-bounce@unicode.org [mailto:cldr-bounce@unicode.org] On
> Behalf Of Roozbeh Pournader Sent: 07 July 2011 22:58
> To: Debbie Garside
> Cc: 'Mark Davis ☕'; 'Mykyta Yevstifeyev'; 'Pete Resnick'; 'LTRU
> Working Group'; 'CLDR list' Subject: RE: [Ltru] Fwd:
> draft-davis-t-langtag-ext
> 
> 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





_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru