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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf