Re: [idn] ZWNJ

[John C Klensin <klensin@jck.com>]

--On Monday, 30 July, 2001 15:24 +0200 Dan Oscarsson
<Dan.Oscarsson@trab.se> wrote:

>> But, if the goal is to
>> be able to retrieve and examine the original name, then, it
>> seems to me that the way to do that is to store the original
>> name somewhere, rather than hoping that nameprep can both do
>> its job and be reversible.
> 
> Today DNS stores the original name, and the case insensitive
> matching is done by case insensitive compare.
> 
> Using UCS, the DNS could store all names using the original
> form in UTF-8.
> When matching names you do form insensitive compare (one way
> to do this is nameprep(query) = nameprep(original name), and
> the nameprep(original name) can be cached to avoid doing it
> more than once). If also ACE encoding is used, the DNS server
> do ACE->UTF-8 decode followed by the same compare as above.

Yes, but this implies that nameprep has to be done on the
server, which requires fairly significant changes to servers
that serve out, or might serve out (authoritatively or from a
cache, I think) an IDN name.  If nameprep(original-name) is to
be cached, that requires further changes, changes that I imagine
would reach fairly close to the architecture of the server
designs.  It isn't the processing time that concerns me here
(not to say that might be significant, I just don't know), but
the deployment process.   And, while I haven't worked the cases,
my hunch is that un-upgraded servers might get themselves into
trouble (e.g., risk of matching errors yielding false positives)
if they didn't recognize a name that required special (nameprep)
handling.

> The difference between current matching and a IDN based
> matching is just the matching algorithm (and ACE decode). I
> expect that the IDN matching algorthm can be done good enough
> so that it will not overburden the DNS server.

For a network consisting exclusively of upgraded servers, I
expect you are correct.

   john