> From: Peter Constable > I'd also like to observe that various members of TC 37 and the ISO 639- > RA/JAC have observed or participated in the development of this draft. For > my part, it is not the draft I would have developed if I had undertaken it, > but I see no problems with it from a TC 37 or ISO 639-RA/JAC perspective. I realized there are some additional comments I should make on the proposed revision of RFC 3066 from a TC 37 perspective. (Note: these comments are offered as an active participant in the work of TC 37 and as a member of the ISO 639-RA/JAC. They are not official statements of TC 37 or any of its sub-committees, but I believe they are a reasonable representation of prevailing opinion within TC 37.) One of the issues this draft attempts to deal with is potential instability of ISO identifiers and the damaging impact that can have on existing content and implementations. ISO 639-2:1998 specifies that its language identifiers may be changed given compelling reasons, but that an identifier may not be reassigned for a period of five years after such a change. ISO 639-1:2002 specifies that an identifier may not be reassigned for a period of *ten* years after such a change. In practice, there has been no case in which an ISO 639-1 or ISO 639-2 identifier was withdrawn and later reassigned. The ISO 639-RA/JAC and TC 37/SC 2 have increasingly taken up concerns for stability to the point that ISO DIS 639-3 has a very strict stability policy designed to ensure that declarations made on existing information objects do undergo any adverse changes. This includes a restriction that identifiers that are deprecated may never be reassigned with a different meaning. To the extent that this draft attempts to protect language tags from instability of ISO identifiers, TC 37 considers it very important to ensure that metadata elements declaring linguistic properties of information objects have stability in relation to their meaning, but feels that there is no significant risk of such instability coming from ISO 639. On the other hand, TC 37 has been very concerned about changes that have been made in ISO 3166 country identifiers in which identifiers that had prior meanings were reassinged with new meanings. ISO 3166 country identifiers have been used by applications of the ISO 639 family of standards to indicate sub-language distinctions, such as differences in spelling or lexical items. Such changes to country identifiers have potential for very detrimental effects on applications of the ISO 639 standards. I note with interest that ccTLDs make use of ISO 3166 in spite of its potential for instability. In the case of ccTLDs, however, there is a considerable infrastructure for dealing with this: the DN system and strict procedures for deploying changes in ccTLDs onto domains. In the case of language tags, there are no such procedures for deploying changes in meanings of country identifiers across instances of metadata elements used to declare linguistic properties of information objects, nor is anything of that sort feasible in the general case. It may be that in the context of certain Internet protocols it is feasible to deploy changes in ISO 3166 across instances of language tags used by those protocols -- I don't know if this is true for any Internet protocols or not. It is certainly not true of all applications of ISO 639 standards that also make use of ISO 3166. In the latter regard, I would like to point out that the IETF specification RFC 3066 is refereced for use in metadata in many other places than IETF protocols, one important application of this specification being its use for the xml:lang attribute in XML. To the extent that ISO 3166 country codes can be reassigned with new meanings, the potential for detrimental effects on RFC 3066 language tags at least in contexts such as XML is of concern to TC 37. To the extent that the proposed draft aims to protect language tags from instability of ISO 3166 country identifiers where there is potential for detrimental effects on metadata elements declaring linguistic properties of language resources and other information objects, TC 37 would view the intent to achieve stability a good thing. It may be that the way in which it aims to achieve this may not be the best in the IETF context -- that is for IETF and not TC 37 to say. In the long term, though, TC 37 would support measures that would lead to ensuring that language tags defined by RFC 3066 or its successors are not subject to detrimental changes in semantics. Peter Constable _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf