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

[Peter Constable]

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

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.

Or the server could respond to a request along the lines of

http://www.iana.org/langtag_alias.asp?tag=i-lux

by returning parsable information regarding the relationship between
i-lux and lb.


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.


Peter
 
Peter Constable
Globalization Infrastructure and Font Technologies
Microsoft Windows Division