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

"Phillips, Addison" <addison@lab126.com> Sun, 10 July 2011 15:50 UTC

Return-Path: <addison@lab126.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 70F8121F866A for <ltru@ietfa.amsl.com>; Sun, 10 Jul 2011 08:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 XtEPU-6uPFcy for <ltru@ietfa.amsl.com>; Sun, 10 Jul 2011 08:50:40 -0700 (PDT)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1113121F8656 for <ltru@ietf.org>; Sun, 10 Jul 2011 08:50:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,509,1304294400"; d="scan'208";a="740756590"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2011 15:50:35 +0000
Received: from ex-hub-31012.ant.amazon.com (ex-hub-31012.sea31.amazon.com [10.185.169.29]) by smtp-in-1104.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id p6AFoTlr021258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Jul 2011 15:50:30 GMT
Received: from EX-SEA31-D.ant.amazon.com ([169.254.1.184]) by ex-hub-31012.ant.amazon.com ([fe80::24e8:aabe:e5e7:2f81%12]) with mapi; Sun, 10 Jul 2011 08:50:29 -0700
From: "Phillips, Addison" <addison@lab126.com>
To: Debbie Garside <debbie@ictmarketing.co.uk>, "'Broome, Karen'" <Karen.Broome@am.sony.com>, "'Steven R. Loomis'" <srl@icu-project.org>
Date: Sun, 10 Jul 2011 08:50:30 -0700
Thread-Topic: [Ltru] Fwd: draft-davis-t-langtag-ext
Thread-Index: Acw9DtbUXcoPM6XxTU65e0/PWxSODAANbkfAAFVQBJAAAEyDcAAcY+3gAAHSVgAAAN7egA==
Message-ID: <131F80DEA635F044946897AFDA9AC3476A94296DBA@EX-SEA31-D.ant.amazon.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> <2CB55BFC7405E94F830537BD924318D5EBF0AB321F@USSDIXMSG11.am.sony.com> <131F80DEA635F044946897AFDA9AC3476A94296D2A@EX-SEA31-D.ant.amazon.com> <099901cc3f10$569195b0$03b4c110$@co.uk> <09a401cc3f14$8a3cadb0$9eb60910$@co.uk>
In-Reply-To: <09a401cc3f14$8a3cadb0$9eb60910$@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
Cc: 'Pete Resnick' <presnick@qualcomm.com>, 'LTRU Working Group' <ltru@ietf.org>, 'CLDR list' <cldr@unicode.org>, 'Roozbeh Pournader' <roozbeh@htpassport.com>
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 15:50:41 -0000

The operative sentence in the paragraph you quote is the first one:

> IANA will maintain a registry of allocated single-character
>    (singleton) subtags.  

That is, the paragraph has to do with a registry containing a list of the extensions and where to find them. 

The actual extensions are located somewhere else. 

Addison


