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

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

on 6/10/2002 9:06 PM Adam M. Costello said the following:

> But IDNA has to work with more than just DNS, it has to work with the
> wide variety of other protocols that carry domain names.

I agree that it makes more sense to do this definition as part of the RR
classification effort.

> I was suggesting that conversion between ASCII and non-ASCII never
> be done inside the infrastructure except possibly when it uses the
> well-known standard profile; for application-specific profiles, I was
> suggesting that conversion be done only at the edges.  This model avoids
> profile-agnostic conversion; only entities that know the proper profile
> perform the conversion, which simplifies the security analysis.

However, this can cause significant amounts of requery traffic for
applications that pull data from DNS frequently. If a pair of applications
are able to exchange UTF-8 data directly and that data resides in DNS,
then the cache needs to be able to handle any fallback conversion which
may be required so that it can handle the next query for that data. If the
query failed at some remote point in the infrastructure (like the
authoritative zone for the owner name in question), then the
infrastructure would get whacked twice every time the application went to
ask for that data (once for the EDNS form, again for the ACE form). This
is a very serious concern and must be prevented at all costs. Conversion
in the middle is the essence of a dual-mode approach.

> If the
> application passes the string along to a non-human, ACEs are not a
> problem, so there's no benefit.

That's not a correct assumption. Consider a situation where the
application uses UTF-8 for all protocol data. The future is not ASCII. I
am not designing for legacy systems. Those systems could only use
EDNS/UTF-8 for connections and logging (and some things like SMTP relays
can't even use it for that), while newer applications can use it for all
kinds of stuff.

This is getting into the ACE-vs-UTF-8 argument that we've already had and
it's not necessarily getting us further along on the current debate.
Skipping to the next section.

> Now let's consider the cost of your model.  Profile-agnostic conversions
> and comparisons can return wrong answers if the inputs are not prepared
> using the proper profile (whether by accident or by malice).  There is
> nothing in the label itself to indicate the proper profile; you want to
> use the same prefix regardless of which profile is needed.

If an application got a hold of a non-nameprep ACE domain name, the lookup
would fail whenever the name was acted upon. The ACE sequence for that
domain name could not be used for any of the RRs that the legacy
application was looking for (A, MX, whatever). EG, if zz--goop was linked
to the FOO RR then it could not be linked with an A RR, since only
nameprepped owner names could have been linked to A RRs. This is the exact
same scenario as trying to use a domain that only has a TXT RR for SMTP,
it ain't gonna work. While it's an unexpected failure, it certainly isn't
an unforseen failure, and is quite common already.

However, this is a good argument against letting sister owner names exist
which collapse to the same domain name.

> Would it work?  Maybe it would.  But is it a good idea?  It still
> seems to me that allowing multiple profiles for domain labels is more
> complication than it's worth.

The problem is that this is a permanent choice. Standards are measured by
their use, not their intent.

> Punycode is reversible.  It can encode any sequence of integers, and the
> input sequence can always be recovered exactly.
> 
> Nameprep is deliberately non-reversible.  It does normalization and
> case-folding.

That's the way it should be.

> ToASCII is non-reversible only because it calls Nameprep.
> 
> If you were to define Eric's-ToASCII, which does not call Nameprep, then
> it would be reversible.

How significant would the change be to have the application call the
appropriate profile prior to calling ToASCII, rather than having ToASCII
make the call itself?

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