Subject: [idn] A case for *ACE, other good/bad ideas, and a rant...

From: William Morris <[email-masked]>
Date: Sun, 7 Jan 2001 20:33:00 -0500 (EST)

Clients or servers that can not be upgraded
  Many embedded devices can't be updated because their code is stored
  in ROM or ASICs. Who knows how many are out there or how they will
  react. *ACE deals with this issue well, UTF-8 does not. It is not
  possible to determine how many devices will be affected. Imagine a
  UPS failing silently in communicating its status.
Clients or servers that can be upgraded Non-IDN Systems
  There will be systems on the Internet for the foreseeable future
  that can handle IDN but will not be upgraded due to various reasons.
  Unless someone takes over the Internet again, there will continue to
  be systems running cc: mail or worse. Clients will attempt to
  communicate with these systems directly, therefore *ACE translation
  MUST be done on the client if it is implemented. Last week I spoke
  with a customer who is running a cc: mail to uucp gateway to send
  mail to the Internet. If you dont mind losing communications between
  those who cant or wont upgrade and those that must use IDN, then
  something other then *ACE is an option.
Input devices
  All known systems that are capable of connecting to the Internet and can
  accept user input, have support for entering the 37 possible characters
  a-z,0-9,- currently possible in a domain name. The user may not
  understand them, but the worst case is someone who only understands
  klingon can look at a business card and select characters from a chart
  of 37, and the most confusing would be O vs 0 which could be resolved by
  using a better font or guessing. Worst case two email addresses per
  card, one in their native language, one in ASCII. Most likely they will
  have another domain name they use or they can use the *ACE version.

Other (bad/good)Ideas...
  Update all of the network protocols to support UTF-8, and make UTF-8
  mandatory for IPv6. Add an opcode to DNS to support UTF-8 query and
  response.

Nameprep is manditory for IDN. there is no way around it. Using the
  Japanese input method for Win98 if you hit period you get one of two
  characters depending on which mode (Japanese/English) you are in. Both
  of these must map to ".", because end users have enough trouble double
  clicking much less typing <gokuhigundan>(ALT+SPACE).com

Despite everything, I think losing a small percentage of communications on
the Internet is better then continuing to prevent a greater population of
potential users who cannot read or write English. Given that many will
agree that UTF-8 is an ideal end goal, I would rather go thru the hell of
upgrading customers(wetware/etc) to support IDN once.

While sad, I would rather that I had problems communicating with a friend
in Japan because pine doesnt support UTF-8 email addresses then deal with
something that in my opinion is a hack, a clever hack but a hack none the
less.

I say force everyone to support or upgrade to UTF-8, if they need to give
their email address to someone who cant type it they should register
5464786464.com or something...

-Bill

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jan 2001 22:29:39 -0000

William Morris writes:
> characters depending on which mode (Japanese/English) you are in.

You are confusing two separate issues: the dots, and the stuff between
the dots.

The nameprep discussion is all about the stuff between the dots. There's
nothing in the nameprep draft about normalizing dots. In fact, dots and
things that look like dots are specifically prohibited.

  [ embedded devices ]
> *ACE deals with this issue well, UTF-8 does not.

What if the sysadmin has to use an embedded device that can't deal with
name components longer than, say, 10 bytes? He has a much better chance
of finding a tolerable 10-byte UTF-8 string than of finding a tolerable
10-byte ACE string with any of the ACE proposals. (Of course, neither
chance is good if the name is supposed to be in Chinese.)

Why should we believe that failures to handle 8-bit data cleanly are
more common than failures to handle long domain names cleanly?

> be systems running cc: mail or worse.

Are you saying that cc:Mail isn't 8-bit clean? Are you also saying that
cc:Mail has no trouble with long domain names?

(It has been a while since I've spotted any cc:Mail systems, so I don't
have an easy way to test any of this.)

---Dan

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Mon, 8 Jan 2001 14:50:20 -0800 (PST)

> Are you saying that cc:Mail isn't 8-bit clean?

cc:Mail could best be described as "8-bit erratic." An instance of the cc:Mail
client inherits the default charset for the platform on which it's running,
which might mean PC-437, PC-850, Shift-JIS, or whatever. This was an artifact
of MS-DOS that carried over to the MS-Windows client, and as a conseqeunce the
Windows client does character conversions between Windows 8-bit charsets and
the old PC charsets. These conversions are very dirty and irrecoverably munge
the data.

Shift-JIS is a great challange in its own right. Raw UTF-8, when passed to an
8859-1 application, is legal and replayable even though unintelligible. Not so
with Shift-JIS; a UTF-8 stream will contain many many code sequences that are
illegal in Shift-JIS, causing a well-behaved client to discard the data.

All of the native-language Japanese clients I know of also have this problem.
They use Shift-JIS natively, and will thoroughly destroy UTF-8 streams.

> Are you also saying that cc:Mail has no trouble with long domain names?

The length of Internet domain names when presented to cc:Mail is a complex
issue, depending on how the SMTP gateway is configured and whether the
recipient is listed in the cc:Mail directory. As a rule of thumb, however, the
limit should be the size of a cc:Mail postoffice name, which on older (but
still widely used systems) is 64 bytes.

<csg>

---

From: William Morris <[email-masked]>
Date: Mon, 8 Jan 2001 18:31:52 -0500 (EST)

> things that look like dots are specifically prohibited.

For Non-ASCII languages, most text input is modal; you are either typing
in ASCII or Non-ASCII. Since users may not enter .com properly, and
application developers have been known to implement things oddly enough
when there are standards. I would really like dot handling in applications
to be standardized. It may not be nameprep but it needs to be dealt with.
I should be able to hit the period while in Japanese mode and have the
application do the right thing.

> more common than failures to handle long domain names cleanly?

Because I have seen more then enough systems that choke at anything over 7
bits, and thats just in the past month. People are still using windows
3.11 to connect to the internet, 8bit-dirty terminal servers, old versions
of netware. At least you can work around long domain names.

> cc:Mail has no trouble with long domain names?

I know cc:mail will have much more problems with 8-bit data then long
domain names.

-Bill