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

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

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

> What I'm suggesting is that whenever you apply Stringprep, you also
> apply Punycode and prepend the prefix.

Which is the replication master and the application. That's not a problem.

> Whenever you roll out a new Stringprep profile, the things that
> need to get updated to know the new profile are exactly the same things
> that need to get updated to know the new prefix.

Resolvers, middle-boxes and replication masters all need to be able to
convert between EDNS and ACE as part of the fallback process. Distributing
the profile-specific prefix to every point where conversion might occur is
a massive problem.

The only way it would work in your model would be for conversion to only
occur at the application or at the replication master. But if the query
made it to the replication master there's no reason to do conversion, so
we are left with the application always performing conversion. That design
blows up the architectural benefits from having the middle-boxes do it (in
particular, having the caches learn the data so they can cache it). It
will sometimes be necessary to have applications perform conversion but
requiring it would blow up DNS.

> Of course, my suggestion implies that there is no prepared-UTF-8 format,
> there's unprepared-UTF-8 and prepared-ACE.  I don't see the point of
> using prepared-UTF-8 as an interchange format, when ACE works just as
> well, requires essentially the same effort from applications, and has
> the added benefit of backward compatibility.

For generating names, ACE conversion is an extra step that comes after
creating the structured UTF-8 domain name. Furthermore, it is an
unnecessary step if the application and protocol are only using UTF-8
domain names. Meanwhile, there is nothing saved from using unstructured
UTF-8 in DNS, since the applications have to use the rules anyway if they
are specifically exchanging domain names.

The only "extra" step is validating data which has been received, which
isn't an extra step for any application with half a clue. It's a
fundamental tenet of application design to validate the data you get from
the network. Only an idiot would use complex strings without some kind of
validation first. Besides, you would also need to do this as part of any
decoding of ACE back into the canonical i18n domain name, so this extra
step also applies to you (not to mention the extra step of conversion).

On all counts, using structured domain names is the fastest of the safe
routes, and is only step longer than the shortest route.

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