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

"Doug Ewell" <doug@ewellic.org> Thu, 07 July 2011 21:00 UTC

Return-Path: <doug@ewellic.org>
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 E83CC21F886B for <ltru@ietfa.amsl.com>; Thu, 7 Jul 2011 14:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 CzKloX5vNjGg for <ltru@ietfa.amsl.com>; Thu, 7 Jul 2011 14:00:49 -0700 (PDT)
Received: from smtpoutwbe08.prod.mesa1.secureserver.net (smtpoutwbe08.prod.mesa1.secureserver.net [208.109.78.210]) by ietfa.amsl.com (Postfix) with SMTP id 1EE9721F885A for <ltru@ietf.org>; Thu, 7 Jul 2011 14:00:49 -0700 (PDT)
Received: (qmail 1380 invoked from network); 7 Jul 2011 21:00:48 -0000
Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe08.prod.mesa1.secureserver.net with SMTP; 7 Jul 2011 21:00:48 -0000
Received: (qmail 9682 invoked by uid 99); 7 Jul 2011 21:00:48 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 208.51.143.190
User-Agent: Web-Based Email 5.5.08
Message-Id: <20110707140047.665a7a7059d7ee80bb4d670165c8327d.487d506b5f.wbe@email03.secureserver.net>
From: "Doug Ewell" <doug@ewellic.org>
To: ltru@ietf.org
Date: Thu, 07 Jul 2011 14:00:47 -0700
Mime-Version: 1.0
Cc: ietf-languages@iana.org
Subject: Re: [Ltru] 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: Thu, 07 Jul 2011 21:00:50 -0000

Pete Resnick <presnick at qualcomm dot com> wrote:

> Publication of this document was requested and we decided that it needed 
> to get some review on ltru and ietf-languages.

Unfortunately, it was only today that the discussion expanded to
ietf-languages.  I did see it on LTRU, but I'm sure quite a few regular
ietf-languages participants are no longer on that list, since the WG has
been closed for 19 months now.

I'm concerned that all of the procedures for assigning field values
adopted in RFC 6067 are being taken as a precedent for this draft as
well.  The assignments are solely up to the CLDR committee, and there is
no public announcement or notification that a change has been made or
why a request was rejected.  It could be argued that the -u- mechanism
was really only meant for CLDR-type usage; no such argument can be made
for the -t- mechanism.

With CLDR 2.0 a new 'calendar' value was added, 'iso8601', and I can't
find any publicly available information about the process by which it
was added, nor about which of the numerous ISO 8601 formats might or
might not be indicated by such an extension value.  Under the present
draft, new releases of CLDR might again contain silent changes to the
"registry" of allowable values.

I can't find any indication of where within CLDR the list of allowable
values will be located.  Saying they're in core.zip is almost useless. 
Saying they're in common/bcp47 is better, but I'd still like to know
what file name, what XML element, etc.  An example would help.  I see in
Section 2.1 that the CLDR committee has already approved the mechanism
and we'll be able to see it by the time the draft is approved, which
does not help.

Section 2.5, item b says I can write any 4-, 6-, or 8-digit subtag and
have that interpreted as a date.  I don't know, as a developer, whether
I'm supposed to validate those in any way -- rejecting, say, '20110229'
as impossible, or '2012' as futuristic.  I'm not even sure what to do,
with regard to the May 1, 2011 revision of BGN used as an example,
whether to treat '2011' and '201105' and '20110501' as synonyms for
matching purposes, or whether any is more valid than the others, since
the draft only says users SHOULD use the short form.

I know this draft will be approved, and I'm hopeful that some of these
concerns will be addressed before it does.

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell ­