Stability of valid IDN labels
John C Klensin
klensin at jck.com
Sun Apr 20 20:50:20 CEST 2008
--On Sunday, April 20, 2008 1:17 AM +0200 LB
<lbleriot at gmail.com> wrote:
> Dear Vint,
> As co-owners of the Multilingual Internet (that is the French
> translation for "at large"), our position is that we do not
> want to depend on the constraints, because it is not known if
> it will be accepted and how far they will go.
>...
> John Klensin began studying why we could not do otherwise than
> IDNA. This is the first thing to do.
Louis,
The purpose of the "alternatives" effort was never to cause a
rethinking of the IDNA effort, but merely to put the claimed
alternatives in context and examine the tradeoffs involved. It
will move along as I have time and, more important, as I get
specific input from others. But it certainly is not the highest
priority as compared to making whatever improvements are needed
in IDNA.
More important, there is a discussion about IDNs that Jefsey and
I have had many times. Often we seem to be in complete
agreement; sometimes I get notes that appear to indicate that we
are not. I find the combination bewildering, to put it mildly,
because I don't see the difference between the discussions in
which we agree and those in which we do not.
I had assumed that those discussions had all been forward to, or
accurately summarized to, MLTF, and hence that you were aware of
them. However, just in case that is not the case, let me try to
summarize something that has been said many times before.
Almost no one, perhaps no one at all, who has made a serious and
careful study of IDNs believes that they are, or can be, a
complete solution to the many issues of getting identifiers that
are culturally and linguistically completely correct. The
problems come from the DNS and its inability to do
context-dependent (or, more specifically, locale-dependent)
matching of strings. One could make IDNs a little better for
that purpose by making them language dependent. However, that
would make them worse for other purposes and would cause
complications for the many contexts in which non-words (e.g.,
strings with embedded digits) are used in domain name labels.
There are other tradeoffs between ease of use, implementation,
or deployment that might have yielded IDN answers different from
IDNA (and, again, the "alternatives" document is intended to
evolved into a discussion of those tradeoffs), but none of them
solve the multicultural problem -- some are just a little better
or a little worse than others for that purpose.
Instead, real progress on culturally-sensitive identifiers
requires moving completely out of the DNS context and into a
context in which use (and storage, and management) of such
identifiers is the primary objective. Many of us think in terms
of such efforts lying "above" the DNS, with culturally-specific
identifiers (and matching rules, etc.) resolving to DNS names
that, in turn, resolve to network identifiers, but a system that
would be parallel to, or replace, the DNS is plausible (at least
in principle -- the deployment issues associated with getting
from "here" to "there" are very serious and complex). But
whether those other efforts are complementary to the DNS or
instead of it, IDNA needs to work as well as possible for the
job of representing DNS-based identifiers in a broad range of
scripts. Jefsey has encountered, and you will encounter,
considerable resistance if you come to a mailing list or WG with
a mission of improving IDNA and say "you should be addressing
this other issue instead" or "don't do any thing more with IDNA
until you have addressed our issues". "IDNA won't solve this
particular problem" is more relevant, but most of us already
know that -- you don't need to convince us because we are
already convinced (for some class of problems) and trying
nonetheless wastes everyone's time.
best,
john
More information about the Idna-update
mailing list