Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt

From: Dan Oscarsson <[email-masked]>
Date: Sun, 03 Feb 2002 11:19:35 +0100

IDNA talks about "domain name slots".
There are "internationalised domain name slots", probably meaning
a domain name slot that uses the native character set of the context
the slot is in, though IDNA is having all non-ASCII domain names being
in ACE.
And there is a "generic domain name slot", which should really
be called "ASCII only domain name slot" because it is not generic.

Reading more in IDNA you find that it a domain name is to be put
in a "ASCII domain name slot" it has to be converted into ASCII.
But you will also find a section about entry and display in
applications.
In it there is talk about different places where domain names can
appear, including that non-ASCII character should be used if allowed.

The probably first place where non-ASCII domain names will be used
is the web. This is also the place where encoding domain names using ACE
is not really needed (as it already can work without it).
When you look at the web, it is the URL people will use non-ASCII it.
They will have them both in the domain name and in the path.
Where do the user enter URLs? In the location field to open
new pages, and in the HTML code in links.
People will NOT enter domain names using ACE. Links in HTML code
will contain non-ASCII! As the context of a HTML document have a
defined charactert set, URLs embedded in the will be written using
the same character set.

The text in the IDNA draft may be interpreted as you must use ACE
encoded
names in URLs inside a HTML-document. Just forget it. It must be
possible
to use the character set of the context of the HTML document.
People will not write ACE! Only automatic software will do that.
IDNA will therefore not be really usefull untill the important
applications
handle conversion to/from ACE automatically totally invisible to
the user. The important applications include the web browser, the
e-mail software and the operating system software handling host names.

   Dan

---

From: "ben" <[email-masked]>
Date: Sun, 3 Feb 2002 09:48:13 -0500

Hi Dan,

>People will not write ACE!

I can not see the problem you are trying to point out and I think a
specific example will help me better understand.  Can you explain why
the following would cause problems?

<p><a href=http://zq--fiq228c.com><b><font
color="#FFFFFF">中文.com</font></b></a></p>

Thanks,
Ben

---

From: Dan Oscarsson <[email-masked]>
Date: Sun, 03 Feb 2002 16:36:08 +0100

Ben wrote:

>color="#FFFFFF">ä¸­æ-?.com</font></b></a></p>
>

That will not cause problems except that the person writing
the HTML page may not know the ACE form and will write:
<p><a href=http://ä¸­æ-?.com><b><font
color="#FFFFFF">ä¸­æ-?.com</font></b></a></p>

and that will not work in browsers that are not IDNA aware
as they will not ACE encode the host name before looking it
up in the DNS server (though it could work with an enhanced
DNS server).

What I want to say is that people will not know how to
convert a host name into ACE and will use the name in the form
most natural for them. And will write the host name into URLs
using the native form. So before all major web browsers are
fixed, non-ASCII host names will fail on the web unless you
use smart DNS servers (like NUBIND and others).

   Dan

---

From: Dan Oscarsson <[email-masked]>
Date: Sun, 03 Feb 2002 17:04:32 +0100

Looking at IDNA and how it would enable me to use
non-ASCII host names on my system, I see only two useful stages:

1) "do nothing".
   No change done anywhere in any software.
   Here I would be able to access other places with
   non-ASCII in host names using the ACE form.
   But it will be ugly for host names that can be expressed
   in my local character set and if somebody get a name in
   the native non-ASCII form they will not be able to use it,
   as they do not know how to convert it into ACE (and will
   see it as absurd that you have to convert it to ACE).
   It will be impossible to use non-ASCII host names on my own
   hosts.

2) "do everything".
   Implement conversion between native local character set and
   ACE encoded names in the resolver libraries and replace the ones
   delivered with my systems so that all applications get
   host names in native form. My DNS server must be upgraded
   so it can load zone files in native local character set and
   sendmail will have to be fixed so it can convert host names
   to ACE before sending. There might be some operating system
   software that does it own checking on what character are
   allowed in host names, will have to require them fixed
   by OS vendor.
   When that is done, most things should work with non-ASCII
   host names. I can define hosts with such names, use web
   pages and send e-mail.

There is really no between stage. I cannot do an incremental upgrade.
It is unacceptable to require people to enter or see ACE encoded names
in the commonly used places. This includes URLs, log files, /etc/hosts,
DNS zone files and configuration files. So I cannot get any
incremental change over to native host names like the IDNA solution
hopes. Instead I will have to wait until I in some way can
get all important software to change at the same time. That is why
the easiest way to do it is by changing the resolver library instead
of changing each application.
As IDNA promotes the use of ACE, many vendors with little understanding
for the need of non-ASCII characters will just use ACE, I can expect
a long wait before applications handle native host names instead of ACE
unless you can force it on them by for example changing the resolver
library.

I have not tried to modify my resolver library so I do not know
how many applications it will break. And as the resolver library
is delivered with the OS I might have to fix it in the DNS server
instead if decide I do not dare trying to replace the resolver library.
Clearly, IDNA will not very much help my systems in the move to
using non-ASCII in host names. Neither would UTF-8, but as the break
with the ASCII world would be much more apparent I would expect
applications to be fixed quicker.

    Dan

---

From: Dave Crocker <[email-masked]>
Date: Sun, 03 Feb 2002 08:21:55 -0800

>non-ASCII host names on my system, I see only two useful stages:

Nope.

Please review the presentation I gave at a working group meeting:

         <http://www.brandenburg.com/presentations/iDN-choices-comments.ppt>

d/

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

---

From: "ben" <[email-masked]>
Date: Sun, 3 Feb 2002 11:49:27 -0500

Hi Dan,

> use smart DNS servers (like NUBIND and others).

I though there were some serious problems.  If you are worry that
people will not know how to convert to ACE, then please don't worry.
Anyways, thanks for the clarification.

Thanks,
Ben

---

From: Mats Dufberg <[email-masked]>
Date: Sun, 3 Feb 2002 17:55:13 +0100 (CET)

On Feb 3, 2002, 17:04 (+0100) Dan Oscarsson <[email-masked]> wrote:

> DNS zone files and configuration files.

That is your assumption. In the beginning system administrators will
accept to enter domain namnes in ACE in configuration files of web
servers, namn servers, mail servers etc. Soon there will be interfaces
that let people enter DNS data in local character set in source zone
files, which will be converted to zone files in the generic format of
bind. And the same will happen to other servers, or servers will be
updated.

> unless you can force it on them by for example changing the resolver

I don't think that your assumption will come true. Next version of Windows
NT (whatever it is called) will have a nameserver with support of the
local character set.

> Neither would UTF-8, but as the break

I prefer ugly ACE domain names rather than total break down. :-)

Mats

----------------------------------------------------------------------
Mats Dufberg <[email-masked]>
----------------------------------------------------------------------

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 4 Feb 2002 00:42:13 +0000

Dan Oscarsson <[email-masked]> wrote:

> There are "internationalised domain name slots", probably meaning a
> domain name slot that uses the native character set of the context the
> slot is in,

The meaning is stated in the draft.  An internationalized slot is one
explicitly designated for carrying an IDN, regardless of how it is
represented.

> though IDNA is having all non-ASCII domain names being in ACE.

All non-ASCII names in generic slots are in ACE.  Non-ASCII names in
internationalized slots need not be in ACE.

> And there is a "generic domain name slot", which should really be
> called "ASCII only domain name slot" because it is not generic.

It is generic in the sense that it is for "domain names", not
specifically for "internationalized domain names", and therefore you
don't know what might happen if you put non-ASCII code points into it.
That's why IDNA allows only ASCII code points in generic domain name
slots.

> Reading more in IDNA you find that it a domain name is to be put in a
> "ASCII domain name slot" it has to be converted into ASCII.  But you
> will also find a section about entry and display in applications.  In
> it there is talk about different places where domain names can appear,
> including that non-ASCII character should be used if allowed.

Yes.  There is no contradiction.  "Slots" are things communicated
between machines/software, like fields of protocol messages, function
arguments, etc.  Text widgets in user interfaces don't really count
as "slots".  But even if you wanted to view them as slots, an
internationalized application would of course consider them to be
internationalized slots, so the requirement to use only ASCII would
still not apply there.

> Where do the user enter URLs?  In the location field to open new
> pages, and in the HTML code in links.

The location field is not a problem.  An internationalized application
will use whatever representation it likes in the location field, and
convert to/from ACE as neede.

> Links in HTML code will contain non-ASCII! As the context of a HTML
> document have a defined charactert set, URLs embedded in the will be
> written using the same character set.

The HTML spec requires the href attribute to contain a URI as specified
by RFC 2396, which requires the host part to contain only LDH
characters.  Under the current rules, ACE is the only way of using IDNs
in an href attribute.

It's possible that a new version of HTML will allow non-ASCII characters
in the host part of the URI in an href attribute.  If that happens, then
you will have an easier way of typing your HTML source, and the href
attribute will no longer be a generic domain name slot, but will in fact
be an internationalized domain name slot, and thus the new HTML will not
be in any conflict with IDNA.

> the person writing the HTML page may not know the ACE form and will
> write:
> <p><a href="http://ä¸­æ-?.com"><b><font

It violates the HTML spec, so there's no reason to expect it to work in
any browsers, regardless of whether they are IDNA aware.

>    sendmail will have to be fixed so it can convert host names to ACE
>    before sending.

It was never our vision that sendmail should be altered in any way.  The
user program (Mutt, Pine, etc.) is what we expect to be altered.

Upgrading just a few applications (a web browser, a mail client, and
maybe an instant messaging client) will go a long way for most users.

You don't even have to touch the resolver (though by messing with it you
might be able to trick some old applications into partially working with
IDNs).

AMC