John Clews writes, in response to the current debate: Michael Everson, quite rightly, is concerned to achieve the effect of freezing the number of 2-letter codes that are to be used in implementing RFC 3066. I agree entirely with this. However, there are details about both ISO 639:1988 and ISO 639-1 (not yet published but due to be published during 2001) which mean that what the ISO 639 Joint Advisory Committee proposed in Washington in February 2000, will pose problems for the Internet community and in fact all users. What follows is an attempt to satisfy both apparently opposed groups, and to find a workable solution for all users of language codes. It works through suggesting freezing a different animal, at a more obvious freezing point (1988). This email contains all the details about what is required (largely as an IETF activity rather than an ISO activity) to achieve these ends: please study the detail carefully before rushing to reply. In passing, Michael also pointed out that: > I am cc:ing the IETF languages list for the first time on this. I am > sure that many of them will be extremely unhappy to hear that members > of the JAC are working to scupper what we understood to have been a > very good deal. This is fine: there is only the practical issue of triplication of emails in some cases, for some users. Is it worth holding the discussion only on the IETF languages list <[log in to unmask]>, at least initially, and others joining that list as necessary? In message <[log in to unmask]> Michael Everson writes Re: (iso639.276) AW: (2 of 3) Reply: adding more 2-letter codes > At 09:17 +0100 2001-02-27, H�vard Hjulstad wrote: > > > Having been through all the items in the alpha-3 list that would > > be blocked from inclusion in the alpha-2 list if we stick to the > > freeze option, I must say that I agree that it is artificial and > > undesireable not to add new alpha-2 identifiers after the publication > > of 639-1. Michael Everson wrote in reply: > For a certain set of identifiers currently used in internet language > tagging. The point being, for heaven's sake, if you want to add two > letter identifiers for those particular items, do so now, and then > keep to the promise/agreement/resolution the JAC made. > > The alternative is to destabilize the usefulness of ISO 639 for > internet use, because we will have to then go and rewrite the RFC > again There is opposition to freezing ISO 639-1 from the representatives of at least three national member bodies of ISO/TC37 (Terminology) who have been active in development of ISO 639-1, because (a) ISO 639-1 has different criteria for adding new codes to the criteria in ISO 639-2; (b) in some programming languages and applications, the use of _only_ 2-letter codes for languages seems to have been built into the system design, and overcoming this limitation, and coping with backwards compatibility, is NOT a trivial task. These are not simply "pie-in-the-sky theoretical considerations" as Michael Everson suggests, later in his email. Discussion so far has not outlined any ways of overcoming the problems outlined above. This email outlines some practical proposals. I think that RFC 3066 _WILL_ have to be rewritten to reflect this exact point. Not doing so will make for all sorts of confusions. It can be done in a way which will keep work to a minimum. Simply rewriting RFC 3066, to refer only to ISO 639 (2-letter codes) and to ISO 639-2 (3-letter codes), and simply reassigning a small number of codes as 3-letter codes from ISO 639-2, in place of the (as yet unpublished) ISO 639-1, seems to be much the simplest solution, and I am happy to suggest small amendments to RFC 3066 which would enable this to be done. RFC 3066 should state that ISO 639:1988 is frozen. ISO 639-1 (as yet unpublished) should not be refered to in RFC 3066. It will take very little rewriting of RFC 3066 to make it work: instead of refering to ISO 639-1 for 2-letter codes, refer simply to: ISO 639:1988 (E/F) - Code for the representation of names of languages - The International Organization for Standardization, 1st edition, 1988-04-01 Prepared by ISO/TC 37 - Terminology (principles and coordination). As I recall, freezing 2-letter codes in Internet use at this point (ISO 639:1988) was Michael Everson's _original_ proposal, prior to his later proposal of freezing ISO 639-1 2001 (not yet published): the Internet community should not tie itself to yet unpublished standards, a position which RFC 3066 currently gets quite near, as it stands now. There will be a need for IANA to reassign some language tags, and deprecate others, but this has already been done for some of these tags, as can be seen from the IANA website. The examples at the end of this email also follow the pattern of the IANA website. It may also be worthwhile to ensure that the only 2-letter codes from any part of ISO 639 which would be used in implementing RFC 3066 are those in the published text and tables of ISO 639:1988, and not any further amendments by the ISO 639 Maintenance Agency between 1988 and 2001. NB: this would have the effect of freezing which Michael Everson, quite rightly, is concerned to achieve. In particular, the following tags (and only those tags) which would have not yet received much use, would need to be rewritten, and to go through the IANA Language Tag registration process. Tag Description Reference Notes ------- ----------------------------- --------- --------- no-bok Norwegian "Book language" Deprecated: use ISO 639-2 nob, registered Feb. 18, 2000 [ALSO ADD] nb Norwegian "Book language" Deprecated: use ISO 639-2 nob, registered Feb. 18, 2000 [Note nb -> nob changes in both Notes on Deprecation above] no-nyn Norwegian "New Norwegian" Deprecated: use ISO 639-2 nno, registered Feb. 18, 2000 [ALSO ADD] nn Norwegian "New Norwegian" Deprecated: use ISO 639-2 nno, registered Feb. 18, 2000 [Note nn -> nno changes in both Notes on Deprecation above] i-navajo Navajo [Burke] Deprecated: use ISO 639-2 nav [remove text "registered Feb. 18, 2000"] [ALSO ADD] nv Navajo [Burke] Deprecated: use ISO 639-2 nav [remove text "registered Feb. 18, 2000"] [Note nv -> nav changes in the Note on Deprecation above] i-lux Luxembourgish [Wimmer] Deprecated: use ISO 639 ltz [remove text "registered Sept. 9, 1998"] [ALSO ADD] lv Luxembourgish [Wimmer] Deprecated: use ISO 639 ltz [remove text "registered Sept. 9, 1998"] [Note lv -> ltz changes in the Note on Deprecation above] I look forward to any further comments which aim to achieve a solution to this. Best regards John Clews -- John Clews, SESAME Computer Projects, 8 Avenue Rd, Harrogate, HG2 7PG tel: +44 1423 888 432; fax: + 44 1423 889061; Email: [log in to unmask] Committee Chair of ISO/TC46/SC2: Conversion of Written Languages; Committee Member of ISO/IEC/JTC1/SC22/WG20: Internationalization; Committee Member of ISO/TC37: Terminology