I have read many interesting and good arguments in this email thread. I am
confident that ISO/TC37, ISO/TC46, and the JAC will take all these arguments
into consideration.
Democracy normally means that a dicision ("final" or not) is valid until a
new decision is made that cancels it. In international standardization the
situation is somewhat different: A standard is valid for 5 years only, at
which point in time a positive decision needs to be made whether to renew it
or change it. As ISO committees we need to stick to these rules: We aren't
writing for "eternity", we are writing to satisfy current needs.
Personally I will bear all the good arguments in mind, and I will do my best
to try to satisfy the needs that are "current" at any point in time.
I don't think there is that much point in going any further with this
discussion NOW. Let's re-iterate the issue in 5, 10, and 15 years.
Best regards,
Havard Hjulstad
-------------------------
Havard Hjulstad mailto:[log in to unmask]
Radet for teknisk terminologi (RTT)
(Norwegian Council for Technical Terminology)
Postboks 660 Skoyen
NO-0214 Oslo, Norway
tel: +47-22049225, dir: +47-22049259
faks: +47-22434224
http://www.rtt.org/
-------------------------
-----Original Message-----
From: Harald Alvestrand [mailto:[log in to unmask]]
Sent: 6. mars 2001 23:07
To: [log in to unmask]; [log in to unmask]
Cc: [log in to unmask]; [log in to unmask]
Subject: (iso639.281) Not freezing ISO 639-1
At 15:09 06/03/2001 +0000, John Clews wrote:
>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.
John,
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*.
The set of languages "permanently discriminated against" is thus fixed as
the set that made ISO 639-2, but did not make ISO 639-1 before the JAC
decision.
Any new language is free to add both 2-letter and 3-letter code, as was
done for nb and nn, without causing any confusion.
BTW - a formalism: RFC 3066 will never change; RFCs never do.
If we want something different to be Internet standard, we will have to
issue a new version, with a new RFC number.
I don't think people will love us if we do so lightly.
--
Harald Tveit Alvestrand, [log in to unmask]
+47 41 44 29 94
Personal email: [log in to unmask]
