[idn] Reality Check

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

Has this working group lost the contact with the real world?

All discussion is about ACE/nameprep/IDNA/backward compatibility!

What about the current real needs and the future?
What about DNS?

It looks like many think the only important thing is
backward compatibility without changing the DNS protocol/server.
Why is people talking about DNSSEC, SRV records, DNAME,..., if
nobody is going to update their DNS servers?
Why not go for a solution that updates DNS and requires upgrade
of the DNS protocol and servers?
Why should it be quicker to implement DNS in the appications and
get them to be updated faster? MIME was introduced very long time
ago and still there are a lot of mail programs that do not handle it.

What does the normal human beings of the real world expect from DNS?
The semantics of current DNS says:
- a name can have mixed upper and lower case letters
- names will be matched case insensitively
IDNA says:
- a name can only be in lower case
- names will be matched exactely
So IDNA breaks current semantics of DNS. Why not go for a solution
that works as people expect? And matches the current semantics of DNS?

I have tried to think of how I as a programmer, developer, editor and
user would handle DNS names.
An ACE-solution will result in e-mails containing lines like:
To: =?quoted-printable-encoded?= <ACE-like-user-name@ACE-domain.ACE-domain.com>
A line with a lot of different mixed encoded forms. To handle this
as a programmer you have to idetify the different parts of the line and then
for each part identify what encoding is used, and the decode each before the
line can be displayed to a user or handled in a program.
As of today I have fewer programs than I want that handles e-mail - this
is because the difficulty in programmatically handling MIME.
With ACE in domain names and something like it in user names it will be
even worse. Why could we not use something simple like having the
entire line encoded in UTF-8? Instead of having a difficult time to
parse data and a lot of different decoders I could use decode UTF-8 into my
local character set.
Many edits their html files with a text editor, or writes documents
with embedded DNS names and URLs. The only way you can expect people
to enter DNS names and URLs in those files is by using the same character
set as the rest of the text and they will not convert them into
ACE, %-encoding or other unnatural form. If we use different encodings
for all things, all software handling text files have to handle the
convertion to/from the character set of the file into the special
encoding needed for protocols. I can see lots of failures giving the
user failures they cannot understand and a lot of encoded forms getting
into the users text files, and a lot of non-encoded forms getting into
the DNS protocol. At my site clearly the simplest and best working
solution is to let my DNS server do most of the work.
While many programmes working for interoperability have code to handle
UCS to local character set conversions and have case insensitive matching,
they do not have code for things like ACE or quoted-printable.
A solution based on using UCS as transport format and matching based
on the normal "case insensitive" matching rules would make many programs
much easier to adopt to non-ASCII DNS names.
And if we used UCS only and did not use ACE as a backward compatibility
encoding, would it really be that bad? In my system the function that
might have most problems is e-mail, but that is also one of the systems
that probably can be handled easiest - I can fix my MTA and I can also
avoid using non-ascii in my mail domain to begin with. or ACE could be used
in the few places where it cannot be avoided for a transition period.

Does the IDNA (ACE in application) solution that appears be the only
focus of this working group match the real needs of people in the
current and future world?

As it feels for me, this working group is going for a solution that
is far from the simple clean handling of non-ASCII in DNS that I have
always wanted and worked for.

    Dan