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

["Doug Ewell" <[e-mail]>]

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 ­