Referencing an alias resource file in 3066:bis

Addison Phillips [wM] aphillips at webmethods.com
Tue Mar 9 02:34:28 CET 2004


Hi Mike,

Thanks for the note.

While it would be possible to add alpha3 country codes to the draft, there
doesn't seem to be any point in doing so. Unlike ISO639-1/-2, there is no
difference in the range of entries in the two sets of ISO3166 codes. In
other words, every entity that has an alpha3 code also has an alpha2 code.
In fact, this is in some ways the source of the problem with ISO3166--the MA
has a limited range of codes available (about 500) and the requirement that
every country get both an alpha2 and alpha3 code more-or-less means eventual
reassignment of some codes.

An earlier version of the draft used the alpha3 codes as the resolution
mechanism when alpha2 codes were ambiguous. We eliminated that in favor of
the UN numeric codes because unlike the alpha3 codes there is no danger of
instability and because the UN codes provide some other values that some
folks might find useful. Since the alpha3 codes don't add any value and make
parsing slightly more difficult, we removed them.

Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

  -----Original Message-----
  From: Mike Ksar [mailto:mikeksar at microsoft.com]
  Sent: lundi 8 mars 2004 15:36
  To: aphillips at webmethods.com; IETF-languages list
  Subject: RE: Referencing an alias resource file in 3066:bis


  Addison,



  Thanks.



  One more questions.  Would it be possible to add an optional attribute to
have RFC 3066bis reference the 3-alpha country codes in 3166?  Currently you
allow the 2-alpha country codes in ISO 3166 and the 3-digit UN country code
(added in the latest draft).



  Mike Ksar




----------------------------------------------------------------------------
--

  From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
  Sent: Monday, March 08, 2004 1:54 PM
  To: Mike Ksar; IETF-languages list
  Subject: RE: Referencing an alias resource file in 3066:bis



  This would be an addition to section 3 (IANA considerations).



  Addison P. Phillips
  Director, Globalization Architecture
  webMethods | Delivering Global Business Visibility
  http://www.webMethods.com
  Chair, W3C Internationalization (I18N) Working Group
  Chair, W3C-I18N-WG, Web Services Task Force
  http://www.w3.org/International

  Internationalization is an architecture.
  It is not a feature.

    -----Original Message-----
    From: Mike Ksar [mailto:mikeksar at microsoft.com]
    Sent: lundi 8 mars 2004 13:32
    To: aphillips at webmethods.com; IETF-languages list
    Subject: RE: Referencing an alias resource file in 3066:bis

    Addison,



    XML is a possibility for sure.  Where would this be described in
3066bis?



    Mike Ksar




----------------------------------------------------------------------------

    From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
    Sent: Monday, March 08, 2004 11:03 AM
    To: Mike Ksar; IETF-languages list
    Subject: RE: Referencing an alias resource file in 3066:bis



    Hi Mike,



    That sounds like a good idea. What format would such a file take? I've
seen suggestions for comma-separated values. Personally, I'd prefer XML
files at the end of a URL. The registration information really isn't very
complicated, so rendering it up in such a manner wouldn't be that difficult.



    Addison

    Addison P. Phillips
    Director, Globalization Architecture
    webMethods | Delivering Global Business Visibility
    http://www.webMethods.com
    Chair, W3C Internationalization (I18N) Working Group
    Chair, W3C-I18N-WG, Web Services Task Force
    http://www.w3.org/International

    Internationalization is an architecture.
    It is not a feature.

      -----Original Message-----
      From: Mike Ksar [mailto:mikeksar at microsoft.com]
      Sent: lundi 8 mars 2004 10:46
      To: aphillips at webmethods.com; IETF-languages list
      Subject: RE: Referencing an alias resource file in 3066:bis

      Addison,



      Let me clarify.  I am talking about an alternate resource file that
uses a different syntax layout than what RFC 3066 or RFC 3066bis uses with
the same basic information and semantics.  I am not talking about having
different semantics.



      Mike Ksar




--------------------------------------------------------------------------

      From: Addison Phillips [wM] [mailto:aphillips at webmethods.com]
      Sent: Saturday, March 06, 2004 3:15 AM
      To: Mike Ksar; IETF-languages list
      Subject: RE: Referencing an alias resource file in 3066:bis



      Hmmm....



      I'm not quite sure I understand your proposal. If by "an alternate
resource file...to 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



      Addison P. Phillips
      Director, Globalization Architecture
      webMethods | Delivering Global Business Visibility
      http://www.webMethods.com
      Chair, W3C Internationalization (I18N) Working Group
      Chair, W3C-I18N-WG, Web Services Task Force
      http://www.w3.org/International

      Internationalization is an architecture.
      It is not a feature.

        -----Original Message-----
        From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no]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 alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no] 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 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



        _______________________________________________

        Ietf-languages mailing list

        Ietf-languages at alvestrand.no

        http://www.alvestrand.no/mailman/listinfo/ietf-languages
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-languages/attachments/20040308/65b0663b/attachment-0001.htm


More information about the Ietf-languages mailing list