Re: [idn] iDNS transition: end-system vs. infrastructure?

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

--On Friday, 11 May, 2001 18:51 -0400 Keith Moore
<moore@cs.utk.edu> wrote:

>> could someone kindly post a
>> simple list of the reasons they feel "Just do pure UTF-8" is
>> *not* a valid alternative.  I am still not convinced that we
>> should not just use pure UTF-8.
> 
> we cannot use pure UTF-8 because non-IDN-aware applications
> will still  need to be able to lookup ACE-encoded IDNs.

Keith,

While I agree -- for the reasons mentioned by Adam and that I'm
sure will be repeated and expanded upon by others-- that "just
send UTF-8" is a bad idea, I'm not sure the above follows.

We have approaches --the "use a different DNS Class" idea is
certainly one example-- which would prevent a non-IDN-aware
application from ever encountering an IDN in a context in which
being able to resolve it is a reasonable expectation.  And
having an application that is completely non-IDN-aware handle
ACE-type IDNs correctly (with IDNA or otherwise), is likely, but
not certain, to bypass unanticipated problems.

So I would contend that the community actually has to make a
choice here, a choice among:

	(i) A family of solutions, including "just send UTF-8"
	which expose non-IDN-aware applications to things they
	almost certainly are not expecting and which, given our
	experience, are likely to cause application problems.
	Showing otherwise would require analysis of all
	implementations of all applications, which is roughly
	equivalent to proving a universal negative.  And, with
	the understanding that this is an observation, not a
	slam, I would assume that anyone with experience with
	applications and operating systems that respond to
	unexpected conditions and data formats with blue screens
	would be particularly sensitive to this sort of problem.
	
	(ii) A family of solutions, including IDNA and
	presumably most of the other ACE-based ideas, that
	attempts to encode the IDN data so that it will slip by
	non-IDN-aware applications, databases, and systems.
	These solutions are, I think clearly, less likely to
	exhibit serious problems than those in the first group,
	but there are still risks.   And some of the human
	interface, and text-imbedded-in-document, issues seem to
	me quite daunting.  The community could conclude that
	the advantages (including a form of quick deployment
	that does not change the DNS and leaves applications on
	their own) are a good compromise with the risks, but the
	approaches are still compromises with risk.
	
	(iii) A family of solutions that are "no risk", because
	their designs prevent non-IDN-aware applications from
	ever seeing an IDN in a DNS context.  If a putative URL
	appears in running text, the application can either cope
	with it or not, but, if it tries to do something with it
	and violates its own rules about what it can handle and
	pass to the DNS, that is clearly a problem with that
	application (not just failure to upgrade).  And, with
	these solutions, DNS queries and responses from
	non-upgraded applications just will not involve IDNs.  

The solutions in the third group, which might be characterized
as "not in Class=IN" or "not in the DNS", or "need to fully
negotiate first" (as far is I know, we don't have any plausible
ones of the latter on the table, but they are logically
possible) have the clear disadvantage that they require serious
deployment to work for the people/ language groups/ countries
that need IDNs.  So they are not quick fixes.  But some of them
provide functionality, possibly critical functionally (such as
imprecise search), that neither of the other two groups do.  So,
again, it is a tradeoff.

But let's avoid assuming that the second group of approaches are
the only alternative to the first and, hence, that applications
will need to handle ACE names no matter what.

   john