> -----Original Message-----
> From: Debbie Garside [mailto:debbie@ictmarketing.co.uk]
> Sent: Sunday, July 10, 2011 8:18 AM
> To: 'Debbie Garside'; Phillips, Addison; 'Broome, Karen'; 'Steven R. Loomis'
> Cc: 'Pete Resnick'; 'Roozbeh Pournader'; 'CLDR list'; 'LTRU Working Group'
> Subject: RE: [Ltru] Fwd: draft-davis-t-langtag-ext
> 
> Can I just clarify...
> 
> I am reading BCP47 with regard to the rules for sending IANA info on extension
> subtags.  The wording is not clear.  Does the paragraph (below) mean that
> every time there is a new part to an extension mechanism that the maintaining
> authority sends this to IANA? Or does it mean that just the details of (in the
> case) the -t singleton are sent to IANA?
> 
> Debbie
> 
> -----Original Message-----
> From: cldr-bounce@unicode.org [mailto:cldr-bounce@unicode.org] On Behalf
> Of Debbie Garside
> Sent: 10 July 2011 15:48
> To: 'Phillips, Addison'; 'Broome, Karen'; 'Steven R. Loomis'
> Cc: 'Pete Resnick'; 'Roozbeh Pournader'; 'CLDR list'; 'LTRU Working Group'
> Subject: RE: [Ltru] Fwd: draft-davis-t-langtag-ext
> 
> Hi Addison
> 
> I'm not sure that I see where the "overhead" is.  Can you elaborate?
> 
> BCP47 states:
> 
> IANA will maintain a registry of allocated single-character
>    (singleton) subtags.  This registry MUST use the record-jar format
>    described by the ABNF in Section 3.1.1.  Upon publication of an
>    extension as an RFC, the maintaining authority defined in the RFC
>    MUST forward this registration form to <iesg@ietf.org>rg>, who MUST
>    forward the request to <iana@iana.org>rg>.  The maintaining authority of
>    the extension MUST maintain the accuracy of the record by sending an
>    updated full copy of the record to <iana@iana.org> with the subject
>    line "LANGUAGE TAG EXTENSION UPDATE" whenever content changes.  Only
>    the 'Comments', 'Contact_Email', 'Mailing_List', and 'URL' fields MAY
>    be modified in these updates.
> 
> This IMHO is the overhead.  Given that we already have ietf-languages as a
> discussion list, and all the rules and regulations for application and registration
> of subtags, why create another "private" process? CLDR-TC would have to
> create transparent rules and regs anyway.
> 
> Keeping everything in one place/list has got to be easier for the end user.  I still
> cannot see any real reason for taking this out of IETF other than BCP47 allows
> for it.
> 
> I can see the proposed -t extension mechanism being widely used by a number
> of organisations, unlike the -u extension which was specifically designed for
> integrating CLDR data within a subtag.  I don't think we can compare the two
> processes.
> 
> Best wishes
> 
> Debbie
> 
> 
> 
> -----Original Message-----
> From: Phillips, Addison [mailto:addison@lab126.com]
> Sent: 10 July 2011 02:37
> To: Broome, Karen; Debbie Garside; 'Steven R. Loomis'
> Cc: 'Pete Resnick'; 'Roozbeh Pournader'; 'CLDR list'; 'LTRU Working Group'
> Subject: RE: [Ltru] Fwd: draft-davis-t-langtag-ext
> 
> > 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.
> 
> There is a fundamental problem with that, though.
> 
> The extension mechanism can be used to create a registry under the auspices
> of the IETF that is managed by IANA using the ietf-languages list. That requires
> Internet-Draft(s) be created laying out the process, rules, format, structure, etc.
> etc. for the registry. We know from experience how much effort is required to
> complete such work. Note that such an extension would still be a separate
> registry and would be managed separately (even if it were to use the same
> mail list, for example).
> 
> The extension mechanism also can be used (indeed, given the foregoing, is
> optimized for use) by standards bodies or other organizations that maintain or
> are willing to create and maintain language-tag-extending standards or
> registries. In this case, one such body (the CLDR-TC of the Unicode Consortium)
> has requested under the BCP 47 rules that the IESG to assign it one of the 34
> remaining singletons for an extension that they will maintain.
> 
> CLDR-TC is already the maintainer of one language tag extension, so it
> probably meets at least meet a minimal bar for fitness as such. Given the
> overhead for creating a different process, isn't it reasonable to use the CLDR
> process and Unicode's willingness to maintain the registry for this purpose? If
> there are concerns about the openness of the process, etc., I believe they can
> be addressed in the Internet-Draft.
> 
> A separate question is whether the current proposal is adequate/appropriate
> for the task, including such stuff as the creation of a single registry. The other
> authors are open to discussing these things and making changes. Is that
> objectionable as an approach?
> 
> Addison
> 
> 
> > -----Original Message-----
> > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf
> > Of Broome, Karen
> > Sent: Saturday, July 09, 2011 5:42 PM
> > To: Debbie Garside; 'Steven R. Loomis'
> > Cc: 'Pete Resnick'; 'Roozbeh Pournader'; 'CLDR list'; 'LTRU Working Group'
> > Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext
> >
> > 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
> > _______________________________________________
> > Ltru mailing list
> > Ltru@ietf.org
> > https://www.ietf.org/mailman/listinfo/ltru
> 
> 
> 
> 
> 
>