Subject: Re: [idn] Let's go forward with IDNA and UTF-8

From: Dan <[email-masked]>
Date: Sun, 27 May 2001 12:00:40 +0200 (MEST)

Patrik said:

>I see two differences between UTF-8 and ACE which was what I used as
>arguments when I made up my mind:
>
>(1) Risk of loss of information
>
>ACE approach is NOT destroying any information when data is sent from
>sender to receiver in any of the protocols we have today. It is 100%
>backward compatible.
Probably 100%, but some software may compare an ACE version of the name
with thde decode version and fail.

But ACE+nameprep IS destroying information.

Also ACE can only be used for host names, if may not fit all types of
DNS names and it cannot be used for other textual data in DNS.
So by using ACE you always need to implement handling of UTF-8 (or what
is used) for all other textual data in DNS.
When we internationalise DNS so IDNs can be handled it must also
include internationalisation of all text data handled in DNS.

>
>Use of UTF-8 in any place in any protocol where we have a domainname today
>MIGHT (I don't use any stronger term, but I don't see I have to either)
>destroy some data during transport.
>
>(2) How to fix broken domainnames
>
>In an ACE approach, the enduser himself can change his own applications to
>get rid of the ACE encoding and instead see the IDN as it was expected.
>
>In an UTF-8 approach the user MIGHT have to change his applications so they
>can display UTF-8 characters and (here comes the important part) someone
>else than the enduser MUST upgrade the intermediary boxes (HTTP proxies,
>SMTP gateways, SMTP MTA's, POP servers, IMAP servers etc) which is not
>under his control.
>
>I.e. if we compare with when we launched MIME, many people have told me
>that "but the goal is that the user should not see the ACE, and geee what
>Quoted Printable was ugly, let's not use the same mechanism again".

There is one major difference between MIME and ACE/UTF-8 in DNS.
In MIME the most importat element for delivery of e-mail, the
e-mail address, was not changed and forced to remain in ascii.
This means that if an adress is copied from an application understanding
MIME to one who does not, it will still work.

With DNS it is the address itself that is changed.
If you have an application understanding ACE and decodes it
into the real address, I am sure people will copy the decoded form
into applications that do not know about ACE and will therefore result
in UTF-8 or other encoding being sent into DNS.
You will get this problem with the UTF-8 solution also.
Some of these problems can be handled if you use DNS servers
like those I have in UDNS which can handle both ACE and UTF-8, as
well as some local characters sets.
So I am sure several of the problems you see with UTF-8 will
also exist with the ACE only solution, though with ACE only
decoded ACE names will never work.

-
One thing everybody also may think about. Even with UTF-8 as
only encoding, there must be a way to display names that
cannot be displayed using the characters available in a client.
So an ACE or a (local charset) Compatible Encoding is still
needed. And I prefer one that can be used by all programs so
all programs display non-displayable names in the same way.

   Dan

---

From: Mats Dufberg <[email-masked]>
Date: Sun, 27 May 2001 14:29:59 +0200 (CEST)

> DNS names and it cannot be used for other textual data in DNS.

Well, nameprep+UTF-8 will cause the same problem when it comes to the name
part. There is no difference in what codepoints that ACE can handle
compared to UTF-8. Nameprep is there to eliminate ambiguity, and will be
needed for any solution (ACE, UTF-8) to avoide chaos in DNS.

> is used) for all other textual data in DNS.

Hm. I guess that some kind of ACE would be better if ACE coding is used
for the names.

> There is one major difference between MIME and ACE/UTF-8 in DNS.

The point is that 8-bit data could be transported through 7-bit-only
server through encoding (quoted-printable, base64). As long as the mail
clients in each end could handle MIME they could use 8-bit character set.

The parallell with the ACE solution is clear.

Mats

-----------------------------------------------------------------
Mats Dufberg                                     +46-8-545 857 06
[email-masked]                           fax: +46-8-545 857 29

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 27 May 2001 21:01:47 +0200

> But ACE+nameprep IS destroying information.

Whether we should do nameprep or not is a different question than encoding,
and that question is orthogonal to whether UTF-8 or ACE encoding of the
domains should be used.

I really want those issues to be separated.

> include internationalisation of all text data handled in DNS.

Sure, but internationalization of the DNS protocol is a no-brainer (I agree
with you here) because the protocol is specified to be able to handle 8bit
octets of any value.

The problem is not DNS, but when the data in DNS is used in other protocols.

> MIME to one who does not, it will still work.

Correct, and I call this "the clipboard problem" (even though it can happen
automatically aswell).

> in UTF-8 or other encoding being sent into DNS.

Yes, absolutely, as also John Klensin has said several times. This is
though nothing special for ACE, or UTF-8 or whatever, but a result of every
operating system in their local version using a different default script.

> You will get this problem with the UTF-8 solution also.

Yes.

> decoded ACE names will never work.

I don't agree with your conclusion, because if you have an application
which take care of broken "clients" already, that can take care of decoded
ACE aswell as UTF-8 aswell as ISO 2022-JP or whatever.

I.e. I think we all agree about one thing: we will get a complete mess all
over the place, and the only thing that can not stop that is to NOT do IDN
at this layer in the protocol stack at all, and instead just do a
dictionary solution.

> cannot be displayed using the characters available in a client.

I would even say that one of the errors we will get in the "clipboard
problem" is if you copy and paste between two applications which both know
ACE, but the internal script used in either of the applications (or the
clipboard itself) can not handle the characters which are encoded (in ACE
or UTF-8). We will loose there aswell, if not the applications are very
clever, and for example encode the domainname before storing it in a
clipboard.

   paf

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 May 2001 13:39:55 -0700

>I really want those issues to be separated.

   * * *  Y  E  S  ! ! !  * * *

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464