Re: [idn] Re: Back to work (Nameprep) (was: Re: Just send UTF-8 with nameprep (was: RE: [idn] Reality Check))

[Keith Moore <moore@cs.utk.edu>]

John,

> This set of conversations has been very interesting to me, for
> the unfortunate reason that it confirms the tentative, but
> painful, conclusion I reached a few months ago.  Once we get
> down to the really fine details of which characters match and
> which do not, how to disambiguate glyphs from different scripts
> that look (or are) identical, and so on, we need to rely on user
> interfaces and human intelligence (or very close approximations
> to the latter), rather than depending on absolute matching rules.

I think this is true to a large degree.  But I think that to come
up with a practical solution to the problem will require a 
combination of not only user interfaces and human intelligence
on the client side, but also client APIs that reject ambiguous
symbol sequences, registration rules that discourage conflicts, 
nameprep-like canonicalization and folding, and perhaps even
fuzzy matching on the server side.
 
> If we have to do that (and I agree that we will),  then we almost
> certainly need a non-DNS mechanism to support it.

I agree that we can't support this with current DNS protocol 
mechanisms.  However there is so much investment and mind-share
in the DNS name space, that I don't think starting another 
name space that is similar to DNS will get very far.  And if
we're going to have DNS-like names, then we might well be better
off augmenting DNS servers (with appropriate protocol extensions
that allow them to do fuzzy matching) than to try to build a 
completely separate service.    Separate services seem far more
likely to get out of sync with each other and produce inconsistent
results.

Keith