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

["Phillips, Addison" <[e-mail]>]

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:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]] 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 <[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
> 
> 
> 
> 
> 
>