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

"Debbie Garside" <debbie@ictmarketing.co.uk> Sun, 10 July 2011 15:31 UTC

Return-Path: <debbie@ictmarketing.co.uk>
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 3B9D521F8637 for <ltru@ietfa.amsl.com>; Sun, 10 Jul 2011 08:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.07
X-Spam-Level:
X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 jNqckR0icKwP for <ltru@ietfa.amsl.com>; Sun, 10 Jul 2011 08:31:07 -0700 (PDT)
Received: from 145.nexbyte.net (145.nexbyte.net [62.197.41.145]) by ietfa.amsl.com (Postfix) with ESMTP id 294D221F85FF for <ltru@ietf.org>; Sun, 10 Jul 2011 08:31:07 -0700 (PDT)
Received: from ICTPC ([78.145.15.124]) by 145.nexbyte.net with MailEnable ESMTP; Sun, 10 Jul 2011 16:31:10 +0100
From: Debbie Garside <debbie@ictmarketing.co.uk>
To: 'Kent Karlsson' <kent.karlsson14@telia.com>, "'Phillips, Addison'" <addison@lab126.com>, "'Broome, Karen'" <Karen.Broome@am.sony.com>, "'Steven R. Loomis'" <srl@icu-project.org>
References: <099901cc3f10$569195b0$03b4c110$@co.uk> <CA3F8CF6.19F80%kent.karlsson14@telia.com>
In-Reply-To: <CA3F8CF6.19F80%kent.karlsson14@telia.com>
Date: Sun, 10 Jul 2011 16:31:50 +0100
Message-ID: <09a501cc3f16$7d680060$78380120$@co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Acw9DtbUXcoPM6XxTU65e0/PWxSODAANbkfAAFVQBJAAAEyDcAAcY+3gAAGmiDYAAGK1wA==
Content-Language: en-gb
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:31:08 -0000

Thanks Kent

I can see that I have not interpreted BCP47 correctly.

I think, taking in the comments from Karen, Doug and others, what I may be
happier with in the current scenario (Unicode as maintaining authority) is
if we could include within the RFC an obligation for Unicode to post any
requests for subtags relating to the -t extension to the ietf-languages list
for discussion, in addition to their own internal discussions, and that the
opinions of the participants on this (aforementioned) list carry the same
weight as they do within IETF. Protection for IETF participants would come
via the IESG (in that IETF participants can ask that the role of maintaining
authority for the -t extension be taken from Unicode if their views are not
considered appropriately).  Also, the resulting -t extension subtag record
should be posted to ietf-languages once agreed.

Further, the registry should be mirrored by IANA and linked to the subtag
registry.

Is this possible?

Best wishes

Debbie

-----Original Message-----
From: cldr-bounce@unicode.org [mailto:cldr-bounce@unicode.org] On Behalf Of
Kent Karlsson
Sent: 10 July 2011 16:08
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


Den 2011-07-10 16:47, skrev "Debbie Garside" <debbie@ictmarketing.co.uk>:

> 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>, who MUST
>    forward the request to <iana@iana.org>.  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.

That is for registering that there at all are certain approved extensions.
It provides *no* data about the subtags "under" any extension.

> 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.

The IANA language subtag registry has no way of registering what goes
"under" an extension. Only things preceding any extension (and separately
a list of approved singletons for extensions). Changing this would mean
revising BCP 47. That would be a major hurdle.

> 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.  

As Addison mentioned, one can have a separate registry for an extension that
is held by IANA. But that would mean defining lots of details on exactly
goes into the registry, its format, procedures for approval, etc. That is
NOT covered by BCP 47.

> I can see the proposed -t extension mechanism being widely used by a
number of
> organisations, 

I can agree with that part.

    /Kent K

> 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