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
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.
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
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/