Stability of valid IDN labels

[John C Klensin]

--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