> Date: 2004-12-12 15:55 > From: "Peter Constable" <petercon@xxxxxxxxxxxxx> > To: ietf-languages@xxxxxxxxxxxxx, ietf@xxxxxxxx > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf