Re: IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

vint cerf <[email protected]> writes:

> It seems to me that we err if we mix "finding" identifiers
> (with search engines, elaborate directories that offer multiple
> choices of IDNs based on imprecise search criteria) with
> resolving unambiguous identifiers into their respective IP addresses
> (speaking roughly since DNS also offers indirect resolutions such as
> MX, CNAME and so on).
>
> I think we do ourselves a disservice if we try to make DNS resolve
> ambiguous references - it is not designed for such applications;
> search engines and directory structures are more oriented towards
> that aspect of finding things "by name" on the Internet.

This seem to argue against the current design of IDNA.

IDNA resolves some ambiguities in identifiers by Unicode
normalization, and introduces further ambiguities by not handling
legacy charset transcoding issues at all.

Admittedly, "resolving ambiguities" in human entered text strings is a
fuzzy area.  One extreme is to not resolve any ambiguity at all, the
other is to use as much intelligence in the software as possible to
figure out what the user meant.  Domain names in DNS traditionally was
in the first extreme, IDNA move things slightly toward the other
extreme with normalization and legacy transcoding, but far from
approaching search engines or directories.

Now, one can argue that Unicode normalization is only used because
Unicode happens to have different ways of representing the same, or
non-visual, characters, but nevertheless this adds an ambiguity
resolving mechanism to software.  One that will have to be modified
over time, as well, since consensus on how to resolve ambiguities will
change over time.  I have trouble visualizing how this can be
implemented and work well for 2, 5, 10 years and more, when Unicode
and other charsets are moving targets.