Date: 2004-12-12 15:55
From: "Peter Constable" <petercon(_at_)microsoft(_dot_)com>
To: ietf-languages(_at_)alvestrand(_dot_)no, ietf(_at_)ietf(_dot_)org
You have not responded to the point that accessibility of source ISO
standards is supposed to be a major factor, yet the draft itself clearly
indicates otherwise.
The source for the statement claiming accessibility as a
major factor has been indicated to be the author or
authors of the draft. I can't explain why it says what
it says; I suggest that you direct that question to
the author(s).
That is a problem for existing implementations of RFC 3066
tags, which can obtain official, internationally agreed
descriptions of the codes in two languages.
Descriptions (language names) are beyond the scope of RFC 3066. It is a non
sequitor to claim that this draft creates a problem for existing
implementations of RFC 3066 on this basis.
3066 refers to "interpretation" of the codes and defers
that interpretation to that given by the ISO lists. One
cannot have an "interpretation" based on the lists without
the natural language definitions which are paired with
the codes. It is a fact that those definitions are
available in two languages in the ISO lists, and that
the proposed replacement for the ISO lists would eliminate
one of those languages.
OK, continuing your hypothetical example and its relationship
to language, suppose that there is another civil war and
that what now corresponds to "US" is split into Blue America
and Red America. Further suppose that in due course ISO
assigns some other code to one of those countries and retains
"US" for the other, and that that happens after the proposed
registry is set up with a definition for "US" and some
description referring to the "old" use.
That is a scenario that has been well considered: it would be very bad IT
practice to redefine a metadata tag "US" to have a narrower denotation than
it previously did, as that immediately breaks an unknown amount of existing
data. If ISO were to make such a change in the meaning of "US", then IT
implementations *absolutely should not* follow suit; the ID "US" must retain
it's prior, broader meaning.
So long as it is known what definition of "US" applied at
the time, there is no problem. This is dealt with in IT
all the time; "EST" has had many definitions in terms of
exact offset from UTC, and when it goes into and out of
effect (likewise for other time zones). Yet we manage to
be able to state with precision the offset and effective
times of "EST" well into the past, and without declaring
that a single value must hold true for all time. I have
provided a URI to the time zone data; a similar mechanism
could be used to track historical values for ISO language
and country codes. Given the existence of such proven
technology, there is no need for the incompatible approach
outlined in the draft.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf