 |
 |
Making things work In message <[log in to unmask]> Harald Alvestrand writes: > you are somewhat late in proposing a freeze based on 639:1988, since a lot > of the changes since 1988 (like the change of code for Yiddish) were > incorporated already in RFC 1766. > > In general, both RFC 1766 and RFC 3066 were written from the viewpoint that > the maintenance of the codesets was an ISO activity, and that having > something mainatined by the IETF separately from the ISO activity would be > a recipe for disaster. Having ALMOST equal sets of codes for languages is a > Bad Thing (see my earlier vituperative comments on 639-2's T and B codes..) > > The particular solution that was proposed by JAC, and referred to in RFC > 3066, was not a freeze on ISO 639-1, but a freeze on *adding new two-letter > codes where a three-letter code has already been assigned*. What would work of course, would be for RFC 3066 to refer to the 2-letter codes in ISO 639-1 _at_the_time_of_publication_ being in scope, while any additions to ISO 639-1 _after_the_time_of_publication_ would be out of scope, and not intended to be used in implementing RFC 3066. Any additions to ISO 639-1, for whatever reason, could be explicitly flagged in any ISO documentation (and if necessary in any IANA documentation by the IANA Registration authority) that these later 2-letter codes should NOT be used in relation to implementing RFC 3066. That could satisfy both needs expressed so far (for stability, and for potential extendibility). Any comments on that? 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