> From: ietf-languages-bounces@xxxxxxxxxxxxx [mailto:ietf-languages- > bounces@xxxxxxxxxxxxx] 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf