Sample IANA language subtag registry

[Peter Constable]

> From: Mark Davis [mailto:mark.davis at jtcsv.com]

> I would agree with you IF the respective authorities
> 
> (a) maintained version control,

??? There has never been any plan for versioning of the tag sets
permitted under RFC1766/3066. I see no reason to fault ISO 639 etc. for
that. Even if they did version code tables, RFC 3066bis still would not.

> (b) publicized data in a way to allow a simple mechanical way to
enumerate
> all the codes that were valid in a particular version,

Ditto for RFC 1766/3066, though that would not be difficult to change
for any of these, and the way to solve the problem is *not* for IETF or
IANA to start publishing code tables for ISO 639, ISO 15924 and ISO
3166.

If you want to see ISO 639 IDs published in a machine-readable data
file, it is reasonably likely that the ISO 639/RA-JAC would be willing
and able to accommodate that request.


> (c) and provided stable codes.

An issue only for ISO 3166, and the draft RFC has provisions for dealing
with that.

 
> For these reasons and others, we followed the path suggested by Doug's
> earlier comments; it is by far best to simply provide all of the data
in
> *one* place that:
> 
> (a) allows any user of RFC 3066bis to determine precisely whether a
tag is
> valid or not,
> 
> (b) provides for absolute stability

It sounds like what you are really arguing for is creating an
independent standard for language, script and country IDs. I understand
the issues you are raising, but (a) I think the stability issue is being
blown out of proportion except in the case of ISO 3166 (which some have
for years thought to be an issue), and (b) I don't think the solutions
being proposed are appropriate. 

As long as the RFC says that the source for particular sub-tags is ISO
639, then there will be people that go to that source to look for IDs
rather than a data file on the IANA site (and likewise for 3166 and
15924). So you won't get around the problems of synchronization and
consistency with others unless you remove those references from the RFC
and instead say that the source of the subtags is the data file. If
that's what you want to happen, then you should prepare a draft that
reflects it.


> We considered the work involved in synchronization, and decided that
since
> we needed the registry to be updated in any event with each change in
the
> ISO standards (for stability),

Why does anything need to change in the registry if a new ID is added to
639 or 15924 except in the rare case that the thing added obsoletes some
registered tag (like tlh replacing i-klingon)?


> The other advantage that RFC 3066bis brings is 'future-proofing';
because
> the structure is more clearly defined, when I get a tag from some
up-version
> of the standard, I can still parse out the structure to determine
whether it
> is well-formed or not, and determine what the individual pieces are
supposed
> to designate.

What has this to do with having a registry that duplicates the code
tables of ISO standards? (I can't actually even figure out what you're
saying -- what is "the standard"? -- but it doesn't seem like it relates
to this thread.)



Peter
 
Peter Constable
Globalization Infrastructure and Font Technologies
Microsoft Windows Division