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:

> Nameprep is only essential to the creation and interpretation of the
> domain names used with *specific* resource records.

Nameprep is at the heart of the definition of equivalent labels.

In today's domain name system, you cannot have foo and Foo and FOO as
three separate entries in the same zone.  No matter which one you ask
for, you'll get the same records back, because they are equivalent
labels.

This will still be true for IDNs.  No matter whether you ask for
föo, Föo, or FÖO, you'll get the same records back.  (For the
Latin-1-impaired, the non-ASCII characters are o with umlaut.)

You seem to be proposing a model in which there might be special kinds
of labels that use different Stringprep profiles that don't do case
folding.  But then queries for föo, Föo, and FÖO could return three
different results.  That would be a fundamental departure from today's
model.

Nameprep is inseparable from IDNA not only for names of resource records
but also for domain names appearing inside resource records, because you
never know when or why or by whom domain names will get compared.

Let's examine how föo and FÖO can get compared.  The ACE form of both
is xx--fo-fka.  But if we were to skip Nameprep when converting FÖO, we
would get xx--FO-ohA.

Now consider an entity that knows that föo and FÖO and xx--fo-fka and
xx--FO-ohA are domain labels, but does not know that they are special
labels that don't use Nameprep.

Will this entity consider föo and FÖO to be equivalent?  Yes, because
domain labels are case-insensitive.  Will it consider föo and xx--fo-fka
to be equivalent?  Yes, because the latter is the ACE encoding of
the former.  Will it consider labels xx--fo-fka and xx--FO-ohA to be
equivalent?  No, because they are ASCII labels and the usual ASCII
comparison rules apply.  Therefore, by transitivity of equivalence, this
entity cannot consider FÖO and xx--FO-ohA to be equivalent.

That's an important result.  An entity that doesn't know about special
non-nameprepped labels cannot convert between the non-nameprepped-ACE
form and the Unicode form (because it doesn't consider the two forms to
be equivalent).  Only an entity that knows the special nature of such
labels can do the conversion.

Therefore, we might as well not overload the IDNA prefix for such
purposes, but instead use a different prefix associated with a
different Stringprep profile.  If an entity knows about the special
non-nameprepped labels, it can easily look for the other prefix.  If
an entity doesn't know about the special non-nameprepped labels, it
couldn't do the conversion anyway, so it doesn't matter that it doesn't
know the prefix.  Having different prefixes for different profiles would
help avoid confusion and mistakes.

I think these special non-nameprepped labels that you envision tend
to be the result of mapping non-domain-label data onto domain labels
(like email address local parts).  Domain labels have their own matching
rules, and those rules apply to all domain labels, and Nameprep is an
integral part of those matching rules (for IDN labels).  If you want
to map some other data type onto domain labels, then it's up to you to
define a mapping that copes with any differences between the domain
label matching rules and the matching rules of the other data type.

IDNA is designed to convert domain labels to other domain labels, and
to compare domain labels.  It is not designed to convert between domain
labels and other data types.  If you want to define such conversions,
you are free to immitate IDNA.  Maybe you will end up with something
just like IDNA except that it uses a different Stringprep profile and a
different ACE prefix.

(But if the other data type has such different matching rules, it might
be easier not to try to map it onto a domain name at all, but instead
just let it be its own data type.  There's no law that says everything
needs to be represented as a domain name.  Resource records can define
arbitrary data formats.)

> Is IDNA capable of producing identical output for two different inputs
> (setting aside the issue of normalizations)?

I'm not sure what you mean.  Nameprep can of course produce identical
output for two distinct inputs.  But for two distinct outputs of
Nameprep, ToASCII cannot produce the same output.

AMC