Subject: Re: [idn] An experiment with UTF-8 domain names

From: Dan <[email-masked]>
Date: Sat, 6 Jan 2001 11:49:59 +0100 (MET)

Mark wrote:

>> So if the applications use the correct normalisation of UTF-8 today they
>need not be changed.
>
>There are many ways to normalize data. NamePrep is designed to provide a
>single, absolutely determinate process for this IDN normalization. The
>chances that the average application would, by chance, duplicate the same
>normalization is minimal.
>

Depends on what you mean with normalisation.

When I talk about normalisation of text, I mean order the character encoding
in a standard way without destroying any important information in the text.
For example Unicode normalisation form C and probably KC is like this.
As ISO 10646 is defined with several alternative ways to encode a
character, you need to normalise it to one way, if you want to
have a simple handling of it. This type of normalisation is needed
to make interoperability really work (because handling all possible
ways of character encoding in your code is a lot of work and makes your
code bigger).

NamePrep defines how to transform the text into a form that can be used
when comparing host names for equvalence using host name semantics.
It destroys important information in the text. This type of "normalisation"
is only needed when you want to compare two host names (and probably
domain names).

If both the above things are going to be called "normalisation" we need
some way to separate the two. Anybody with a good idea for what
to call them?

   Dan

---

From: Johnny Eriksson <[email-masked]>
Date: Mon, 8 Jan 2001 14:54:48 WET

"Martin J. Duerst" <[email-masked]> wrote:

> >...but could also on my buissness card have (if the ACE ends up being RACE):
> >
> >   bq--abtoi3duon2hf5tn .com
> 
> Sorry, but I very strongly doubt that this should be done, and that
> very many people will want to embarrass themselves that way.

If I had a domain name with non-ASCII characters in it, I would certainly
provide the ACE-encoded version as well, to help people that might not be
able to use the non-ASCII characters.  As noted by other people in this
discussion there might be several reasons for this.

When AT&T publish something like "1-800-CALL-ATT" they usually embarrass
themselves by providing "1-800-2255-288" as well.

Final note:  In this thread the ACE encoded string "bq--abtoi3duon2hf5tn"
has survived in several messages.  Patriks family name, on the other hand...

> Regards,   Martin.

--Johnny

---

From: Martin Oldfield <[email-masked]>
Date: Mon, 8 Jan 2001 10:57:11 +0000 (GMT)

Thank you for your clarification. I was trying to find out to what
extent UTF-8 and ACE would be interoperable with existing, rather than
upgraded systems. I really think that this is the important
consideration, because I think everyone agrees that if all the world
used either system then it would work.

>From what you've said, it seems clear to me that for email IDNs
containing a byte in the range \200 through \237, would be
significantly less useful under a UTF-8 system than under an ACE
encoding. Obviously my definition of useful puts gives more weight to
`can exchange email with people who have old software' than to `will
display the IDN correctly'. 

Whilst I quite accept that you might order these things differently,
I'd quite like to sort out in my own mind the pros and cons of the two
encodings. Please could you tell me if you think that UTF-8 would
display the IDN correctly in more places, whilst ACE would pass
through more of the existing infrastructure without error ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.