Referencing an alias resource file in 3066:bis

Addison Phillips [wM] aphillips at
Sat Mar 6 12:14:53 CET 2004


I'm not quite sure I understand your proposal. If by "an alternate resource validate language-tags" you mean "a way to implement tags that use
a different valiation scheme than the one in RFC3066" (e.g., one in which
the subtags have a different meaning) then I would point to the extension
mechanism. "x-something" can have externally defined semantics.

If that means "a way to implement registered values on an automatic basis",
we can add text to the IANA registration section requiring some additional
file formats, such as comma delimited or XML, be maintained for each
registration or for the lot of them (or both). This would assist
implementers a little bit (the REAL problem, you'll note isn't the small
number of registrations: it's the availability of the underlying ISO
standards in a machine parseable format).


Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force

Internationalization is an architecture.
It is not a feature.

  -----Original Message-----
  From: ietf-languages-bounces at
[mailto:ietf-languages-bounces at]On Behalf Of Mike Ksar
  Sent: vendredi 5 mars 2004 20:25
  To: IETF-languages list
  Subject: Referencing an alias resource file in 3066:bis

  I have not seen any feedback on my inquiry about the possibility of
referencing an alias resource file for language tags that do not follow the
syntax of 3066:bis.  I am not thinking of this as part of the extension
mechanism but as an alternate resource file to allow the implementer to
choose an additional resource file at IANA or externally to validate
language-tags.  This would address the issues raised by the example on
i-klingon deprecation and other examples that have not been raised yet for
implementations that do not follow the exact syntax of 3066:bis.

  Mike Ksar

  -----Original Message-----
  From: ietf-languages-bounces at
[mailto:ietf-languages-bounces at] On Behalf Of Peter Constable
  Sent: Tuesday, February 24, 2004 8:54 AM
  To: IETF-languages list
  Subject: RE: (iso639.1574) New ISO 639 language identifier - Klingon

  > From: ietf-languages-bounces at [mailto:ietf-languages-

  > bounces at] On Behalf Of Addison Phillips [wM]

  > According to the rules in place in RFC3066 (not bis), as I understand


  > the tag 'i-klingon' will never be *deleted*, only deprected with a


  > 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

  ( 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


  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.







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

  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 Constable

  Globalization Infrastructure and Font Technologies

  Microsoft Windows Division


  Ietf-languages mailing list

  Ietf-languages at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Ietf-languages mailing list