(iso639.1574) New ISO 639 language identifier - Klingon

[Harald Tveit Alvestrand]

--On 24. februar 2004 08:54 -0800 Peter Constable <petercon at microsoft.com> 
wrote:

>> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
>> bounces at alvestrand.no] On Behalf Of Addison Phillips [wM]
>
>> According to the rules in place in RFC3066 (not bis), as I understand
> them,
>> the tag 'i-klingon' will never be *deleted*, only deprected with a
> reference
>> to 'tlh'.
>
> I think what Mike was suggesting was that the RFC say something explicit
> about how alisasing in such cases is dealt with. It currently is silent
> on this, so while I could look in the registration file for i-lux
> (http://www.iana.org/assignments/lang-tags/i-lux) and find that it "has
> been deprecated by ISO 639 lb", there's nothing in the RFC to tell me
> that that will always be done, or that it will always be done the same
> way.

RFC 3066 does say that a generating application MUST use the ISO code:

   4. When a language has both an IANA-registered tag (i-something) and
      a tag derived from an ISO registered code, you MUST use the ISO
      tag.  NOTE: When such a situation is discovered, the IANA-
      registered tag SHOULD be deprecated as soon as possible.

At the time this was written, we didn't have Håvard to feed us the new 
registrations in real time, so I imagined that we could find out about new 
ISO codes months or years after its registration....

> And more could be done to make life easier for application developers,
> or even to allow for more intelligent apps. For instance, the IANA
> lang-tags folder could contain a tab- or comma-delimited file alias.txt
> containing alias mappings; e.g.
>
> ;deprecated,best_practice
> i-lux,lb
> i-navajo,nv
> no-bok,nb
> no-nyn,nn
>
> etc.

That seems like a not unreasonable thing to do, even though giving a 
machine-parseable list of all registered tags would be higher on my list .-)

I haven't gotten around to critiquing the latest version of 3066bis yet, 
but it seems to me that a subtag registry could have a much greater need to 
publish "derived" files to make it easy to correctly verify what tags in 
fact exist and are supposed to be used than a whole-tag registry has. Does 
3066bis discuss the functioning of the registry at all?

Also, "put your money where your mouth is" is a popular IETF game - if it's 
simple to generate those data files, someone who's interested could hack up 
the scripts to do it, provide a "contribution" site that has the files, and 
donate the scripts to IANA if they're willing to run them.

> The fact is that aliases can and do exist. The question is whether we
> are doing all that we could to deal with that reality.

The answer is definitely "no". The more relevant question is what the 
optimum use of resources is...... IANA's currently extricating itself from 
a situation that allowed a multi-month registration backlog to build up in 
the IETF registries... NOT the right time to ask for creativity......

                 Harald