New Last Call: 'Tags for Identifying Languages' to BCP

Bruce Lilly blilly at erols.com
Mon Dec 13 02:35:18 CET 2004


>  Date: 2004-12-12 15:55
>  From: "Peter Constable" <petercon at microsoft.com>
>  To: ietf-languages at alvestrand.no, ietf at ietf.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.org
https://www1.ietf.org/mailman/listinfo/ietf


More information about the Ietf-languages mailing list