From: ietf-languages-bounces(_at_)alvestrand(_dot_)no [mailto:ietf-languages-
bounces(_at_)alvestrand(_dot_)no] On Behalf Of Bruce Lilly
I don't know where the statement accompanying the announcement came from,
According to the "New Last Call" issued by the IESG Secretary,
the text is "Author's discussion of drivers for this work".
You singled out that one point to comment on as though it were the main
factor.
I mentioned a matter which was repeatedly indicated as a
factor for existing implementations and with which I
strongly disagree.
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.
[regarding the proposed registry vs. internationally-
standardized ISO lists for subtag definitions]
It is certainly the case that only it should be consulted for
determining what sub-tags are valid with what denotation, which was the
intent.
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.
By looking in the sub-tag registry. If ISO changed the meaning of "US"
to something other than what it is now, its meaning for purposes of use in
an IETF language tag would not change, because it would remain stable in
the sub-tag registry. You would be fairly well protected against the whim
of politicians.
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.
Now suppose that one
wishes to produce an appropriate language tag for the text
"moral values" (which clearly has different meaning in Blue
America (telling the truth, admitting to mistakes, etc.) and
in Red America (imposing totalitarian control over others)).
How specifically would the proposed registry handle such a
change in the meaning of "US", and how would the registry
help differentiate the meaning of a 1990's "en-us" tag to
that of the hypothetical time described?
It would leave "US" with it's historic meaning, so that existing data is left
intact. (You wouldn't want a document containing "moral values" created on the
eve of the cival war by someone supporting the Blue America side of the divide
to suddenly get assigned an interpretation of 'imposing totalitarian control
over others'.) New identifiers would be assigned for use in IT applications to
designate the two new countries.
you already have to look beyond the ISO standards for anything more than
English and French
But existing RFC 3066 implementations can get official
descriptions in *both* of those languages; the proposal
would adversely affect those existing implementations by
eliminating the French description.
Of course, it is a more serious defect of the proposal
that it would fail to reflect internationally-agreed
codes and would fail to keep pace with changes...
it would not be new that you have to look beyond the registry itself to
decide what human-readable descriptors you should provide in a product.
It would be new that one could not find a standard
(i.e. official) French-language description in the
list of codes.
Incorrect. The registry for RFC 3066 did not provide a language/country name in
*any* language for any ISO 639 or ISO 3166 identifier. Tags registered under
RFC 3066 included an English-language name and an ASCII-transcription of the
indigenous name; they did not contain French-language names.
Again, you are trying to impose UI-localization concerns that have always been
out of scope for the RFC 1766/3066/... sequence of specifications.
One possibility would be two description fields. But the
registry would need a charset closer to ISO-8859-1 than
to ANSI X3.4 as currently specified. Or an encoding
scheme.
Personally, I don't see the value in something like that. Given the
intent to have a registry that can be machine-readable, changing its
charset from ANSI X3.4 in order to gain descriptors in just one more
language is not worth it IMO.
Fine, use utf-8, which encompasses ANSI X3.4 and
ISO-8859-1 (plus others). The point is that ANSI
X3.4 is inadequate.
There is no point changing the charset to support something that is out of
scope for the specification.
Speaking at least for Microsoft, we're interested in having descriptors
in far more than two languages, and we certainly would not blindly base
the descriptors we present to our customers solely on what a registry
provides, no matter what its charset.
Surely in going from two (the current situation per
RFC 3066) to "more than two" indicates that decreasing
to one (as in the draft proposal) is heading in the
wrong direction. It certainly invalidates the claim
that the proposal is compatible with existing
implementations, at least one of which does make use
of the descriptions currently provided in both
languages in the ISO lists specified by RFC 3066.
Incorrect; you are making false claims about what is specified in RFC 3066.
Peter Constable
Microsoft Corporation
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf