Re: [idn] WG last call summary

["Eric A. Hall" <ehall@ehsco.com>]

Keith Moore wrote:

> > I would like to hear your arguments as to how, say, using EBCDIC
> > to pass ASCII data around could possibly be seen as reasonable
> > design.
> 
> it would be quite reasonable for applications that already had a
> deeply-wired assumption that character strings were in EBCDIC.

Mapped to the current topic, you are saying that ~if the current apps were
already deeply-wired for IDNA, then it would be reasonable to use. Of
course, I would agree with that, if it were anything resembling the
current situation. Too bad nothing in the known universe makes any use
whatsoever of IDNA or (more importantly) its conversion routines.

> > Of course the native encodings are always best.
> 
> utter hogwash.  first, there is no single "native" encoding of UCS,

You already know that UTF-8 is the implicit default encoding for it here.

> second; there's no encoding of IDNs that is native to the vast majority
> of deployed applications.

Keith, there's no IDNA encodings of IDNs that are native to *any*
applications, either current or scheduled.

[big snip]

> if and when the rest of the protocol uses UTF-8, then the worst that
> happens is that there's an extra layer of encoding that happens before
> a DNS query is sent.

No, the "worst" that happens is that well-known and widely-used data-types
get extended by a third-party process, and then get reused.

>  and having the client do encoding
> prior to lookup is less complex than the extra cruft that's required
> to take advantage of having two kinds of DNS queries without introducing
> a significant new source of failures or delays.

There is definitely some transitional pain in getting to direct UTF-8, but
it is non-fatal here, there, and in-between. It doesn't rewrite data, it
doesn't require a forklift upgrade of the entire Internet for rendering
purposes, and the entire Industry would be better off when it was done.
None of that can be said for IDNA transliteration. Well, the pain part
still applies.

> you're ignoring the set of new problems that comes with either
> a) providing multiple DNS query interfaces or

Also necessary for IDNA sooner or later, mark my words.

> b) failing to provide an ascii-compatible encoding of IDNs that can be
>    tolerating by existing apps

To repeat myself for the record, I think that the IDNA transfer-encoding
portion is necessary to provide legacy applications with access to
resources in the IDN namespace. What I am specifically arguing against is
transliteration. It is just foolish to expect that well-known and
widely-used data-types can survive being extended beyond their spec and
still function as expected. I have even provided you with evidence proof
to the contrary.

Look, if a private venture were to come out pitching an untested add-on
that rewrote every domain name which appeared on screen, the greybeards
would trot out to make measured statements cautioning against mangling of
well-known datatypes. What's the difference here?

Oh, shit, we *ARE* the greybeards!

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/