Re: [idn] Adding "optional" characters in draft-ietf-idn-nameprep

[Paul Hoffman / IMC <phoffman@imc.org>]

At 3:49 PM -0400 8/13/00, Keith Moore wrote:
>  > >d) we could have IDN servers accept strings with or without Hebrew
>>  >vowels, then return records with the "correct" spelling.
>>
>>  This sounds like a close variation on (a). What is the advantage  of
>>  returning a label that is different than what was requested?
>
>there are limits to what can be done with pre-canonicalization.
>
>with (a) the canonicalization rules for all langauages have to be
>known in advance and defined as part of the spec in order for the
>client to be expected to implement them.    and the client can't
>use any sort of fuzzy matching. because it doesn't know what it's
>matching against.
>
>with (d) the matching rules only have to be known by the server
>that implements such names (the client isn't aware of them at all),
>and the server only has to know the rules for the languages that
>it supports. also, the matching rules don't have to be defined
>as part of the spec.

But with (d), these rules will have to be implemented on all servers 
that are directly superior to an authoritative server that might use 
the letter, which might eventually mean putting it in the root 
servers. The extra processing might be small, but we have to decide 
whether or not we really want it there.

>there are two cases of interest:
>
>1. the client supplies a slightly "mis"-spelled name.  the
>    server realizes that there can be only one name matching this one,
>    so it returns the records for that name to the client.

The same thing happens under (a) or (b) or (c), except that the 
application or resolver (whichever is doing the normalization) does 
the realizing before sending out the correct DNS query.

>2. the server realizes that there are multiple names which might
>    match the one that the client typed in.  so it returns a list.
>    in this case the client has to provide some mechansism that
>    allows the user to choose.

This forces a significant change in the way applications use the DNS 
(including expecting a person to be able to choose by context).  That 
seems pretty extreme for a problem where we have much simpler 
solutions.

--Paul Hoffman, Director
--Internet Mail Consortium