Subject: [idn] Challenge: longest UTF-8 with valid domain name

From: Martin Duerst <[email-masked]>
Date: Mon, 07 Apr 2003 15:07:49 -0400

Here is a little challenge that might end up in Simon's test suite
and be otherwise valuable for testing:

What is the longest (in terms of bytes) internationalized
domain name (when encoded as UTF-8)? Obviously because there
are characters that are ignored by nameprep, we would have to
ask for the longest one after ToUnicode.

The problem applies both to single labels as well as to
FQDNs.

Regards,    Martin.

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 7 Apr 2003 21:42:11 +0000

Martin Duerst <[email-masked]> wrote:

> What is the longest (in terms of bytes) internationalized domain name
> (when encoded as UTF-8)?
>
> Obviously because there are characters that are ignored by nameprep,
> we would have to ask for the longest one after ToUnicode.

You mean the longest after nameprep.  The output of ToUnicode is not
necessarily nameprepped (because ToUnicode leaves its input untouched if
the input is not an ACE).

> The problem applies both to single labels as well as to FQDNs.

I think the longest nameprepped label is 224 bytes in UTF-8.  Taken any
code point in the range 10000..55931 (hex) and repeat it 56 times.  The
ACE form will be 63 characters.  The nameprepped non-ACE form in UTF-8
will be 56*4 = 224 bytes.

As for the longest IDN, I think that would have four labels, three
of which are maximal, and one of which is just shy of maximal (62
characters in the ACE).  With the four length bytes, that hits the DNS
limit of 255 bytes.

The longest UTF-8 representation of that name (with nameprepped labels)
would use ideographic full stops for dots, and would include the
trailing dot.  So it would be (3*56+55)*4 + 4*3 = 904 bytes.

AMC

---

From: <[email-masked]>
Date: Mon, 7 Apr 2003 17:38:37 -0500

Hello,

I'm trying to understand the purpose behind some steps in 
ToUnicode. From the IDNA spec:

1. If all code points in the sequence are in the ASCII range (0..7F)
   then skip to step 3.

2. Perform the steps specified in [NAMEPREP] and fail if there is an
   error. (If step 3 of ToAscii is also performed here, it will not
   affect the overall behavior of ToUnicode, but it is not
   necessary.) The AllowUnassigned flag is used in [NAMEPREP].

3. Verify that the sequence begins with the ACE prefix, and save a
   copy of the sequence.

I'm curious about steps 1 & 2. I don't understand why nameprep
is being applied to ASCII domain labels. This seems to be pointless 
in situations where the input string is 8-bit ASCII. Wouldn't
a simple dns character compatibility check in place of steps 1 
and 2 suffice?

Regards,
Jim Mathies

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 7 Apr 2003 23:06:36 +0000

[email-masked] wrote:

> is being applied to ASCII domain labels.

Nameprep is *not* being applied to ASCII labels.  That's what step 1
does, it prevents nameprep from being applied to ASCII labels.

> Wouldn't a simple dns character compatibility check in place of steps
> 1 and 2 suffice?

ToUnicode is not only intended to be applied to DNS-compatible labels.
It is intended to be applied to any internationalized label.

Imagine an application wants to display a domain name.  The name might
contain some non-ACE ASCII labels, some ACE ASCII labels, some non-ACE
non-ASCII labels, and some ACE non-ASCII labels.  (A mixture could arise
if the name is constructed from pieces obtained from various places,
like typed user input, the clipboard, a config file, the network, etc.)
The application can simply apply ToUnicode to every label, and the
result will be an equivalent name containing no ACE labels.

By the way, if you're wondering what an ACE non-ASCII label is, the
typical example arises when an ACE label is manually typed using an
input method that outputs fullwidth characters (which are non-ASCII, but
which would be mapped to ASCII by nameprep).

AMC