Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

From: Dan Oscarsson <[email-masked]>
Date: Sun, 02 Jun 2002 10:11:19 +0200

Adam M. Costello wrote:

>That's not what we're doing.  In data intended for machine consumption
>(protocol messages, function arguments, machine-readable file formats,
>etc) we are insisting that domain names continue to be ASCII-only;
>non-ASCII domain names may appear only where they are explicitly invited
>by new protocols/interfaces/formats (or new versions of old ones).
>
>What's bad is if old software and new software both accept the same
>things, but behave differently.  That's the situation we're afraid of
>with 8-bit domain names in DNS.  Existing DNS servers already accept
>8-bit names in queries.  If we were to declare that such queries must
>now be handled differently, we'd create interoperability problems.

But domain names in use today are not ASCII-only. I know at least
two DNS servers serving names using UTF-8 (Microsofts and .NU-bind).
IDNA will change how things are handle. Applications that before
sent UTF-8 will now send ACE-names breaking what worked before.
This creates interoperability problems.
It will force changes in DNS servers, despite IDNA saying that
no changes are needed in DNS servers. The .Nu-bind and Microsoft
servers will have to be changed so they can both recognise the
old native UTF-8 names and the new ACE-names, for the same name.

So you see, IDNA will break the current handling of non-ASCII
names in DNS. As things will break, why not standardise the
usage of non-ASCII in domain names. This would result in
some servers breaking, but will give better stability for the future.

   Dan

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 2 Jun 2002 09:02:06 +0000

Dan Oscarsson <[email-masked]> wrote:

> IDNA will change how things are handle.  Applications that before sent
> UTF-8 will now send ACE-names breaking what worked before.

Applications that started using proprietary IDN techniques before
anything was standardized knew the risk they were taking.

> The .Nu-bind and Microsoft servers will have to be changed so they can
> both recognise the old native UTF-8 names and the new ACE-names, for
> the same name.

You don't need to change the servers, you merely need to add the ACE
forms to the zone files.  One could write a perl script to do that.

> As things will break, why not standardise the usage of non-ASCII in
> domain names.

I have no problem with that, but as long as you're willing to break
things, why not segregate the non-ASCII requests using EDNS or a new
class, so that things break in a predictable fashion rather than getting
randomly misinterpreted?

AMC

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 3 Jun 2002 07:32:38 -0400

Hi Dan,
You could add NeDNS to your list.  And bettering the two you have listed, we
already deal with the inevitable ACE requests that are being sporadically
sent to the NeDNS servers at the various registries that we run.  To allow
for hosting the delegated IDN using existing nameservers, NeDNS also offers
the ability for the delegatee host server to use only the ACE form.
But, I do in fact agree with your observation that IDNA, even though
heralded as being fully backward compatible, isnt such, and is also not
forward looking which is the key issue at stake here I believe.
Edmon

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 3 Jun 2002 07:50:17 -0400

----- Original Message -----
From: "Adam M. Costello" <[email-masked]>
> class, so that things break in a predictable fashion rather than getting

This is a misleading statement that you are making.  non-ASCII requests are
not "randomly misinterpreted", at least not in NeDNS, they get uniquely
resolved into the intended domain name that a non-aware user is typing in.
Adam, whether you like it or not, the reality is that non-ASCII request are
reaching registry name servers and whether you resolve these domain names or
not is the operator's choice.  Resolve it and resolve customer support
issues at the same time because existing users will be able to immediately
get to multilingual domain names.  Reject it and expect frustrated
registrants asking you why their name doesnt work yet.  At the end of the
day, it is the registry's choice, but I would advise that...reject at your
own peril... Just look at the support nightmare some registries have face by
introducing names that do not yet work for most people...
So, my point is that while it is all well that an IDNA standard will be
published, the real world will have to have some sort of a transitional
system that supports accurate resolution of non-ASCII requests so that
existing users can access these names.

Edmon

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 4 Jun 2002 04:01:38 +0000

[Edmon, sorry you got two copies of this, it was an accident.]

Edmon Chung <[email-masked]> wrote:

> non-ASCII requests are not "randomly misinterpreted", at least not in
> NeDNS, they get uniquely resolved into the intended domain name that a
> non-aware user is typing in.

Really?  So if I type a name, and my IDN-unaware software blindly copies
the name into a DNS request (which won't necessarily happen, but let's
say it does), the server will match on the name I intended no matter
whether my system uses iso-8869-1 or shift_jis or iso-2022-jp or euc-jp
or UTF-8 or UTF-16be or UTF-16le or...?  And it will match uppercase
Latin letters with fullwidth lowercase Latin letters?  And it will match
precomposed characters with their decomposed equivalents?

Isn't it inevitable that there will be collisions between the various
charsets, so that a request for one name using one charset will
accidentally match an unrelated name stored under a different charset?

That's what I mean by random misinterpretation.  In the current DNS
protocol, the semantics of octets 80..FF are undefined, so the server
cannot know what the client is really asking for--it cannot know what
the user typing the name really saw on the screen.  It can guess, and
maybe guess right most of the time, but it can't really know.

> Adam, whether you like it or not, the reality is that non-ASCII
> request are reaching registry name servers and whether you resolve
> these domain names or not is the operator's choice.

That's true, I'm just saying it's risky.  Whenever text is passed
around without a charset tag (implicit or explicit), there is a risk of
misinterpretation.

If RFC 1035 had said clearly "domain names in zones shall not contain
80..FF until the semantics have been defined", then we could decide
tomorrow that 80..FF are nameprepped UTF-8 (or arbitrary UTF-8 if we
require the server to perform Nameprep), and there would be no problem.
Unfortunately, RFC 1035 contained no such clear prohibition, and various
conflicting interpretations of 80..FF have been deployed, and now any
standard definition will conflict with those deployments, and so people
who want standard 8-bit names are turning to EDNS and/or new classes.

AMC

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 4 Jun 2002 09:32:21 -0400

----- Original Message -----
> say it does), the server will match on the name I intended

Unless you are misinformed, yes you will be reaching the "intended" domain.

> That's what I mean by random misinterpretation.

Therefore it is not "random" and there is no "misinterpretation".

> and so people

The point I am putting out is that it is a fact that non-ASCII request will
reach the registry and it is the registry's choice to resolve it or not.  A
new protocol is entirely another discussion and I think anyone in this group
knows very well.  Of course if we want to "standardize" a 8-bit transport we
would need extra bit-identifiers in the DNS packets whether by way of EDNS
or new class.  What I am saying is that in the public point of view what
users care is that their names work immediately, if not, they will be
confused and frustrated.  It is the engineer's responsibility to try their
best to match the user's expectation in deploying any technology, and mind
you these are the unsophisticated users.  Therefore registries that are
putting out multilingual domain names for registration should think long and
hard about their responsibility and try to accomodate their users the best
they can.  That is what I am saying.

Edmon