At 04:05 06/07/23, JFC Morfin wrote:
4.3. IANA registries. .... In the case of IANA registries there is no market
alternative [we saw that in the alt-root case]. The control of a IANA registry
can therefore be strategic. Until now the IANA had three main areas: numbers,
names, protocol parameters. The numbers/names are pure Internet issues but
were considered sensible enough to be delegated to ICANN. The new area of
languages
This is not a new area. IANA has managed a language tag registry
since around 1995 (see RFC 1766). But it is important to note that
IANA just registers language tags (or since recently, language
subtags), not languages.
is not an Internet issue,
RFC 1766, RFC 3066, as well as its approved successors
(draft-ietf-ltru-registry, draft-ietf-ltru-initial and
draft-ietf-ltru-matching) only deal with language tags
on the Internet. It is difficult to understand how language
tagging on the Internet would not be an Internet issue.
is far more important and sensible than names and numbers,
I wouldn't be co-chair of the LTRU WG if I wouldn't believe
that language tagging is important, but there are far more
important issues (it's e.g. easy to show that 'charset'
tagging is much more important than language tagging,
because the consequences of failures are much greater).
Also, I agree that language tagging occasionally can be
a sensible issue (a look at the ietf-languages(_at_)iana(_dot_)org
mailing list would definitely give that impression), but
by and large, most language tags are used in practice
without any problems.
and is de facto [this is what I object] delegated to UNICODE.
It's difficult to object to something that isn't the case.
The language subtag registry is de facto delegated to ISO
(for language codes, country codes, and script codes) because
the IANA registry (except for blunders by ISO that we hope
they won't make anymore) just reflects the relevant ISO
standards. Of the above three kinds of codes, language codes
are obviously the most important (no language tag without a
language code), and script codes are the least important
(most language tags don't need a script code). The Unicode
consortium is designated as the for registration authority
for script codes. But this doesn't mean that they can assign
new script codes at will; ISO 15924 (see e.g.
http://www.unicode.org/iso15924/standard/) describes that
new codes need at least four positive votes from the six
voting members of the Joint Advisory Committee. Only one of
these members is from the Registration Authority (Unicode),
all the others are from other, ISO-related, organizations.
The IETF is obviously not prepared to this kind of fundamental conflict.
In order to talk about whether the IETF is prepared for a certain
kind of conflict, we first would need to know what kind of conflict
this is. But I can't find any fundamental conflict in the paragraph
above.
5. IETF strategy. There are cases where a possible solution is a significant
change of the IETF, or even to kill the IETF itself. The conflict I am engaged
into, is certainly of that nature. RFC 3935 gives "IETF leaders" the capacity
to address such situations, except when the opposed option is defended by
one/several IETF leaders. We should not consider that such conflicts are
exceptional: the lack of architectural guidance by the IAB raises several
other issues. After the Multilingual Internet, what about the multilateral,
the multitechnology, etc. support?
There are two ways to understand "Multilingual Internet" above.
One is that the Internet is already to the most part multilingual:
There are Web pages in a large number of langugages, emails are sent
around daily in a similar number of languages, and so on, and some
of the remaining issues, mostly in the area of identifiers, are either
on the verge of being fully deployied (IDN) or at least work has started
(internationalized email addresses).
The other way to understand "Multilingual Internet" is that the
"Multilingual Internet" is something completely different from what
we have now, much more multilingual for the end user, or whatever.
But while we have heard much buzzwording about that, we haven't
seen any of that in any actual kind, shape, or form, nor have we
actually been told what it's going to look like, or how it's going
to be better than what we have now (see previous paragraph).
So it's vaporware even by the standards of vaporware.
A similar analysis can be made for "multilateral" and "multitechnology"
above. Of course the Internet is "multilateral", it allows multiple
parties to communicate with each other. Of course it is "multitechnology",
on many levels (from the physical and link layer up to the applications
layer).
Regards, Martin.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp
mailto:duerst(_at_)it(_dot_)aoyama(_dot_)ac(_dot_)jp
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf