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

["Eric A. Hall" <ehall@ehsco.com>]

"Adam M. Costello" wrote:
> 
> "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).

Nameprep is only essential to the creation and intepretation of the domain
names used with *specific* resource records. Storing, transferring and
converting the data does not require this knowledge.

For example, the authoritative master for a zone needs to know that
nameprep applies to the owner name of an i18n A RR, so that these rules
can be enforced when the RR is created. Similarly, an application which
can create and/or read i18n A RRs from EDNS messages needs to know that
nameprep applies so that it can validate the domain name.

However, a cache inbetween an EDNS client and server does not need to know
these rules, since it will only work with data which has already been
properly formatted by the client or server. Furthermore, a cache which
converts a UTF-8 i18n A RR into ACE does not need to know the rules,
because the input data will have already been formatted properly. This is
also true for replication servers within the zone; they can assume that
the original data is properly formatted, with no knownledge of the rules
used to generate that data.

This same reasoning applies to all RRs regardless of the stringprep
profile they use. If an i18n RP RR contains an i18n email address, the
i18n localpart rules would only apply to the creation of the RR data. The
infrastructure can be relatively ignorant about these rules.

Consider another example, where a specific application requires the use of
an i18n RR which does not conform to nameprep. It is feasible that a FOO
RR will need to define it's own rules, perhaps because the application
requires all-uppercase, or because the RR data is storing raw text which
must not be normalized.

If the infrastructure is opaque, then these RRs can be defined at the
authoritative master for the zone and within the application that uses
these RRs, while the infrastructure can be completely ignorant of the
rules. Caches can even perform conversion because the rules say (or they
*SHOULD* say) that the inputs and outputs are simple octet streams.

That is the same model used today and we need to stick with it.

> 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.

Is IDNA capable of producing identical output for two different inputs
(setting aside the issue of normalizations)? That is the only real
question as to whether or not the separation can occur.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/