Re: [idn] Determining equivalence in Unicode DNS names

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

--On Tuesday, 22 January, 2002 10:41 -0500 "Michael Froomkin -
U.Miami School of Law" <froomkin@law.miami.edu> wrote:

> Perhaps this is the decision -- if conscious decision it was?
> -- that it is time to revisit?
> 
> I recognize this is not a small or necessarily easy change to
> make, but after following this debate for some time, I'm
> increasingly persuaded that it does seem to provide the best
> long-run solution...and doesn't affect backwards-compatibility
> either, does it?

Well, I made the "new class" proposal for a reason, and I still
believe in the reasoning (which you have more or less summarized
above).  The argument against it, to me, is the number of
problems it _doesn't_ solve.  While we could make some changes
in matching/ equivalence models via a new Class, it isn't going
to solve problems with near-matches that might be considered
matching and might not.  It isn't going to solve problems that
really require different actions for different languages.  It
isn't going to solve problems for people who really want phrases
and not invented words.  It isn't going to resolve the insane
problem of which "Joe's Pizza" is entitled to exclusive,
worldwide, use of "joespizza.com".  And it isn't going to solve
a very large number of other problems.  Consequently, whatever
we do, we are going to need other systems --whether "above DNS"
layering or otherwise-- to deal with those issues.

In that context, let's horribly oversimplify things and assume
that we can make a three-way choice as far as the DNS is
concerned.

	(i) We can do some fairly fancy mapping and exclusions,
	then encode IDNs into the DNS.  IDNA (including
	nameprep) is clearly an instance of this; all of the
	other proposals are seeming to me to be nearly
	isomorphic to it as far as the major issues and
	capabilities are concerned.
	
	(ii) We can do the new class stuff, cleaning up some of
	the compatibility and matching issues, but making only a
	marginal improvement over IDNA in the grand scheme of
	things.
	
	(iii) We can prohibit _all_ encoding of non-LDH
	characters in the DNS, relying entirely on the layered
	stuff to do the internationalization job.

Now, to me, the questions then become whether IDNA (or the first
option more broadly) is likely to cause enough damage to push us
toward the second or third.  And, if the answer is "yes",
whether the advantages of the hard-to-deploy second alternative
make it more attractive than the third one.

I don't know.  But my instincts right now --reinforced by the
lack of interest in, and willingness of people to work on, "new
class"-- are that the real choice lies between the first and
third of those options.    And, of course, for whatever it is
worth, "postpone/prohibit CDN" is, I think, just a special case
of the third option: while the problems with Chinese are
somewhat different, I'm convinced that we have somewhat parallel
equivalence or look-alike problems with almost any language or
script we might focus on.

    john


----

> On Mon, 21 Jan 2002, John C Klensin wrote:
> [...]
>> 
>> (iii) One could adopt the "new class" model, using that class
>> to impose a somewhat different set of matching rules by
>> redefining the query types.  That was, you will recall,
>> proposed and rejected (or, more accurately, ignored), I think
>> mostly because people were concerned about the length of time
>> it would take to deploy.
> --