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

["Debbie Garside" <[e-mail]>]

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 <[e-mail]>, who MUST
   forward the request to <[e-mail]>.  The maintaining authority of
   the extension MUST maintain the accuracy of the record by sending an
   updated full copy of the record to <[e-mail]> 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:[e-mail]] 
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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltru
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltru