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

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

I would support this argument.

Debbie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: 09 July 2011 01:59
To: Kent Karlsson; Debbie Garside
Cc: [e-mail]
Subject: Re: [Ltru] draft-davis-t-langtag-ext

The current draft refers partly to the LSR (for "from" tags, which I
understand), partly to data located somewhere within CLDR, and partly to a
set of numeric patterns and an interpretation rule. That's not "a registry"
in any sense, so I guess it's a good thing that BCP 47 doesn't seem to
require one.

During the review period for the draft that became 6067, I argued hard for
putting all the relevant data in one easy-to-find place, not zipped together
with a lot of unrelated data. That argument was not successful, and you can
see now that much of the current draft is being defended as "this is the
same thing we did in 6067, which was approved." So the argument is even less
likely to be accepted than it was before.

--Doug  
------Original Message------
From: Kent Karlsson
To: Doug Ewell
To: Debbie Garside
Cc: [e-mail]
Subject: Re: [Ltru] draft-davis-t-langtag-ext
Sent: Jul 8, 2011 15:32


Den 2011-07-08 18:38, skrev "Doug Ewell" <[e-mail]>:

> I just noticed that RFC 5646, Section 2.2.6 ("Extension Subtags"), item
3
> says, "Note that there might not be a registry of these subtags."  I


The extension subtags may be defined (by listing them) only in the RFC
defining the extension. Or, as in the current draft, refer (in part) to
*another* registry; in the case of the current draft: the IANA language
subtag registry; ok, that is a registry, but not specifically for that
extension.



Den 2011-07-07 23:00, skrev "Doug Ewell" <[e-mail]>:

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

I agree that "URL: http://www.unicode.org/Public/cldr/latest/core.zip",
referring to a rather larger zip-file, containing *lots* of other stuff,
*unrelated* to the registry (for the "mechanisms" part) for this extension,
is highly unsatisfactory. It shouldn't be a zip-file (nor any other kind of
non-plain-text file; though a directory with plain text files would be ok),
and it should be a URL to *only* the registry for the extension.


    /Kent K




Sent via BlackBerry by AT&T