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

[John C Klensin <klensin@jck.com>]

--On Wednesday, 18 July, 2001 14:36 -0400 Keith Moore
<moore@cs.utk.edu> wrote:

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

I believe in all of these but the last.  Perhaps it is just lack
of knowledge on my part, but I don't understand how to do fuzzy
matching in a deterministic way.  Fuzzy matching, to me, always
implies heuristics and, in a changing environment (as new names
are registered and others drop out of the DNS space), heuristics
imply that a given search string might resolve to one name and
target on one day and a different one on a different day.  That
is a property I hope to never see in the DNS.

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

Well, I don't know anyone who has seriously proposed a non-DNS
name space.  The most radical proposals on the table are, to my
knowledge, both my strawmen:

	* Staying within the DNS, but using a different Class to
	force application changes and create an unambiguous
	distinction between "upgraded" and "non-upgraded"
	clients.  The arguments against that include important
	"slow deployment" and "difficult transition" issues, a
	risk-free environment (even the proponents of ACE see
	some risks), but are otherwise painfully similar to the
	ACE-versus-UTF8 discussion we have seen in the last week
	or so.
	
	* Layering additional search-type facilities on top of
	the DNS, with most or all of the "internationalization"
	work being done in those additional sublayers, rather
	than relying exclusively on the DNS.

I hope it is obvious that neither of these is a "discard the
DNS, find another namespace and mechanism" approach.

And I note for the record that I haven't suggested, this week,
that the IDN WG declare success and shut down without proposing
any modifications to the DNS or the way it is used.

   john