Touchstones for "Mapping"

"Martin J. Dürst" duerst at
Fri Apr 3 03:38:36 CEST 2009

Hello Vint,

I think Mark and Shawn have given quite a few arguments, but let me
try again. If we want to split the world into IDN-aware and
IDN-unaware applications, then for many people, it seems to look
like this (layer diagram):

1) IDN-aware (modern browsers,...)

2) IDN-unaware (DNS itself, HTTP,...)

However, I think it's more like this:

0) IDN-unaware (humans, side of a bus, napkin, simple text editors
           databases (Mark's example), email text (Shawn's example))

1) IDN-aware (modern browsers, very sophisticated editors,...)

2) IDN-unaware (DNS itself, HTTP,...)

I.e. we have a layer 0 that deals with IDNs in their human-readable
form, a layer 1 that negotiates between human-readable and A-labels,
and a layer 2 that deals with A-labels only.

Parallels to this structure are easily found in other areas, the
best one is probably the DNS->IP# mapping itself: We have a layer
0 that only (or mostly) uses domain names (most application protocols
and what's above them), a layer 1 that negotiates (DNS resolvers,...),
and a layer 2 that deals just with numbers (TCP/IP).

The properties of the mapping are somewhat different, but I'm
sure you can agree with me that whoever claimed that domain
names are ONLY used because the IP address might change is
clearly wrong. They are also used because people are much
better at working with names than at working with numbers.
Same for IDNs, for those people who need IDNs (and for
whom we are doing all this work, after all).

Regards,    Martin.

On 2009/03/31 21:44, Vint Cerf wrote:
> Martin,
> for IDN-aware application, storage as A-labels has the benefit of
> storing an unambiguous string that can be converted directly to U-
> label form.
> For IDN-unaware applications it isn't clear what will happen to a U-
> label (presented in some strange way maybe? IDN-unaware means the
> software thinks domain names are ASCII only) but at least the A-label
> form conforms to IDN-unaware domain name expectations.
> So I am not sure I follow your line of reasoning.
> v
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at

More information about the Idna-update mailing list