Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

"Eric A. Hall" <ehall@ehsco.com> wrote:

> IDNA applies to any domain name defined as a profile of stringprep,
> and is not dependent on nameprep.

Nameprep is essential to any IDN solution (IDNA or any other).  In order
to avoid chaos, we need everyone (not just DNS servers, but applications
and everything else) to agree on whether two domain names are the same
or not.

We already have this property for ASCII domain names--everyone uses a
case-insensitive ASCII comparison, which is equivalent to performing
ToLower and then doing an exact comparision (which is how it's usually
implemented).

In order for everyone to agree on whether two IDNs are the same, we
need to extend ToLower to work on non-ASCII strings.  There needs to
be a single precise transformation that everyone agrees on.  That
transformation has been decided--it's NFKC followed by the mapping step
defined in Nameprep.  Anything that compares non-ASCII domain names
must know that transformation (or must be promised that its inputs have
already had it applied).

Nameprep is an inseparable part of IDNA.

> This means that IDNA takes i18n labels as input and gives ACE as
> output (and vice-versa).  IE, just one codec.  No new codecs for
> localpart or for NetBIOS or for KERBEROS or anything else.

Agreed, there is only one codec for converting between ASCII domain
labels and non-ASCII domain labels.  Nameprep is an integral part of it.

For email address local parts, there is currently no interaction with
IDNA, because local parts are ASCII only, according to RFC 2822.
The procedure for mapping an email address onto a domain name is to
trivially encode the local part as a single label prepended to the
domain name.  That procedure applies to ASCII local parts, because all
local parts are ASCII.

Presumably someday soon someone will define non-ASCII local parts.  You
could imagine two ways of mapping a non-ASCII email address onto an
ASCII domain name.  (1) You could extend the old precedure to work on
non-ASCII email addresses, that is, trivially encode the local part as
a single internationalized label prepended to the domain name, and then
use IDNA to convert the domain name to ASCII.  (2) You could convert
the local part and the domain name to ASCII separately (using IDNA for
the domain name and something else for the local part), and now you've
reduced the problem to the old problem for ASCII email addresses.

It will be up to the email folks to decide which approach to take.
Local parts are *not* domain labels (even though they are sometimes
*mapped* onto domain labels), so IDNA does not automatically apply
to them.  The mapping from internationalized local parts to domain
labels might or might not be as trivial as it was for ASCII local parts.
That's something for another working group to decide.

As for NetBIOS and Kerberos, I'm not familiar with the issues there.

AMC