--On Friday, 11 May, 2001 18:51 -0400 Keith Moore
<[EMAIL PROTECTED]> 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
